Re: [PATCH 09/13] mfd: omap-usb-host: Add device tree support and binding information

[Roger Quadros]

On 02/05/2013 06:11 PM, Mark Rutland wrote:
 [...]
 
 +
 +- single_ulpi_bypass: Must be present if the controller contains a single
 +  ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1

 Again it would be nicer to have '-' rather than '_' here. It might be worth
 prefixing this ti,.

 Is prefixing with ti really required? how does it better?
 
 I thought single-ulpi-bypass sounded rather generic, but it probably is
 specific enough as-is. I don't know enough about USB hardware to have strong
 feelings either way.
 

Yes, it is specific to the TI silicon. I'll leave it as it is then.

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drivers/gpio: using common order: let 'static const' instead of 'const static'

[Chen Gang]

  'const static ' is not a common order, better to use 'const static' instead.

building:
  make EXTRA_CFLAGS=-W ARCH=arm

  drivers/gpio/gpio-omap.c:1479:
warning: 'static' is not at beginning of declaration
  drivers/gpio/gpio-omap.c:1485:
warning: 'static' is not at beginning of declaration
  drivers/gpio/gpio-omap.c:1491:
warning: 'static' is not at beginning of declaration


Signed-off-by: Chen Gang gang.c...@asianux.com
---
 drivers/gpio/gpio-omap.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f1fbedb2..159f5c5 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1476,19 +1476,19 @@ static struct omap_gpio_reg_offs omap4_gpio_regs = {
.fallingdetect =OMAP4_GPIO_FALLINGDETECT,
 };
 
-const static struct omap_gpio_platform_data omap2_pdata = {
+static const struct omap_gpio_platform_data omap2_pdata = {
.regs = omap2_gpio_regs,
.bank_width = 32,
.dbck_flag = false,
 };
 
-const static struct omap_gpio_platform_data omap3_pdata = {
+static const struct omap_gpio_platform_data omap3_pdata = {
.regs = omap2_gpio_regs,
.bank_width = 32,
.dbck_flag = true,
 };
 
-const static struct omap_gpio_platform_data omap4_pdata = {
+static const struct omap_gpio_platform_data omap4_pdata = {
.regs = omap4_gpio_regs,
.bank_width = 32,
.dbck_flag = true,
-- 
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drivers/gpio: using common order: let 'static const' instead of 'const static'

[Santosh Shilimkar]

On Wednesday 06 February 2013 02:54 PM, Chen Gang wrote:
 
'const static ' is not a common order, better to use 'const static' 
 instead.
You mean   use static const  instead , right ?

 building:
make EXTRA_CFLAGS=-W ARCH=arm
 
drivers/gpio/gpio-omap.c:1479:
  warning: 'static' is not at beginning of declaration
drivers/gpio/gpio-omap.c:1485:
  warning: 'static' is not at beginning of declaration
drivers/gpio/gpio-omap.c:1491:
  warning: 'static' is not at beginning of declaration
 
 
 Signed-off-by: Chen Gang gang.c...@asianux.com
 ---
With change log fixed,

Acked-by: Santosh Shilimkar ,santosh.shilim...@ti.com

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DSS build breakage

[Tomi Valkeinen]

Hi,

On 2013-02-05 23:38, Felipe Balbi wrote:
 Hi Tomi,
 
 DSS doesn't build with allyesconfig:
 
 drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
 drivers/video/omap2/dss/dss.c:572:20: error: 
 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
 drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is 
 reported only once for each function it appears in
 make[4]: *** [drivers/video/omap2/dss/dss.o] Error 1
 
 Found when debugging another problem reported by Arnd.

Thanks for reporting. It looks like omapdrm and omap_vout use select
to enable omapdss, instead of depending on omapdss. This causes omapdss
to be enabled in the config, even if the omapdss Kconfig dependencies
don't allow this.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: how to specify an OMAP clock in device tree?

[Rajendra Nayak]

On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote:

Doesn't look very elegant to me, but I wouldn't mind if there is no better 
option.
Even then, we can't rely on the device name as its index can change based on 
where it is


Well, thats what I said in the first mail, that *if* you are able to
fix the device name, *then* we could use clkdev the way its used in
non-DT case. But then you came back saying 'Fixing the device name
doesn't really solve the problem.' :)


located in the dts file. e.g. in the beginning it may be named phy.8, and if a 
device
node is added before it, it will get changed to phy.9


If you provide a phandle to the PHY node in the board node, for which
you need to add the clk alias, you can always extract the device (using
of_find_device_by_node() ) and hence its name, so it doesn't matter if
its phy.8 or phy.9.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drivers/gpio: using common order: let 'static const' instead of 'const static'

[Chen Gang]

于 2013年02月06日 17:36, Santosh Shilimkar 写道:
 On Wednesday 06 February 2013 02:54 PM, Chen Gang wrote:
  
 'const static ' is not a common order, better to use 'const static' 
  instead.
 You mean   use static const  instead , right ?
 

  oh, yes.  it is my miswritten.

  if necessary to send patch v2, please tell me.

  thanks.

  :-)

-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: how to specify an OMAP clock in device tree?

[Roger Quadros]

On 02/06/2013 12:21 PM, Rajendra Nayak wrote:
 On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote:
 Doesn't look very elegant to me, but I wouldn't mind if there is no better 
 option.
 Even then, we can't rely on the device name as its index can change based on 
 where it is
 
 Well, thats what I said in the first mail, that *if* you are able to
 fix the device name, *then* we could use clkdev the way its used in
 non-DT case. But then you came back saying 'Fixing the device name
 doesn't really solve the problem.' :)

It does, yes, but depending on fixed device names is not so great for DT, is it?
Doesn't solve the problem in the right sense :)

 
 located in the dts file. e.g. in the beginning it may be named phy.8, and if 
 a device
 node is added before it, it will get changed to phy.9
 
 If you provide a phandle to the PHY node in the board node, for which
 you need to add the clk alias, you can always extract the device (using
 of_find_device_by_node() ) and hence its name, so it doesn't matter if
 its phy.8 or phy.9.

Right, I'll come up with something on these lines.

Thanks for the suggestions :).

cheers,
-roger

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drivers/gpio: using common order: let 'static const' instead of 'const static'

[Santosh Shilimkar]

On Wednesday 06 February 2013 04:08 PM, Chen Gang wrote:

于 2013年02月06日 17:36, Santosh Shilimkar 写道:

On Wednesday 06 February 2013 02:54 PM, Chen Gang wrote:


'const static ' is not a common order, better to use 'const static' instead.

You mean   use static const  instead , right ?



   oh, yes.  it is my miswritten.

   if necessary to send patch v2, please tell me.


Please do send updated version.

Regards,
Santosh

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] drivers/gpio: using common order: let 'static const' instead of 'const static'

[Chen Gang]

  'const static ' is not a common order, better to use 'static const' instead.

building:
  make EXTRA_CFLAGS=-W ARCH=arm

  drivers/gpio/gpio-omap.c:1479:
warning: 'static' is not at beginning of declaration
  drivers/gpio/gpio-omap.c:1485:
warning: 'static' is not at beginning of declaration
  drivers/gpio/gpio-omap.c:1491:
warning: 'static' is not at beginning of declaration


Signed-off-by: Chen Gang gang.c...@asianux.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/gpio/gpio-omap.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f1fbedb2..159f5c5 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1476,19 +1476,19 @@ static struct omap_gpio_reg_offs omap4_gpio_regs = {
.fallingdetect =OMAP4_GPIO_FALLINGDETECT,
 };
 
-const static struct omap_gpio_platform_data omap2_pdata = {
+static const struct omap_gpio_platform_data omap2_pdata = {
.regs = omap2_gpio_regs,
.bank_width = 32,
.dbck_flag = false,
 };
 
-const static struct omap_gpio_platform_data omap3_pdata = {
+static const struct omap_gpio_platform_data omap3_pdata = {
.regs = omap2_gpio_regs,
.bank_width = 32,
.dbck_flag = true,
 };
 
-const static struct omap_gpio_platform_data omap4_pdata = {
+static const struct omap_gpio_platform_data omap4_pdata = {
.regs = omap4_gpio_regs,
.bank_width = 32,
.dbck_flag = true,
-- 
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] drivers/gpio: using common order: let 'static const' instead of 'const static'

[Santosh Shilimkar]

On Wednesday 06 February 2013 04:14 PM, Chen Gang wrote:


   'const static ' is not a common order, better to use 'static const' instead.

building:
   make EXTRA_CFLAGS=-W ARCH=arm

   drivers/gpio/gpio-omap.c:1479:
 warning: 'static' is not at beginning of declaration
   drivers/gpio/gpio-omap.c:1485:
 warning: 'static' is not at beginning of declaration
   drivers/gpio/gpio-omap.c:1491:
 warning: 'static' is not at beginning of declaration


Signed-off-by: Chen Gang gang.c...@asianux.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---

Thanks for update.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] ARM: OMAP2: MUSB: Specify omap4 has mailbox

[Russell King - ARM Linux]

On Wed, Feb 06, 2013 at 11:28:11AM +0530, Kishon Vijay Abraham I wrote:
 Added has_mailbox to the musb platform data to specify that omap uses
 an external mailbox (in control module) to communicate with the musb
 core during device connect and disconnect.

So, I've been through your five patches looking for any other users of
has_mailbox and I can find none.  You introduce this in this patch,
and you set it.  But I don't see anything that uses it.

Write only variables are not useful.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] ARM: OMAP2: MUSB: Specify omap4 has mailbox

[Felipe Balbi]

Hi,

On Wed, Feb 06, 2013 at 10:57:13AM +, Russell King - ARM Linux wrote:
 On Wed, Feb 06, 2013 at 11:28:11AM +0530, Kishon Vijay Abraham I wrote:
  Added has_mailbox to the musb platform data to specify that omap uses
  an external mailbox (in control module) to communicate with the musb
  core during device connect and disconnect.
 
 So, I've been through your five patches looking for any other users of
 has_mailbox and I can find none.  You introduce this in this patch,
 and you set it.  But I don't see anything that uses it.
 
 Write only variables are not useful.

looking back at what I sent Greg this was probably my fault. When taking
Kishon's patches (in particular $SUBJECT) I removed some of arch/arm/
code and ended up forgetting to add the include file which introduces
has_mailbox.

This means that my lack of attention has introduced a compile break on
Greg's tree. Oh well, s**t happens. In any case, the user is already in
Greg's tree and there's no way Greg will rebase his tree to amend
$SUBJECT there, so it will have to go separately.

I didn't even notice this before because I had the diff in my tree, just
forgot to git add and/or git reset. Too late now

-- 
balbi


signature.asc
Description: Digital signature

RE: [PATCH v4 5/8] MFD: ti_am335x_tscadc: Add DT support

[Patil, Rachna]

Hi Koen,

 SNIP
Since AM335x is DT only, why is there a platform data codepath and why 
is it the first branch it tries? And I guess the next question is 
related to the first: why doesn't it work when used with DT? When I 
copy over the nodes from the evm.dts to my board I get tsc tsc: 
Missing platform data in dmesg.
   
   This IP came up 1st on AM335x, but it is not platform dependent. The 
   driver can be used on other platforms where-in DT is not supported.
   According to the maintainers platform data takes precedence over DT. 
   Hence the order.
   
  
  Rachana,
  
  I see no point adding support for platform_data when you know that none of 
  older platforms are going to use this driver and all future platforms 
  _must_ follow device-tree model.
  
  So I agree that you should remove board file dependency from the driver.
 
 Ok. I will remove support for platform data in the next version of patches.
 
  
  
   I do not see Missing platform data error msg in the latest driver. I am 
   not able to trace from where this got populated.
   
  
  Can you share the branch which you have tested?
 
 https://github.com/patilrachna/linux/tree/v3.8_rc3_MFD_TSCADC_DT-v2

Did you get a chance to test this branch?
And can you also share your branch, on which you observed the issue.

Regards,
Rachna

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] ARM: OMAP2: MUSB: Specify omap4 has mailbox

[Felipe Balbi]

Hi again,

On Wed, Feb 06, 2013 at 01:03:55PM +0200, Felipe Balbi wrote:
 Hi,
 
 On Wed, Feb 06, 2013 at 10:57:13AM +, Russell King - ARM Linux wrote:
  On Wed, Feb 06, 2013 at 11:28:11AM +0530, Kishon Vijay Abraham I wrote:
   Added has_mailbox to the musb platform data to specify that omap uses
   an external mailbox (in control module) to communicate with the musb
   core during device connect and disconnect.
  
  So, I've been through your five patches looking for any other users of
  has_mailbox and I can find none.  You introduce this in this patch,
  and you set it.  But I don't see anything that uses it.
  
  Write only variables are not useful.
 
 looking back at what I sent Greg this was probably my fault. When taking
 Kishon's patches (in particular $SUBJECT) I removed some of arch/arm/
 code and ended up forgetting to add the include file which introduces
 has_mailbox.
 
 This means that my lack of attention has introduced a compile break on
 Greg's tree. Oh well, s**t happens. In any case, the user is already in
 Greg's tree and there's no way Greg will rebase his tree to amend
 $SUBJECT there, so it will have to go separately.
 
 I didn't even notice this before because I had the diff in my tree, just
 forgot to git add and/or git reset. Too late now

there's a little more to it. When running allmodconfig,
CONFIG_ARCH_MULTIPLATFORM is set but none of the other ARCHes
(ARCH_OMAP, ARCH_AT91, ARCH_VERSATILE, etc) are set, so it turned out
that the driver wasn't even included on my build test.

Russell, is this expected (the MULTIPLATFORM thing) ? Just so I fix my
build test scripts to use another defconfig instead of allmod and
allyes.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Bad divider used for sysclk for DSS and ABE (CM_ABE_DSS_SYS_CLKSEL)

[Tomi Valkeinen]

Hi Paul,

OMAP4 TRM has a mention in CM_ABE_DSS_SYS_CLKSEL's description:

Select SYS_CLK divided by 2. Must be used for
SYS_CLK  26 MHz

This doesn't seem to be enforced with the current kernel. OMAP4 blaze
has 38.4MHz sys clk, but above mentioned divider is 1.

I made a quick test with omapdss, so that omapdss sets the divider to 2
when initializing. Everything seemed to work fine, although everything
has been working fine with the divider 1 also. But I think it'd be wise
to adhere to the TRM.

Is this something that the bootloader should setup, or should kernel do
it (also)?

 Tomi



signature.asc
Description: OpenPGP digital signature

RE: [PATCH 1/4] arch: arm: gpmc: gpmc migration support

[Philip, Avinash]

On Sat, Feb 02, 2013 at 03:35:10, Tony Lindgren wrote:
 * Philip Avinash avinashphi...@ti.com [130123 01:28]:
  With recent GPMC driver conversion, usage of gpmc_save/restore_context
  can done from gpmc driver itself. Hence removes the usage from pm34xx.c.
  Also removes the conditional compilation primitives ARCH_OMAP3 for
  gpmc_save/restore_context.
 
 Hmm I think this will break GPMC for deeper idle modes. Note that we
 need to save and restore the context every time hitting off-idle, not
 just for suspend and resume. Or am I missing something here?

I understand dependency on idle modes. So I will send a second version
with this patch eliminated so that user initiated suspend/resume work
for am335x platforms.

Thanks
Avinash

 
 Regards,
 
 Tony
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] ARM: OMAP2: MUSB: Specify omap4 has mailbox

[Russell King - ARM Linux]

On Wed, Feb 06, 2013 at 01:22:31PM +0200, Felipe Balbi wrote:
 there's a little more to it. When running allmodconfig,
 CONFIG_ARCH_MULTIPLATFORM is set but none of the other ARCHes
 (ARCH_OMAP, ARCH_AT91, ARCH_VERSATILE, etc) are set, so it turned out
 that the driver wasn't even included on my build test.
 
 Russell, is this expected (the MULTIPLATFORM thing) ? Just so I fix my
 build test scripts to use another defconfig instead of allmod and
 allyes.

Don't know.  Most of that logic is sitting in arm-soc.  Nothing obvious
stands out as to why that's happening.

The first thing to check is which of the CONFIG_ARCH_MULTI_* options are
set.  It should be ARCH_MULTI_V7 and ARCH_MULTI_V6_V7.  This should then
allow ARCH_OMAP2PLUS to be set.

However, I've said this before, and I'll say it again: if you want to use
the all* targets, it's better to seed the configuration so that you end
up with the platform you're targetting selected.  I've always done this
with the build system, and even before it when I've wanted to use the all*
targets, because generally I want that behaviour, but I want it for a
particular platform.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB regression in linux next at least for pandboard

[Vivek Gautam]

Hi Tony,


On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren t...@atomide.com wrote:
 * Tony Lindgren t...@atomide.com [121004 18:41]:
 
   Also on the EHCI port, I've seen issues where unplugging
   the cable hangs kernel with an infinite loop. But that happens
   only occasionally, sorry does not seem to happen right
   now so no output to paste here. Or maybe this issue
   has already been fixed?

 Looks like the system eventually recovers from the EHCI issue
 after about fivew minutes or so of spamming the logs. It seems
 the ehci-omap errors are:

 [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31
 [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes
 [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule

 More data below.


Is this issue fixed ?
Actually we too are getting very similar issue with samsung exynos5250 hardware.
With latest 'usb-next' kernel and supporting arch patches, when i use
following test scenerio:
Connect a USB 2.0 external hub to USB 2.0 port, and connect mice or
keyboard enumeration and
functionality is fine but once disconnecting the HID we get to see the
error log:
hid-generic 0003:04B3:3025.0002: can't reset device,
s5p-ehci-1.3/input0, status -71

When i tried to enable CONFIG_USB_DEBUG, get the following log:

hub 1-1:1.0: state 7 ports 7 chg  evt 0008
hub 1-1:1.0: port 3, status 0301, change 0001, 1.5 Mb/s
hub 1-1:1.0: debounce: port 3: total 100ms stable 100ms status 0x301
usb 1-1.3: new low-speed USB device number 5 using s5p-ehci
usb 1-1.3: skipped 1 descriptor after interface
usb 1-1.3: default language 0x0409
usb 1-1.3: udev 5, busnum 1, minor = 4
usb 1-1.3: New USB device found, idVendor=04b3, idProduct=3025
usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.3: Product: USB NetVista Full Width Keyboard
usb 1-1.3: Manufacturer: CHICONY
usb 1-1.3: usb_probe_device
usb 1-1.3: configuration #1 chosen from 1 choice
usb 1-1.3: adding 1-1.3:1.0 (config #1, interface 0)
usbhid 1-1.3:1.0: usb_probe_interface
usbhid 1-1.3:1.0: usb_probe_interface - got id
input: CHICONY USB NetVista Full Width Keyboard as
/devices/s5p-ehci/usb1/1-1/1-1.3/1-1.3:1.0/input/input1
usb 1-1.3: link qh8-0e01/c193f140 start 2 [1/2 us]
hid-generic 0003:04B3:3025.0002: input: USB HID v1.10 Keyboard
[CHICONY USB NetVista Full Width Keyboard] on usb-s5p-ehci-1.3/input0
hub 1-1:1.0: state 7 ports 7 chg  evt 0008

s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 1
usb 1-1.3: unlink qh8-0e01/c193f140 start 2 [1/2 us]
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 1
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 2
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 3
hub 1-1:1.0: state 7 ports 7 chg  evt 0008
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 4
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 5
hub 1-1:1.0: port 3, status 0100, change 0001, 12 Mb/s
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 6
usb 1-1.3: USB disconnect, device number 5
usb 1-1.3: unregistering device
usb 1-1.3: unregistering interface 1-1.3:1.0
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 7
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 8
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 9
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 10
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 11
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 12
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 13
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 14
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 15
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 16
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 17
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 18
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 19
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 20
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 21
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 22
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 23
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 24
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 25
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 26
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 27
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 28
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 29
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 30
s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 31
s5p-ehci s5p-ehci: devpath 1.3 ep0out 3strikes
usb 1-1: clear tt buffer port 3, a5 ep0 t00080248
hid-generic 0003:04B3:3025.0002: can't reset device,
s5p-ehci-1.3/input0, status -71

Similar log as you get on ehci-omap ;-)
Sorry i might have missed some information to put here.

Your help will be very much useful.
Thanks in advance :-)

 ...
 [62927.200012] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 19
 [62927.215606] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 25
 [62927.220092] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 22
 [62927.225738] ehci-omap ehci-omap.0: 

Re: [PATCH 0/3] omap_hsmmc DT DMA Client support

[Lars Poeschel]

Hi Matt!

At first thanks for you efforts on DMA Engine on AM33XX.

On Friday 01 February 2013 at 22:01:17, Matt Porter wrote:
 This series adds DT DMA Engine Client support to the omap_hsmmc.
 It leverages the generic DMA OF helpers in -next and the
 dma_request_slave_channel_compat() wrapper introduced in the
 AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms
 booting via DT. These platforms include omap2/3/4/5 and am33xx.
 
 These patches were split out from the v5 version of the AM33XX DMA
 series and split from the EDMA-specific omap_hsmmc changes.
 
 The series depends on the following patches:
 
   - dmaengine DT support and edma dmaengine driver fix from
 the git://git.infradead.org/users/vkoul/slave-dma.git next
 branch
   - dma_request_slave_channel_compat() support
 https://patchwork.kernel.org/patch/2081671/
 
 The series with all dependencies can be found at
 https://github.com/ohporter/linux/tree/omap-hsmmc-dt-dmaengine-v1

I cloned your github repository and did short testing with it. I get the 
following error when the kernel mounts my sd-card:

Starting udev
[5.884738] udevd[72]: starting version 182
[8.879651] edma-dma-engine edma-dma-engine.0: Exceeded max SG segments 33 
 16
[8.887377] omap_hsmmc mmc.3: prep_slave_sg() failed
[8.892588] omap_hsmmc mmc.3: MMC start dma failure
[8.897725] mmcblk0: unknown error -1 sending read/write command, card 
status 0x900
[8.905889] end_request: I/O error, dev mmcblk0, sector 17039
[8.911926] end_request: I/O error, dev mmcblk0, sector 17047
[8.917934] end_request: I/O error, dev mmcblk0, sector 17055
[8.923960] end_request: I/O error, dev mmcblk0, sector 17063
[8.929967] end_request: I/O error, dev mmcblk0, sector 17071
[8.935988] end_request: I/O error, dev mmcblk0, sector 17079
[8.942010] end_request: I/O error, dev mmcblk0, sector 17087
[8.948016] end_request: I/O error, dev mmcblk0, sector 17095
[8.954037] end_request: I/O error, dev mmcblk0, sector 17103
[8.960043] end_request: I/O error, dev mmcblk0, sector 17111
[9.020919] EXT4-fs error (device mmcblk0p2): __ext4_get_inode_loc:3764: 
inode #8: block 239: comm mount: unable to read itable block
[9.033514] EXT4-fs (mmcblk0p2): no journal found
[9.043799] kjournald starting.  Commit interval 5 seconds
[9.049589] EXT3-fs (mmcblk0p2): warning: mounting fs with errors, running 
e2fsck is recommended
[9.060940] EXT3-fs (mmcblk0p2): using internal journal
[9.066437] EXT3-fs (mmcblk0p2): recovery complete
[9.071460] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode

After that the filesystem on the sd-card has an error that I have to fix with 
e2fsck. As rootfs I use a nfsroot.
In my quick tests, same setup, I don't get any error on edma-dmaengine-
am33xx-v5 branch of your repository.
If you need any further information, let me now.

Regards,
Lars
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] ARM: OMAP: devices: create device for usb part of control module

[Sergei Shtylyov]

Hello.

On 06-02-2013 9:58, Kishon Vijay Abraham I wrote:


A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.



Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
  arch/arm/mach-omap2/devices.c |   45 +
  1 file changed, 45 insertions(+)



diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 626f3ea..6cda103 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@

[...]

@@ -254,6 +255,49 @@ static inline void omap_init_camera(void)

[...]

+static struct platform_device omap4_control_usb = {
+   .name   = omap-control-usb,
+   .id = -1,
+   .dev = {
+   .platform_data = omap4_control_usb_pdata,
+   },
+   .num_resources = 2,
+   .resource = omap4_control_usb_res,


   Either align = or not, not both at once.


+};


WBR, Sergei

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] omap_hsmmc DT DMA Client support

[Matt Porter]

On Wed, Feb 06, 2013 at 01:41:06PM +0100, Lars Poeschel wrote:
 Hi Matt!
 
 At first thanks for you efforts on DMA Engine on AM33XX.
 
 On Friday 01 February 2013 at 22:01:17, Matt Porter wrote:
  This series adds DT DMA Engine Client support to the omap_hsmmc.
  It leverages the generic DMA OF helpers in -next and the
  dma_request_slave_channel_compat() wrapper introduced in the
  AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms
  booting via DT. These platforms include omap2/3/4/5 and am33xx.
  
  These patches were split out from the v5 version of the AM33XX DMA
  series and split from the EDMA-specific omap_hsmmc changes.
  
  The series depends on the following patches:
  
  - dmaengine DT support and edma dmaengine driver fix from
the git://git.infradead.org/users/vkoul/slave-dma.git next
branch
  - dma_request_slave_channel_compat() support
https://patchwork.kernel.org/patch/2081671/
  
  The series with all dependencies can be found at
  https://github.com/ohporter/linux/tree/omap-hsmmc-dt-dmaengine-v1
 
 I cloned your github repository and did short testing with it. I get the 
 following error when the kernel mounts my sd-card:
 
 Starting udev
 [5.884738] udevd[72]: starting version 182
 [8.879651] edma-dma-engine edma-dma-engine.0: Exceeded max SG segments 33 

Hi Lars,

I left it somewhat ambiguous as to what this series claims to support,
sorry about that. This series, by itself, supports only platforms using
SDMA (omap 2/3/4/5 assuming you add the appropriate DMA dts bits). This
is only part of what am33xx requires for working mmc support. I've also
posted v3 of dmaengine slave sg caps series at
https://lkml.org/lkml/2013/2/4/561

I have to rebase the am33xx specific bits for omap_hsmmc on top of that
and post. That was previously all contained in one series but I didn't
want to block omap2/3/4/5 from working DMA on DT support until the api
change is resolved for am33xx.

-Matt

 [8.887377] omap_hsmmc mmc.3: prep_slave_sg() failed
 [8.892588] omap_hsmmc mmc.3: MMC start dma failure
 [8.897725] mmcblk0: unknown error -1 sending read/write command, card 
 status 0x900
 [8.905889] end_request: I/O error, dev mmcblk0, sector 17039
 [8.911926] end_request: I/O error, dev mmcblk0, sector 17047
 [8.917934] end_request: I/O error, dev mmcblk0, sector 17055
 [8.923960] end_request: I/O error, dev mmcblk0, sector 17063
 [8.929967] end_request: I/O error, dev mmcblk0, sector 17071
 [8.935988] end_request: I/O error, dev mmcblk0, sector 17079
 [8.942010] end_request: I/O error, dev mmcblk0, sector 17087
 [8.948016] end_request: I/O error, dev mmcblk0, sector 17095
 [8.954037] end_request: I/O error, dev mmcblk0, sector 17103
 [8.960043] end_request: I/O error, dev mmcblk0, sector 17111
 [9.020919] EXT4-fs error (device mmcblk0p2): __ext4_get_inode_loc:3764: 
 inode #8: block 239: comm mount: unable to read itable block
 [9.033514] EXT4-fs (mmcblk0p2): no journal found
 [9.043799] kjournald starting.  Commit interval 5 seconds
 [9.049589] EXT3-fs (mmcblk0p2): warning: mounting fs with errors, running 
 e2fsck is recommended
 [9.060940] EXT3-fs (mmcblk0p2): using internal journal
 [9.066437] EXT3-fs (mmcblk0p2): recovery complete
 [9.071460] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode
 
 After that the filesystem on the sd-card has an error that I have to fix with 
 e2fsck. As rootfs I use a nfsroot.
 In my quick tests, same setup, I don't get any error on edma-dmaengine-
 am33xx-v5 branch of your repository.
 If you need any further information, let me now.
 
 Regards,
 Lars
 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/5] ARM: OMAP4: remove control module address space from PHY and OTG

[Kishon Vijay Abraham I]

Now that we have a separate driver for the control module,
stop populating the control module device data in other modules
(PHY and OTG) device info.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   13 -
 1 file changed, 13 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 793f54a..624a7e8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2702,13 +2702,6 @@ static struct resource omap44xx_usb_phy_and_pll_addrs[] 
= {
.end= 0x4a0ae000,
.flags  = IORESOURCE_MEM,
},
-   {
-   /* XXX: Remove this once control module driver is in place */
-   .name   = ctrl_dev,
-   .start  = 0x4a002300,
-   .end= 0x4a002303,
-   .flags  = IORESOURCE_MEM,
-   },
{ }
 };
 
@@ -6156,12 +6149,6 @@ static struct omap_hwmod_addr_space 
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab7ff,
.flags  = ADDR_TYPE_RT
},
-   {
-   /* XXX: Remove this once control module driver is in place */
-   .pa_start   = 0x4a00233c,
-   .pa_end = 0x4a00233f,
-   .flags  = ADDR_TYPE_RT
-   },
{ }
 };
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/5] usb: omap_control_usb: fix compile warning

[Kishon Vijay Abraham I]

From: Felipe Balbi ba...@ti.com

When CONFIG_OMAP_CONTROL_USB isn't enabled,
there's a compile warning stating that a
particular function isn't a prototype.

Fix it.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 include/linux/usb/omap_control_usb.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/usb/omap_control_usb.h 
b/include/linux/usb/omap_control_usb.h
index f306db7..27b5b8c 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -70,7 +70,7 @@ extern void omap_control_usb3_phy_power(struct device *dev, 
bool on);
 extern void omap_control_usb_set_mode(struct device *dev,
enum omap_control_usb_mode mode);
 #else
-static inline struct device *omap_get_control_dev()
+static inline struct device *omap_get_control_dev(void)
 {
return ERR_PTR(-ENODEV);
 }
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/5] ARM: OMAP: devices: create device for usb part of control module

[Kishon Vijay Abraham I]

A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/devices.c |   45 +
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 626f3ea..6cda103 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@
 #include linux/pinctrl/machine.h
 #include linux/platform_data/omap4-keypad.h
 #include linux/platform_data/omap_ocp2scp.h
+#include linux/usb/omap_control_usb.h
 
 #include asm/mach-types.h
 #include asm/mach/map.h
@@ -254,6 +255,49 @@ static inline void omap_init_camera(void)
 #endif
 }
 
+#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
+static struct omap_control_usb_platform_data omap4_control_usb_pdata = {
+   .type = 1,
+};
+
+struct resource omap4_control_usb_res[] = {
+   {
+   .name   = control_dev_conf,
+   .start  = 0x4a002300,
+   .end= 0x4a002303,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .name   = otghs_control,
+   .start  = 0x4a00233c,
+   .end= 0x4a00233f,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device omap4_control_usb = {
+   .name = omap-control-usb,
+   .id = -1,
+   .dev = {
+   .platform_data = omap4_control_usb_pdata,
+   },
+   .num_resources = 2,
+   .resource = omap4_control_usb_res,
+};
+
+static inline void __init omap_init_control_usb(void)
+{
+   if (!cpu_is_omap44xx())
+   return;
+
+   if (platform_device_register(omap4_control_usb))
+   pr_err(Error registering omap_control_usb device\n);
+}
+
+#else
+static inline void omap_init_control_usb(void) { }
+#endif /* CONFIG_OMAP_CONTROL_USB */
+
 int __init omap4_keyboard_init(struct omap4_keypad_platform_data
*sdp4430_keypad_data, struct omap_board_data *bdata)
 {
@@ -721,6 +765,7 @@ static int __init omap2_init_devices(void)
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
+   omap_init_control_usb();
omap_init_dmic();
omap_init_mcpdm();
omap_init_mcspi();
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/5] ARM: OMAP2: MUSB: Specify omap4 has mailbox

[Kishon Vijay Abraham I]

Added has_mailbox to the musb platform data to specify that omap uses
an external mailbox (in control module) to communicate with the musb
core during device connect and disconnect.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/usb-musb.c |3 +++
 include/linux/usb/musb.h   |2 ++
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 7b33b37..9d27e3f 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data 
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
 
+   if (cpu_is_omap44xx())
+   musb_plat.has_mailbox = true;
+
if (soc_is_am35xx()) {
oh_name = am35x_otg_hs;
name = musb-am35x;
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..053c268 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,6 +99,8 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8  mode;
 
+   u8  has_mailbox:1;
+
/* for clk_get() */
const char  *clock;
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/5] ARM: OMAP: USB: Add phy binding information

[Kishon Vijay Abraham I]

This is w.r.t the changes in PHY library to support adding and getting
multiple PHYs of the same type. In the new design, the
binding information between the PHY and the USB controller should be
specified in the platform specific initialization code. So it's been
done here for OMAP platforms.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-2430sdp.c  |2 ++
 arch/arm/mach-omap2/board-3430sdp.c  |2 ++
 arch/arm/mach-omap2/board-4430sdp.c  |2 ++
 arch/arm/mach-omap2/board-cm-t35.c   |2 ++
 arch/arm/mach-omap2/board-devkit8000.c   |2 ++
 arch/arm/mach-omap2/board-igep0020.c |2 ++
 arch/arm/mach-omap2/board-ldp.c  |2 ++
 arch/arm/mach-omap2/board-omap3beagle.c  |2 ++
 arch/arm/mach-omap2/board-omap3evm.c |2 ++
 arch/arm/mach-omap2/board-omap3logic.c   |2 ++
 arch/arm/mach-omap2/board-omap3pandora.c |2 ++
 arch/arm/mach-omap2/board-omap3stalker.c |2 ++
 arch/arm/mach-omap2/board-omap3touchbook.c   |2 ++
 arch/arm/mach-omap2/board-omap4panda.c   |2 ++
 arch/arm/mach-omap2/board-overo.c|2 ++
 arch/arm/mach-omap2/board-rm680.c|2 ++
 arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++
 17 files changed, 34 insertions(+)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 4815ea6..1337f2c 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -27,6 +27,7 @@
 #include linux/clk.h
 #include linux/io.h
 #include linux/gpio.h
+#include linux/usb/phy.h
 
 #include asm/mach-types.h
 #include asm/mach/arch.h
@@ -263,6 +264,7 @@ static void __init omap_2430sdp_init(void)
omap_hsmmc_init(mmc);
 
omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA | OMAP_PULL_UP);
+   usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
 
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index bb73afc..8a2e242 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -25,6 +25,7 @@
 #include linux/gpio.h
 #include linux/mmc/host.h
 #include linux/platform_data/spi-omap2-mcspi.h
+#include linux/usb/phy.h
 
 #include asm/mach-types.h
 #include asm/mach/arch.h
@@ -579,6 +580,7 @@ static void __init omap_3430sdp_init(void)
omap_ads7846_init(1, gpio_pendown, 310, NULL);
omap_serial_init();
omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL);
+   usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 1cc6696..8e8efcc 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -28,6 +28,7 @@
 #include linux/leds_pwm.h
 #include linux/platform_data/omap4-keypad.h
 #include linux/usb/musb.h
+#include linux/usb/phy.h
 
 #include asm/hardware/gic.h
 #include asm/mach-types.h
@@ -696,6 +697,7 @@ static void __init omap_4430sdp_init(void)
omap4_sdp4430_wifi_init();
omap4_twl6030_hsmmc_init(mmc);
 
+   usb_bind_phy(musb-hdrc.0.auto, 0, omap-usb2.1.auto);
usb_musb_init(musb_board_data);
 
status = omap_ethernet_init();
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index b3102c2..f1172f2 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -30,6 +30,7 @@
 #include linux/regulator/fixed.h
 #include linux/regulator/machine.h
 #include linux/mmc/host.h
+#include linux/usb/phy.h
 
 #include linux/spi/spi.h
 #include linux/spi/tdo24m.h
@@ -724,6 +725,7 @@ static void __init cm_t3x_common_init(void)
cm_t35_init_display();
omap_twl4030_audio_init(cm-t3x);
 
+   usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
cm_t35_init_usbh();
cm_t35_init_camera();
diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index 12865af..77cade52 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -29,6 +29,7 @@
 #include linux/mtd/partitions.h
 #include linux/mtd/nand.h
 #include linux/mmc/host.h
+#include linux/usb/phy.h
 
 #include linux/regulator/machine.h
 #include linux/i2c/twl.h
@@ -622,6 +623,7 @@ static void __init devkit8000_init(void)
 
omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL);
 
+   usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
board_nand_init(devkit8000_nand_partitions,
diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 0f24cb8..15e5881 

Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Benoit Cousson]

Salut Florian,

On 02/04/2013 10:14 AM, Florian Vaussard wrote:
 Hello Benoit,
 
 On 01/24/2013 01:21 PM, Benoit Cousson wrote:
 + Peter who did the original PWM

 Hi Florian,

 On 01/23/2013 06:56 PM, Florian Vaussard wrote:
 Hello Benoit,

 This patchset adds some new DT supports to the Overo products. The
 first patch converts the PMIC LEDB output to use the pwm-leds,
 newly merged in your branch for_3.9/dts. The second patch adds the
 audio support.

 Excellent, that looks very good to me, but I'd like to get the
 feedback from Peter before merging it.

 
 So a patch is being merged to handle triggers in the case of pwm leds [1].
 When done, we will be able to add back the default trigger. Do you want
 to wait on it to merge this series?

What kind of dependency do we have between these two series? I mean what
will happen if the DTS is merged before the pwm subsystem?

If that does not generate any regression / crash, then it is OK, if not,
we should take care of the order.

Thanks,
Benoit

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] omap_hsmmc DT DMA Client support

[Arnd Bergmann]

On Friday 01 February 2013, Matt Porter wrote:
 
 This series adds DT DMA Engine Client support to the omap_hsmmc.
 It leverages the generic DMA OF helpers in -next and the
 dma_request_slave_channel_compat() wrapper introduced in the
 AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms
 booting via DT. These platforms include omap2/3/4/5 and am33xx.
 
 These patches were split out from the v5 version of the AM33XX DMA
 series and split from the EDMA-specific omap_hsmmc changes.
 
 The series depends on the following patches:
 
 - dmaengine DT support and edma dmaengine driver fix from
   the git://git.infradead.org/users/vkoul/slave-dma.git next
   branch
 - dma_request_slave_channel_compat() support
   https://patchwork.kernel.org/patch/2081671/
 
 The series with all dependencies can be found at
 https://github.com/ohporter/linux/tree/omap-hsmmc-dt-dmaengine-v1

Nice series,

Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB regression in linux next at least for pandboard

[Felipe Balbi]

Hi,

On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote:
 Hi Tony,
 
 
 On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren t...@atomide.com wrote:
  * Tony Lindgren t...@atomide.com [121004 18:41]:
  
Also on the EHCI port, I've seen issues where unplugging
the cable hangs kernel with an infinite loop. But that happens
only occasionally, sorry does not seem to happen right
now so no output to paste here. Or maybe this issue
has already been fixed?
 
  Looks like the system eventually recovers from the EHCI issue
  after about fivew minutes or so of spamming the logs. It seems
  the ehci-omap errors are:
 
  [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31
  [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes
  [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule
 
  More data below.
 
 
 Is this issue fixed ?
 Actually we too are getting very similar issue with samsung exynos5250 
 hardware.
 With latest 'usb-next' kernel and supporting arch patches, when i use
 following test scenerio:
 Connect a USB 2.0 external hub to USB 2.0 port, and connect mice or
 keyboard enumeration and
 functionality is fine but once disconnecting the HID we get to see the
 error log:
 hid-generic 0003:04B3:3025.0002: can't reset device,
 s5p-ehci-1.3/input0, status -71
 
 When i tried to enable CONFIG_USB_DEBUG, get the following log:

looks like it's not OMAP-specific. Alan any tips ?

(keeping logs below)

 hub 1-1:1.0: state 7 ports 7 chg  evt 0008
 hub 1-1:1.0: port 3, status 0301, change 0001, 1.5 Mb/s
 hub 1-1:1.0: debounce: port 3: total 100ms stable 100ms status 0x301
 usb 1-1.3: new low-speed USB device number 5 using s5p-ehci
 usb 1-1.3: skipped 1 descriptor after interface
 usb 1-1.3: default language 0x0409
 usb 1-1.3: udev 5, busnum 1, minor = 4
 usb 1-1.3: New USB device found, idVendor=04b3, idProduct=3025
 usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
 usb 1-1.3: Product: USB NetVista Full Width Keyboard
 usb 1-1.3: Manufacturer: CHICONY
 usb 1-1.3: usb_probe_device
 usb 1-1.3: configuration #1 chosen from 1 choice
 usb 1-1.3: adding 1-1.3:1.0 (config #1, interface 0)
 usbhid 1-1.3:1.0: usb_probe_interface
 usbhid 1-1.3:1.0: usb_probe_interface - got id
 input: CHICONY USB NetVista Full Width Keyboard as
 /devices/s5p-ehci/usb1/1-1/1-1.3/1-1.3:1.0/input/input1
 usb 1-1.3: link qh8-0e01/c193f140 start 2 [1/2 us]
 hid-generic 0003:04B3:3025.0002: input: USB HID v1.10 Keyboard
 [CHICONY USB NetVista Full Width Keyboard] on usb-s5p-ehci-1.3/input0
 hub 1-1:1.0: state 7 ports 7 chg  evt 0008
 
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 1
 usb 1-1.3: unlink qh8-0e01/c193f140 start 2 [1/2 us]
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 1
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 2
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 3
 hub 1-1:1.0: state 7 ports 7 chg  evt 0008
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 4
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 5
 hub 1-1:1.0: port 3, status 0100, change 0001, 12 Mb/s
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 6
 usb 1-1.3: USB disconnect, device number 5
 usb 1-1.3: unregistering device
 usb 1-1.3: unregistering interface 1-1.3:1.0
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 7
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 8
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 9
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 10
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 11
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 12
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 13
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 14
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 15
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 16
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 17
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 18
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 19
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 20
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 21
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 22
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 23
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 24
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 25
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 26
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 27
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 28
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 29
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 30
 s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 31
 s5p-ehci s5p-ehci: devpath 1.3 ep0out 3strikes
 usb 1-1: clear tt buffer port 3, a5 ep0 t00080248
 hid-generic 0003:04B3:3025.0002: can't reset device,
 s5p-ehci-1.3/input0, status -71
 
 Similar log as you get on ehci-omap ;-)
 Sorry i might have missed some information to put here.
 
 Your help will be very much useful.
 Thanks in advance :-)
 
  ...
  

[PATCH] ARM: OMAP: Clear GPMC bits when applying new setting

[Mark Jackson]

When setting the GPMC device type, make sure any previous
bits are cleared down, before applying the new setting.

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 arch/arm/mach-omap2/gpmc.c |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1adb2d4..026e786 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -613,6 +613,10 @@ int gpmc_cs_configure(int cs, int cmd, int wval)

case GPMC_CONFIG_DEV_TYPE:
regval  = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+   /* clear 3 target bits */
+   regval = ~(GPMC_CONFIG1_DEVICETYPE(3) |
+   GPMC_CONFIG1_MUXADDDATA);
+   /* set the proper value */
regval |= GPMC_CONFIG1_DEVICETYPE(wval);
if (wval == GPMC_DEVICETYPE_NOR)
regval |= GPMC_CONFIG1_MUXADDDATA;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP: Clear GPMC bits when applying new setting

[Felipe Balbi]

On Wed, Feb 06, 2013 at 02:15:34PM +, Mark Jackson wrote:
 When setting the GPMC device type, make sure any previous
 bits are cleared down, before applying the new setting.
 
 Signed-off-by: Mark Jackson m...@newflow.co.uk

looks alright:

Reviewed-of-by: Felipe Balbi ba...@ti.com

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Philippe Rétornaz]

Hi all !

Le 06/02/2013 14:30, Benoit Cousson a écrit :

Salut Florian,

On 02/04/2013 10:14 AM, Florian Vaussard wrote:

Hello Benoit,

On 01/24/2013 01:21 PM, Benoit Cousson wrote:

+ Peter who did the original PWM

Hi Florian,

On 01/23/2013 06:56 PM, Florian Vaussard wrote:

Hello Benoit,

This patchset adds some new DT supports to the Overo products.
The first patch converts the PMIC LEDB output to use the
pwm-leds, newly merged in your branch for_3.9/dts. The second
patch adds the audio support.


Excellent, that looks very good to me, but I'd like to get the
feedback from Peter before merging it.



So a patch is being merged to handle triggers in the case of pwm
leds [1]. When done, we will be able to add back the default
trigger. Do you want to wait on it to merge this series?


What kind of dependency do we have between these two series? I mean
what will happen if the DTS is merged before the pwm subsystem?

If that does not generate any regression / crash, then it is OK, if
not, we should take care of the order.


Florian is on holiday the next two weeks.

AFAIK if the PWM/leds subsystem patches are not merged before this one
then the kernel will panic if a trigger is used to change the led status.

Regards,

Philippe
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] mmc: omap_hsmmc: MAINTAINERS: update

[Balaji T K]

Update Maintainer email for omap_hsmmc,
as Venkatraman will no longer be able to maintain omap_hsmmc driver.

Signed-off-by: Balaji T K balaj...@ti.com
Acked-by: Venkatraman S svenk...@gmail.com
---
 MAINTAINERS |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 92e726c..f319237 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5498,7 +5498,7 @@ S:Maintained
 F: drivers/mmc/host/omap.c
 
 OMAP HS MMC SUPPORT
-M: Venkatraman S svenk...@ti.com
+M: Balaji T K balaj...@ti.com
 L: linux-...@vger.kernel.org
 L: linux-omap@vger.kernel.org
 S: Maintained
-- 
1.7.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP: Clear GPMC bits when applying new setting

[Jon Hunter]

On 02/06/2013 08:15 AM, Mark Jackson wrote:
 When setting the GPMC device type, make sure any previous
 bits are cleared down, before applying the new setting.
 
 Signed-off-by: Mark Jackson m...@newflow.co.uk
 ---
  arch/arm/mach-omap2/gpmc.c |4 
  1 file changed, 4 insertions(+)
 
 diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
 index 1adb2d4..026e786 100644
 --- a/arch/arm/mach-omap2/gpmc.c
 +++ b/arch/arm/mach-omap2/gpmc.c
 @@ -613,6 +613,10 @@ int gpmc_cs_configure(int cs, int cmd, int wval)
 
   case GPMC_CONFIG_DEV_TYPE:
   regval  = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
 + /* clear 3 target bits */
 + regval = ~(GPMC_CONFIG1_DEVICETYPE(3) |
 + GPMC_CONFIG1_MUXADDDATA);

MUXADDDATA is actually a 2-bit field on current devices (OMAP4+ and
AM335x). For OMAP2/3 devices it was only a one bit field. So it may be
worth clearing both bits for all devices. For OMAP2 devices bit 8 is
reserved but the TRM says to writes a 0, so clearing bit 8 on OMAP2/3
devices should not be a problem. In fact bit 8 should read as 0 on OMAP2/3.

 + /* set the proper value */
   regval |= GPMC_CONFIG1_DEVICETYPE(wval);
   if (wval == GPMC_DEVICETYPE_NOR)
   regval |= GPMC_CONFIG1_MUXADDDATA;
 

Otherwise ...

Acked-by: Jon Hunter jon-hun...@ti.com

Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/8] ARM: dts: omap5: Add ocp2scp data

[Kishon Vijay Abraham I]

Add ocp2scp data node in omap5 device tree file. The information for
the node added here can be found @
Documentation/devicetree/bindings/bus/omap-ocp2scp.txt

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index c937500..230b779 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -504,5 +504,13 @@
reg-names = control_dev_conf, phy_power_usb;
ti,type = 2;
};
+
+   ocp2scp {
+   compatible = ti,omap-ocp2scp;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+   ti,hwmods = ocp2scp1;
+   };
};
 };
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 8/8] ARM: dts: omap5: add dwc3 core dt data

[Kishon Vijay Abraham I]

Add dwc3 core dt data as a subnode to dwc3 omap glue data in omap5 dt
data file. The information for the entered data node is available @
Documentation/devicetree/bindings/usb/dwc3.txt

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index c4eb2ec..24dd69f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -514,6 +514,13 @@
#size-cells = 1;
utmi-mode = 2;
ranges;
+   dwc3@4a03 {
+   compatible = synopsys,dwc3;
+   reg = 0x4a03 0x1000;
+   interrupts = 0 92 4;
+   usb-phy = usb2_phy, usb3_phy;
+   tx-fifo-resize;
+   };
};
 
ocp2scp {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/8] ARM: dts: omap: Add omap control usb data

[Kishon Vijay Abraham I]

Add omap control usb data in omap4 device tree file. This will have the
register address of registers to power on the PHY and to write to
mailbox. The information about this data node is available @
Documentation/devicetree/bindings/usb/omap-usb.txt

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap4.dtsi |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..ffc7352 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,13 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+   omap_control_usb: omap-control-usb@4a002300 {
+   compatible = ti,omap-control-usb;
+   reg = 0x4a002300 0x4,
+ 0x4a00233c 0x4;
+   reg-names = control_dev_conf, otghs_control;
+   ti,type = 1;
+   };
};
 };
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/8] ARM: dts: omap5: add dwc3 omap dt data

[Kishon Vijay Abraham I]

Add dwc3 omap glue data to the omap5 dt data file. The information about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index bd73257..c4eb2ec 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -505,6 +505,17 @@
ti,type = 2;
};
 
+   omap_dwc3@4a02 {
+   compatible = ti,dwc3;
+   ti,hwmods = usb_otg_ss;
+   reg = 0x4a02 0x1000;
+   interrupts = 0 93 4;
+   #address-cells = 1;
+   #size-cells = 1;
+   utmi-mode = 2;
+   ranges;
+   };
+
ocp2scp {
compatible = ti,omap-ocp2scp;
#address-cells = 1;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/8] ARM: dts: omap: Add omap-usb2 dt data

[Kishon Vijay Abraham I]

Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp. The information about this data node is availabe @
Documentation/devicetree/bindings/usb/usb-phy.txt

Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap4.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index ffc7352..c829d7e 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -438,6 +438,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+   usb2_phy: usb2phy@4a0ad080 {
+   compatible = ti,omap-usb2;
+   reg = 0x4a0ad080 0x58;
+   ctrl-module = omap_control_usb;
+   };
};
 
timer1: timer@4a318000 {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/8] ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data

[Kishon Vijay Abraham I]

Add omap-usb3 and omap-usb2 data node in omap5 device tree file.
The information for the node added here is available @
Documentation/devicetree/bindings/usb/usb-phy.txt

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 230b779..bd73257 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -511,6 +511,20 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp1;
+   usb2_phy: usb2phy@4a084000 {
+   compatible = ti,omap-usb2;
+   reg = 0x4a084000 0x7c;
+   ctrl-module = omap_control_usb;
+   };
+
+   usb3_phy: usb3phy@4a084400 {
+   compatible = ti,omap-usb3;
+   reg = 0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40;
+   reg-names = phy_rx, phy_tx, pll_ctrl;
+   ctrl-module = omap_control_usb;
+   };
};
};
 };
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/8] ARM: dts: omap: Add usb_otg and glue data

[Kishon Vijay Abraham I]

Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
The dt data specifies among others the interface type (ULPI or UTMI), mode
which is mostly OTG, power that specifies the amount of power this can supply
when in host mode.
The information about usb otg node is available @
Documentation/devicetree/bindings/usb/omap-usb.txt

Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |1 +
 arch/arm/boot/dts/omap3-beagle-xm.dts  |6 ++
 arch/arm/boot/dts/omap3-evm.dts|6 ++
 arch/arm/boot/dts/omap3-overo.dtsi |6 ++
 arch/arm/boot/dts/omap3.dtsi   |   12 
 arch/arm/boot/dts/omap4-panda.dts  |6 ++
 arch/arm/boot/dts/omap4-sdp.dts|6 ++
 arch/arm/boot/dts/omap4.dtsi   |   13 +
 arch/arm/boot/dts/twl4030.dtsi |2 +-
 9 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB GLUE
represents PERIPHERAL.
  - power : Should be 50. This signifies the controller can supply upto
100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device
 
 SOC specific device node entry
 usb_otg_hs: usb_otg_hs@4a0ab000 {
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..cb07583 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -107,3 +107,9 @@
 */
ti,pulldowns = 0x03a1c4;
 };
+
+usb_otg_hs {
+   interface_type = 0;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..afb9ba9 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -59,3 +59,9 @@
 twl_gpio {
ti,use-leds;
 };
+
+usb_otg_hs {
+   interface_type = 0;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..4b3d157 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -55,3 +55,9 @@
 twl_gpio {
ti,use-leds;
 };
+
+usb_otg_hs {
+   interface_type = 0;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..b6472f7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,17 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+   usb_otg_hs: usb_otg_hs@480ab000 {
+   compatible = ti,omap3-musb;
+   reg = 0x480ab000 0x1000;
+   interrupts = 0 92 0x4, 0 93 0x4;
+   interrupt-names = mc, dma;
+   ti,hwmods = usb_otg_hs;
+   usb-phy = usb2_phy;
+   multipoint = 1;
+   num_eps = 16;
+   ram_bits = 12;
+   };
};
 };
diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..612c9bb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -206,3 +206,9 @@
 twl_usb_comparator {
usb-supply = vusb;
 };
+
+usb_otg_hs {
+   interface_type = 1;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..582d7ee 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -428,3 +428,9 @@
 twl_usb_comparator {
usb-supply = vusb;
 };
+
+usb_otg_hs {
+   interface_type = 1;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index c829d7e..5171739 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -542,5 +542,18 @@
reg-names = control_dev_conf, otghs_control;
ti,type = 1;
};
+
+   usb_otg_hs: usb_otg_hs@4a0ab000 {
+   compatible = ti,omap4-musb;
+   reg = 0x4a0ab000 0x7ff;
+   interrupts = 0 92 0x4, 0 93 0x4;
+   interrupt-names = mc, dma;
+   ti,hwmods = usb_otg_hs;
+   usb-phy = usb2_phy;
+   multipoint = 1;
+   num_eps = 16;
+   ram_bits 

[PATCH 0/8] ARM: dts: omap: Add dts data for USB

[Kishon Vijay Abraham I]

Hi Benoit,

Here are the dt data patches to get usb device functional in OMAP platforms.
This series applies cleanly in both for_3.9/dts and 3.8-rc6.

All the patches deal with modifying arch/arm/boot except one which modifies
Documentation/../usb/omap-usb.txt

Kishon Vijay Abraham I (8):
  ARM: dts: omap: Add omap control usb data
  ARM: dts: omap: Add omap-usb2 dt data
  ARM: dts: omap: Add usb_otg and glue data
  ARM: dts: omap5: Add omap control usb data
  ARM: dts: omap5: Add ocp2scp data
  ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data
  ARM: dts: omap5: add dwc3 omap dt data
  ARM: dts: omap5: add dwc3 core dt data

 Documentation/devicetree/bindings/usb/omap-usb.txt |1 +
 arch/arm/boot/dts/omap3-beagle-xm.dts  |6 +++
 arch/arm/boot/dts/omap3-evm.dts|6 +++
 arch/arm/boot/dts/omap3-overo.dtsi |6 +++
 arch/arm/boot/dts/omap3.dtsi   |   12 +
 arch/arm/boot/dts/omap4-panda.dts  |6 +++
 arch/arm/boot/dts/omap4-sdp.dts|6 +++
 arch/arm/boot/dts/omap4.dtsi   |   26 +++
 arch/arm/boot/dts/omap5.dtsi   |   48 
 arch/arm/boot/dts/twl4030.dtsi |2 +-
 10 files changed, 118 insertions(+), 1 deletion(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/8] ARM: dts: omap5: Add omap control usb data

[Kishon Vijay Abraham I]

Add omap control usb data in omap5 device tree file. This will have the
register address of registers to power on the USB2 PHY and USB3 PHY. The
information for the node added here is available in
Documentation/devicetree/bindings/usb/omap-usb.txt

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..c937500 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -496,5 +496,13 @@
hw-caps-ll-interface;
hw-caps-temp-alert;
};
+
+   omap_control_usb: omap-control-usb@4a002300 {
+   compatible = ti,omap-control-usb;
+   reg = 0x4a002300 0x4,
+ 0x4a002370 0x4;
+   reg-names = control_dev_conf, phy_power_usb;
+   ti,type = 2;
+   };
};
 };
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB regression in linux next at least for pandboard

[Roger Quadros]

On 02/06/2013 03:51 PM, Felipe Balbi wrote:
 Hi,
 
 On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote:
 Hi Tony,


 On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren t...@atomide.com wrote:
 * Tony Lindgren t...@atomide.com [121004 18:41]:

 Also on the EHCI port, I've seen issues where unplugging
 the cable hangs kernel with an infinite loop. But that happens
 only occasionally, sorry does not seem to happen right
 now so no output to paste here. Or maybe this issue
 has already been fixed?

 Looks like the system eventually recovers from the EHCI issue
 after about fivew minutes or so of spamming the logs. It seems
 the ehci-omap errors are:

 [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31
 [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes
 [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule

 More data below.


 Is this issue fixed ?
 Actually we too are getting very similar issue with samsung exynos5250 
 hardware.
 With latest 'usb-next' kernel and supporting arch patches, when i use
 following test scenerio:
 Connect a USB 2.0 external hub to USB 2.0 port, and connect mice or
 keyboard enumeration and
 functionality is fine but once disconnecting the HID we get to see the
 error log:
 hid-generic 0003:04B3:3025.0002: can't reset device,
 s5p-ehci-1.3/input0, status -71

 When i tried to enable CONFIG_USB_DEBUG, get the following log:
 
 looks like it's not OMAP-specific. Alan any tips ?
 

I can't reproduce the problem on Panda, but I can on Beagle with a slightly
different behaviour.

1) connecting/disconnecting device directly to the beagleboard's USB port works 
fine.

2) If I connect a USB Hub to the port and connect a device to it after the hub 
has
autosuspended, the device is never detected.
doing lsusb after that triggers the detection and produces a lot of transaction 
errors.
Beagle log is below, before and after 'lsusb'

I suppose this doesn't affect Panda because it has a hub connected immediately 
below the
root hub that never suspends (as ethernet is hardwired to it).

So there must be some problem in the hub drivers.

cheers,
-roger

root@beagleboard:~# [   62.666595] usb usb1: usb wakeup-resume
[   62.670684] usb usb1: usb auto-resume
[   62.674591] ehci-omap ehci-omap.0: resume root hub
[   62.679687] hub 1-0:1.0: hub_resume
[   62.683471] ehci-omap ehci-omap.0: GetStatus port:2 status 001803 0  ACK 
POWER sig=j CSC CONNECT
[   62.692779] hub 1-0:1.0: port 2: status 0501 change 0001
[   62.772460] hub 1-0:1.0: state 7 ports 3 chg 0004 evt 
[   62.778533] hub 1-0:1.0: port 2, status 0501, change , 480 Mb/s
[   62.849182] ehci-omap ehci-omap.0: port 2 reset complete, port enabled
[   62.856109] ehci-omap ehci-omap.0: GetStatus port:2 status 001005 0  ACK 
POWER sig=se0 PE CONNECT
[   62.929931] usb 1-2: new high-speed USB device number 4 using ehci-omap
[   62.998352] ehci-omap ehci-omap.0: port 2 reset complete, port enabled
[   63.005279] ehci-omap ehci-omap.0: GetStatus port:2 status 001005 0  ACK 
POWER sig=se0 PE CONNECT
[   63.107635] usb 1-2: udev 4, busnum 1, minor = 3
[   63.112548] usb 1-2: New USB device found, idVendor=0409, idProduct=005a
[   63.119720] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[   63.128936] usb 1-2: usb_probe_device
[   63.132812] usb 1-2: configuration #1 chosen from 1 choice
[   63.139160] usb 1-2: adding 1-2:1.0 (config #1, interface 0)
[   63.145629] hub 1-2:1.0: usb_probe_interface
[   63.150146] hub 1-2:1.0: usb_probe_interface - got id
[   63.155578] hub 1-2:1.0: USB hub found
[   63.200195] hub 1-2:1.0: 4 ports detected
[   63.204467] hub 1-2:1.0: standalone hub
[   63.208679] hub 1-2:1.0: ganged power switching
[   63.213470] hub 1-2:1.0: global over-current protection
[   63.219055] hub 1-2:1.0: Single TT
[   63.222747] hub 1-2:1.0: TT requires at most 16 FS bit times (1332 ns)
[   63.229644] hub 1-2:1.0: Port indicators are supported
[   63.235137] hub 1-2:1.0: power on to power good time: 0ms
[   63.242584] hub 1-2:1.0: local power source is good
[   63.247955] hub 1-2:1.0: no over-current condition exists
[   63.254852] hub 1-2:1.0: enabling power on all ports
[   63.357482] usb 1-2: link qh256-0001/cf68f6c0 start 1 [1/0 us]
[   63.364044] hub 1-2:1.0: state 7 ports 4 chg  evt 
[   63.370086] hub 1-2:1.0: hub_suspend
[   63.374023] usb 1-2: unlink qh256-0001/cf68f6c0 start 1 [1/0 us]
[   63.384948] usb 1-2: usb auto-suspend, wakeup 1
[   63.410217] hub 1-0:1.0: hub_suspend
[   63.414062] usb usb1: bus auto-suspend, wakeup 1
[   63.419036] ehci-omap ehci-omap.0: suspend root hub

root@beagleboard:~# 
root@beagleboard:~# lsusb
[   80.925262] usb usb1: usb auto-resume
[   80.929351] ehci-omap ehci-omap.0: resume root hub
[   80.934539] hub 1-0:1.0: hub_resume
[   80.938323] hub 1-0:1.0: port 2: status 0507 change 
[   80.945373] hub 1-0:1.0: state 7 ports 3 chg  evt 
[   80.952026] hub 1-0:1.0: hub_suspend
[   80.956024] usb 

Re: [PATCH 1/2] ARM: OMAP2+: SoC name and revision unification

[Ruslan Bilovol]

On Wed, Feb 6, 2013 at 1:56 AM, Tony Lindgren t...@atomide.com wrote:
 * Ruslan Bilovol ruslan.bilo...@ti.com [130131 11:28]:
 This is a long story where for each new generation of
 OMAP we used different approaches for creating
 strings for SoCs names and revisions that this patch
 fixes. It makes future exporting of this information
 to SoC infrastructure easier.

 Maybe use name soc_name and soc_rev instead and make
Yes agree, will change in next patchset

 cpu_name and cpu_rev local to the functions?
 That would reduce some churn here.
This is used in second patch in this series


 Also this does not apply to my omap-for-v3.9/soc
 branch. Care to update this (and possibly the second one)
 against that?
Yes, I will rebase the patches on top of this branch.


 Regards,

 Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB regression in linux next at least for pandboard

[Felipe Balbi]

Hi,

On Wed, Feb 06, 2013 at 05:03:36PM +0200, Roger Quadros wrote:
 On 02/06/2013 03:51 PM, Felipe Balbi wrote:
  Hi,
  
  On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote:
  Hi Tony,
 
 
  On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren t...@atomide.com wrote:
  * Tony Lindgren t...@atomide.com [121004 18:41]:
 
  Also on the EHCI port, I've seen issues where unplugging
  the cable hangs kernel with an infinite loop. But that happens
  only occasionally, sorry does not seem to happen right
  now so no output to paste here. Or maybe this issue
  has already been fixed?
 
  Looks like the system eventually recovers from the EHCI issue
  after about fivew minutes or so of spamming the logs. It seems
  the ehci-omap errors are:
 
  [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31
  [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes
  [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule
 
  More data below.
 
 
  Is this issue fixed ?
  Actually we too are getting very similar issue with samsung exynos5250 
  hardware.
  With latest 'usb-next' kernel and supporting arch patches, when i use
  following test scenerio:
  Connect a USB 2.0 external hub to USB 2.0 port, and connect mice or
  keyboard enumeration and
  functionality is fine but once disconnecting the HID we get to see the
  error log:
  hid-generic 0003:04B3:3025.0002: can't reset device,
  s5p-ehci-1.3/input0, status -71
 
  When i tried to enable CONFIG_USB_DEBUG, get the following log:
  
  looks like it's not OMAP-specific. Alan any tips ?
  
 
 I can't reproduce the problem on Panda, but I can on Beagle with a slightly
 different behaviour.
 
 1) connecting/disconnecting device directly to the beagleboard's USB port 
 works fine.
 
 2) If I connect a USB Hub to the port and connect a device to it after the 
 hub has
 autosuspended, the device is never detected.
 doing lsusb after that triggers the detection and produces a lot of 
 transaction errors.
 Beagle log is below, before and after 'lsusb'
 
 I suppose this doesn't affect Panda because it has a hub connected 
 immediately below the
 root hub that never suspends (as ethernet is hardwired to it).

Roger, try changing hub's autosuspend delay to something greater than
30ms and see if it helps. There was a discussion lately about that.

-- 
balbi


signature.asc
Description: Digital signature

Re: MUSB regression in linux next at least for pandboard

[Alan Stern]

On Wed, 6 Feb 2013, Felipe Balbi wrote:

  I can't reproduce the problem on Panda, but I can on Beagle with a slightly
  different behaviour.
  
  1) connecting/disconnecting device directly to the beagleboard's USB port 
  works fine.
  
  2) If I connect a USB Hub to the port and connect a device to it after the 
  hub has
  autosuspended, the device is never detected.
  doing lsusb after that triggers the detection and produces a lot of 
  transaction errors.
  Beagle log is below, before and after 'lsusb'
  
  I suppose this doesn't affect Panda because it has a hub connected 
  immediately below the
  root hub that never suspends (as ethernet is hardwired to it).
 
 Roger, try changing hub's autosuspend delay to something greater than
 30ms and see if it helps. There was a discussion lately about that.

There also were some patches to address this problem recently merged by
Greg KH (they are in Linus's current git, added after 3.8-rc6 was 
released):

da0aa7169b97d90f4af39a9dc84d58bbe19d7e78 USB: add 
usb_hcd_{start,end}_port_resume
f292e7f9fb0e4bec68bbd83443407d6bb7922d36 USB: EHCI: notify usbcore about port 
resumes
ee74290b7853db9d5fd64db70e5c175241c59fba USB: EHCI: fix timer bug affecting 
port resume

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB regression in linux next at least for pandboard

[Alan Stern]

On Wed, 6 Feb 2013, Felipe Balbi wrote:

 Hi,
 
 On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote:
  Hi Tony,
  
  
  On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren t...@atomide.com wrote:
   * Tony Lindgren t...@atomide.com [121004 18:41]:
   
 Also on the EHCI port, I've seen issues where unplugging
 the cable hangs kernel with an infinite loop. But that happens
 only occasionally, sorry does not seem to happen right
 now so no output to paste here. Or maybe this issue
 has already been fixed?
  
   Looks like the system eventually recovers from the EHCI issue
   after about fivew minutes or so of spamming the logs. It seems
   the ehci-omap errors are:
  
   [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31
   [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes
   [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule
  
   More data below.
  
  
  Is this issue fixed ?
  Actually we too are getting very similar issue with samsung exynos5250 
  hardware.
  With latest 'usb-next' kernel and supporting arch patches, when i use
  following test scenerio:
  Connect a USB 2.0 external hub to USB 2.0 port, and connect mice or
  keyboard enumeration and
  functionality is fine but once disconnecting the HID we get to see the
  error log:
  hid-generic 0003:04B3:3025.0002: can't reset device,
  s5p-ehci-1.3/input0, status -71
  
  When i tried to enable CONFIG_USB_DEBUG, get the following log:
 
 looks like it's not OMAP-specific. Alan any tips ?

It could be a problem with the hub the keyboard is plugged into.  Or 
something going on with the hub driver.  I'll try doing the same thing 
on my system.

 (keeping logs below)
...
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 1
  usb 1-1.3: unlink qh8-0e01/c193f140 start 2 [1/2 us]
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 1
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 2
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 3
  hub 1-1:1.0: state 7 ports 7 chg  evt 0008
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 4
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 5
  hub 1-1:1.0: port 3, status 0100, change 0001, 12 Mb/s
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 6
  usb 1-1.3: USB disconnect, device number 5
  usb 1-1.3: unregistering device
  usb 1-1.3: unregistering interface 1-1.3:1.0
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 7
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 8
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 9
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 10
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 11
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 12
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 13
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 14
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 15
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 16
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 17
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 18
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 19
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 20
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 21
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 22
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 23
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 24
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 25
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 26
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 27
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 28
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 29
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 30
  s5p-ehci s5p-ehci: detected XactErr len 0/8 retry 31
  s5p-ehci s5p-ehci: devpath 1.3 ep0out 3strikes
  usb 1-1: clear tt buffer port 3, a5 ep0 t00080248
  hid-generic 0003:04B3:3025.0002: can't reset device,
  s5p-ehci-1.3/input0, status -71

Note that most of these are debug messages, so they wouldn't normally 
appear.  (BTW: timestamps would be nice -- CONFIG_PRINTK_TIME.)

  Similar log as you get on ehci-omap ;-)
  Sorry i might have missed some information to put here.
  
  Your help will be very much useful.
  Thanks in advance :-)
  
   ...
   [62927.200012] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 19
   [62927.215606] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 25
   [62927.220092] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 22
   [62927.225738] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes

A certain amount of this is normal when an HID device is unplugged.  It 
should stop after 250 ms, however, when the hub notifies the host that 
a cable has been unplugged.  (Unless the hub driver is busy doing 
something else at the time...)

   ...
  
   After waiting for several minutes, it stops, and dmesg shows:
  
   # dmesg | grep -i omap

This grep will drop the important information.

Alan Stern

--
To unsubscribe from 

Re: [GIT PULL] ARM: OMAP: Audio support via omap-twl4030 and pwm support

[Tony Lindgren]

* Peter Ujfalusi peter.ujfal...@ti.com [130205 23:25]:
 On 02/05/2013 07:40 PM, Tony Lindgren wrote:
  For some reason the CONFIG_DEBUG_SECTION_MISMATCH got disabled in my 
  rolling
  kernel config...
  
  At least gcc version 4.3.5 (Debian 4.3.5-4) shows them. What's
  the compiler you have? 
 
 It show for me as well now that I have enabled the
 CONFIG_DEBUG_SECTION_MISMATCH in my config.

Maybe update your build scripts to always just:
$ ARCH=arm CONFIG_DEBUG_SECTION_MISMATCH=y make ...
 
 My GCC is:
 armv7a-hardfloat-linux-gnueabi-gcc (Gentoo 4.7.2 p1.3, pie-0.5.5) 4.7.2
 
  Yes let's do that rather than start copying things around. I'll apply
  the following fix to the omap-for-v3.9/twl branch.
 
 Cool, thanks Tony. I will drop my patch and pick the one from 
 omap-for-v3.9/twl.

OK will send that off today then.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] omap twl platform init changes for v3.9 merge window

[Tony Lindgren]

The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:

  Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v3.9/twl-signed-v2

for you to fetch changes up to 6689c87555839d90f2a0b76d1f982713487a11d2:

  ARM: OMAP2+: Fix twl section warnings related to omap_twl4030_audio_init 
(2013-02-05 10:36:21 -0800)


OMAP TWL updates from Peter Ujfalusi peter.ujfal...@ti.com:

Update for audio support via omap-twl4030 and pwm updates in board level,
and zoom-peripherals update to not request the TWL GPIO7.


Peter Ujfalusi (9):
  ARM: OMAP: 3430sdp: Enable extmute functionality for audio
  ARM: OMAP: zoom: Zoom2 does not have extmute functionality
  ARM: OMAP2+: twl-common: Add default twl4030 audio configuration
  ARM: OMAP2+: twl-common: Allow boards to customize the twl4030 audio setup
  ARM: OMAP: zoom: Audio support via the common omap-twl4030 machine driver
  ARM: OMAP: sdp3430: Audio support via the common omap-twl4030 machine 
driver
  ARM: OMAP: board-4430sdp: Proper support for TWL6030 PWM LED/Backlight
  ARM: OMAP: omap3beagle: Use the pwm_leds driver to control the PMU_STAT 
led
  ARM: board-zoom: Do not request LCD panel enable GPIO from twl4030

Tony Lindgren (2):
  Merge branch 'peter/for-tony' of 
git://gitorious.org/omap-audio/linux-audio into omap-for-v3.9/twl
  ARM: OMAP2+: Fix twl section warnings related to omap_twl4030_audio_init

 arch/arm/mach-omap2/board-3430sdp.c  | 20 ++
 arch/arm/mach-omap2/board-4430sdp.c  | 30 +++-
 arch/arm/mach-omap2/board-cm-t35.c   |  2 +-
 arch/arm/mach-omap2/board-devkit8000.c   |  2 +-
 arch/arm/mach-omap2/board-igep0020.c |  2 +-
 arch/arm/mach-omap2/board-omap3beagle.c  | 41 ++--
 arch/arm/mach-omap2/board-omap3evm.c |  2 +-
 arch/arm/mach-omap2/board-overo.c|  2 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c | 39 ++
 arch/arm/mach-omap2/twl-common.c | 17 
 arch/arm/mach-omap2/twl-common.h |  3 +-
 11 files changed, 120 insertions(+), 40 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation

[Tony Lindgren]

* Jon Hunter jon-hun...@ti.com [130205 16:26]:
 
 Actually, let me look into this a bit more. It appears that for all
 omap2+ devices NOR should be mapped to CS0 at 0x0800. So I am
 wondering if the boot-loader is re-mapping the CS0 space. If it is then
 may be we can avoid having such hacks in the kernel by fixing the
 bootloader. To date only the apollon board has really had this problem
 and I need to check what I have on my H4 (which has been hacked by me ;-)

OK. Yeah sorry I don't remember the history of why the different
mappings were needed. It could be it was just needed to keep some
devices working that were only initialized in the bootloader like
you're suspecting.

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] ARM: OMAP2+: Export SoC information to userspace using SoC infrastructure

[Ruslan Bilovol]

Hi,

This patch series is an attempt to export some OMAP SoC
information (like name, revision etc.) to userspace.
The first patch does some unification of OMAP SoC
information representation in current sources.
Second patch adds exactly needed changes using
exists in Linux kernel SoC infrastructure.

-
v2:
- changed cpu_* - soc_* variable names
- rebased on top of 'omap-for-v3.9/soc' branch of tmlind/linux-omap tree

Ruslan Bilovol (2):
  ARM: OMAP2+: SoC name and revision unification
  ARM: OMAP2+: Export SoC information to userspace

 arch/arm/mach-omap2/common.h |8 +++
 arch/arm/mach-omap2/id.c |  154 +++---
 arch/arm/mach-omap2/io.c |1 +
 arch/arm/plat-omap/Kconfig   |1 +
 4 files changed, 126 insertions(+), 38 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] ARM: OMAP2+: Export SoC information to userspace

[Ruslan Bilovol]

In some situations it is useful for userspace to
know some SoC-specific information. For example,
this may be used for deciding what kernel module to
use or how to better configure some settings etc.
This patch exports OMAP SoC information to userspace
using existing in Linux kernel SoC infrastructure.

This information can be read under
/sys/devices/socX directory

Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
 arch/arm/mach-omap2/common.h |8 ++
 arch/arm/mach-omap2/id.c |   65 ++
 arch/arm/mach-omap2/io.c |1 +
 arch/arm/plat-omap/Kconfig   |1 +
 4 files changed, 75 insertions(+)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 0c3a991..a024084 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -111,6 +111,14 @@ void ti81xx_init_late(void);
 void omap4430_init_late(void);
 int omap2_common_pm_late_init(void);
 
+#ifdef CONFIG_SOC_BUS
+void omap_soc_device_init(void);
+#else
+static inline void omap_soc_device_init(void)
+{
+}
+#endif
+
 #if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
 void omap2xxx_restart(char mode, const char *cmd);
 #else
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index b16a432..6134073 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,11 @@
 #include linux/kernel.h
 #include linux/init.h
 #include linux/io.h
+#include linux/slab.h
+
+#ifdef CONFIG_SOC_BUS
+#include linux/sys_soc.h
+#endif
 
 #include asm/cputype.h
 
@@ -582,3 +587,63 @@ void __init omap2_set_globals_tap(u32 class, void __iomem 
*tap)
else
tap_prod_id = 0x0208;
 }
+
+#ifdef CONFIG_SOC_BUS
+
+static const char const *omap_types[] = {
+   [OMAP2_DEVICE_TYPE_TEST]= TST,
+   [OMAP2_DEVICE_TYPE_EMU] = EMU,
+   [OMAP2_DEVICE_TYPE_SEC] = HS,
+   [OMAP2_DEVICE_TYPE_GP]  = GP,
+   [OMAP2_DEVICE_TYPE_BAD] = BAD,
+};
+
+static const char * __init omap_get_family(void)
+{
+   if (cpu_is_omap24xx())
+   return kasprintf(GFP_KERNEL, OMAP2);
+   else if (cpu_is_omap34xx())
+   return kasprintf(GFP_KERNEL, OMAP3);
+   else if (cpu_is_omap44xx())
+   return kasprintf(GFP_KERNEL, OMAP4);
+   else if (soc_is_omap54xx())
+   return kasprintf(GFP_KERNEL, OMAP5);
+   else
+   return kasprintf(GFP_KERNEL, Unknown);
+}
+
+static ssize_t omap_get_type(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   return sprintf(buf, %s\n, omap_types[omap_type()]);
+}
+
+static struct device_attribute omap_soc_attr =
+   __ATTR(type,  S_IRUGO, omap_get_type,  NULL);
+
+void __init omap_soc_device_init(void)
+{
+   struct device *parent;
+   struct soc_device *soc_dev;
+   struct soc_device_attribute *soc_dev_attr;
+
+   soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+   if (!soc_dev_attr)
+   return;
+
+   soc_dev_attr-machine  = soc_name;
+   soc_dev_attr-family   = omap_get_family();
+   soc_dev_attr-revision = soc_rev;
+
+   soc_dev = soc_device_register(soc_dev_attr);
+   if (IS_ERR_OR_NULL(soc_dev)) {
+   kfree(soc_dev_attr);
+   return;
+   }
+
+   parent = soc_device_to_device(soc_dev);
+   if (!IS_ERR_OR_NULL(parent))
+   device_create_file(parent, omap_soc_attr);
+}
+#endif /* CONFIG_SOC_BUS */
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 2c3fdd6..08003c1 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -602,6 +602,7 @@ void __init omap4430_init_late(void)
omap2_common_pm_late_init();
omap4_pm_init();
omap2_clk_enable_autoidle_all();
+   omap_soc_device_init();
 }
 #endif
 
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 1fbac36..24b5687 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -30,6 +30,7 @@ config ARCH_OMAP2PLUS
select PROC_DEVICETREE if PROC_FS
select SPARSE_IRQ
select USE_OF
+   select SOC_BUS
help
  Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] ARM: OMAP2+: SoC name and revision unification

[Ruslan Bilovol]

This is a long story where for each new generation of
OMAP we used different approaches for creating
strings for SoCs names and revisions that this patch
fixes. It makes future exporting of this information
to SoC infrastructure easier.

Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
 arch/arm/mach-omap2/id.c |   89 ++
 1 file changed, 51 insertions(+), 38 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 8a68f1e..b16a432 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -31,8 +31,11 @@
 #define OMAP4_SILICON_TYPE_STANDARD0x01
 #define OMAP4_SILICON_TYPE_PERFORMANCE 0x02
 
+#define OMAP_SOC_MAX_NAME_LENGTH   16
+
 static unsigned int omap_revision;
-static const char *cpu_rev;
+static char soc_name[OMAP_SOC_MAX_NAME_LENGTH];
+static char soc_rev[OMAP_SOC_MAX_NAME_LENGTH];
 u32 omap_features;
 
 unsigned int omap_rev(void)
@@ -169,9 +172,12 @@ void __init omap2xxx_check_revision(void)
j = i;
}
 
-   pr_info(OMAP%04x, omap_rev()  16);
+   sprintf(soc_name, OMAP%04x, omap_rev()  16);
+   sprintf(soc_rev, ES%x, (omap_rev()  12)  0xf);
+
+   pr_info(%s, soc_name);
if ((omap_rev()  8)  0x0f)
-   pr_info(ES%x, (omap_rev()  12)  0xf);
+   pr_info(%s, soc_rev);
pr_info(\n);
 }
 
@@ -181,8 +187,7 @@ void __init omap2xxx_check_revision(void)
 
 static void __init omap3_cpuinfo(void)
 {
-   const char *cpu_name;
-
+   const char *omap3_soc_name;
/*
 * OMAP3430 and OMAP3530 are assumed to be same.
 *
@@ -191,28 +196,30 @@ static void __init omap3_cpuinfo(void)
 * and CPU class bits.
 */
if (cpu_is_omap3630()) {
-   cpu_name = OMAP3630;
+   omap3_soc_name = OMAP3630;
} else if (soc_is_am35xx()) {
-   cpu_name = (omap3_has_sgx()) ? AM3517 : AM3505;
+   omap3_soc_name = (omap3_has_sgx()) ? AM3517 : AM3505;
} else if (cpu_is_ti816x()) {
-   cpu_name = TI816X;
+   omap3_soc_name = TI816X;
} else if (soc_is_am335x()) {
-   cpu_name =  AM335X;
+   omap3_soc_name =  AM335X;
} else if (cpu_is_ti814x()) {
-   cpu_name = TI814X;
+   omap3_soc_name = TI814X;
} else if (omap3_has_iva()  omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
-   cpu_name = OMAP3430/3530;
+   omap3_soc_name = OMAP3430/3530;
} else if (omap3_has_iva()) {
-   cpu_name = OMAP3525;
+   omap3_soc_name = OMAP3525;
} else if (omap3_has_sgx()) {
-   cpu_name = OMAP3515;
+   omap3_soc_name = OMAP3515;
} else {
-   cpu_name = OMAP3503;
+   omap3_soc_name = OMAP3503;
}
 
+   sprintf(soc_name, %s, omap3_soc_name);
+
/* Print verbose information */
-   pr_info(%s ES%s (, cpu_name, cpu_rev);
+   pr_info(%s %s (, soc_name, soc_rev);
 
OMAP3_SHOW_FEATURE(l2cache);
OMAP3_SHOW_FEATURE(iva);
@@ -291,6 +298,7 @@ void __init ti81xx_check_features(void)
 
 void __init omap3xxx_check_revision(void)
 {
+   const char *omap3_soc_rev;
u32 cpuid, idcode;
u16 hawkeye;
u8 rev;
@@ -303,7 +311,7 @@ void __init omap3xxx_check_revision(void)
cpuid = read_cpuid(CPUID_ID);
if cpuid  4)  0xfff) == 0xc08)  ((cpuid  0xf) == 0x0)) {
omap_revision = OMAP3430_REV_ES1_0;
-   cpu_rev = 1.0;
+   omap3_soc_rev = ES1.0;
return;
}
 
@@ -324,26 +332,26 @@ void __init omap3xxx_check_revision(void)
case 0: /* Take care of early samples */
case 1:
omap_revision = OMAP3430_REV_ES2_0;
-   cpu_rev = 2.0;
+   omap3_soc_rev = ES2.0;
break;
case 2:
omap_revision = OMAP3430_REV_ES2_1;
-   cpu_rev = 2.1;
+   omap3_soc_rev = ES2.1;
break;
case 3:
omap_revision = OMAP3430_REV_ES3_0;
-   cpu_rev = 3.0;
+   omap3_soc_rev = ES3.0;
break;
case 4:
omap_revision = OMAP3430_REV_ES3_1;
-   cpu_rev = 3.1;
+   omap3_soc_rev = ES3.1;
break;
case 7:
/* FALLTHROUGH */
default:
/* Use the latest known revision as default */
omap_revision = OMAP3430_REV_ES3_1_2;
-   cpu_rev = 3.1.2;
+   omap3_soc_rev = ES3.1.2;
}
  

Re: [PATCH v4 0/2] Add CPSW VLAN Support

[David Miller]

From: Mugunthan V N mugunthan...@ti.com
Date: Tue, 5 Feb 2013 23:56:46 +0530

 CPSW is capable of filtering VLAN packets in hardware. This patch series
 implements VLAN support to CPSW driver.
 This patch series is tested on net-next with AM335x EVM with ping test.

Series applied.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] ARM: dts: Add DT bindings for OMAP SDMA

[Jon Hunter]

Adds device-tree bindings from SDMA on OMAP2+ devices. DMA client
bindings are also added for devices that have SPI and MMC bindings
populated. Client binding data is based upon existing HWMOD data for
OMAP and has been checked against OMAP documentation.

Testing includes ...
1. Boot tested on OMAP3430 Beagle board, OMAP4430 Panda board and
   OMAP4460 Panda board with and without device-tree present.
2. Testing of MMC1 with SD card on OMAP3430 Beagle board, OMAP4430
   Panda board and OMAP4460 Panda board with and without device-tree
   present.

Testing branch available here [1].

Series is based upon v3.8-rc6 on top of the following ...
- Vinod's topic/dmaengine_dt branch [2]
- Matt Porter's series DMA Engine support for AM33XX [3]
- Matt Porter's series omap_hsmmc DT DMA Client support [4]
- Sourav Poddar's series add omap mcspi device tree data [5]

[1] https://github.com/jonhunter/linux/commits/dev-dt-dma
[2] 
http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dmaengine_dt
[3] http://permalink.gmane.org/gmane.linux.kernel.spi.devel/12508
[4] http://permalink.gmane.org/gmane.linux.ports.arm.omap/93165
[5] http://permalink.gmane.org/gmane.linux.kernel/1435002

Jon Hunter (2):
  ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
  dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

 .../devicetree/bindings/dma/omap-sdma.txt  |   44 
 arch/arm/boot/dts/omap2.dtsi   |   12 ++
 arch/arm/boot/dts/omap3.dtsi   |   40 ++
 arch/arm/boot/dts/omap4.dtsi   |   41 ++
 arch/arm/boot/dts/omap5.dtsi   |   41 ++
 drivers/dma/omap-dma.c |   31 +-
 6 files changed, 208 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt

-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes

[Jon Hunter]

Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC periperhal on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 .../devicetree/bindings/dma/omap-sdma.txt  |   44 
 arch/arm/boot/dts/omap2.dtsi   |   12 ++
 arch/arm/boot/dts/omap3.dtsi   |   40 ++
 arch/arm/boot/dts/omap4.dtsi   |   41 ++
 arch/arm/boot/dts/omap5.dtsi   |   41 ++
 5 files changed, 178 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt

diff --git a/Documentation/devicetree/bindings/dma/omap-sdma.txt 
b/Documentation/devicetree/bindings/dma/omap-sdma.txt
new file mode 100644
index 000..5c2c125
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/omap-sdma.txt
@@ -0,0 +1,44 @@
+* TI OMAP SDMA controller
+
+Required properties:
+- compatible:  Must be ti,omap-sdma
+- reg: Contains DMA registers location and length.
+- interrupts:  Contains DMA interrupt information.
+- #dma-cells:  Must be 1.
+- #dma-channels:   Contains total number of programmable DMA channels.
+- #dma-requests:   Contains total number of DMA requests.
+
+Example:
+
+   sdma: dma-controller@4A056000 {
+   compatible = ti,omap-sdma;
+   reg = 0x4A056000 0x1000;
+   interrupts = 0 12 0x4,
+0 13 0x4,
+0 14 0x4,
+0 15 0x4;
+   #dma-cells = 1;
+   #dma-channels = 32;
+   #dma-requests = 127;
+   };
+
+
+* TI OMAP SDMA clients
+
+Required properties:
+- dmas:List of one or more DMA specifiers, each 
consisting of
+   - A phandle pointing to DMA controller node
+   - The DMA request number associated with client device
+- dma-names:   Contains one identifier string for each dma specifier in
+   the dmas property. The specific strings that can be used
+   are defined in the binding of the DMA client device.
+
+Example:
+
+   mmc1: mmc@4809c000 {
+   ...
+   dmas = sdma 61,  /* TX channel */
+  sdma 62;  /* RX channel */
+   dma-names = tx, rx;
+   ...
+   };
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..7288972 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -49,6 +49,18 @@
reg = 0x480FE000 0x1000;
};
 
+   sdma: dma-controller@48056000 {
+   compatible = ti,omap-sdma;
+   reg = 0x48056000 0x1000;
+   interrupts = 12,
+13,
+14,
+15;
+   #dma-cells = 1;
+   #dma-channels = 32;
+   #dma-requests = 64;
+   };
+
uart1: serial@4806a000 {
compatible = ti,omap2-uart;
ti,hwmods = uart1;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..4d63aa2 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -75,6 +75,18 @@
reg = 0x4820 0x1000;
};
 
+   sdma: dma-controller@48056000 {
+   compatible = ti,omap-sdma;
+   reg = 0x48056000 0x1000;
+   interrupts = 12,
+13,
+14,
+15;
+   #dma-cells = 1;
+   #dma-channels = 32;
+   #dma-requests = 96;
+   };
+
omap3_pmx_core: pinmux@48002030 {
compatible = ti,omap3-padconf, pinctrl-single;
reg = 0x48002030 0x05cc;
@@ -192,6 +204,16 @@
#size-cells = 0;
ti,hwmods = mcspi1;
ti,spi-num-cs = 4;
+   dmas = sdma 35,
+  sdma 36,
+  sdma 37,
+  sdma 38,
+  sdma 39,
+  sdma 40,
+  sdma 41,
+  sdma 42;
+   dma-names = tx0, rx0, tx1, rx1,
+   tx2, rx2, tx3, rx3;
};
 

[PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

[Jon Hunter]

If the device-tree blob is present during boot, then register the SDMA
controller with the device-tree DMA driver so that we can use device-tree
to look-up DMA client information.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 drivers/dma/omap-dma.c |   31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 5a31264..a32d81b 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -16,6 +16,8 @@
 #include linux/platform_device.h
 #include linux/slab.h
 #include linux/spinlock.h
+#include linux/of_dma.h
+#include linux/of_device.h
 
 #include virt-dma.h
 
@@ -67,6 +69,8 @@ static const unsigned es_bytes[] = {
[OMAP_DMA_DATA_TYPE_S32] = 4,
 };
 
+static struct of_dma_filter_info info;
+
 static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
 {
return container_of(d, struct omap_dmadev, ddev);
@@ -621,10 +625,25 @@ static int omap_dma_probe(struct platform_device *pdev)
pr_warn(OMAP-DMA: failed to register slave DMA engine device: 
%d\n,
rc);
omap_dma_free(od);
+   return rc;
} else {
platform_set_drvdata(pdev, od);
}
 
+   if (pdev-dev.of_node) {
+   info.dma_cap = od-ddev.cap_mask;
+   info.filter_fn = omap_dma_filter_fn;
+
+   /* Device-tree DMA controller registration */
+   rc = of_dma_controller_register(pdev-dev.of_node,
+   of_dma_simple_xlate, info);
+   if (rc) {
+   pr_warn(OMAP-DMA: failed to register DMA 
controller\n);
+   dma_async_device_unregister(od-ddev);
+   omap_dma_free(od);
+   }
+   }
+
dev_info(pdev-dev, OMAP DMA engine driver\n);
 
return rc;
@@ -634,18 +653,28 @@ static int omap_dma_remove(struct platform_device *pdev)
 {
struct omap_dmadev *od = platform_get_drvdata(pdev);
 
+   if (pdev-dev.of_node)
+   of_dma_controller_free(pdev-dev.of_node);
+
dma_async_device_unregister(od-ddev);
omap_dma_free(od);
 
return 0;
 }
 
+static const struct of_device_id omap_dma_match[] = {
+   { .compatible = ti,omap-sdma, },
+   {},
+};
+MODULE_DEVICE_TABLE(of, omap_dma_match);
+
 static struct platform_driver omap_dma_driver = {
.probe  = omap_dma_probe,
.remove = omap_dma_remove,
.driver = {
.name = omap-dma-engine,
.owner = THIS_MODULE,
+   .of_match_table = of_match_ptr(omap_dma_match)
},
 };
 
@@ -673,7 +702,7 @@ static int omap_dma_init(void)
 {
int rc = platform_driver_register(omap_dma_driver);
 
-   if (rc == 0) {
+   if ((rc == 0)  (!of_have_populated_dt())) {
pdev = platform_device_register_full(omap_dma_dev_info);
if (IS_ERR(pdev)) {
platform_driver_unregister(omap_dma_driver);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

[Jon Hunter]

On 02/06/2013 03:03 PM, Jon Hunter wrote:
 If the device-tree blob is present during boot, then register the SDMA
 controller with the device-tree DMA driver so that we can use device-tree
 to look-up DMA client information.
 
 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
  drivers/dma/omap-dma.c |   31 ++-
  1 file changed, 30 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
 index 5a31264..a32d81b 100644
 --- a/drivers/dma/omap-dma.c
 +++ b/drivers/dma/omap-dma.c
 @@ -16,6 +16,8 @@
  #include linux/platform_device.h
  #include linux/slab.h
  #include linux/spinlock.h
 +#include linux/of_dma.h
 +#include linux/of_device.h
  
  #include virt-dma.h
  
 @@ -67,6 +69,8 @@ static const unsigned es_bytes[] = {
   [OMAP_DMA_DATA_TYPE_S32] = 4,
  };
  
 +static struct of_dma_filter_info info;
 +
  static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
  {
   return container_of(d, struct omap_dmadev, ddev);
 @@ -621,10 +625,25 @@ static int omap_dma_probe(struct platform_device *pdev)
   pr_warn(OMAP-DMA: failed to register slave DMA engine device: 
 %d\n,
   rc);
   omap_dma_free(od);
 + return rc;
   } else {
   platform_set_drvdata(pdev, od);
   }

I realise now that I could get rid of the else here and just call
platform_set_drvdata(), if we don't return.

Anyway, I will wait for other comments before changing.

Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: OMAP2xxx: PM: enter WFI via inline asm if CORE stays active

[Paul Walmsley]

On Sun, 30 Dec 2012, Paul Walmsley wrote:

 There shouldn't be any need to jump to SRAM code if the OMAP CORE
 clockdomain (and consequently the SDRAM controller and CORE PLL) stays
 active during MPU WFI.  The SRAM code should only be needed when the RAM
 enters self-refresh.  So in the case where CORE stays active, just call
 WFI directly from the mach-omap2/pm24xx.c code.  This removes some
 unnecessary SRAM code.
 
 Signed-off-by: Paul Walmsley p...@pwsan.com
 Cc: Richard Woodruff r-woodru...@ti.com
 Cc: Kevin Hilman khil...@deeprootsystems.com

Here's an updated version of this one.


- Paul

From: Paul Walmsley p...@pwsan.com
Date: Sun, 30 Dec 2012 10:15:48 -0700
Subject: [PATCH] ARM: OMAP2xxx: PM: enter WFI via inline asm if CORE stays
 active

There shouldn't be any need to jump to SRAM code if the OMAP CORE
clockdomain (and consequently the SDRAM controller and CORE PLL) stays
active during MPU WFI.  The SRAM code should only be needed when the RAM
enters self-refresh.  So in the case where CORE stays active, just call
WFI directly from the mach-omap2/pm24xx.c code.  This removes some
unnecessary SRAM code.

This second version replaces the inline WFI with the corresponding
coprocessor register call, using tlbflush.h as an example.  This is
because the assembler doesn't recognize WFI as a valid ARMv6
instruction.

Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/pm24xx.c|   12 ++--
 arch/arm/mach-omap2/sleep24xx.S |   19 ---
 2 files changed, 6 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index c333fa6..8914b9e 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -54,7 +54,6 @@
 #include powerdomain.h
 #include clockdomain.h
 
-static void (*omap2_sram_idle)(void);
 static void (*omap2_sram_suspend)(u32 dllctrl, void __iomem *sdrc_dlla_ctrl,
  void __iomem *sdrc_power);
 
@@ -172,6 +171,8 @@ static int omap2_allow_mpu_retention(void)
 
 static void omap2_enter_mpu_retention(void)
 {
+   const int zero = 0;
+
/* Putting MPU into the WFI state while a transfer is active
 * seems to cause the I2C block to timeout. Why? Good question. */
if (omap2_i2c_active())
@@ -196,7 +197,8 @@ static void omap2_enter_mpu_retention(void)
 OMAP2_PM_PWSTCTRL);
}
 
-   omap2_sram_idle();
+   /* WFI */
+   asm(mcr p15, 0, %0, c7, c0, 4 : : r (zero) : memory, cc);
 }
 
 static int omap2_can_sleep(void)
@@ -356,11 +358,9 @@ int __init omap2_pm_init(void)
/*
 * We copy the assembler sleep/wakeup routines to SRAM.
 * These routines need to be in SRAM as that's the only
-* memory the MPU can see when it wakes up.
+* memory the MPU can see when it wakes up after the entire
+* chip enters idle.
 */
-   omap2_sram_idle = omap_sram_push(omap24xx_idle_loop_suspend,
-omap24xx_idle_loop_suspend_sz);
-
omap2_sram_suspend = omap_sram_push(omap24xx_cpu_suspend,
omap24xx_cpu_suspend_sz);
 
diff --git a/arch/arm/mach-omap2/sleep24xx.S b/arch/arm/mach-omap2/sleep24xx.S
index ce0ccd2..1d3cb25 100644
--- a/arch/arm/mach-omap2/sleep24xx.S
+++ b/arch/arm/mach-omap2/sleep24xx.S
@@ -37,25 +37,6 @@
.text
 
 /*
- * Forces OMAP into idle state
- *
- * omap24xx_idle_loop_suspend() - This bit of code just executes the WFI
- * for normal idles.
- *
- * Note: This code get's copied to internal SRAM at boot. When the OMAP
- *  wakes up it continues execution at the point it went to sleep.
- */
-   .align  3
-ENTRY(omap24xx_idle_loop_suspend)
-   stmfd   sp!, {r0, lr}   @ save registers on stack
-   mov r0, #0  @ clear for mcr setup
-   mcr p15, 0, r0, c7, c0, 4   @ wait for interrupt
-   ldmfd   sp!, {r0, pc}   @ restore regs and return
-
-ENTRY(omap24xx_idle_loop_suspend_sz)
-   .word   . - omap24xx_idle_loop_suspend
-
-/*
  * omap24xx_cpu_suspend() - Forces OMAP into deep sleep state by completing
  * SDRC shutdown then ARM shutdown.  Upon wake MPU is back on so just restore
  * SDRC.
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

Hi Vaibhav,

On Thu, 24 Jan 2013, Bedia, Vaibhav wrote:

 I could not track down U-Boot that you were using

It's posted now at:

http://www.pwsan.com/omap/bootloaders/beaglebone/u-boot/2011.09-9-gcf6e04d__20120803171543/

Care to try it?

 However, using your build configs for v3.7 and v3.8-rcX I got the same
 observations i.e. v3.7 boots but others don't.
 
 One difference that I found was that post v3.7 the configs that you are using 
 have
 CONFIG_EARLY_PRINTK set. Once I disabled that I was able to bootup v3.8-rc1/4
 (didn't try rc2/3 but I suspect early_printk was the culprit there too).
 
 I checked with Santosh on this and he mentioned that for DT-only boot, which 
 AM335x is,
 that's expected behavior.
 
 Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK

Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing.

I also tried building a v3.8-rc6 kernel with the old v3.7-rc config that 
was used before; no luck.

 or just skip earlyprintk option in the bootargs for now?

Haven't tried this one yet.

 If you still have issues booting can you update your U-Boot to v2013.01 since 
 things
 seem to be working fine at this point.

Let's try to identify and get rid of bootloader dependencies in the 
kernel.  They indicate that the kernel isn't initializing something 
appropriately, which could cause strange problems later.


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] ARM: OMAP2+: SoC name and revision unification

[Ruslan Bilovol]

On Wed, Feb 6, 2013 at 9:19 PM, Tony Lindgren t...@atomide.com wrote:
 Hi,

 * Ruslan Bilovol ruslan.bilo...@ti.com [130206 11:03]:
 This is a long story where for each new generation of
 OMAP we used different approaches for creating
 strings for SoCs names and revisions that this patch
 fixes. It makes future exporting of this information
 to SoC infrastructure easier.

 Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
 ---
  arch/arm/mach-omap2/id.c |   89 
 ++
  1 file changed, 51 insertions(+), 38 deletions(-)

 diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
 index 8a68f1e..b16a432 100644
 --- a/arch/arm/mach-omap2/id.c
 +++ b/arch/arm/mach-omap2/id.c
 @@ -31,8 +31,11 @@
  #define OMAP4_SILICON_TYPE_STANDARD  0x01
  #define OMAP4_SILICON_TYPE_PERFORMANCE   0x02

 +#define OMAP_SOC_MAX_NAME_LENGTH 16
 +
  static unsigned int omap_revision;
 -static const char *cpu_rev;
 +static char soc_name[OMAP_SOC_MAX_NAME_LENGTH];
 +static char soc_rev[OMAP_SOC_MAX_NAME_LENGTH];
  u32 omap_features;

  unsigned int omap_rev(void)

 Sorry I was not clear earlier with what I meant, but if
 you remove static const char *cpu_rev here and use
 soc_name and soc_rev here..

 @@ -181,8 +187,7 @@ void __init omap2xxx_check_revision(void)

  static void __init omap3_cpuinfo(void)
  {
 - const char *cpu_name;
 -
 + const char *omap3_soc_name;
   /*
* OMAP3430 and OMAP3530 are assumed to be same.
*

 ..then no need to replace cpu_name with omap3_soc_name here?

 @@ -191,28 +196,30 @@ static void __init omap3_cpuinfo(void)
* and CPU class bits.
*/
   if (cpu_is_omap3630()) {
 - cpu_name = OMAP3630;
 + omap3_soc_name = OMAP3630;
   } else if (soc_is_am35xx()) {
 - cpu_name = (omap3_has_sgx()) ? AM3517 : AM3505;
 + omap3_soc_name = (omap3_has_sgx()) ? AM3517 : AM3505;
   } else if (cpu_is_ti816x()) {
 - cpu_name = TI816X;
 + omap3_soc_name = TI816X;
   } else if (soc_is_am335x()) {
 - cpu_name =  AM335X;
 + omap3_soc_name =  AM335X;
 ...

 Or here?

  void __init omap3xxx_check_revision(void)
  {
 + const char *omap3_soc_rev;
   u32 cpuid, idcode;
   u16 hawkeye;
   u8 rev;

 Then here if you just make it a local cpu_rev..

 @@ -303,7 +311,7 @@ void __init omap3xxx_check_revision(void)
   cpuid = read_cpuid(CPUID_ID);
   if cpuid  4)  0xfff) == 0xc08)  ((cpuid  0xf) == 0x0)) {
   omap_revision = OMAP3430_REV_ES1_0;
 - cpu_rev = 1.0;
 + omap3_soc_rev = ES1.0;
   return;
   }

 @@ -324,26 +332,26 @@ void __init omap3xxx_check_revision(void)
   case 0: /* Take care of early samples */
   case 1:
   omap_revision = OMAP3430_REV_ES2_0;
 - cpu_rev = 2.0;
 + omap3_soc_rev = ES2.0;
   break;
   case 2:
   omap_revision = OMAP3430_REV_ES2_1;
 - cpu_rev = 2.1;
 + omap3_soc_rev = ES2.1;
   break;
   case 3:
   omap_revision = OMAP3430_REV_ES3_0;
 - cpu_rev = 3.0;
 + omap3_soc_rev = ES3.0;
   break;
   case 4:
   omap_revision = OMAP3430_REV_ES3_1;
 - cpu_rev = 3.1;
 + omap3_soc_rev = ES3.1;
   break;

 ..no need to replace cpu_rev with omap3_soc_rev all over the
 place?

Okay, I understood what do you mean here. Will fix it in next patchset..


 Regards,

 Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

On Wed, 6 Feb 2013, Paul Walmsley wrote:

 Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing.

And just tried this with u-boot v2013.01 on a BeagleBoard A6a, does not 
fix it.

  If you still have issues booting can you update your U-Boot to v2013.01 
  since things
  seem to be working fine at this point.
 
 Let's try to identify and get rid of bootloader dependencies in the 
 kernel.  They indicate that the kernel isn't initializing something 
 appropriately, which could cause strange problems later.

Oh and it's worth noting that parts of u-boot v2013.01 don't work 
correctly on earlier BeagleBones, i.e. Ethernet booting.


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: On MIPI-CSI2 YUV420 formats and V4L2 Media Bus formats

[Antonio Ospite]

On Wed, 30 Jan 2013 01:23:48 +0100
Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:

 Hi Antonio,


Sorry for the delay Laurent and thanks for your reply, some more
questions below.

 On Monday 28 January 2013 13:22:10 Antonio Ospite wrote:
  Hi,
  
  looking at the MIPI Alliance Specification for Camera Serial Interface
  2 (I'll call it MIPI-CSI2 from now on, the document I am referring to
  is mentioned at [1] and available at [2]), I see there is an YUV420 8
  bit format (MIPI Data Type 0x18) specified with interleaved components
  in the form of:
  
... (odd lines)
UYVYUYVY... (even lines)
  
  With even lines twice the size of odd lines.
  Such format is also supported by some sensors, for instance ov5640, and
  by MIPI-CSI2 receivers like OMAP4 ISS.
  
  The doubt I have is: how should I represent those formats as media bus
  formats?
 
 We likely need new media bus formats to describe those.

OK, I'll think to some names if I am going to actually use them.

  I've seen that some drivers (sensors and SoC, for instance[3]) tend to
  identify the MIPI-CSI2 format above (0x18) with media bus formats like
  V4L2_MBUS_FMT_UYVY8_1_5X8 (actually the code above uses
  V4L2_MBUS_FMT_YUYV8_1_5X8 is this OK?), but from the v4l2 documentation
  [4] I understand that this format is supposed to have data in this
  configuration:
  
...
...
...
...
...
...
 
 Not exactly, the UYVY8_1_5X8 is transmits Y, U and V samples as UYYVYY...


Wait, am I misunderstanding the documentation at
http://kernel.org/doc/htmldocs/media/subdev.html#v4l2-mbus-pixelcode-yuv8
? From the tables there it looks like that in UYVY8_1_5X8 the
components are not interleaved on the same line, only the lines are.

And that's why I was believing the code in [3] which maps 
YUYV8_1_5X8 (line interleaved, according to my interpretation of the v4l
doc) to the MIPI-CSI2 0x18 format (components interleaved), was
inaccurate (in the sense that I would have expected another [new] media
bus format).

  That is with interleaved lines, but NOT interleaved components. Should
  new media bus formats be added for .../UYVYUYVY...?
 
 Yes, I think so.

  Another doubt I have is: how is the .../UYVYUYVY... data supposed
  to be processed in userspace? Is the MIPI Receiver (i.e, the SoC)
  expected to be able to convert it to a more usable format like YUV420P
  or NV12/NV21? Or are there applications capable of handling this data
  directly, or efficiently convert them to planar or semi-planar YUV420
  formats?
 
 The bridge (receiver and DMA engine) driver will expose V4L2 pixel formats 
 corresponding to the bridge capabilities. If the bridge can store the above 
 stream in memory in NV12 it will expose that to applications. If the bridge 
 stores data in memory as described above, it will just expose that format (it 
 seems to correspond to the V4L2 M420 pixel format), and applications will 
 need 
 to handle that explicitly.


I see, so what I can get in userspace obviously depends on the hardware
_and_ the driver (i.e. how complete it is in exposing the hardware
capabilities), but that means that if a bridge can transparently pass
the data it gets from the sensor (in a given mediabus format) we could
have as many pixelformats as we have media bus formats, I know these
latter won't be added in practice, but is my reasoning right in
principle? Each mediabus format is a possible candidate for a new
pixelformat. Maybe I am asking the obvious but I am trying to complete
my understanding about the relationship between media bus formats and
pixelformats.

BTW that M420 format you mention is a bit different, from what I can
see[6] it is something like a line interleaved NV12:

  ...
  ...
  UVUV...
  ...
  ...
  UVUV...
  

[6]
http://www.linuxtv.org/downloads/v4l-dvb-apis/V4L2-PIX-FMT-M420.html

So still another variation  on the theme :) Or am I still reading the
documentation the wrong way?

  In particular I am curios if the OMAP4 ISS can do the conversion to NV12, I
  understand that the formats with interleaved _lines_ can be produced by the
  resizer and handled by the OMAP ISP DMA-Engine by setting buffers offsets to
  Y and UV in order to send NV12 data to userspace, but I couldn't find info
  about how to handle the YUV420 MIPI-CSI2 formats (interleaved components)
  without the resizer in the Developer Manual [5]; having NV12 data directly
  from the hardware without using the OMAP4 ISS/ISP Resizer can be valuable in
  some use cases (e.g. dual camera setups).
 
 No idea about that, sorry.


Not at all. I was hoping Sergio would step up here.

Thanks again,
   Antonio

  [1] http://www.mipi.org/specifications/camera-interface#CSI2
  [2] http://ishare.sina.cn/dintro.php?id=20498632
  [3]
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=driver
  s/media/platform/soc_camera/sh_mobile_csi2.c;h=a17aba9a0104c41cbc4e5e5d27701
  

[PATCH] arm: Include soc.h to fix compiling

[André Hentschel]

I needed this when compiling for pandaboard at commit: 
0944c0a03465718909ba8e800a5230528aeabafb

Signed-off-by: André Hentschel n...@dawncrow.deFrom: 
=?UTF-8?q?Andr=C3=A9=20Hentschel?= n...@dawncrow.de
From: =?UTF-8?q?Andr=C3=A9=20Hentschel?= n...@dawncrow.de
Date: Wed, 6 Feb 2013 23:16:20 +0100
Subject: [PATCH] arm: Include soc.h to fix compiling

---
 arch/arm/mach-omap2/drm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
index 4c7566c..b4faf96 100644
--- a/arch/arm/mach-omap2/drm.c
+++ b/arch/arm/mach-omap2/drm.c
@@ -27,6 +27,7 @@
 
 #include omap_device.h
 #include omap_hwmod.h
+#include soc.h
 
 #if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
 
-- 
1.8.0

Best Regards, André Hentschel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/2] ARM: OMAP2+: Export SoC information to userspace using SoC infrastructure

[Ruslan Bilovol]

Hi,

This patch series is an attempt to export some OMAP SoC
information (like name, revision etc.) to userspace.
The first patch does some unification of OMAP SoC
information representation in current sources.
Second patch adds exactly needed changes using
exists in Linux kernel SoC infrastructure.

-
v3:
- reduced number of lines changed in the first patch (reusing
  existent code)

-
v2:
- changed cpu_* - soc_* variable names
- rebased on top of 'omap-for-v3.9/soc' branch of tmlind/linux-omap tree


Ruslan Bilovol (2):
  ARM: OMAP2+: SoC name and revision unification
  ARM: OMAP2+: Export SoC information to userspace

 arch/arm/mach-omap2/common.h |8 
 arch/arm/mach-omap2/id.c |   95 ++
 arch/arm/mach-omap2/io.c |1 +
 arch/arm/plat-omap/Kconfig   |1 +
 4 files changed, 97 insertions(+), 8 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/2] ARM: OMAP2+: SoC name and revision unification

[Ruslan Bilovol]

This is a long story where for each new generation of
OMAP we used different approaches for creating
strings for SoCs names and revisions that this patch
fixes. It makes future exporting of this information
to SoC infrastructure easier.

Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
 arch/arm/mach-omap2/id.c |   30 ++
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 8a68f1e..3737700 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -31,8 +31,11 @@
 #define OMAP4_SILICON_TYPE_STANDARD0x01
 #define OMAP4_SILICON_TYPE_PERFORMANCE 0x02
 
+#define OMAP_SOC_MAX_NAME_LENGTH   16
+
 static unsigned int omap_revision;
-static const char *cpu_rev;
+static char soc_name[OMAP_SOC_MAX_NAME_LENGTH];
+static char soc_rev[OMAP_SOC_MAX_NAME_LENGTH];
 u32 omap_features;
 
 unsigned int omap_rev(void)
@@ -169,9 +172,12 @@ void __init omap2xxx_check_revision(void)
j = i;
}
 
-   pr_info(OMAP%04x, omap_rev()  16);
+   sprintf(soc_name, OMAP%04x, omap_rev()  16);
+   sprintf(soc_rev, ES%x, (omap_rev()  12)  0xf);
+
+   pr_info(%s, soc_name);
if ((omap_rev()  8)  0x0f)
-   pr_info(ES%x, (omap_rev()  12)  0xf);
+   pr_info(%s, soc_rev);
pr_info(\n);
 }
 
@@ -211,8 +217,10 @@ static void __init omap3_cpuinfo(void)
cpu_name = OMAP3503;
}
 
+   sprintf(soc_name, %s, cpu_name);
+
/* Print verbose information */
-   pr_info(%s ES%s (, cpu_name, cpu_rev);
+   pr_info(%s %s (, soc_name, soc_rev);
 
OMAP3_SHOW_FEATURE(l2cache);
OMAP3_SHOW_FEATURE(iva);
@@ -291,6 +299,7 @@ void __init ti81xx_check_features(void)
 
 void __init omap3xxx_check_revision(void)
 {
+   const char *cpu_rev;
u32 cpuid, idcode;
u16 hawkeye;
u8 rev;
@@ -438,6 +447,7 @@ void __init omap3xxx_check_revision(void)
cpu_rev = 1.2;
pr_warn(Warning: unknown chip type; assuming OMAP3630ES1.2\n);
}
+   sprintf(soc_rev, ES%s, cpu_rev);
 }
 
 void __init omap4xxx_check_revision(void)
@@ -512,8 +522,10 @@ void __init omap4xxx_check_revision(void)
omap_revision = OMAP4430_REV_ES2_3;
}
 
-   pr_info(OMAP%04x ES%d.%d\n, omap_rev()  16,
-   ((omap_rev()  12)  0xf), ((omap_rev()  8)  0xf));
+   sprintf(soc_name, OMAP%04x, omap_rev()  16);
+   sprintf(soc_rev, ES%d.%d, (omap_rev()  12)  0xf,
+   (omap_rev()  8)  0xf);
+   pr_info(%s %s\n, soc_name, soc_rev);
 }
 
 void __init omap5xxx_check_revision(void)
@@ -547,8 +559,10 @@ void __init omap5xxx_check_revision(void)
omap_revision = OMAP5430_REV_ES1_0;
}
 
-   pr_info(OMAP%04x ES%d.0\n,
-   omap_rev()  16, ((omap_rev()  12)  0xf));
+   sprintf(soc_name, OMAP%04x, omap_rev()  16);
+   sprintf(soc_rev, ES%d.0, (omap_rev()  12)  0xf);
+
+   pr_info(%s %s\n, soc_name, soc_rev);
 }
 
 /*
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/2] ARM: OMAP2+: Export SoC information to userspace

[Ruslan Bilovol]

In some situations it is useful for userspace to
know some SoC-specific information. For example,
this may be used for deciding what kernel module to
use or how to better configure some settings etc.
This patch exports OMAP SoC information to userspace
using existing in Linux kernel SoC infrastructure.

This information can be read under
/sys/devices/socX directory

Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
 arch/arm/mach-omap2/common.h |8 ++
 arch/arm/mach-omap2/id.c |   65 ++
 arch/arm/mach-omap2/io.c |1 +
 arch/arm/plat-omap/Kconfig   |1 +
 4 files changed, 75 insertions(+)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 0c3a991..a024084 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -111,6 +111,14 @@ void ti81xx_init_late(void);
 void omap4430_init_late(void);
 int omap2_common_pm_late_init(void);
 
+#ifdef CONFIG_SOC_BUS
+void omap_soc_device_init(void);
+#else
+static inline void omap_soc_device_init(void)
+{
+}
+#endif
+
 #if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
 void omap2xxx_restart(char mode, const char *cmd);
 #else
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 3737700..098e94e 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,11 @@
 #include linux/kernel.h
 #include linux/init.h
 #include linux/io.h
+#include linux/slab.h
+
+#ifdef CONFIG_SOC_BUS
+#include linux/sys_soc.h
+#endif
 
 #include asm/cputype.h
 
@@ -583,3 +588,63 @@ void __init omap2_set_globals_tap(u32 class, void __iomem 
*tap)
else
tap_prod_id = 0x0208;
 }
+
+#ifdef CONFIG_SOC_BUS
+
+static const char const *omap_types[] = {
+   [OMAP2_DEVICE_TYPE_TEST]= TST,
+   [OMAP2_DEVICE_TYPE_EMU] = EMU,
+   [OMAP2_DEVICE_TYPE_SEC] = HS,
+   [OMAP2_DEVICE_TYPE_GP]  = GP,
+   [OMAP2_DEVICE_TYPE_BAD] = BAD,
+};
+
+static const char * __init omap_get_family(void)
+{
+   if (cpu_is_omap24xx())
+   return kasprintf(GFP_KERNEL, OMAP2);
+   else if (cpu_is_omap34xx())
+   return kasprintf(GFP_KERNEL, OMAP3);
+   else if (cpu_is_omap44xx())
+   return kasprintf(GFP_KERNEL, OMAP4);
+   else if (soc_is_omap54xx())
+   return kasprintf(GFP_KERNEL, OMAP5);
+   else
+   return kasprintf(GFP_KERNEL, Unknown);
+}
+
+static ssize_t omap_get_type(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   return sprintf(buf, %s\n, omap_types[omap_type()]);
+}
+
+static struct device_attribute omap_soc_attr =
+   __ATTR(type,  S_IRUGO, omap_get_type,  NULL);
+
+void __init omap_soc_device_init(void)
+{
+   struct device *parent;
+   struct soc_device *soc_dev;
+   struct soc_device_attribute *soc_dev_attr;
+
+   soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+   if (!soc_dev_attr)
+   return;
+
+   soc_dev_attr-machine  = soc_name;
+   soc_dev_attr-family   = omap_get_family();
+   soc_dev_attr-revision = soc_rev;
+
+   soc_dev = soc_device_register(soc_dev_attr);
+   if (IS_ERR_OR_NULL(soc_dev)) {
+   kfree(soc_dev_attr);
+   return;
+   }
+
+   parent = soc_device_to_device(soc_dev);
+   if (!IS_ERR_OR_NULL(parent))
+   device_create_file(parent, omap_soc_attr);
+}
+#endif /* CONFIG_SOC_BUS */
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 2c3fdd6..08003c1 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -602,6 +602,7 @@ void __init omap4430_init_late(void)
omap2_common_pm_late_init();
omap4_pm_init();
omap2_clk_enable_autoidle_all();
+   omap_soc_device_init();
 }
 #endif
 
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 1fbac36..24b5687 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -30,6 +30,7 @@ config ARCH_OMAP2PLUS
select PROC_DEVICETREE if PROC_FS
select SPARSE_IRQ
select USE_OF
+   select SOC_BUS
help
  Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] watchdog: introduce retu_wdt driver

[Paul Walmsley]

Hi Wim,

On Mon, 28 Jan 2013, Aaro Koskinen wrote:

 On Thu, Dec 27, 2012 at 10:58:29PM +0200, Aaro Koskinen wrote:
  Introduce Retu watchdog driver.
 
 Wim, any comments about this driver? Do you think it could be queued
 for 3.9?

It'd be really great if this could go in for v3.9.  Without it, Nokia N800 
boards crash shortly after boot because the Retu watchdog isn't being 
tickled :-(


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.8-rc5

[Paul Walmsley]

On Sat, 26 Jan 2013, Felipe Balbi wrote:

 Hi,
 
 On Sat, Jan 26, 2013 at 08:40:07AM +, Paul Walmsley wrote:
  Boot tests:
  
  * am335xbone: hangs after Starting kernel
- Cause unknown; may be due to CONFIG_EARLY_PRINTK=y?
- http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html
- http://marc.info/?l=linux-omapm=135903184512238w=2
 
 FYI, I don't think it's related to CONFIG_EARLY_PRINTK. Tested with and
 without it, also removed CONFIG_DEBUG_LL completely and nothing seemed
 to help my bone, no matter if I had appended DTB or not.

Thanks, I've adjusted the (upcoming) message for v3.8-rc6 accordingly.


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode

[Paul Walmsley]

Hi Matthieu,

On Tue, 22 Jan 2013, Paul Walmsley wrote:

 Any progress on updating and resending your omap3 nand : use 
 NAND_BUSWIDTH_AUTO patch?  We're in danger of missing the 3.9 merge 
 window if it takes too much longer.

Could you let us know if you're planning to update and repost this one?

thanks,

- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

OMAP baseline test results for v3.8-rc6

[Paul Walmsley]

Here are some basic OMAP test results for Linux v3.8-rc6.
Logs and other details at:

http://www.pwsan.com/omap/testlogs/test_v3.8-rc6/20130206155004/


Test summary


Boot to userspace:
Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
  3730beaglexm, 37xxevm, 4430es2panda, 5912osk,
  4460pandaes
FAIL ( 2/11): am335xbone, cmt3517 
  
PM ret/off, suspend + dynamic idle:
Pass (3/3): 3530es3beagle, 3730beaglexm, 37xxevm

PM ret, suspend + dynamic idle:
Pass (1/2): 4460pandaes
FAIL (1/2): 4430es2panda

PM ret, dynamic idle:
FAIL (1/1): 2430sdp


Failing tests: fixed by posted patches
--

Other:

* 2420N800: powers down 30 seconds after boot
  - Presumably due to missing CBUS patches for watchdog control
  - http://lkml.org/lkml/2012/9/3/265
  - http://marc.info/?l=linux-omapm=135274739624125w=2
  - http://marc.info/?l=linux-omapm=135664195831104w=2


Failing tests: needing investigation


Boot tests:

* am335xbone: hangs after Starting kernel
  - Cause unknown
  - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html
  - http://marc.info/?l=linux-omapm=135903184512238w=2
  - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg83942.html

* 3517EVM  CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC
  - Longstanding bug

* CM-T3517: boot hangs with MMC root
  - Due to missing MMC setup in board file
  - http://www.spinics.net/lists/arm-kernel/msg211471.html

Boot warnings:

* 3530es3beagle, 3730beaglexm, 37xxevm: nand_scan_ident() warning
  - at drivers/mtd/nand/nand_base.c:2861 nand_scan_ident+0xdb4/0xf90()
  - http://marc.info/?l=linux-omapm=135630897110185w=2

* CM-T3517: L3 in-band error with IPSS during boot
  - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2
  - Longstanding issue; does not occur on the 3517EVM

PM tests:

* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
  - need to doublecheck wakeup dependencies

* 2430sdp: power domains not entering retention
  - Cause unknown

* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE

* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA 

* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
  - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
  - Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock gate (debug ignore_loglevel)
  - Cause unknown
  - Not yet part of the automated test suite
  - Re-tested at v3.7; still failing:

http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt

Other:

* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
  - Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
  - Jon Hunter reports this does not appear with the same X-loader/bootloader
on his 4430ES2.3 Panda, so could be ES-level dependent


Failing tests: needing local investigation (may be due to testbed issues)
-

Boot tests:

* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
  - May be fixed now, pending retest:
- http://marc.info/?l=linux-omapm=135082257727502w=2
  - Not yet part of the automated test suite
  - Nishanth Menon  Vaibhav Hiremath report that it works for them
  * May be due to an old U-boot with FDT support problems used here?
Pending local investigation and re-test


Problems reported by others
---

(none currently listed)

--
Branch: test_v3.8-rc6
Test-Serial: 20130206155004
Commit-ID: 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7
Test-Target-Board-Count: 11
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP4: PM: Warn users about usage of older bootloaders

[Paul Walmsley]

On Mon, 4 Feb 2013, Rajendra Nayak wrote:

 OMAP4 CHIP level PM works only with newer bootloaders. The
 dependency on the bootloader comes from the fact that the
 kernel is missing reset and initialization code for some
 devices.
 
 While the right thing to do is to add reset and init code in
 the kernel, for some co-processor IP blocks like DSP and IVA
 it means downloading firmware into each one of them to execute
 idle instructions.
 
 While a feasible solution is worked upon on how such IP blocks
 can be better handled in the kernel, in the interim, to avoid
 any further frustration to users testing PM on OMAP4 and finding
 it broken, warn them about the bootloader being a possible
 cause.
 
 Signed-off-by: Rajendra Nayak rna...@ti.com
 Cc: Tero Kristo t-kri...@ti.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: R Sricharan r.sricha...@ti.com

Thanks Rajendra, I appreciate the patch.  I've tweaked it slightly and the 
following is what's queued here; hopefully it can go in for v3.9.


- Paul

From: Rajendra Nayak rna...@ti.com
Date: Mon, 4 Feb 2013 17:54:43 +0530
Subject: [PATCH] ARM: OMAP4: PM: Warn users about usage of older bootloaders

OMAP4 CHIP level PM works only with newer bootloaders. The
dependency on the bootloader comes from the fact that the
kernel is missing reset and initialization code for some
devices.

While the right thing to do is to add reset and init code in
the kernel, for some co-processor IP blocks like DSP and IVA
it means downloading firmware into each one of them to execute
idle instructions.

While a feasible solution is worked upon on how such IP blocks
can be better handled in the kernel, in the interim, to avoid
any further frustration to users testing PM on OMAP4 and finding
it broken, warn them about the bootloader being a possible
cause.

Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: R Sricharan r.sricha...@ti.com
[p...@pwsan.com: tweaked warning messages and comments slightly]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
 arch/arm/mach-omap2/pm44xx.c |   19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index aa6fd98..502ed9b 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -77,8 +77,18 @@ static int omap4_pm_suspend(void)
omap_set_pwrdm_state(pwrst-pwrdm, pwrst-saved_state);
pwrdm_set_logic_retst(pwrst-pwrdm, pwrst-saved_logic_state);
}
-   if (ret)
+   if (ret) {
pr_crit(Could not enter target state in pm_suspend\n);
+   /*
+* OMAP4 chip PM currently works only with certain (newer)
+* versions of bootloaders. This is due to missing code in the
+* kernel to properly reset and initialize some devices.
+* Warn the user about the bootloader version being one of the
+* possible causes.
+* http://www.spinics.net/lists/arm-kernel/msg218641.html
+*/
+   pr_warn(A possible cause could be an old bootloader - try 
u-boot = v2012.07\n);
+   }
else
pr_info(Successfully put all powerdomains to target state\n);
 
@@ -146,6 +156,13 @@ int __init omap4_pm_init(void)
}
 
pr_err(Power Management for TI OMAP4.\n);
+   /*
+* OMAP4 chip PM currently works only with certain (newer)
+* versions of bootloaders. This is due to missing code in the
+* kernel to properly reset and initialize some devices.
+* http://www.spinics.net/lists/arm-kernel/msg218641.html
+*/
+   pr_warn(u-boot = v2012.07 is required for full PM support\n);
 
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/8] ARM: dts: omap: Add usb_otg and glue data

[Rajendra Nayak]

[]...



diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB GLUE
 represents PERIPHERAL.
   - power : Should be 50. This signifies the controller can supply upto
 100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device

  SOC specific device node entry
  usb_otg_hs: usb_otg_hs@4a0ab000 {
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..cb07583 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -107,3 +107,9 @@
 */
ti,pulldowns = 0x03a1c4;
  };
+
+usb_otg_hs {
+   interface_type = 0;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..afb9ba9 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -59,3 +59,9 @@
  twl_gpio {
ti,use-leds;
  };
+
+usb_otg_hs {
+   interface_type = 0;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..4b3d157 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -55,3 +55,9 @@
  twl_gpio {
ti,use-leds;
  };
+
+usb_otg_hs {
+   interface_type = 0;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..b6472f7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,17 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+   usb_otg_hs: usb_otg_hs@480ab000 {
+   compatible = ti,omap3-musb;
+   reg = 0x480ab000 0x1000;
+   interrupts = 0 92 0x4, 0 93 0x4;
+   interrupt-names = mc, dma;
+   ti,hwmods = usb_otg_hs;
+   usb-phy = usb2_phy;
+   multipoint = 1;
+   num_eps = 16;
+   ram_bits = 12;


Where are these bindings documented? The general convention is to use
a '-' for property names and not '_'


+   };
};
  };
diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..612c9bb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -206,3 +206,9 @@
  twl_usb_comparator {
usb-supply = vusb;
  };
+
+usb_otg_hs {
+   interface_type = 1;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..582d7ee 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -428,3 +428,9 @@
  twl_usb_comparator {
usb-supply = vusb;
  };
+
+usb_otg_hs {
+   interface_type = 1;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index c829d7e..5171739 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -542,5 +542,18 @@
reg-names = control_dev_conf, otghs_control;
ti,type = 1;
};
+
+   usb_otg_hs: usb_otg_hs@4a0ab000 {
+   compatible = ti,omap4-musb;
+   reg = 0x4a0ab000 0x7ff;
+   interrupts = 0 92 0x4, 0 93 0x4;
+   interrupt-names = mc, dma;
+   ti,hwmods = usb_otg_hs;
+   usb-phy = usb2_phy;
+   multipoint = 1;
+   num_eps = 16;
+   ram_bits = 12;
+   ti,has-mailbox;
+   };
};
  };
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index ed0bc95..398d2c3 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -67,7 +67,7 @@
#interrupt-cells = 1;
};

-   twl4030-usb {
+   usb2_phy: twl4030-usb {
compatible = ti,twl4030-usb;
interrupts = 10, 4;
usb1v5-supply = vusb1v5;



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/8] ARM: dts: omap: Add usb_otg and glue data

[kishon]

Hi,

On Thursday 07 February 2013 11:51 AM, Rajendra Nayak wrote:

[]...



diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB GLUE
 represents PERIPHERAL.
   - power : Should be 50. This signifies the controller can supply
upto
 100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device

  SOC specific device node entry
  usb_otg_hs: usb_otg_hs@4a0ab000 {
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..cb07583 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -107,3 +107,9 @@
   */
  ti,pulldowns = 0x03a1c4;
  };
+
+usb_otg_hs {
+interface_type = 0;
+mode = 3;
+power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts
b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..afb9ba9 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -59,3 +59,9 @@
  twl_gpio {
  ti,use-leds;
  };
+
+usb_otg_hs {
+interface_type = 0;
+mode = 3;
+power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..4b3d157 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -55,3 +55,9 @@
  twl_gpio {
  ti,use-leds;
  };
+
+usb_otg_hs {
+interface_type = 0;
+mode = 3;
+power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..b6472f7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,17 @@
  ti,timer-alwon;
  ti,timer-secure;
  };
+
+usb_otg_hs: usb_otg_hs@480ab000 {
+compatible = ti,omap3-musb;
+reg = 0x480ab000 0x1000;
+interrupts = 0 92 0x4, 0 93 0x4;
+interrupt-names = mc, dma;
+ti,hwmods = usb_otg_hs;
+usb-phy = usb2_phy;
+multipoint = 1;
+num_eps = 16;
+ram_bits = 12;


Where are these bindings documented? The general convention is to use
a '-' for property names and not '_'


It's documented in Documentation/devicetree/bindings/usb/omap-usb.txt
Actually the documentation and the drivers got merged with this binding 
long back.


Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Peter Ujfalusi]

Hi,

On 02/06/2013 02:30 PM, Benoit Cousson wrote:
 So a patch is being merged to handle triggers in the case of pwm leds [1].
 When done, we will be able to add back the default trigger. Do you want
 to wait on it to merge this series?
 
 What kind of dependency do we have between these two series? I mean what
 will happen if the DTS is merged before the pwm subsystem?
 
 If that does not generate any regression / crash, then it is OK, if not,
 we should take care of the order.

In this series the 'linux,default-trigger' property is not added to the
pwm-leds node, so it is safe to take this series.
I'm sure Florian will send the update to add this flag back for 3.10 or for
3.9-rc (the needed patches for PWM and leds-pwm will be in 3.9).

I'm also waiting for 3.9-rc1 so I can finish up some of the pending things
regarding to PWMs.

-- 
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html