Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Michael Trimarchi]

Hi

On Fri, Nov 27, 2015 at 9:38 AM, Pali Rohár  wrote:
> On Thursday 26 November 2015 12:39:30 Tony Lindgren wrote:
>> Just to explore options.. How about make a minimal device driver that
>> just loads the atags blob from /lib/firmware and then shows it in
>> /proc/atags? Of course some checking on the atags should be done by
>> the driver..
>
> And who can dynamically create that blob file in /lib/firmware? If
> kernel does not export those atags (somehow) from bootloader, then
> userspace is not able to create that blob... cyclic problem.
>

Are those atags from bootloader fix or they change device by device. If they
are fixed they can be included in some firmware and get from the disk.

Michael

> So no, problem is that bootloader provides via custom atags dynamic
> information like: boot reason (how was device started, by rtc alarm? by
> reboot? by usb charger? by power button?), boot mode (should be enter
> into firmware update mode?, is this normal boot mode?), ... and those
> information are needed for some proprietary software (e.g. firmware
> upgrade/flash) but also by any other open source applications (based on
> usb charger we enter different runlevel -- for just only charging
> device).
>
> --
> Pali Rohár
> pali.ro...@gmail.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
--
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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Michael Trimarchi]

Hi

On Fri, Nov 27, 2015 at 9:44 AM, Michael Trimarchi
<mich...@amarulasolutions.com> wrote:
> Hi
>
> On Fri, Nov 27, 2015 at 9:38 AM, Pali Rohár <pali.ro...@gmail.com> wrote:
>> On Thursday 26 November 2015 12:39:30 Tony Lindgren wrote:
>>> Just to explore options.. How about make a minimal device driver that
>>> just loads the atags blob from /lib/firmware and then shows it in
>>> /proc/atags? Of course some checking on the atags should be done by
>>> the driver..
>>
>> And who can dynamically create that blob file in /lib/firmware? If
>> kernel does not export those atags (somehow) from bootloader, then
>> userspace is not able to create that blob... cyclic problem.
>>
>
> Are those atags from bootloader fix or they change device by device. If they
> are fixed they can be included in some firmware and get from the disk.
>

Sorry, miss the second part of email ;)

Michael

> Michael
>
>> So no, problem is that bootloader provides via custom atags dynamic
>> information like: boot reason (how was device started, by rtc alarm? by
>> reboot? by usb charger? by power button?), boot mode (should be enter
>> into firmware update mode?, is this normal boot mode?), ... and those
>> information are needed for some proprietary software (e.g. firmware
>> upgrade/flash) but also by any other open source applications (based on
>> usb charger we enter different runlevel -- for just only charging
>> device).
>>
>> --
>> Pali Rohár
>> pali.ro...@gmail.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



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.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: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Michael Trimarchi]

Hi

Do you have /sys/kernel/debug/clk/clock_summary?

Michael

On Tue, Nov 24, 2015 at 7:50 PM, Daniel. <danielhi...@gmail.com> wrote:
> Doing some printk mess I found that the usbhost_48m_fck is enabled. So
> my problem should be another thing:
>
> clock.c:omap2_dflt_clk_enable@193: usbhost_48m_fck enable_reg value 0x01
>
> 2015-11-23 18:10 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
>> Hi
>>
>> Can you check if you have this patch in?
>>
>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
>> Author: Paul Walmsley <p...@pwsan.com>
>> Date:   Fri Jul 24 19:44:06 2009 -0600
>>
>> OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
>>
>> Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
>> USBHOST, and HSOTGUSB devices.  These devices are both interconnect
>> initiators and targets.  Without this patch, clk_enable()s on clocks for
>> these modules can be very high latency (potentially up to ~200
>> milliseconds) and message such as the following are generated:
>>
>> Clock usbhost_48m_fck didn't enable in 10 tries
>>
>> Two bugs are fixed by this patch.  First, OMAP hardware only supports
>> target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
>> should not wait for these clocks to enable.  So, split the appropriate
>> clocks into ES1 and ES2+ variants, so that kernels running on ES1
>> devices won't try to wait.
>>
>> Second, the current heuristic in omap2_clk_dflt_find_idlest() will
>> fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
>> is the same as the CM_*CLKEN bit, which is false[1].  Fix by
>> implementing custom clkops .find_idlest function pointers for the
>> appropriate clocks that return the correct slave IDLEST bit shift.
>>
>> This was originally fixed in the linux-omap kernel during 2.6.29 in a
>> slightly different manner[2][3].
>>
>>
>> On Mon, Nov 23, 2015 at 9:06 PM, Daniel. <danielhi...@gmail.com> wrote:
>>> Hi,
>>>
>>> Building as built-in doesn't solve my problem. The difference is that
>>> when compiled as module the dump shows up when I load it, and when is
>>> built-in the dump shows up at boot time. Also when built-in the
>>> problem seems to ocurr when device is reseted (on ehci_omap_stop) and
>>> the first stack dump is followed by much more other dumps. At the end
>>> I can see something like: "Fixing recursive fault but reboot is
>>> needed!"
>>>
>>>
>>> Here is the module info:
>>> root@csi:~# modinfo ehci-hcd
>>> filename:   /lib/modules/2.6.37+/kernel/drivers/usb/host/ehci-hcd.ko
>>> author: Felipe Balbi <felipe.ba...@nokia.com>
>>> author: Texas Instruments, Inc.
>>> alias:  platform:omap-ehci
>>> license:GPL
>>> author: David Brownell
>>> description:USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>>> srcversion: B282C11CACFB9E75921367C
>>> depends:
>>> vermagic:   2.6.37+ mod_unload modversions ARMv7
>>> parm:   log2_irq_thresh:log2 IRQ latency, 1-64 microframes (int)
>>> parm:   park:park setting; 1-3 back-to-back async packets (uint)
>>> parm:   ignore_oc:ignore bogus hardware overcurrent indications 
>>> (bool)
>>> parm:   hird:host initiated resume duration, +1 for each 75us
>>>  (int)
>>> root@csi:~#
>>>
>>>
>>> Best regards,
>>>
>>> 2015-11-23 17:55 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
>>>> Hi
>>>>
>>>> On Mon, Nov 23, 2015 at 8:05 PM, Daniel. <danielhi...@gmail.com> wrote:
>>>>> Hi Michael,
>>>>>
>>>>> It's a plain linux. I'm considering upgrading kernel as last option.
>>>>> Variscite doesn't
>>>>> support another kernel for this SoM so this would be a really hard
>>>>> work. I'm looking
>>>>> for a solution on this kernel and mainly trying to understand why
>>>>> usbhost_48m_fck
>>>>> is not getting enabled. I'm contacting Variscite in parallel.
>>>>>
>>>>
>>>> Can you point me to te module description? I think that the module
>>>> is working if it's compiled in. Correct?
>>>>
>>>> Michael
>>>>
>>>>
>>>>> Thanks for your re

Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Michael Trimarchi]

Hi

On Mon, Nov 23, 2015 at 8:05 PM, Daniel. <danielhi...@gmail.com> wrote:
> Hi Michael,
>
> It's a plain linux. I'm considering upgrading kernel as last option.
> Variscite doesn't
> support another kernel for this SoM so this would be a really hard
> work. I'm looking
> for a solution on this kernel and mainly trying to understand why
> usbhost_48m_fck
> is not getting enabled. I'm contacting Variscite in parallel.
>

Can you point me to te module description? I think that the module
is working if it's compiled in. Correct?

Michael


> Thanks for your reply, best regards!
>
> 2015-11-23 16:57 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
>> Hi Daniel
>>
>>
>> On Mon, Nov 23, 2015 at 7:45 PM, Daniel. <danielhi...@gmail.com> wrote:
>>> Hi every body!
>>>
>>> I'm running a (2.6.37) kernel based on linux-omap tree
>>> (http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary).
>>> The board is a SoM from Variscite (var-som-am3517).
>>>
>>> I've compiled the ehci-hcd as a module. When I enable it I got this dump:
>>> http://pastebin.com/5idXXBBi
>>>
>>
>> Do you have an android device? or it's just plain linux.
>> For option 2 I suggest to move on newest kernel
>>
>> Michael
>>
>>> Googling arroud I found that this can be triggered while trying to
>>> access uhh registers when usbhost_48m_fck is not enabled. This is what
>>> I think is happening since the message
>>> "Clock usbhost_48m_fck didn't enable in 10 tries" is aways present
>>> before the crash, and since the crash happens at first read o uhh
>>> registers. I just can't figure out why usbhost_48m_fck is not getting
>>> enabled and how to check if is trully disabled.
>>>
>>> Any ideas?
>>>
>>> Thanks in advance!
>>> Regards,
>>>
>>> --
>>> "Do or do not. There is no try"
>>>   Yoda Master
>>> --
>>> 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
>>
>>
>>
>> --
>> | Michael Nazzareno Trimarchi Amarula Solutions BV |
>> | COO  -  Founder  Cruquiuskade 47 |
>> | +31(0)851119172 Amsterdam 1018 AM NL |
>> |  [`as] http://www.amarulasolutions.com   |
>
>
>
> --
> "Do or do not. There is no try"
>   Yoda Master
> --
> 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



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.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: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Michael Trimarchi]

Hi

Can you check if you have this patch in?

commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
Author: Paul Walmsley <p...@pwsan.com>
Date:   Fri Jul 24 19:44:06 2009 -0600

OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB

Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:

Clock usbhost_48m_fck didn't enable in 10 tries

Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.

Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.

This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].


On Mon, Nov 23, 2015 at 9:06 PM, Daniel. <danielhi...@gmail.com> wrote:
> Hi,
>
> Building as built-in doesn't solve my problem. The difference is that
> when compiled as module the dump shows up when I load it, and when is
> built-in the dump shows up at boot time. Also when built-in the
> problem seems to ocurr when device is reseted (on ehci_omap_stop) and
> the first stack dump is followed by much more other dumps. At the end
> I can see something like: "Fixing recursive fault but reboot is
> needed!"
>
>
> Here is the module info:
> root@csi:~# modinfo ehci-hcd
> filename:   /lib/modules/2.6.37+/kernel/drivers/usb/host/ehci-hcd.ko
> author: Felipe Balbi <felipe.ba...@nokia.com>
> author: Texas Instruments, Inc.
> alias:  platform:omap-ehci
> license:GPL
> author: David Brownell
> description:USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> srcversion: B282C11CACFB9E75921367C
> depends:
> vermagic:   2.6.37+ mod_unload modversions ARMv7
> parm:   log2_irq_thresh:log2 IRQ latency, 1-64 microframes (int)
> parm:   park:park setting; 1-3 back-to-back async packets (uint)
> parm:   ignore_oc:ignore bogus hardware overcurrent indications (bool)
> parm:   hird:host initiated resume duration, +1 for each 75us
>  (int)
> root@csi:~#
>
>
> Best regards,
>
> 2015-11-23 17:55 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
>> Hi
>>
>> On Mon, Nov 23, 2015 at 8:05 PM, Daniel. <danielhi...@gmail.com> wrote:
>>> Hi Michael,
>>>
>>> It's a plain linux. I'm considering upgrading kernel as last option.
>>> Variscite doesn't
>>> support another kernel for this SoM so this would be a really hard
>>> work. I'm looking
>>> for a solution on this kernel and mainly trying to understand why
>>> usbhost_48m_fck
>>> is not getting enabled. I'm contacting Variscite in parallel.
>>>
>>
>> Can you point me to te module description? I think that the module
>> is working if it's compiled in. Correct?
>>
>> Michael
>>
>>
>>> Thanks for your reply, best regards!
>>>
>>> 2015-11-23 16:57 GMT-02:00 Michael Trimarchi <mich...@amarulasolutions.com>:
>>>> Hi Daniel
>>>>
>>>>
>>>> On Mon, Nov 23, 2015 at 7:45 PM, Daniel. <danielhi...@gmail.com> wrote:
>>>>> Hi every body!
>>>>>
>>>>> I'm running a (2.6.37) kernel based on linux-omap tree
>>>>> (http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary).
>>>>> The board is a SoM from Variscite (var-som-am3517).
>>>>>
>>>>> I've compiled the ehci-hcd as a module. When I enable it I got this dump:
>>>>> http://pastebin.com/5idXXBBi
>>>>>
>>>>
>>>> Do you have an android device? or it's just plain linux.
>>>> For option 2 I suggest to move on newest kernel
>>>>
>>>> Michael
>>>>
>>>>> Googling arroud I found that this can be triggered while trying to
>>>>> access uhh registers when usbhost_48m_fck is not enabled. This is what
>>>>> I think 

Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Michael Trimarchi]

Hi Daniel


On Mon, Nov 23, 2015 at 7:45 PM, Daniel.  wrote:
> Hi every body!
>
> I'm running a (2.6.37) kernel based on linux-omap tree
> (http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary).
> The board is a SoM from Variscite (var-som-am3517).
>
> I've compiled the ehci-hcd as a module. When I enable it I got this dump:
> http://pastebin.com/5idXXBBi
>

Do you have an android device? or it's just plain linux.
For option 2 I suggest to move on newest kernel

Michael

> Googling arroud I found that this can be triggered while trying to
> access uhh registers when usbhost_48m_fck is not enabled. This is what
> I think is happening since the message
> "Clock usbhost_48m_fck didn't enable in 10 tries" is aways present
> before the crash, and since the crash happens at first read o uhh
> registers. I just can't figure out why usbhost_48m_fck is not getting
> enabled and how to check if is trully disabled.
>
> Any ideas?
>
> Thanks in advance!
> Regards,
>
> --
> "Do or do not. There is no try"
>   Yoda Master
> --
> 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



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.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] base: power: wakeirq: don't leak dev-power.wakeirq

[Michael Trimarchi]

Hi

On Mon, Jul 6, 2015 at 8:09 PM, Felipe Balbi ba...@ti.com wrote:
 On Mon, Jul 06, 2015 at 08:06:17PM +0200, Michael Trimarchi wrote:
 Hi

 On Jul 6, 2015 8:01 PM, Felipe Balbi ba...@ti.com wrote:
 
  on a first call to dev_pm_attach_wake_irq(), if it
  fails, it will leave dev-power.wakeirq set to a
  dangling pointer. Instead, let's clear it to make
  sure a subsequent call to dev_pm_attach_wake_irq()
  has chance to succeed.
 
  Cc: Tony Lindgren tml...@atomide.com
  Signed-off-by: Felipe Balbi ba...@ti.com
  ---
   drivers/base/power/wakeirq.c | 9 -
   1 file changed, 8 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c
  index 7470004ca810..394d250a1ad8 100644
  --- a/drivers/base/power/wakeirq.c
  +++ b/drivers/base/power/wakeirq.c
  @@ -50,9 +50,16 @@ static int dev_pm_attach_wake_irq(struct device *dev,
 int irq,
 
  err = device_wakeup_attach_irq(dev, wirq);
  if (err)
  -   return err;
  +   goto err_cleanup;
 
  return 0;
  +
  +err_cleanup:
  +   spin_lock_irqsave(dev-power.lock, flags);
  +   dev-power.wakeirq = NULL;
  +   spin_unlock_irqrestore(dev-power.lock, flags);
  +

 Why here and not in the fuction that return the error?

 because the field was set here, why would I clear it elsewhere ?


Clear now and even more from the other patch proposal.

Michael

 --
 balbi



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.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: [RFC PATCH] usb: dwc3: ep0: Fix mem corruption on OUT transfers of more than 512 bytes

[Michael Trimarchi]

Hi

On Tue, Jun 9, 2015 at 3:44 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
 Hi,

 On Tuesday 09 June 2015 08:09 PM, Michael Trimarchi wrote:

 Hi

 On Jun 9, 2015 4:36 PM, Kishon Vijay Abraham I kis...@ti.com
 mailto:kis...@ti.com wrote:
  
   DWC3 uses bounce buffer to handle non max packet aligned OUT transfers
 and
   the size of bounce buffer is 512 bytes. However if the host initiates
 OUT
   transfers of size more than 512 bytes (and non max packet aligned), the
   driver throws a WARN dump but still programs the TRB to receive more
 than
   512 bytes. This will cause bounce buffer to overflow and corrupt the
   adjacent memory locations which can be fatal.
  
   Fix it by programming the TRB to receive a maximum of
 DWC3_EP0_BOUNCE_SIZE
   (512) bytes.
  
   Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 mailto:kis...@ti.com

   ---
   Steps to see the issue (before this patch)
   1) Insert g_zero in DUT
   2) run './testusb -t 14 -c 1 -s 520 -v 1' in host (size should be 
 512)
  
   The test should FAIL since bounce buffer can handle only 512 bytes, but
 the
   test PASS. There is a WARN dump in DUT but still there will be memory
   corruption since the bounce buffer overflows.
  
   Tested this patch using USB3 Gen X CV (ch9 tests: usb2 and usb3, link
 layer
   testing and MSC tests) and using USB2 X CV (ch9 tests, MSC tests).
  
   After the patch, the tests timeout!
   ./testusb -t 14 -c 1 -s 514 -v 1
   unknown speed   /dev/bus/usb/001/0180
   /dev/bus/usb/001/018 test 14 -- 110 (Connection timed out)
  
   IMO a patch to fix this is required for stable releases too. So If this
   patch is alright, I can post the patch cc'ing stable. While the actual
 fix
   would be to have chained TRB, I'm not sure if it can go to stable
   releases.
drivers/usb/dwc3/ep0.c |   12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
  
   diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
   index 2ef3c8d..8858c60 100644
   --- a/drivers/usb/dwc3/ep0.c
   +++ b/drivers/usb/dwc3/ep0.c
   @@ -816,6 +816,11 @@ static void dwc3_ep0_complete_data(struct dwc3
 *dwc,
   unsigned maxp = ep0-endpoint.maxpacket;
  
   transfer_size += (maxp - (transfer_size % maxp));
   +
   +   /* Maximum of DWC3_EP0_BOUNCE_SIZE can only be received
 */
   +   if (transfer_size  DWC3_EP0_BOUNCE_SIZE)
   +   transfer_size = DWC3_EP0_BOUNCE_SIZE;
   +

 Can you just use maxp in the correct way?


 what do you mean by correct way? Using roundup() to calculate transfer_size?


just a max

Michael

 Thanks
 Kishon



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.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: reboot command fails with low frequency

[Michael Trimarchi]

Hi

On Thu, Mar 5, 2015 at 9:46 AM, Ran Shalit ransha...@gmail.com wrote:
 I added power support to kernel menuconfig, such as cpuidle, and it
 seems to work fine. I also validated in counter that cpu gets into
 retention.

 We observer that with highest available frequency (60) reboot
 command is OK, but when frequency is changed to lower value, the
 reboot command fails.
 Has anyone observed such behaviour ?

I remember some commit for this problem. What version of the linux are
you running?

Michael


 Regards,
 Ran
 --
 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
--
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: reboot command fails with low frequency

[Michael Trimarchi]

Hi

You should find the twl4030 power script and you should have something like this

static struct twl4030_ins wrst_seq[] __initdata = {
{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
{MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
{MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
{MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
{MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
};

static struct twl4030_script wrst_script __initdata = {
.script = wrst_seq,
.size   = ARRAY_SIZE(wrst_seq),
.flags  = TWL4030_WRST_SCRIPT,
};

static struct twl4030_script *omap3_power_scripts[] __initdata = {
wrst_script,
};

If I remember it was solved by some change here. In my old kernel I
have this commit

 Fix the reboot at lower frequency

Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com

diff --git a/arch/arm/mach-omap2/board-panther.c
b/arch/arm/mach-omap2/board-panther.c
index ad2adf3..c71fdd9 100644
--- a/arch/arm/mach-omap2/board-panther.c
+++ b/arch/arm/mach-omap2/board-panther.c
@@ -368,7 +368,7 @@ static int __init panther_i2c_init(void)
 {
omap3_pmic_get_config(panther_twldata,
TWL_COMMON_PDATA_MADC |
-   TWL_COMMON_PDATA_AUDIO,
+   TWL_COMMON_PDATA_AUDIO | TWL_COMMON_PDATA_POWER,
TWL_COMMON_REGULATOR_VDAC);

omap3_pmic_init(twl4030, panther_twldata);

But this apply on an old device with a newer kernel and I don't
remember now the reason ;) Sorry.

Is this an android device? (2.6.37??? is really old)

Michael

On Thu, Mar 5, 2015 at 10:29 AM, Ran Shalit ransha...@gmail.com wrote:
 We observer that with highest available frequency (60) reboot
 command is OK, but when frequency is changed to lower value, the
 reboot command fails.
 Has anyone observed such behaviour ?

 I remember some commit for this problem. What version of the linux are
 you running?

 I use Linux version 2.6.37 #36 PREEMPT Thu Mar 5 10:56:04 IST 2015
 armv7l GNU/Linux

 Do you know how I can find this fix ?

 Thanks!
 Ran



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.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: OMAP3/AM3517 EHCI USB Issue

[Michael Trimarchi]

Hi Roger

On Fri, Sep 19, 2014 at 11:22 AM, Roger Quadros rog...@ti.com wrote:
 Hi Michael,

 On 08/04/2014 06:27 PM, Michael Welling wrote:
 On Mon, Aug 04, 2014 at 12:34:16PM +0300, Roger Quadros wrote:
 On 08/02/2014 02:51 AM, Michael Welling wrote:
 On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling mwell...@emacinc.com 
 wrote:
 On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote:
 On 07/29/2014 06:20 PM, Michael Welling wrote:
 On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote:
 Hi Michael,

 On 07/28/2014 09:10 PM, Felipe Balbi wrote:
 On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote:
 On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote:
 Hi,

 On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote:
 On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote:
 On Fri, 25 Jul 2014, Michael Welling wrote:

 The plot thickens

 So if I run the above command before anything is plugged into 
 the ports
 the HUB disconnects.

 root@som3517:~# echo on  /sys/bus/usb/devices/1-1/power/control
 [   63.068839] usb 1-1: USB disconnect, device number 2

 Here is the output of the usbmon output when running the above 
 command:
 root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t
 de382e40 376573 S Ci:001:00 s a3 00  0001 0004 4 
 de382e40 3788890604 C Ci:001:00 0 4 = 0705
 de382e40 3788892965 S Ci:001:00 s a3 00  0002 0004 4 
 de382e40 3788893093 C Ci:001:00 0 4 = 0001
 de382e40 3788894834 S Ci:001:00 s a3 00  0003 0004 4 
 de382e40 3788894958 C Ci:001:00 0 4 = 0001
 de7d92c0 3788896519 S Ii:001:01 -115 4 
 de382e40 3788898778 S Ci:001:00 s a3 00  0001 0004 4 
 de382e40 3788900188 C Ci:001:00 0 4 = 0705
 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001  0
 de382e40 3788905793 C Co:001:00 0 0
 de382e40 3788940998 S Ci:001:00 s a3 00  0001 0004 4 
 de7d92c0 3788942065 C Ii:001:01 0 1 = 02
 de7d92c0 3788943013 S Ii:001:01 -115 4 
 de382e40 3788943145 C Ci:001:00 0 4 = 03050400
 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001  0
 de382e40 3788961175 C Co:001:00 0 0
 de382e40 3788961304 S Ci:002:00 s 80 00   0002 2 
 de382e40 3788965395 C Ci:002:00 -71 0
 de249040 3788966954 S Co:001:00 s 23 03 0004 0001  0
 de249040 3788968362 C Co:001:00 0 0
 de249040 3789021103 S Ci:001:00 s a3 00  0001 0004 4 
 de7d92c0 3789022194 C Ii:001:01 0 1 = 02
 de7d92c0 378906 S Ii:001:01 -115 4 
 de249040 3789023423 C Ci:001:00 0 4 = 01051200
 de249040 3789025010 S Co:001:00 s 23 03 0004 0001  0
 de249040 3789026815 C Co:001:00 0 0
 de249040 3789230980 S Ci:001:00 s a3 00  0001 0004 4 
 de249040 378923 C Ci:001:00 0 4 = 00010300
 de249040 3789232280 S Co:001:00 s 23 01 0014 0001  0
 de249040 3789232404 C Co:001:00 0 0
 de249040 3789233056 S Co:001:00 s 23 01 0001 0001  0
 de249040 3789235345 C Co:001:00 0 0
 de249040 3789236820 S Co:001:00 s 23 01 0001 0001  0
 de249040 3789237201 C Co:001:00 0 0
 de249040 3789238180 S Co:001:00 s 23 01 0001 0001  0
 de249040 3789238510 C Co:001:00 0 0
 de249040 3789240602 S Ci:001:00 s a3 00  0001 0004 4 
 de249040 3789241661 C Ci:001:00 0 4 = 00010300
 de249040 3789242264 S Co:001:00 s 23 01 0010 0001  0
 de249040 3789243921 C Co:001:00 0 0
 de249040 3789246540 S Co:001:00 s 23 01 0011 0001  0
 de249040 3789246930 C Co:001:00 0 0
 de2490c0 3789283096 S Ci:001:00 s a3 00  0001 0004 4 
 de2490c0 3789286255 C Ci:001:00 0 4 = 0001
 de2490c0 3789330975 S Ci:001:00 s a3 00  0001 0004 4 
 de2490c0 3789332606 C Ci:001:00 0 4 = 0001
 de2490c0 3789371015 S Ci:001:00 s a3 00  0001 0004 4 
 de2490c0 3789371146 C Ci:001:00 0 4 = 0001
 de2490c0 3789410975 S Ci:001:00 s a3 00  0001 0004 4 
 de2490c0 3789411097 C Ci:001:00 0 4 = 0001
 de2490c0 3789450972 S Ci:001:00 s a3 00  0001 0004 4 
 de2490c0 3789451081 C Ci:001:00 0 4 = 0001
 de7d92c0 3789452462 C Ii:001:01 -2 0

 Not sure what any of it means.

 Basically it means what you said above: the hub disconnected.  I 
 can't
 tell why.  You'll have to ask someone who's familiar with the 
 hardware
 on that board.

 Sadly, there is no one more familar with this specific hardware 
 than myself.

 I can however ellaborate the hardware setup of the USB subsystem in
 case there is someone out there that has used a similar setup.

 The board uses the AM3517 SoC from TI. The SoC's USB host port 
 (HSUSB1) is
 connected to a USB3320 PHY. The PHY is connected to a USB2512 
 switch to
 provide two downstream USB ports.

 The very same hardware worked with the 2.6.37 kernel that I am 
 trying to
 move away from.

 It should be noted that the USB hardware work on the 3.2 kernel as well.


 Today I am going to try using 3.10 and 3.14 kernels see if they 
 exhibit
 the same behavior.


 It should be noted that the 3.10 kernel did not even detect the 
 external
 HUB and the 3.14 kernel exhibits the same failure as 3.16.

 Do you have off-while-idle enabled ? This could be, as Alan 

Re: OMAP 3630 random crashes

[Michael Trimarchi]

Hi

On Mon, Jun 30, 2014 at 3:43 PM, Casper Lyngesen Mogensen
clmogen...@grundfos.com wrote:
 Hi

 I got two new Overo AirStorm today, and they have same behavior. I tried 
 disabling
 the SMSC9xxx again and booted from MMC. This seems to make the backtrace a
 little more consistent(Tried on both new and old). There is (almost) always 
 something
 about Alignment trap, the crash log itself differs every time. Also i get to 
 allocate a lot
 more memory before crash with these settings.



What kernel version are you using?

Michael

 mallocsize = 3446
 mallocsize = 34464000
 mallocsize = 34468000
 [  425.438629] Alignment trap: not handling instruction e1932f9f at 
 [c0082060]
 [  425.446136] Unhandled fault: alignment exception (0x001) at 0x7be3c202
 [  425.453002] Internal error: : 1 [#1] SMP ARM
 [  425.457489] Modules linked in: snd_soc_omap_twl4030 libertas_sdio libertas 
 snd_soc_omap snd_pcm_dmaengine lib80211 cfg80211 snd_soc_twl4030 snd_soc_core 
 snd_compress snd_pcm snd_timer snd soundcore
 [  425.476226] CPU: 0 PID: 1582 Comm: kworker/u2:2 Not tainted 3.15.0-dirty 
 #14
 [  425.483642] task: de062080 ti: dd1b8000 task.ti: dd1b8000
 [  425.489349] PC is at __lock_acquire+0x160/0x1cb8
 [  425.494232] LR is at lock_acquire+0xa0/0xfc
 [  425.498626] pc : [c0082064]lr : [c00843c4]psr: 2193
 [  425.498626] sp : dd1b9bb0  ip : 0001  fp : 7be3c0fe
 [  425.510681] r10: c0854c10  r9 : c0d7785c  r8 : de062080
 [  425.516174] r7 :   r6 : dd1b8030  r5 :   r4 : dfaef6d0
 [  425.523010] r3 : 7be3c202  r2 : dfaef6d0  r1 : 28014a03  r0 : dfaef6d0
 [  425.529876] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
 kernel
 [  425.537628] Control: 10c5307d  Table: 9e76c019  DAC: 0015
 [  425.543670] Process kworker/u2:2 (pid: 1582, stack limit = 0xdd1b8248)
 [  425.550506] Stack: (0xdd1b9bb0 to 0xdd1ba000)
 [  425.555114] 9ba0: de062080 0004 
 0006 c07fb7e4
 [  425.563720] 9bc0: 0008 c0081998 dd1b8020 de062080  0001 
 c07ef168 c0081ab8
 [  425.572296] 9be0: 1f2b8000 ddbe1780 ddbe65c0 dd1b8000 1f2b8000 c01486d4 
  ddbd60f0
 [  425.580902] 9c00: ddbe65c0      
  
 [  425.589508] 9c20: dfaef6d0    0001  
 c007914c c00843c4
 [  425.598114] 9c40: 0001 0080  c007914c  0002 
 dd1b8000 6193
 [  425.606689] 9c60: c0854c10 dfaef6c0 0113 c007914c 0003 dd1b9cc8 
 c0146d90 c0147b3c
 [  425.615295] 9c80: 0001 c054a808 0001  c007914c  
 dfaef6c0 
 [  425.623901] 9ca0: 0001 c007914c   ddbe65c0  
 dd1b9d30 0060
 [  425.632507] 9cc0: 0001 c00791ac ddbe65c0 0002  c0149548 
 0001 
 [  425.641082] 9ce0: 0001 ddbd60f0 dd1b9d40 0001 dd1b9d2c c01b60a0 
 dd1b9d2c 0001
 [  425.649688] 9d00: de062080 0004 0006 0001 0001  
 de1ff000 dde0a490
 [  425.658294] 9d20: dd1b9d9c  0001  ddbe65c0 c00843c4 
 0001 
 [  425.666900] 9d40: ddbe65c0 c0130274  c007fa8c dd1b8038 6113 
 de1ff000 ddbd22a0
 [  425.675506] 9d60: dde0a468 dde0a468 ddbd60f0 ddbd2240 dd1b8000 de141015 
 de141014 
 [  425.684082] 9d80: dd1b9eb8 c01b6534 dde0a468 c054a8d4 ddbd2240 c01302a8 
  
 [  425.692687] 9da0: dde0a468 ddbd2240 ddbd2240 c0121cb4 0001 0011 
 ddbd2240 c012297c
 [  425.701293] 9dc0: dd1b8000 01141015 de141014 dd1b9eb8 dd1b9e10 c0123344 
  dd1b9e18
 [  425.709899] 9de0: dd1b9e10 0003 dd1b8000 c0123c08 c0124b3c 0001 
  c0081ab8
 [  425.718505] 9e00: dd1b9eb8 dd1b8030 c01269a4 de086dc0  c0124b3c 
 0001 
 [  425.727081] 9e20: 00727375 0003 de141011 de086e00 de11fb80 de11fb80 
 dd1b9eb8 c0565f50
 [  425.735687] 9e40: de141000 ff9c   dd1b8000 c01269cc 
 dd1b9e70 
 [  425.744293] 9e60: dd1b8038 0002 de062080 c0d7785c   
  
 [  425.752899] 9e80: 00192082 c0926c08 000d c0565f50 0001 de141000 
 ff9c de770500
 [  425.761474] 9ea0: de062080 dd1b8000  c0127ed8 0041 0004 
 de0361d0 ddbd2240
 [  425.770080] 9ec0: 00727375 0003 de141011 de086e00 de0361d0 ddbd2240 
 ddbd60f0 0011
 [  425.778686] 9ee0: 0002 0056    0002 
  
 [  425.787292] 9f00: c011fbfc c00843c4    c011fbfc 
  de141000
 [  425.795867] 9f20: dd1b8010 de671344  c011e450 de671344  
 de062080 de141000
 [  425.804473] 9f40: dd1b8010 de671344  c011fcd8   
 c011fbfc de141010
 [  425.813079] 9f60: 0021   de0623ac 0021 dd0b8940 
  de498140
 [  425.821685] 9f80:      c0053580 
 de498140 c00535b0
 [  425.830291] 9fa0:   

Re: Help to run latest kernel on DART-4460

[Michael Trimarchi]

Hi Tony

On Fri, Apr 18, 2014 at 6:51 PM, Tony Lindgren t...@atomide.com wrote:
 * Michael Trimarchi mich...@amarulasolutions.com [140325 09:37]:
 Hi

 On Tue, Mar 25, 2014 at 5:33 PM, Andrey Utkin
 andrey.krieger.ut...@gmail.com wrote:
  2014-03-25 17:17 GMT+02:00 Michael Trimarchi 
  mich...@amarulasolutions.com:
  I have already done somenthing like that more then 6 months ago. I was
  in a good state, What camera sensors are you using?
 
  Hi Michael, it is JAL-MIPI-OV5640.
 

 I think that I have all somewhere on top of 3.4. Can you contact on my email?

 I take it this issue has been resolved already? Probably you
 did not configure u-boot for the dtb? :)


Yes, I have helped them. Nice should be test on a newest kernel. It
should work but the
device is in US and I help them remote using teamviewer so not so easy ;)

Michael

 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: Help to run latest kernel on DART-4460

[Michael Trimarchi]

Hi

On Tue, Mar 25, 2014 at 4:00 PM, Andrey Utkin
andrey.krieger.ut...@gmail.com wrote:
 Hi! We have a DART-4460 board which is based on TI OMAP4460.
 It is shipped by Variscite with linux kernel v3.4.27 (as
 /proc/config.gz states; uname -a shows Linux localhost.localdomain
 3.4.0-1489-omap4 #28 SMP PREEMPT Wed Oct 30 10:58:36 IST 2013 armv7l
 armv7l armv7l GNU/Linux).
 We try to make it work with latest kernel, because we want to get
 video4linux interface to the cameras which are attached to the board
 by CSI interface. So we need drivers/staging/media/omap4iss/ stuff, if
 i understand it correct. This stuff is currently included in
 linux-stable master branch (but not in any tag) and in
 git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git

 The problem is that the kernel uImage we have prepared doesn't boot.

 The config of latest linux-stable kernel i have tried last time:
 https://gist.github.com/krieger-od/9a2c6bce5a69d22ca2dd
 The serial console output with it:
 https://gist.github.com/krieger-od/0fa0f6f6f597b10f95a4

 The shipped kernel's config:
 https://gist.github.com/krieger-od/55b34ebe3571ae4dd875
 The serial console output with kernel shipped by vendor:
 https://gist.github.com/krieger-od/32481d718e0519dd0bd9

 Could anybody share a working config for recent enough kernel for this
 or similar hardware?
 Any comments?
 We appreciate any help. Thanks in advance.


I have already done somenthing like that more then 6 months ago. I was
in a good state, What camera sensors are you using?

Michael

 --
 Andrey Utkin
 --
 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



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.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: Help to run latest kernel on DART-4460

[Michael Trimarchi]

Hi

On Tue, Mar 25, 2014 at 5:33 PM, Andrey Utkin
andrey.krieger.ut...@gmail.com wrote:
 2014-03-25 17:17 GMT+02:00 Michael Trimarchi mich...@amarulasolutions.com:
 I have already done somenthing like that more then 6 months ago. I was
 in a good state, What camera sensors are you using?

 Hi Michael, it is JAL-MIPI-OV5640.


I think that I have all somewhere on top of 3.4. Can you contact on my email?

Michael

 --
 Andrey Utkin



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.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: SD card timeout problems on Nokia N900 (omap_hsmmc on OMAP3)

[Michael Trimarchi]

Hi Sebastian

On Wed, Feb 26, 2014 at 12:47 AM, Sebastian Reichel s...@ring0.de wrote:
 Hi,

 I have problems with the SD-card initialization on my Nokia N900
 using a 3.14-rc1 based kernel in DT boot mode. The bug is can be
 circumvented by changing the kernel slightly (e.g. remove some DT
 nodes or mark them as disabled). So the SD card's timeout problems
 seem to derive from kernel timing problems. I'm pretty sure, that
 the problems are not originating from a broken SD card, since

  1. The SD card worked quite good before and still does depending
 on unrelated DTS changes (= loading less drivers).
  2. The SD card works flawlessly on my notebook using a USB adapter
  3. Another SD card showed the same problem

 I tried to git bisect the problem, but I just get shown some
 unrelated driver additions.

 Anyways, this is the error I get during boot:

 [3.896820] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz
 ...
 [5.956237] mmc0: error -110 whilst initialising SD card


Are you sure that some subsystem that you deactivate don't change
pin muxing setting? Can you check in the broken system if the pins of the sdcard
are correctly muxed? Does it happen even if you change the sdcard?

Michael

 I added some debug prints to trace the error:

  * mmc_sd_init_card()
  * mmc_sd_get_cid()
  * mmc_send_app_op_cond()

 Can you give me any hints how to find  fix the problem's source?

 -- Sebastian
--
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 2/3] bq2415x_charger: Use power_supply notifier for automode

[Michael Trimarchi]

Hi

On Sun, Jan 19, 2014 at 9:54 PM, Sebastian Reichel s...@ring0.de wrote:
 On Mon, Dec 02, 2013 at 02:45:06AM +0100, Michael Trimarchi wrote:
 On Mon, Dec 2, 2013 at 1:24 AM, Anton Vorontsov an...@enomsg.org wrote:
  On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote:
  On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov an...@enomsg.org wrote:
   On Mon, Nov 25, 2013 at 08:16:34PM +0100, Michael Trimarchi wrote:
   ...
So you can read this value without any type of synchronization
with the power_supply_core
and sysfs implementation?
   ...
   https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html
  
   I found and equivalent scenario that I was trying to said
  
   That's a good question, actually. Even though in Pali's case the 
   notifier
   is atomic (so that we are pretty confident that the object won't be
   unregistered), there is still a possiblity of a dead lock, for example. 
   So
 
  So if the get_property is a sleeping function it will be a deadlock. 
  Right?
 
  All kind of bad things might happen, yes. But before that I would expect a
  bunch of warnings from might_sleep() stuff.
 
  I would recommend to test the patches using preempt/smp kernels + various
  DEBUG_ kernel options set.
 

 Is it more simple to make it not atomic and use a mutex in get_property?

 I just built a kernel with CONFIG_DEBUG_ATOMIC_SLEEP to test another
 driver and got the following output for bq2415x:

 [7.667449] Workqueue: events power_supply_changed_work
 [7.673034] [c0015c28] (unwind_backtrace+0x0/0xe0) from [c0011e1c] 
 (show_stack+0x10/0x14)
 [7.682098] [c0011e1c] (show_stack+0x10/0x14) from [c052cdd0] 
 (dump_stack+0x78/0xac)
 [7.690704] [c052cdd0] (dump_stack+0x78/0xac) from [c052a044] 
 (__schedule_bug+0x48/0x60)
 [7.699645] [c052a044] (__schedule_bug+0x48/0x60) from [c053071c] 
 (__schedule+0x74/0x638)
 [7.708618] [c053071c] (__schedule+0x74/0x638) from [c05301fc] 
 (schedule_timeout+0x1dc/0x24c)
 [7.718017] [c05301fc] (schedule_timeout+0x1dc/0x24c) from [c05316ec] 
 (wait_for_common+0x138/0x17c)
 [7.727966] [c05316ec] (wait_for_common+0x138/0x17c) from [c0362a70] 
 (omap_i2c_xfer+0x340/0x4a0)
 [7.737640] [c0362a70] (omap_i2c_xfer+0x340/0x4a0) from [c035d928] 
 (__i2c_transfer+0x40/0x74)
 [7.747039] [c035d928] (__i2c_transfer+0x40/0x74) from [c035e22c] 
 (i2c_transfer+0x6c/0x90)
 [7.756195] [c035e22c] (i2c_transfer+0x6c/0x90) from [c037ad24] 
 (bq2415x_i2c_write+0x48/0x78)
 [7.765563] [c037ad24] (bq2415x_i2c_write+0x48/0x78) from [c037ae60] 
 (bq2415x_set_weak_battery_voltage+0x4c/0x50)
 [7.776824] [c037ae60] (bq2415x_set_weak_battery_voltage+0x4c/0x50) from 
 [c037bce8] (bq2415x_set_mode+0xdc/0x14c)
 [7.788085] [c037bce8] (bq2415x_set_mode+0xdc/0x14c) from [c037bfb8] 
 (bq2415x_notifier_call+0xa8/0xb4)
 [7.798309] [c037bfb8] (bq2415x_notifier_call+0xa8/0xb4) from 
 [c005f228] (notifier_call_chain+0x38/0x68)
 [7.808715] [c005f228] (notifier_call_chain+0x38/0x68) from [c005f284] 
 (__atomic_notifier_call_chain+0x2c/0x3c)
 [7.819732] [c005f284] (__atomic_notifier_call_chain+0x2c/0x3c) from 
 [c005f2a8] (atomic_notifier_call_chain+0x14/0x18)
 [7.831420] [c005f2a8] (atomic_notifier_call_chain+0x14/0x18) from 
 [c0378078] (power_supply_changed_work+0x6c/0xb8)
 [7.842864] [c0378078] (power_supply_changed_work+0x6c/0xb8) from 
 [c00556c0] (process_one_work+0x248/0x440)
 [7.853546] [c00556c0] (process_one_work+0x248/0x440) from [c0055d6c] 
 (worker_thread+0x208/0x350)
 [7.863372] [c0055d6c] (worker_thread+0x208/0x350) from [c005b0ac] 
 (kthread+0xc8/0xdc)
 [7.872131] [c005b0ac] (kthread+0xc8/0xdc) from [c000e138] 
 (ret_from_fork+0x14/0x3c)

 -- Sebastian


I have already give my opinion about this problem

Michael
--
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 host mode suspend mode

[Michael Trimarchi]

Hi

I forget to post the solution for old kernel 3.0.31. The code to
support the suspend/resume in host mode when some
peripheral is connected (no wake lock should be taken for android device)

+static int omap2430_resume_noirq(struct device *dev)
+{
+   struct omap2430_glue*glue = dev_get_drvdata(dev);
+   struct musb *musb = glue_to_musb(glue);
+   struct platform_device  *pdev = to_platform_device(dev);
+
+   if (pm_runtime_suspended(dev))
+   return 0;
+
+   if (pdev)
+   omap_device_enable(pdev);
+
+   omap2430_low_level_init(musb);
+   musb_writel(musb-mregs, OTG_INTERFSEL,
+   musb-context.otg_interfsel);
+
+   otg_set_suspend(musb-xceiv, 0);
+
+   return 0;
+}
+
+
+static int omap2430_suspend_noirq(struct device *dev)
+{
+   struct omap2430_glue*glue = dev_get_drvdata(dev);
+   struct musb *musb = glue_to_musb(glue);
+   struct platform_device  *pdev = to_platform_device(dev);
+
+   if (pm_runtime_suspended(dev))
+   return 0;
+
+   musb-context.otg_interfsel = musb_readl(musb-mregs,
+   OTG_INTERFSEL);
+
+   omap2430_low_level_exit(musb);
+   otg_set_suspend(musb-xceiv, 1);
+   if (pdev)
+   omap_device_idle(pdev);
+
+   return 0;
+}
+
+struct dev_pm_ops omap2430_pm_ops = {
+   SET_RUNTIME_PM_OPS(omap2430_runtime_suspend, omap2430_runtime_resume,
+  NULL)
+   .suspend_noirq = omap2430_suspend_noirq,
+   .resume_noirq = omap2430_resume_noirq,
 };


Michael

On Wed, Dec 11, 2013 at 5:14 PM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
 Hi

 On Sat, Dec 7, 2013 at 6:22 PM, Michael Trimarchi
 mich...@amarulasolutions.com wrote:
 Hi

 On Wed, Nov 27, 2013 at 4:26 PM, Michael Trimarchi
 mich...@amarulasolutions.com wrote:
 Hi Felipe,

 I'm trying to understand how dpll_usb and vbus should work in suspend mode.
 What I have in my kernel 3.0.31 from ti is that if I suspend the device 
 with id
 pin ground and no device connected I have:

 - vbus 5v
 - dpll_usb locked problem so l3domain can not suspend

 If I have the id pin floating (device mode) and no device connected I
 can suspend
 without problem. I'm not care about remote wakeup and I would like to 
 understand
 what is the reason of having no complete suspend in host mode. Can you give
 some insight?

 I get a bit further and if I do something like that so basically force
 device mode I can suspend.

 +   if (val) {
 +   twl-force_device = false;
 +   twl6030_writeb(twl, TWL_MODULE_USB, 0x14, USB_ID_CTRL_SET);
 +   twl6030_usb_irq(twl-irq2, twl);
 +   twl6030_usbotg_irq(twl-irq1, twl);
 +   } else {
 +   twl-force_device = true;
 +   twl6030_writeb(twl, TWL_MODULE_USB, 0x14, USB_ID_CTRL_CLR);
 +   twl6030_usb_irq(twl-irq2, twl);
 +   twl6030_usbotg_irq(twl-irq1, twl);
 +   }

 So my problem is let the device connect host mode (remote wakeup
 disable) and let the system suspend in the correct way.


 I think that I have almost fixed the problem of suspend resume of the
 otg host mode in this old
 version of the kernel. But I would like to share my short summary:

 - I have implemented the suspend/resume hooks of the omap2430 and manually
 call the omap_device_idle and omap_device_disable because in old
 version of the kernel
 this hooks are not implemented in the omap_device structure

 - I understand the reason in not having the runtime_suspend the otg in
 host mode but I'm not sure:
   * the runtime_get_sync is taken on the ID_GND event so as soon it's
 host connected the use_count
 go to 1 but I did't find where it is released

 - I still have a

 4[   41.856445] WARNING: at
 /home/michael/work/amarula/wincor/paypad/kernel/arch/arm/mach-omap2/omap_l3_noc.c:135
 l3_interrupt_handler+0x254/0x344()
 4[   41.856475] CUSTOM SRESP error with SOURCE:L4CFG
 4[   41.856506] Modules linked in: pvrsrvkm_sgx540_120 gps_drv
 wl12xx mac80211 cfg80211 compat
 4[   41.856567] Backtrace:
 4[   41.856597] [c00e43e0] (dump_backtrace+0x0/0x10c) from
 [c0679db0] (dump_stack+0x18/0x1c)
 4[   41.856628]  r7:0009 r6:0087 r5:c010652c r4:c783dc80
 4[   41.856689] [c0679d98] (dump_stack+0x0/0x1c) from [c012b31c]
 (warn_slowpath_common+0x54/0x6c)
 4[   41.856750] [c012b2c8] (warn_slowpath_common+0x0/0x6c) from
 [c012b3d8] (warn_slowpath_fmt+0x38/0x40)
 4[   41.856781]  r9: r8:f8000400 r7:00080003 r6:c08ce948 r5:0448
 4[   41.856811] r4:f800
 4[   41.856842] [c012b3a0] (warn_slowpath_fmt+0x0/0x40) from
 [c010652c] (l3_interrupt_handler+0x254/0x344)
 4[   41.856872]  r3:c07ee514 r2:c07ee4b0
 4[   41.856933] [c01062d8] (l3_interrupt_handler+0x0/0x344) from
 [c017291c] (handle_irq_event_percpu+0x6c/0x290)
 4[   41.856964

Re: [PATCH v9 4/7] mmc: omap_hsmmc: adapt hsmmc to use pbias regulator

[Michael Trimarchi]

Hi

On Fri, Jan 10, 2014 at 6:30 PM, Balaji T K balaj...@ti.com wrote:
 In DT case, PBAIS registers are programmed via regulator,
 use regulator APIs to control PBIAS.

 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  drivers/mmc/host/omap_hsmmc.c |   39 +++
  1 files changed, 39 insertions(+), 0 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 342be25..0a390f8 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -126,6 +126,10 @@
  #define OMAP_MMC_MAX_CLOCK 5200
  #define DRIVER_NAMEomap_hsmmc

 +#define VDD_1V8180 /* 18 uV */
 +#define VDD_3V0300 /* 30 uV */
 +#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
 +
  /*
   * One controller can have multiple slots, like on some omap boards using
   * omap.c controller driver. Luckily this is not currently done on any known
 @@ -164,6 +168,8 @@ struct omap_hsmmc_host {
  */
 struct  regulator   *vcc;
 struct  regulator   *vcc_aux;
 +   struct  regulator   *pbias;
 +   boolpbias_enabled;
 int pbias_disable;
 void__iomem *base;
 resource_size_t mapbase;
 @@ -272,6 +278,15 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
 if (mmc_slot(host).before_set_reg)
 mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);

 +   if (host-pbias) {
 +   if (host-pbias_enabled == 1) {
 +   ret = regulator_disable(host-pbias);
 +   if (!ret)
 +   host-pbias_enabled = 0;
 +   }
 +   regulator_set_voltage(host-pbias, VDD_3V0, VDD_3V0);
 +   }
 +
 /*
  * Assume Vcc regulator is used only to power the card ... OMAP
  * VDDS is used to power the pins, optionally with a transceiver to
 @@ -306,9 +321,29 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
 }
 }

 +   if (host-pbias) {
 +   if (vdd = VDD_165_195)
 +   ret = regulator_set_voltage(host-pbias, VDD_1V8,
 +   VDD_1V8);
 +   else
 +   ret = regulator_set_voltage(host-pbias, VDD_3V0,
 +   VDD_3V0);
 +   if (ret  0)
 +   goto error_set_power;
 +
 +   if (host-pbias_enabled == 0) {
 +   ret = regulator_enable(host-pbias);
 +   if (!ret) {
 +   host-pbias_enabled = 1;
 +   goto error_set_power;

why you a goto to error_set_power if the regulator enable was a succes?
and if pbias_enabled is used for verify if is already enabled. Is the
same to use
regulator_is_enabled?

Michael

 +   }
 +   }
 +   }
 +
 if (mmc_slot(host).after_set_reg)
 mmc_slot(host).after_set_reg(dev, slot, power_on, vdd);

 +error_set_power:
 return ret;
  }

 @@ -342,6 +377,9 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
 *host)
 reg = devm_regulator_get_optional(host-dev, vmmc_aux);
 host-vcc_aux = IS_ERR(reg) ? NULL : reg;

 +   reg = devm_regulator_get_optional(host-dev, pbias);
 +   host-pbias = IS_ERR(reg) ? NULL : reg;
 +
 /* For eMMC do not power off when not in sleep state */
 if (mmc_slot(host).no_regulator_off_init)
 return 0;
 @@ -1808,6 +1846,7 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 host-base  = ioremap(host-mapbase, SZ_4K);
 host-power_mode = MMC_POWER_OFF;
 host-next_data.cookie = 1;
 +   host-pbias_enabled = 0;

 platform_set_drvdata(pdev, host);

 --
 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
--
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 v7 4/7] mmc: omap_hsmmc: adapt hsmmc to use pbias regulator

[Michael Trimarchi]

Hi

On Fri, Dec 20, 2013 at 6:35 PM, Balaji T K balaj...@ti.com wrote:
 In DT case, PBAIS registers are programmed via regulator,
 use regulator APIs to control PBIAS.

 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  drivers/mmc/host/omap_hsmmc.c |   39 +++
  1 files changed, 39 insertions(+), 0 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 342be25..0a390f8 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -126,6 +126,10 @@
  #define OMAP_MMC_MAX_CLOCK 5200
  #define DRIVER_NAMEomap_hsmmc

 +#define VDD_1V8180 /* 18 uV */
 +#define VDD_3V0300 /* 30 uV */
 +#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
 +
  /*
   * One controller can have multiple slots, like on some omap boards using
   * omap.c controller driver. Luckily this is not currently done on any known
 @@ -164,6 +168,8 @@ struct omap_hsmmc_host {
  */
 struct  regulator   *vcc;
 struct  regulator   *vcc_aux;
 +   struct  regulator   *pbias;
 +   boolpbias_enabled;
 int pbias_disable;
 void__iomem *base;
 resource_size_t mapbase;
 @@ -272,6 +278,15 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
 if (mmc_slot(host).before_set_reg)
 mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);

 +   if (host-pbias) {
 +   if (host-pbias_enabled == 1) {
 +   ret = regulator_disable(host-pbias);
 +   if (!ret)
 +   host-pbias_enabled = 0;

you should return error?

 +   }
 +   regulator_set_voltage(host-pbias, VDD_3V0, VDD_3V0);
 +   }
 +
 /*
  * Assume Vcc regulator is used only to power the card ... OMAP
  * VDDS is used to power the pins, optionally with a transceiver to
 @@ -306,9 +321,29 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
 }
 }

 +   if (host-pbias) {
 +   if (vdd = VDD_165_195)
 +   ret = regulator_set_voltage(host-pbias, VDD_1V8,
 +   VDD_1V8);
 +   else
 +   ret = regulator_set_voltage(host-pbias, VDD_3V0,
 +   VDD_3V0);
 +   if (ret  0)
 +   goto error_set_power;
 +
 +   if (host-pbias_enabled == 0) {
 +   ret = regulator_enable(host-pbias);
 +   if (!ret) {
 +   host-pbias_enabled = 1;
 +   goto error_set_power;

Is this an error condition? Do you need this flag?

Mcihael

 +   }
 +   }
 +   }
 +
 if (mmc_slot(host).after_set_reg)
 mmc_slot(host).after_set_reg(dev, slot, power_on, vdd);

 +error_set_power:
 return ret;
  }

 @@ -342,6 +377,9 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
 *host)
 reg = devm_regulator_get_optional(host-dev, vmmc_aux);
 host-vcc_aux = IS_ERR(reg) ? NULL : reg;

 +   reg = devm_regulator_get_optional(host-dev, pbias);
 +   host-pbias = IS_ERR(reg) ? NULL : reg;
 +
 /* For eMMC do not power off when not in sleep state */
 if (mmc_slot(host).no_regulator_off_init)
 return 0;
 @@ -1808,6 +1846,7 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 host-base  = ioremap(host-mapbase, SZ_4K);
 host-power_mode = MMC_POWER_OFF;
 host-next_data.cookie = 1;
 +   host-pbias_enabled = 0;

 platform_set_drvdata(pdev, host);

 --
 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
--
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 host mode suspend mode

[Michael Trimarchi]

Hi

On Wed, Nov 27, 2013 at 4:26 PM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
 Hi Felipe,

 I'm trying to understand how dpll_usb and vbus should work in suspend mode.
 What I have in my kernel 3.0.31 from ti is that if I suspend the device with 
 id
 pin ground and no device connected I have:

 - vbus 5v
 - dpll_usb locked problem so l3domain can not suspend

 If I have the id pin floating (device mode) and no device connected I
 can suspend
 without problem. I'm not care about remote wakeup and I would like to 
 understand
 what is the reason of having no complete suspend in host mode. Can you give
 some insight?

I get a bit further and if I do something like that so basically force
device mode I can suspend.

+   if (val) {
+   twl-force_device = false;
+   twl6030_writeb(twl, TWL_MODULE_USB, 0x14, USB_ID_CTRL_SET);
+   twl6030_usb_irq(twl-irq2, twl);
+   twl6030_usbotg_irq(twl-irq1, twl);
+   } else {
+   twl-force_device = true;
+   twl6030_writeb(twl, TWL_MODULE_USB, 0x14, USB_ID_CTRL_CLR);
+   twl6030_usb_irq(twl-irq2, twl);
+   twl6030_usbotg_irq(twl-irq1, twl);
+   }

So my problem is let the device connect host mode (remote wakeup
disable) and let the system suspend in the correct way.

Michael


 Michael
--
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/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

[Michael Trimarchi]

Hi Roger

On Mon, Dec 2, 2013 at 10:39 AM, Roger Quadros rog...@ti.com wrote:
 +Benoit, Tony, Paul.

 Hi Michael,

 On 11/30/2013 06:48 AM, Michael Trimarchi wrote:
 Hi Roger

 On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }


 I'm digging in the code but as I understand this should be done by
 omap_hwmod and
 i660 avoid reset of the ehci module. This is done by ocp_softreset?


 It won't be done by omap_hwmod as we set HWMOD_INIT_NO_RESET flag in the 
 hwmod data [1].

 Question is do we do it in the driver of leave it to hwmod?

 The other concern about i660 is in this comment [1]


I don't find any description of this errata for omap4. Is this errata valid?

My change was to remove the NO_INIT and add 2uS as you have done

 /*
  * During system oot; If the hwmod framework resets the module
  * the module will have smart idle settings; which can lead to 
 deadlock
  * (above Errata Id:i660); so, dont reset the module during boot;
  * Use HWMOD_INIT_NO_RESET.
  */

 But if you look at the errata document [2], Advisory 1.108, it doesn't say 
 that we can't be in smart-idle, but
 only that we should put the module in force-idle, before cutting the module's 
 functional clock. It also states
 that the only way to recover from a lockup condition is to soft reset the 
 module. So I'm not sure if the above comment
 in the code is really valid. What if the lockup happens in the bootloader? In 
 that case we will have to reset the module in
 the kernel.

Michael


 Doing the reset in probe does solve a problem for now i.e. eliminates 
 dependency on bootloader.

 [1] - 
 http://git.kernel.org/cgit/linux

Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.

[Michael Trimarchi]

Hi Pekon

On Mon, Dec 2, 2013 at 6:05 PM, Gupta, Pekon pe...@ti.com wrote:
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
Dear Gupta, Pekon,

On Mon, 2 Dec 2013 16:13:56 +, Gupta, Pekon wrote:

 Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'.
 The infrastructure is still in place, however the command 'nandecc' is
 deprecated in newer versions.
 References in mainline u-boot:
 arch/arm/cpu/armv7/omap3/board.c  @@do_switch_ecc()
 driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc()

 So with minor hacks, you should be able to bring-back 'nandecc'.

So in short, what it means is that indeed the fact of switching to BCH8
on the kernel side is really breaking things, because U-Boot users now
have the choice between:

 * Configuring U-Boot to use Hamming ECC, and be able to reflash their
   SPL, but not their filesystem images.

 * Configuring U-Boot to use BCH8, and be able to reflash their
   filesystem images, but not their SPL.

Seems a little bit annoying for users, no?

 Yes, agree ..
 But this is only because we have mis-match in ecc-scheme between
 ROM-code (while reading SPL) v/s  rest of system.
 However, if you continue using 'HAM1' for *both* u-boot and kernel
 you should not face any issue. And with latest patch on u-boot
 your board file should also remain unchanged.

 [...]

 But for all these, images need to be flashed from u-boot. As kernel
 cannot switch ecc-schemes on-the-fly.

Which as I was saying, is a bit of shame. There is technically nothing
that makes the ECC scheme something that needs to be applied globally
on the entire flash.

 No, I don't think that kernel needs to ever dynamically switch ecc-schemes.
 This feature should be limited only to u-boot (or bootloaders) because:


I don't think so. There are cpu that can be boot only using some ecc scheme
but for a lot of reason you should require to have for the filesystem
a different ecc scheme

 (1) Adding support for dynamic switching of ecc-schemes will require all
   code to be compiled in driver which increases the kernel  driver footprint.
   (example adding BCH8_SW means you need to compile in lib/bch.c)


It depends on the system that you are using and sometime increase the
kernel size is less important that guarantee system consistency

 (2) Also selection of ecc-scheme mainly depends on NAND device parameter
  (like density, page-size, oobsize) which remain constant for a device
 (all NAND partitions). Thus all partitions should use *same* ecc-scheme
 preferable highest possible available with NAND device  kernel.


same as above. It can be a limitation on the bootrom

 (3) Kernel uses same driver instance to handle all MTD partitions, so if one
partition uses HAM1 while other uses BCH8, and both are simultaneously
mounted, then it would be difficult for driver to switch ecc-schemes while
   doing interleaved Read/Write between the partitions.
   (though it can be added in framework, but then it's too much over-head).


agree

Michael

 In my opinion, kernel driver should be free from all over-heads, And should
 be *as lite as possible, while continuing to be strong in catching bit-flips.*
 Because there are lot of file-system layers over it, to handle more severe
 failures.
 Example: even if you use HAM1 and report un-correctable errors, still
 UBIFS has too much redundancy of critical metadata, that it can still
 recover your volume.
 Therefore, I preferred having ecc-scheme selectable via DT (static) for
 kernel. However these are purely my opinions based on my assessments.


 And we see real practical cases where being able
to specify a different ECC scheme per partition would make sense: when
the ROM code uses a weaker ECC scheme than the one used for most other
partitions.

 This constrain of changing ecc-scheme has come because ROM code
 ecc-scheme is hardened to select HAM1. And so u-boot (bootloaders)
 is used to between bridge gaps between ROM code and kernel.
 - This could have been avoided, if u-boot still supported 'nandecc'  OR
 - ROM code had mechanism to change its ecc-scheme based on some
Boot-mode setting (sysboot pins on board).


 So coming back to the specific problem here.
 I think we need 'nandecc' back in u-boot till atleast all systems have
 migrated to BCH16 or whatever highest ecc-scheme which can be
 supported on OMAP devices.


 with regards, pekon
 --
 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
--
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 2/3] bq2415x_charger: Use power_supply notifier for automode

[Michael Trimarchi]

Hi Anton

On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov an...@enomsg.org wrote:
 On Mon, Nov 25, 2013 at 08:16:34PM +0100, Michael Trimarchi wrote:
 ...
  So you can read this value without any type of synchronization
  with the power_supply_core
  and sysfs implementation?
 ...
 https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html

 I found and equivalent scenario that I was trying to said

 That's a good question, actually. Even though in Pali's case the notifier
 is atomic (so that we are pretty confident that the object won't be
 unregistered), there is still a possiblity of a dead lock, for example. So

So if the get_property is a sleeping function it will be a deadlock. Right?

Michael

 notifiers should be careful to not hold any locks, because the other
 driver might call get_property(), which might acquire locks.

 Thanks,

 Anton
--
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 2/3] bq2415x_charger: Use power_supply notifier for automode

[Michael Trimarchi]

Hi

On Mon, Dec 2, 2013 at 1:24 AM, Anton Vorontsov an...@enomsg.org wrote:
 On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote:
 On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov an...@enomsg.org wrote:
  On Mon, Nov 25, 2013 at 08:16:34PM +0100, Michael Trimarchi wrote:
  ...
   So you can read this value without any type of synchronization
   with the power_supply_core
   and sysfs implementation?
  ...
  https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html
 
  I found and equivalent scenario that I was trying to said
 
  That's a good question, actually. Even though in Pali's case the notifier
  is atomic (so that we are pretty confident that the object won't be
  unregistered), there is still a possiblity of a dead lock, for example. So

 So if the get_property is a sleeping function it will be a deadlock. Right?

 All kind of bad things might happen, yes. But before that I would expect a
 bunch of warnings from might_sleep() stuff.

 I would recommend to test the patches using preempt/smp kernels + various
 DEBUG_ kernel options set.


Is it more simple to make it not atomic and use a mutex in get_property?

Michael

 Thanks,

 Anton
--
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/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

[Michael Trimarchi]

Hi

On Sat, Nov 30, 2013 at 6:10 AM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
 Hi

 On Sat, Nov 30, 2013 at 5:48 AM, Michael Trimarchi
 mich...@amarulasolutions.com wrote:
 Hi Roger

 On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }


 I'm digging in the code but as I understand this should be done by
 omap_hwmod and
 i660 avoid reset of the ehci module. This is done by ocp_softreset?


 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 +   reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 +   timeout = jiffies + msecs_to_jiffies(100);
 +   while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +OMAP_UHH_SYSSTATUS_RESETDONE)) {
 +   cpu_relax();
 +
 +   if (time_after(jiffies, timeout)) {
 +   dev_err(dev, Soft RESET operation timed out\n);
 +   break;
 +   }
 +   }
 +
 +   /* Set No-Standby */
 +   reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 +OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 +   /* Set No-Idle */
 +   reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 +OMAP_UHH_SYSCONFIG_SIDLESHIFT;
 +
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG, reg);
 +}
 +
 +static void omap_usbhs_rev2_reset(struct device *dev

Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

[Michael Trimarchi]

Hi Roger

On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.


Do you think that we need something similar of usb musb?
I have seen the OTG_SYSCONFIG is touched in uboot and
only readed in omap2430.c.

Michael

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }

 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 +   reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 +   timeout = jiffies + msecs_to_jiffies(100);
 +   while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +OMAP_UHH_SYSSTATUS_RESETDONE)) {
 +   cpu_relax();
 +
 +   if (time_after(jiffies, timeout)) {
 +   dev_err(dev, Soft RESET operation timed out\n);
 +   break;
 +   }
 +   }
 +
 +   /* Set No-Standby */
 +   reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 +OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 +   /* Set No-Idle */
 +   reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 +OMAP_UHH_SYSCONFIG_SIDLESHIFT;
 +
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG, reg);
 +}
 +
 +static void omap_usbhs_rev2_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 + 

Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

[Michael Trimarchi]

Hi Roger

On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }


I'm digging in the code but as I understand this should be done by
omap_hwmod and
i660 avoid reset of the ehci module. This is done by ocp_softreset?


 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 +   reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 +   timeout = jiffies + msecs_to_jiffies(100);
 +   while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +OMAP_UHH_SYSSTATUS_RESETDONE)) {
 +   cpu_relax();
 +
 +   if (time_after(jiffies, timeout)) {
 +   dev_err(dev, Soft RESET operation timed out\n);
 +   break;
 +   }
 +   }
 +
 +   /* Set No-Standby */
 +   reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 +OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 +   /* Set No-Idle */
 +   reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 +OMAP_UHH_SYSCONFIG_SIDLESHIFT;
 +
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG, reg);
 +}
 +
 +static void omap_usbhs_rev2_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset 

Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

[Michael Trimarchi]

Hi

On Sat, Nov 30, 2013 at 5:48 AM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
 Hi Roger

 On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }


 I'm digging in the code but as I understand this should be done by
 omap_hwmod and
 i660 avoid reset of the ehci module. This is done by ocp_softreset?


 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 +   reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 +   timeout = jiffies + msecs_to_jiffies(100);
 +   while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +OMAP_UHH_SYSSTATUS_RESETDONE)) {
 +   cpu_relax();
 +
 +   if (time_after(jiffies, timeout)) {
 +   dev_err(dev, Soft RESET operation timed out\n);
 +   break;
 +   }
 +   }
 +
 +   /* Set No-Standby */
 +   reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 +OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 +   /* Set No-Idle */
 +   reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 +OMAP_UHH_SYSCONFIG_SIDLESHIFT;
 +
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG, reg);
 +}
 +
 +static void omap_usbhs_rev2_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long

musb host mode suspend mode

[Michael Trimarchi]

Hi Felipe,

I'm trying to understand how dpll_usb and vbus should work in suspend mode.
What I have in my kernel 3.0.31 from ti is that if I suspend the device with id
pin ground and no device connected I have:

- vbus 5v
- dpll_usb locked problem so l3domain can not suspend

If I have the id pin floating (device mode) and no device connected I
can suspend
without problem. I'm not care about remote wakeup and I would like to understand
what is the reason of having no complete suspend in host mode. Can you give
some insight?

Michael
--
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 2/3] bq2415x_charger: Use power_supply notifier for automode

[Michael Trimarchi]

Hi

On Sun, Nov 24, 2013 at 8:01 PM, Pali Rohár pali.ro...@gmail.com wrote:
 On Sunday 24 November 2013 18:18:03 Michael Trimarchi wrote:
 Hi

 On Tue, Nov 19, 2013 at 11:18 AM, Pali Rohár
 pali.ro...@gmail.com wrote:
  This patch removing set_mode_hook function from board data
  and replacing it with new string variable of notifier power
  supply device. After this change it is possible to add DT
  support because driver does not need specific board
  function anymore. Only static data and name of power supply
  device is required.
 
  Signed-off-by: Pali Rohár pali.ro...@gmail.com
  ---
 
   drivers/power/bq2415x_charger.c   |   77
   +
   include/linux/power/bq2415x_charger.h |   48
   +++- 2 files changed, 65 insertions(+), 60
   deletions(-)
 
 ...
 
  -   struct bq2415x_device *bq = data;
  +   struct bq2415x_device *bq =
  +   container_of(nb, struct bq2415x_device, nb);
  +   struct power_supply *psy = v;
  +   enum bq2415x_mode mode;
  +   union power_supply_propval prop;
  +   int ret;
  +   int mA;
 
  -   if (!bq)
  -   return;
  +   if (val != PSY_EVENT_PROP_CHANGED)
  +   return NOTIFY_OK;
  +
  +   if (strcmp(psy-name, bq-init_data.notify_device)
  != 0) +   return NOTIFY_OK;
  +
  +   dev_dbg(bq-dev, notifier call was called\n);
  +
  +   ret = psy-get_property(psy,
  POWER_SUPPLY_PROP_CURRENT_MAX, prop); +   if (ret !=
  0)
  +   return NOTIFY_OK;

 So you can read this value without any type of synchronization
 with the power_supply_core
 and sysfs implementation?


 Michael


 I do not see reason why I cannot use it. When isp1704 driver send
 PSY_EVENT_PROP_CHANGED then property
 POWER_SUPPLY_PROP_CURRENT_MAX is already updated and can be read
 by get_property function.


https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html

I found and equivalent scenario that I was trying to said

Michael


 --
 Pali Rohár
 pali.ro...@gmail.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 v2 2/3] bq2415x_charger: Use power_supply notifier for automode

[Michael Trimarchi]

Hi

On Tue, Nov 19, 2013 at 11:18 AM, Pali Rohár pali.ro...@gmail.com wrote:
 This patch removing set_mode_hook function from board data and replacing it 
 with
 new string variable of notifier power supply device. After this change it is
 possible to add DT support because driver does not need specific board 
 function
 anymore. Only static data and name of power supply device is required.

 Signed-off-by: Pali Rohár pali.ro...@gmail.com
 ---
  drivers/power/bq2415x_charger.c   |   77 
 +
  include/linux/power/bq2415x_charger.h |   48 +++-
  2 files changed, 65 insertions(+), 60 deletions(-)

 diff --git a/drivers/power/bq2415x_charger.c b/drivers/power/bq2415x_charger.c
 index 0727f92..d89583d 100644
 --- a/drivers/power/bq2415x_charger.c
 +++ b/drivers/power/bq2415x_charger.c
 @@ -1,7 +1,7 @@
  /*
   * bq2415x charger driver
   *
 - * Copyright (C) 2011-2012  Pali Rohár pali.ro...@gmail.com
 + * Copyright (C) 2011-2013  Pali Rohár pali.ro...@gmail.com
   *
   * This program is free software; you can redistribute it and/or modify
   * it under the terms of the GNU General Public License as published by
 @@ -170,6 +170,7 @@ struct bq2415x_device {
 struct bq2415x_platform_data init_data;
 struct power_supply charger;
 struct delayed_work work;
 +   struct notifier_block nb;
 enum bq2415x_mode reported_mode;/* mode reported by hook function */
 enum bq2415x_mode mode; /* current configured mode */
 enum bq2415x_chip chip;
 @@ -791,24 +792,53 @@ static int bq2415x_set_mode(struct bq2415x_device *bq, 
 enum bq2415x_mode mode)

  }

 -/* hook function called by other driver which set reported mode */
 -static void bq2415x_hook_function(enum bq2415x_mode mode, void *data)
 +static int bq2415x_notifier_call(struct notifier_block *nb,
 +   unsigned long val, void *v)
  {
 -   struct bq2415x_device *bq = data;
 +   struct bq2415x_device *bq =
 +   container_of(nb, struct bq2415x_device, nb);
 +   struct power_supply *psy = v;
 +   enum bq2415x_mode mode;
 +   union power_supply_propval prop;
 +   int ret;
 +   int mA;

 -   if (!bq)
 -   return;
 +   if (val != PSY_EVENT_PROP_CHANGED)
 +   return NOTIFY_OK;
 +
 +   if (strcmp(psy-name, bq-init_data.notify_device) != 0)
 +   return NOTIFY_OK;
 +
 +   dev_dbg(bq-dev, notifier call was called\n);
 +
 +   ret = psy-get_property(psy, POWER_SUPPLY_PROP_CURRENT_MAX, prop);
 +   if (ret != 0)
 +   return NOTIFY_OK;

So you can read this value without any type of synchronization with
the power_supply_core
and sysfs implementation?


Michael

 +
 +   mA = prop.intval;
 +
 +   if (mA == 0)
 +   mode = BQ2415X_MODE_OFF;
 +   else if (mA  500)
 +   mode = BQ2415X_MODE_NONE;
 +   else if (mA  1800)
 +   mode = BQ2415X_MODE_HOST_CHARGER;
 +   else
 +   mode = BQ2415X_MODE_DEDICATED_CHARGER;
 +
 +   if (bq-reported_mode == mode)
 +   return NOTIFY_OK;

 -   dev_dbg(bq-dev, hook function was called\n);
 bq-reported_mode = mode;

 /* if automode is not enabled do not tell about reported_mode */
 if (bq-automode  1)
 -   return;
 +   return NOTIFY_OK;

 sysfs_notify(bq-charger.dev-kobj, NULL, reported_mode);
 bq2415x_set_mode(bq, bq-reported_mode);

 +   return NOTIFY_OK;
  }

  / timer functions /
 @@ -1508,6 +1538,7 @@ static int bq2415x_probe(struct i2c_client *client,
 int num;
 char *name;
 struct bq2415x_device *bq;
 +   struct power_supply *psy;

 if (!client-dev.platform_data) {
 dev_err(client-dev, platform data not set\n);
 @@ -1569,16 +1600,27 @@ static int bq2415x_probe(struct i2c_client *client,
 goto error_4;
 }

 -   if (bq-init_data.set_mode_hook) {
 -   if (bq-init_data.set_mode_hook(
 -   bq2415x_hook_function, bq)) {
 -   bq-automode = 1;
 +   if (bq-init_data.notify_device) {
 +   bq-nb.notifier_call = bq2415x_notifier_call;
 +   ret = power_supply_reg_notifier(bq-nb);
 +   if (ret) {
 +   dev_err(bq-dev, failed to reg notifier: %d\n, ret);
 +   goto error_5;
 +   }
 +   psy = power_supply_get_by_name(bq-init_data.notify_device);
 +   if (psy) {
 +   /* Query for initial reported_mode and set it */
 +   bq2415x_notifier_call(bq-nb,
 +   PSY_EVENT_PROP_CHANGED, psy);
 bq2415x_set_mode(bq, bq-reported_mode);
 -   dev_info(bq-dev, automode enabled\n);
 } else {
 -   

Re: [PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.

[Michael Trimarchi]

Hi Andreas

On Mon, Nov 18, 2013 at 8:53 AM, Andreas Fenkart afenk...@gmail.com wrote:
 The am335x can't detect pending cirq in PM runtime suspend.
 This patch reconfigures dat1 as a GPIO before going to suspend.
 SDIO interrupts are detected with the GPIO, the GPIO will only wake
 the module from suspend, SDIO irq detection will still happen through the
 IP block.

 Idea of remuxing the pins by Tony Lindgren as well as the implementation
 of omap_hsmmc_pin_init.

 Signed-off-by: Andreas Fenkart afenk...@gmail.com

 diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
 b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 index 1136e6b..146f3ad 100644
 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 @@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
  ti,needs-special-reset: Requires a special softreset sequence
  ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
 High Speed
  ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
 -SDIO irq while in suspend. Fallback to polling. Affected chips are
 -am335x,
 +SDIO irq while in suspend. The workaround is to reconfigure the dat1 line as 
 a
 +GPIO upon suspend. Beyond this option and the GPIO config, you also need to 
 set
 +named pinctrl states default, active and idle , see example below.  The
 +MMC driver will then then toggle between default and idle during the runtime
 +Affected chips are am335x,

  --
  | PRCM |
 @@ -49,3 +52,24 @@ Example:
 vmmc-supply = vmmc; /* phandle to regulator node */
 ti,non-removable;
 };
 +
 +[am335x with with gpio for sdio irq]
 +
 +   mmc1_cirq_pin: pinmux_cirq_pin {
 +   pinctrl-single,pins = 
 +   0x0f8 0x3f  /* MMC0_DAT1 as GPIO2_28 */
 +   ;
 +   };
 +
 +   mmc1: mmc@4806 {
 +   ti,non-removable;
 +   bus-width = 4;
 +   vmmc-supply = ldo2_reg;
 +   vmmc_aux-supply = vmmc;
 +   ti,quirk-swakeup-missing;
 +   pinctrl-names = default, active, idle;
 +   pinctrl-0 = mmc1_pins;
 +   pinctrl-1 = mmc1_pins;
 +   pinctrl-2 = mmc1_cirq_pin;
 +   ti,cirq-gpio = gpio3 28 0;
 +   };
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 6b0ec55..b94ab08 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -36,6 +36,7 @@
  #include linux/mmc/core.h
  #include linux/mmc/mmc.h
  #include linux/io.h
 +#include linux/irq.h
  #include linux/gpio.h
  #include linux/regulator/consumer.h
  #include linux/pinctrl/consumer.h
 @@ -213,11 +214,32 @@ struct omap_hsmmc_host {
 int req_in_progress;
 int flags;
  #define HSMMC_SDIO_IRQ_ENABLED (1  0)/* SDIO irq enabled */
 +#define HSMMC_SWAKEUP_QUIRK(1  1)
 +#define HSMMC_CIRQ_GPIO_ENABLED (1  2)

 struct omap_hsmmc_next  next_data;
 +   struct pinctrl  *pinctrl;
 +   struct pinctrl_state*fixed, *active, *idle;
 struct  omap_mmc_platform_data  *pdata;
  };

 +static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
 +{
 +   struct omap_hsmmc_host *host = dev_id;
 +   unsigned long flags;
 +
 +   spin_lock_irqsave(host-irq_lock, flags);
 +   if (host-flags  HSMMC_CIRQ_GPIO_ENABLED) {
 +   disable_irq_nosync(mmc_slot(host).sdio_irq);
 +   host-flags = ~HSMMC_CIRQ_GPIO_ENABLED;
 +   }
 +   spin_unlock_irqrestore(host-irq_lock, flags);
 +
 +   pm_request_resume(host-dev); /* no use counter */
 +
 +   return IRQ_HANDLED;
 +}
 +
  static int omap_hsmmc_card_detect(struct device *dev, int slot)
  {
 struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 @@ -452,10 +474,25 @@ static int omap_hsmmc_gpio_init(struct 
 omap_mmc_platform_data *pdata)
 } else
 pdata-slots[0].gpio_wp = -EINVAL;

 +   if (gpio_is_valid(pdata-slots[0].gpio_cirq)) {
 +   pdata-slots[0].sdio_irq =
 +   gpio_to_irq(pdata-slots[0].gpio_cirq);

What is this? re-assign the platform data?

 +   ret = gpio_request_one(pdata-slots[0].gpio_cirq, 
 GPIOF_DIR_IN,
 +  sdio_cirq);
 +   if (ret)
 +   goto err_free_ro;
 +
 +   } else {
 +   pdata-slots[0].gpio_cirq = -EINVAL;
 +   }
 +
 +
 return 0;

 +err_free_ro:
 +   if (gpio_is_valid(pdata-slots[0].gpio_wp))
  err_free_wp:
 -   gpio_free(pdata-slots[0].gpio_wp);
 +   gpio_free(pdata-slots[0].gpio_wp);
  err_free_cd:
 if (gpio_is_valid(pdata-slots[0].switch_pin))
  err_free_sp:
 @@ -469,6 +506,69 @@ static void 

Re: [PATCH 1/3] mmc: omap_hsmmc: Enable SDIO IRQ.

[Michael Trimarchi]

Hi Andreas

On Mon, Nov 11, 2013 at 9:06 PM, Andreas Fenkart afenk...@gmail.com wrote:
 For now, only support SDIO interrupt if we are booted with
 DT. This is because some platforms need special quirks. And
 we don't want to add new legacy mux platform init code
 callbacks any longer as we are moving to DT based booting
 anyways.

 Broken hardware, missing the swakueup line, should fallback
 to polling, by setting 'ti,quirk-swakup-missing' in the
 device tree. Otherwise pending SDIO IRQ are not detected
 while in suspend. This affects am33xx processors.

 For the DT-Binding portion:
 Reviewed-by: Grant Likely grant.lik...@secretlab.ca
 Acked-by: Kumar Gala ga...@codeaurora.org
 Signed-off-by: Andreas Fenkart afenk...@gmail.com
 ---

I think that you should add patch revision, change log description.

Michael

  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   18 
  drivers/mmc/host/omap_hsmmc.c  |   86 
 ++--
  2 files changed, 95 insertions(+), 9 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
 b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 index ed271fc..1136e6b 100644
 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 @@ -20,6 +20,24 @@ ti,dual-volt: boolean, supports dual voltage cards
  ti,non-removable: non-removable slot (like eMMC)
  ti,needs-special-reset: Requires a special softreset sequence
  ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
 High Speed
 +ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
 +SDIO irq while in suspend. Fallback to polling. Affected chips are
 +am335x,
 +
 +--
 +| PRCM |
 + --
 +  ^ |
 +  swakeup | | fclk
 +  | v
 +  -----   -
 + | card | -- CIRQ --  | hsmmc | -- IRQ --  | CPU |
 +  -----   -
 +
 +In suspend the fclk is off and the module is disfunctional. Even
 +register reads will fail. A small logic in the host will request fclk
 +restore, when an external event is detected. Once the clock is
 +restored, the host detects the event normally.

  Example:
 mmc1: mmc@0x4809c000 {
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index b392130..6b0ec55 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -130,6 +130,7 @@ static void apply_clk_hack(struct device *dev)
  #define TC_EN  (1  1)
  #define BWR_EN (1  4)
  #define BRR_EN (1  5)
 +#define CIRQ_EN(1  8)
  #define ERR_EN (1  15)
  #define CTO_EN (1  16)
  #define CCRC_EN(1  17)
 @@ -210,6 +211,9 @@ struct omap_hsmmc_host {
 int reqs_blocked;
 int use_reg;
 int req_in_progress;
 +   int flags;
 +#define HSMMC_SDIO_IRQ_ENABLED (1  0)/* SDIO irq enabled */
 +
 struct omap_hsmmc_next  next_data;
 struct  omap_mmc_platform_data  *pdata;
  };
 @@ -490,27 +494,40 @@ static void omap_hsmmc_stop_clock(struct 
 omap_hsmmc_host *host)
  static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
   struct mmc_command *cmd)
  {
 -   unsigned int irq_mask;
 +   u32 irq_mask = INT_EN_MASK;
 +   unsigned long flags;

 if (host-use_dma)
 -   irq_mask = INT_EN_MASK  ~(BRR_EN | BWR_EN);
 -   else
 -   irq_mask = INT_EN_MASK;
 +   irq_mask = ~(BRR_EN | BWR_EN);

 /* Disable timeout for erases */
 if (cmd-opcode == MMC_ERASE)
 irq_mask = ~DTO_EN;

 +   spin_lock_irqsave(host-irq_lock, flags);
 OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
 OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
 +
 +   /* latch pending CIRQ, but don't signal */
 +   if (host-flags  HSMMC_SDIO_IRQ_ENABLED)
 +   irq_mask |= CIRQ_EN;
 OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
 +   spin_unlock_irqrestore(host-irq_lock, flags);
  }

  static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
  {
 -   OMAP_HSMMC_WRITE(host-base, ISE, 0);
 -   OMAP_HSMMC_WRITE(host-base, IE, 0);
 +   u32 irq_mask = 0;
 +   unsigned long flags;
 +
 +   spin_lock_irqsave(host-irq_lock, flags);
 +   /* no transfer running, need to signal cirq if enabled */
 +   if (host-flags  HSMMC_SDIO_IRQ_ENABLED)
 +   irq_mask |= CIRQ_EN;
 +   OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
 +   OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
 OMAP_HSMMC_WRITE(host-base, 

Re: [PATCH 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.

[Michael Trimarchi]

Hi

On Mon, Nov 11, 2013 at 9:06 PM, Andreas Fenkart afenk...@gmail.com wrote:
 The am335x can't detect pending cirq in PM runtime suspend.
 This patch reconfigures dat1 as a GPIO before going to suspend.
 SDIO interrupts are detected with the GPIO, the GPIO will only wake
 the module from suspend, SDIO irq detection will still happen through the
 IP block.

 Idea of remuxing the pins by Tony Lindgren as well as the implementation
 of omap_hsmmc_pin_init.

 Signed-off-by: Andreas Fenkart afenk...@gmail.com
 ---
  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   28 ++-
  drivers/mmc/host/omap_hsmmc.c  |  189 
 ++--
  include/linux/platform_data/mmc-omap.h |4 +
  3 files changed, 207 insertions(+), 14 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
 b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 index 1136e6b..146f3ad 100644
 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 @@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
  ti,needs-special-reset: Requires a special softreset sequence
  ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
 High Speed
  ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
 -SDIO irq while in suspend. Fallback to polling. Affected chips are
 -am335x,
 +SDIO irq while in suspend. The workaround is to reconfigure the dat1 line as 
 a
 +GPIO upon suspend. Beyond this option and the GPIO config, you also need to 
 set
 +named pinctrl states default, active and idle , see example below.  The
 +MMC driver will then then toggle between default and idle during the runtime
 +Affected chips are am335x,

  --
  | PRCM |
 @@ -49,3 +52,24 @@ Example:
 vmmc-supply = vmmc; /* phandle to regulator node */
 ti,non-removable;
 };
 +
 +[am335x with with gpio for sdio irq]
 +
 +   mmc1_cirq_pin: pinmux_cirq_pin {
 +   pinctrl-single,pins = 
 +   0x0f8 0x3f  /* MMC0_DAT1 as GPIO2_28 */
 +   ;
 +   };
 +
 +   mmc1: mmc@4806 {
 +   ti,non-removable;
 +   bus-width = 4;
 +   vmmc-supply = ldo2_reg;
 +   vmmc_aux-supply = vmmc;
 +   ti,quirk-swakeup-missing;
 +   pinctrl-names = default, active, idle;
 +   pinctrl-0 = mmc1_pins;
 +   pinctrl-1 = mmc1_pins;
 +   pinctrl-2 = mmc1_cirq_pin;
 +   ti,cirq-gpio = gpio3 28 0;
 +   };
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 6b0ec55..5a7fb4b 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -36,6 +36,7 @@
  #include linux/mmc/core.h
  #include linux/mmc/mmc.h
  #include linux/io.h
 +#include linux/irq.h
  #include linux/gpio.h
  #include linux/regulator/consumer.h
  #include linux/pinctrl/consumer.h
 @@ -213,11 +214,30 @@ struct omap_hsmmc_host {
 int req_in_progress;
 int flags;
  #define HSMMC_SDIO_IRQ_ENABLED (1  0)/* SDIO irq enabled */
 +#define HSMMC_SWAKEUP_QUIRK(1  1)
 +#define HSMMC_CIRQ_GPIO_FIRED  (1  2)

 struct omap_hsmmc_next  next_data;
 +   struct pinctrl  *pinctrl;
 +   struct pinctrl_state*fixed, *active, *idle;
 struct  omap_mmc_platform_data  *pdata;
  };

 +static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
 +{
 +   struct omap_hsmmc_host *host = dev_id;
 +   unsigned long flags;
 +
 +   spin_lock_irqsave(host-irq_lock, flags);
 +   host-flags |= HSMMC_CIRQ_GPIO_FIRED;
 +   disable_irq_nosync(mmc_slot(host).sdio_irq);
 +   spin_unlock_irqrestore(host-irq_lock, flags);
 +
 +   pm_request_resume(host-dev); /* no use counter */
 +
 +   return IRQ_HANDLED;
 +}
 +
  static int omap_hsmmc_card_detect(struct device *dev, int slot)
  {
 struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 @@ -452,10 +472,25 @@ static int omap_hsmmc_gpio_init(struct 
 omap_mmc_platform_data *pdata)
 } else
 pdata-slots[0].gpio_wp = -EINVAL;

 +   if (gpio_is_valid(pdata-slots[0].gpio_cirq)) {
 +   pdata-slots[0].sdio_irq =
 +   gpio_to_irq(pdata-slots[0].gpio_cirq);
 +   ret = gpio_request_one(pdata-slots[0].gpio_cirq, 
 GPIOF_DIR_IN,
 +  sdio_cirq);
 +   if (ret)
 +   goto err_free_ro;
 +
 +   } else {
 +   pdata-slots[0].gpio_cirq = -EINVAL;
 +   }
 +
 +
 return 0;

 +err_free_ro:
 +   if (gpio_is_valid(pdata-slots[0].gpio_wp))
  err_free_wp:
 -   gpio_free(pdata-slots[0].gpio_wp);
 +   gpio_free(pdata-slots[0].gpio_wp);
  

Re: [PATCH 3/3] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux.

[Michael Trimarchi]

Hi

On Mon, Nov 11, 2013 at 7:52 PM,  afenk...@gmail.com wrote:
 From: Andreas Fenkart afenk...@gmail.com

 Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
 state of data lines, incl. SDIO IRQ pending

 Signed-off-by: Andreas Fenkart afenk...@gmail.com
 ---
  drivers/mmc/host/omap_hsmmc.c |   22 +-
  1 file changed, 21 insertions(+), 1 deletion(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index e880b44..34e2ee0 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -81,6 +81,7 @@ static void apply_clk_hack(struct device *dev)
  #define OMAP_HSMMC_RSP54   0x0118
  #define OMAP_HSMMC_RSP76   0x011C
  #define OMAP_HSMMC_DATA0x0120
 +#define OMAP_HSMMC_PSTATE  0x0124
  #define OMAP_HSMMC_HCTL0x0128
  #define OMAP_HSMMC_SYSCTL  0x012C
  #define OMAP_HSMMC_STAT0x0130
 @@ -1800,6 +1801,23 @@ static int omap_hsmmc_regs_show(struct seq_file *s, 
 void *data)
  {
 struct mmc_host *mmc = s-private;
 struct omap_hsmmc_host *host = mmc_priv(mmc);
 +   unsigned long flags;
 +   bool suspended;
 +
 +   spin_lock_irqsave(host-irq_lock, flags);

Why do you need a spin_lock_irqsave just to print out the status?

 +   seq_puts(s, \n);
 +   seq_printf(s, sdio irq\t%s\n, ((host-flags  
 HSMMC_SDIO_IRQ_ENABLED)
 +? enabled : disabled));
 +   suspended = host-dev-power.runtime_status != RPM_ACTIVE;
 +   if (host-flags  HSMMC_SWAKEUP_QUIRK) {
 +   seq_printf(s, pinmux config\t%s\n, (suspended ?
 + gpio : sdio));
 +   if (suspended)
 +   seq_printf(s, sdio irq pin\t%s\n,
 +  gpio_get_value(mmc_slot(host).gpio_cirq) ?
 +  high : low);
 +   }
 +   spin_unlock_irqrestore(host-irq_lock, flags);


Michael

 if (host-suspended) {
 seq_printf(s, host suspended, can't read registers\n);
 @@ -1807,9 +1825,11 @@ static int omap_hsmmc_regs_show(struct seq_file *s, 
 void *data)
 }

 pm_runtime_get_sync(host-dev);
 -
 +   seq_puts(s, \nregs:\n);
 seq_printf(s, CON:\t\t0x%08x\n,
 OMAP_HSMMC_READ(host-base, CON));
 +   seq_printf(s, PSTATE:\t\t0x%08x\n,
 +  OMAP_HSMMC_READ(host-base, PSTATE));
 seq_printf(s, HCTL:\t\t0x%08x\n,
 OMAP_HSMMC_READ(host-base, HCTL));
 seq_printf(s, SYSCTL:\t\t0x%08x\n,
 --
 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
--
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/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.

[Michael Trimarchi]

Hi

On Mon, Nov 11, 2013 at 7:52 PM,  afenk...@gmail.com wrote:
 From: Andreas Fenkart andreas.fenk...@dev.digitalstrom.org

 The am335x can't detect pending cirq in PM runtime suspend.
 This patch reconfigures dat1 as a GPIO before going to suspend.
 SDIO interrupts are detected with the GPIO, the GPIO will only wake
 the module from suspend, SDIO irq detection will still happen through the
 IP block.

 Idea of remuxing the pins by Tony Lindgren as well as the implementation
 of omap_hsmmc_pin_init.

 Signed-off-by: Andreas Fenkart afenk...@gmail.com
 ---
  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   28 ++-
  drivers/mmc/host/omap_hsmmc.c  |  195 
 ++--
  include/linux/platform_data/mmc-omap.h |4 +
  3 files changed, 213 insertions(+), 14 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
 b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 index 1136e6b..146f3ad 100644
 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 @@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
  ti,needs-special-reset: Requires a special softreset sequence
  ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
 High Speed
  ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
 -SDIO irq while in suspend. Fallback to polling. Affected chips are
 -am335x,
 +SDIO irq while in suspend. The workaround is to reconfigure the dat1 line as 
 a
 +GPIO upon suspend. Beyond this option and the GPIO config, you also need to 
 set
 +named pinctrl states default, active and idle , see example below.  The
 +MMC driver will then then toggle between default and idle during the runtime
 +Affected chips are am335x,

  --
  | PRCM |
 @@ -49,3 +52,24 @@ Example:
 vmmc-supply = vmmc; /* phandle to regulator node */
 ti,non-removable;
 };
 +
 +[am335x with with gpio for sdio irq]
 +
 +   mmc1_cirq_pin: pinmux_cirq_pin {
 +   pinctrl-single,pins = 
 +   0x0f8 0x3f  /* MMC0_DAT1 as GPIO2_28 */
 +   ;
 +   };
 +
 +   mmc1: mmc@4806 {
 +   ti,non-removable;
 +   bus-width = 4;
 +   vmmc-supply = ldo2_reg;
 +   vmmc_aux-supply = vmmc;
 +   ti,quirk-swakeup-missing;
 +   pinctrl-names = default, active, idle;
 +   pinctrl-0 = mmc1_pins;
 +   pinctrl-1 = mmc1_pins;
 +   pinctrl-2 = mmc1_cirq_pin;
 +   ti,cirq-gpio = gpio3 28 0;
 +   };
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 6b0ec55..e880b44 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -36,6 +36,7 @@
  #include linux/mmc/core.h
  #include linux/mmc/mmc.h
  #include linux/io.h
 +#include linux/irq.h
  #include linux/gpio.h
  #include linux/regulator/consumer.h
  #include linux/pinctrl/consumer.h
 @@ -213,11 +214,30 @@ struct omap_hsmmc_host {
 int req_in_progress;
 int flags;
  #define HSMMC_SDIO_IRQ_ENABLED (1  0)/* SDIO irq enabled */
 +#define HSMMC_SWAKEUP_QUIRK(1  1)
 +#define HSMMC_CIRQ_GPIO_FIRED  (1  2)

 struct omap_hsmmc_next  next_data;
 +   struct pinctrl  *pinctrl;
 +   struct pinctrl_state*fixed, *active, *idle;
 struct  omap_mmc_platform_data  *pdata;
  };

 +static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
 +{
 +   struct omap_hsmmc_host *host = dev_id;
 +   unsigned long flags;
 +
 +   spin_lock_irqsave(host-irq_lock, flags);
 +   host-flags |= HSMMC_CIRQ_GPIO_FIRED;
 +   disable_irq_nosync(mmc_slot(host).sdio_irq);
 +   spin_unlock_irqrestore(host-irq_lock, flags);
 +
 +   pm_request_resume(host-dev); /* no use counter */
 +
 +   return IRQ_HANDLED;
 +}
 +
  static int omap_hsmmc_card_detect(struct device *dev, int slot)
  {
 struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 @@ -452,10 +472,31 @@ static int omap_hsmmc_gpio_init(struct 
 omap_mmc_platform_data *pdata)
 } else
 pdata-slots[0].gpio_wp = -EINVAL;

 +   if (pdata-slots[0].gpio_cirq  0 
 +   gpio_is_valid(pdata-slots[0].gpio_cirq)) {

Is ok only gpio_is_valid?

 +   pdata-slots[0].sdio_irq =
 +   gpio_to_irq(pdata-slots[0].gpio_cirq);
 +
 +   ret = gpio_request(pdata-slots[0].gpio_cirq, sdio_cirq);
 +   if (ret)
 +   goto err_free_ro;
 +   ret = gpio_direction_input(pdata-slots[0].gpio_cirq);
 +   if (ret)
 +   goto err_free_cirq;

Can you use gpio_request_one?


Michael

 +
 +   } else {
 +   

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi Roger

On Thu, Jul 4, 2013 at 10:53 AM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
 Hi

 On 07/02/2013 05:03 PM, Roger Quadros wrote:

 On 07/02/2013 05:49 PM, Michael Trimarchi wrote:
 Hi Roger

 On 07/02/2013 04:42 PM, Roger Quadros wrote:
 On 06/28/2013 07:47 PM, Michael Trimarchi wrote:
 Hi



I'm working on PM consumption of other subsystem because it's a very
complex device.
Right now the pm consumption is sleep mode is 6mA just for (off mode disabled)

omap4 + LPDDR2 and TWL6032

I don't exactly know if they have updated the last bootloader but I think so.

I have tried to work on STP signal and re-enable it just before resume
but nothing change

Anyway my idea is the problem is releated on 18clk counter and an
invalid state of the
hw. I will try to implement save  restore register by hand instead
using the sar.

Michael



 When you said earlier that the problem doesn't happen when one of the 
 ULPIs is used
 did you try both of them individually. e.g. case 1: port 1 only enabled,
 case 2: port 2 only enabled.

 Did it work in both the cases?

 Yes, so I don't think could be a problem of ulpi pins and why this happen
 on both at the same time? Seems more connected to somenthing else.


 Right. Seems to be related to two things. OFF Mode and 2 ports being used 
 simultaneously.

 I'm not sure how to go about fixing this. How important is OFF Mode for 
 your application.
 Can you keep it always disabled?




 Right now I delivery without off mode. I will try to fix in long run the 
 usb and I think that it could be a good platform to test omap4 mainline.


 Yes, our aim is to get it working with mainline as well.

 Last question:
 If one domain is in RET mode and not OFF mode what happen during SAR 
 restore in OFF mode?


 SAR restore will only happen when the Device enters OFF mode.

 Device OFF mode can only be reached when all voltage domains are switched 
 OFF and that would depend
 if all power domains entered OFF or not. Just a simplistic explanation. You 
 can refer to chapter
 3.9.3 Device OFF State Management in the TRM.

 What happen if we ask to go in off mode for all domains but one doesn't go in 
 off mode so the device
 will not go in off mode and the sar will not be used? How can work the 
 restore?



 I have added a check of CM_RESTORE_ST. This register need to be clear before
 going in OFF mode and then show if the status of phase1 2a and 2b is 
 completed.
 So before proceed with system resume and after resetting OFF_MODE bit I have 
 tried to wait on this register,
 but without success.

 Michael

 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] ASoC: omap-mcbsp: Support SND_SOC_DAIFMT_CBM_CFS for omap3/4

[Michael Trimarchi]

Add SND_SOC_DAIFMT_CBM_CFS support for omap3/omap4. The patch was tested on
a pandaboard-es board connected to the pcm1792a codec. mcbspx_fsx must
configured as output and mcbspx_clkx must be configured as input.

Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com
---
 sound/soc/omap/omap-mcbsp.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 7483efb..6c19bba 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -433,6 +433,11 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai 
*cpu_dai,
/* Sample rate generator drives the FS */
regs-srgr2 |= FSGM;
break;
+   case SND_SOC_DAIFMT_CBM_CFS:
+   /* McBSP slave. FS clock as output */
+   regs-srgr2 |= FSGM;
+   regs-pcr0  |= FSXM;
+   break;
case SND_SOC_DAIFMT_CBM_CFM:
/* McBSP slave */
break;
-- 
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: mcbsp.1 slave clkx ext problem

[Michael Trimarchi]

Hi Peter

On Fri, Jul 19, 2013 at 05:29:44PM +0200, Michael Trimarchi wrote:
 Hi
 
 On 07/19/2013 03:33 PM, Michael Trimarchi wrote:
  Hi
  
  I'm trying to understand what is wrong here with this small
  driver.
  
  /* McBSP1 */
  OMAP4_MUX(ABE_MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
  OMAP4_MUX(ABE_MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
  OMAP4_MUX(ABE_MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
OMAP_PULL_ENA),
  OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
  
  kernel 3.8.0
  
 
 I have fixed my problem ;). I will send a description about it
 
 Michael
 

I will prepare a proper patch. But OMAP supports (both omap3/omap4) the
SND_SOC_DAIFMT_CBM_CFS format in this way. I have already tested it on
my devkit platform

diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 8d2defd..85dd415 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -435,6 +435,11 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai 
*cpu_dai,
/* Sample rate generator drives the FS */
regs-srgr2 |= FSGM;
break;
+   case SND_SOC_DAIFMT_CBM_CFS:
+   /* McBSP slave. FS clock as output */
+   regs-srgr2 |= FSGM;
+   regs-pcr0  |= FSXM;
+   break;
case SND_SOC_DAIFMT_CBM_CFM:
/* McBSP slave */
break;


Best regards
Michael

  [  107.276702] omap-mcbsp omap-mcbsp.1: Configuring McBSP1  phys_base: 
  0x40122000
  [  107.283691] omap-mcbsp omap-mcbsp.1:  McBSP1 regs 
  [  107.283721] omap-mcbsp omap-mcbsp.1: DRR2:  0x88260a09
  [  107.283721] omap-mcbsp omap-mcbsp.1: DRR1:  0x
  [  107.283752] omap-mcbsp omap-mcbsp.1: DXR2:  0x
  [  107.283752] omap-mcbsp omap-mcbsp.1: DXR1:  0x
  [  107.283752] omap-mcbsp omap-mcbsp.1: SPCR2: 0x0233
  [  107.283782] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030
  [  107.283782] omap-mcbsp omap-mcbsp.1: RCR2:  0x80a1
  [  107.283813] omap-mcbsp omap-mcbsp.1: RCR1:  0x00a0
  [  107.283813] omap-mcbsp omap-mcbsp.1: XCR2:  0x80a1
  [  107.283813] omap-mcbsp omap-mcbsp.1: XCR1:  0x00a0
  [  107.283843] omap-mcbsp omap-mcbsp.1: SRGR2: 0x203f
  [  107.283843] omap-mcbsp omap-mcbsp.1: SRGR1: 0x1f00
  [  107.283843] omap-mcbsp omap-mcbsp.1: PCR0:  0x008f
  [  107.283874] omap-mcbsp omap-mcbsp.1: ***
  [  119.926177] omap-dma-engine omap-dma-engine: freeing channel for 33
  
  Well basically it doesn't start the transfer. The clock is provided
  using the clkx pin. clkx is rate * channel * bitsxword and come from
  the codec. 
  
  What is wrong? (I know that how I register the card is deprecated)
  
  Regards Michael
  
  /*
   * dacmax.c  --  SoC audio for pandaboard demokit
   *
   * Author: Michael Trimarchi mich...@amarulasolutions.com
   *
   * Based on:
   * Author: Misael Lopez Cruz x0052...@ti.com
   *
   * This program is free software; you can redistribute it and/or
   * modify it under the terms of the GNU General Public License
   * version 2 as published by the Free Software Foundation.
   *
   * This program is distributed in the hope that it will be useful, but
   * WITHOUT ANY WARRANTY; without even the implied warranty of
   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   * General Public License for more details.
   *
   * You should have received a copy of the GNU General Public License
   * along with this program; if not, write to the Free Software
   * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
   * 02110-1301 USA
   *
   */
  
  #include linux/clk.h
  #include linux/platform_device.h
  #include sound/core.h
  #include sound/pcm.h
  #include sound/pcm_params.h
  #include sound/soc.h
  
  #include asm/mach-types.h
  #include linux/gpio.h
  #include linux/platform_data/asoc-ti-mcbsp.h
  
  #include linux/module.h
  #include omap-mcbsp.h
  
  static struct snd_soc_card snd_soc_dacmax;
  
  static int dacmax_hw_params(struct snd_pcm_substream *substream,
  struct snd_pcm_hw_params *params)
  {
  int ret;
  struct snd_soc_pcm_runtime *rtd = substream-private_data;
  struct snd_soc_dai *cpu_dai = rtd-cpu_dai;
  
  pr_info(%s: setting the params\n, __func__);
  
  ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKX_EXT, 0,
  SND_SOC_CLOCK_IN);
  if (ret  0) {
  printk(KERN_ERR can't set CPU system clock  \
  OMAP_MCBSP_CLKR_SRC_CLKX\n);
  }
  
  return 0;
  }
  
  static struct snd_soc_ops dacmax_ops = {
  .hw_params = dacmax_hw_params,
  };
  
  static int dacmax_init(struct snd_soc_pcm_runtime *rtd)
  {
  pr_info(%s: INIT\n, __func__);
  return 0;
  }
  
  /* Digital audio interface glue - connects codec -- CPU */
  static struct snd_soc_dai_link dacmax_dai = {
  .name = DACMAX-I2S,
  .stream_name = DACMAX-Audio,
  .cpu_dai_name = omap

mcbsp.1 slave clkx ext problem

[Michael Trimarchi]

Hi

I'm trying to understand what is wrong here with this small
driver.

/* McBSP1 */
OMAP4_MUX(ABE_MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP4_MUX(ABE_MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
OMAP4_MUX(ABE_MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
  OMAP_PULL_ENA),
OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),

kernel 3.8.0

[  107.276702] omap-mcbsp omap-mcbsp.1: Configuring McBSP1  phys_base: 
0x40122000
[  107.283691] omap-mcbsp omap-mcbsp.1:  McBSP1 regs 
[  107.283721] omap-mcbsp omap-mcbsp.1: DRR2:  0x88260a09
[  107.283721] omap-mcbsp omap-mcbsp.1: DRR1:  0x
[  107.283752] omap-mcbsp omap-mcbsp.1: DXR2:  0x
[  107.283752] omap-mcbsp omap-mcbsp.1: DXR1:  0x
[  107.283752] omap-mcbsp omap-mcbsp.1: SPCR2: 0x0233
[  107.283782] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030
[  107.283782] omap-mcbsp omap-mcbsp.1: RCR2:  0x80a1
[  107.283813] omap-mcbsp omap-mcbsp.1: RCR1:  0x00a0
[  107.283813] omap-mcbsp omap-mcbsp.1: XCR2:  0x80a1
[  107.283813] omap-mcbsp omap-mcbsp.1: XCR1:  0x00a0
[  107.283843] omap-mcbsp omap-mcbsp.1: SRGR2: 0x203f
[  107.283843] omap-mcbsp omap-mcbsp.1: SRGR1: 0x1f00
[  107.283843] omap-mcbsp omap-mcbsp.1: PCR0:  0x008f
[  107.283874] omap-mcbsp omap-mcbsp.1: ***
[  119.926177] omap-dma-engine omap-dma-engine: freeing channel for 33

Well basically it doesn't start the transfer. The clock is provided
using the clkx pin. clkx is rate * channel * bitsxword and come from
the codec. 

What is wrong? (I know that how I register the card is deprecated)

Regards Michael

/*
 * dacmax.c  --  SoC audio for pandaboard demokit
 *
 * Author: Michael Trimarchi mich...@amarulasolutions.com
 *
 * Based on:
 * Author: Misael Lopez Cruz x0052...@ti.com
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 *
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 * 02110-1301 USA
 *
 */

#include linux/clk.h
#include linux/platform_device.h
#include sound/core.h
#include sound/pcm.h
#include sound/pcm_params.h
#include sound/soc.h

#include asm/mach-types.h
#include linux/gpio.h
#include linux/platform_data/asoc-ti-mcbsp.h

#include linux/module.h
#include omap-mcbsp.h

static struct snd_soc_card snd_soc_dacmax;

static int dacmax_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
int ret;
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct snd_soc_dai *cpu_dai = rtd-cpu_dai;

pr_info(%s: setting the params\n, __func__);

ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKX_EXT, 0,
SND_SOC_CLOCK_IN);
if (ret  0) {
printk(KERN_ERR can't set CPU system clock  \
OMAP_MCBSP_CLKR_SRC_CLKX\n);
}

return 0;
}

static struct snd_soc_ops dacmax_ops = {
.hw_params = dacmax_hw_params,
};

static int dacmax_init(struct snd_soc_pcm_runtime *rtd)
{
pr_info(%s: INIT\n, __func__);
return 0;
}

/* Digital audio interface glue - connects codec -- CPU */
static struct snd_soc_dai_link dacmax_dai = {
.name = DACMAX-I2S,
.stream_name = DACMAX-Audio,
.cpu_dai_name = omap-mcbsp.1,
.codec_dai_name = pcm1792a-hifi,
.platform_name = omap-pcm-audio,
.codec_name = pcm1792a,
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
   SND_SOC_DAIFMT_CBM_CFM,
.init = dacmax_init,
.ops = dacmax_ops,
};

/* Audio machine driver */
static struct snd_soc_card snd_soc_dacmax = {
.name = DACMAX,
.driver_name = OMAP4,
.long_name = TI OMAP4 Board,
.dai_link = dacmax_dai,
.num_links = 1,
};

static struct platform_device *dacmax_snd_device;

static int __init dacmax_soc_init(void)
{
int ret;

printk(KERN_INFO DACMAX SoC init\n);

dacmax_snd_device = platform_device_alloc(soc-audio, -1);
if (!dacmax_snd_device) {
printk(KERN_ERR Platform device allocation failed\n);
return -ENOMEM;
}

platform_set_drvdata(dacmax_snd_device, snd_soc_dacmax);

ret = platform_device_add(dacmax_snd_device);
if (ret)
goto err1;

return 0;

err1:
printk(KERN_ERR Unable to add platform device\n);
platform_device_put(dacmax_snd_device);

return ret;
}
module_init

Re: mcbsp.1 slave clkx ext problem

[Michael Trimarchi]

Hi

On 07/19/2013 03:33 PM, Michael Trimarchi wrote:
 Hi
 
 I'm trying to understand what is wrong here with this small
 driver.
 
 /* McBSP1 */
 OMAP4_MUX(ABE_MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 OMAP4_MUX(ABE_MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
 OMAP4_MUX(ABE_MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
   OMAP_PULL_ENA),
 OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 
 kernel 3.8.0
 

I have fixed my problem ;). I will send a description about it

Michael

 [  107.276702] omap-mcbsp omap-mcbsp.1: Configuring McBSP1  phys_base: 
 0x40122000
 [  107.283691] omap-mcbsp omap-mcbsp.1:  McBSP1 regs 
 [  107.283721] omap-mcbsp omap-mcbsp.1: DRR2:  0x88260a09
 [  107.283721] omap-mcbsp omap-mcbsp.1: DRR1:  0x
 [  107.283752] omap-mcbsp omap-mcbsp.1: DXR2:  0x
 [  107.283752] omap-mcbsp omap-mcbsp.1: DXR1:  0x
 [  107.283752] omap-mcbsp omap-mcbsp.1: SPCR2: 0x0233
 [  107.283782] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030
 [  107.283782] omap-mcbsp omap-mcbsp.1: RCR2:  0x80a1
 [  107.283813] omap-mcbsp omap-mcbsp.1: RCR1:  0x00a0
 [  107.283813] omap-mcbsp omap-mcbsp.1: XCR2:  0x80a1
 [  107.283813] omap-mcbsp omap-mcbsp.1: XCR1:  0x00a0
 [  107.283843] omap-mcbsp omap-mcbsp.1: SRGR2: 0x203f
 [  107.283843] omap-mcbsp omap-mcbsp.1: SRGR1: 0x1f00
 [  107.283843] omap-mcbsp omap-mcbsp.1: PCR0:  0x008f
 [  107.283874] omap-mcbsp omap-mcbsp.1: ***
 [  119.926177] omap-dma-engine omap-dma-engine: freeing channel for 33
 
 Well basically it doesn't start the transfer. The clock is provided
 using the clkx pin. clkx is rate * channel * bitsxword and come from
 the codec. 
 
 What is wrong? (I know that how I register the card is deprecated)
 
 Regards Michael
 
 /*
  * dacmax.c  --  SoC audio for pandaboard demokit
  *
  * Author: Michael Trimarchi mich...@amarulasolutions.com
  *
  * Based on:
  * Author: Misael Lopez Cruz x0052...@ti.com
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
  * version 2 as published by the Free Software Foundation.
  *
  * This program is distributed in the hope that it will be useful, but
  * WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  * General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
  * 02110-1301 USA
  *
  */
 
 #include linux/clk.h
 #include linux/platform_device.h
 #include sound/core.h
 #include sound/pcm.h
 #include sound/pcm_params.h
 #include sound/soc.h
 
 #include asm/mach-types.h
 #include linux/gpio.h
 #include linux/platform_data/asoc-ti-mcbsp.h
 
 #include linux/module.h
 #include omap-mcbsp.h
 
 static struct snd_soc_card snd_soc_dacmax;
 
 static int dacmax_hw_params(struct snd_pcm_substream *substream,
   struct snd_pcm_hw_params *params)
 {
   int ret;
   struct snd_soc_pcm_runtime *rtd = substream-private_data;
   struct snd_soc_dai *cpu_dai = rtd-cpu_dai;
 
   pr_info(%s: setting the params\n, __func__);
 
   ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKX_EXT, 0,
 SND_SOC_CLOCK_IN);
   if (ret  0) {
   printk(KERN_ERR can't set CPU system clock  \
   OMAP_MCBSP_CLKR_SRC_CLKX\n);
   }
 
   return 0;
 }
 
 static struct snd_soc_ops dacmax_ops = {
   .hw_params = dacmax_hw_params,
 };
 
 static int dacmax_init(struct snd_soc_pcm_runtime *rtd)
 {
   pr_info(%s: INIT\n, __func__);
   return 0;
 }
 
 /* Digital audio interface glue - connects codec -- CPU */
 static struct snd_soc_dai_link dacmax_dai = {
   .name = DACMAX-I2S,
   .stream_name = DACMAX-Audio,
   .cpu_dai_name = omap-mcbsp.1,
   .codec_dai_name = pcm1792a-hifi,
   .platform_name = omap-pcm-audio,
   .codec_name = pcm1792a,
   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
  SND_SOC_DAIFMT_CBM_CFM,
   .init = dacmax_init,
   .ops = dacmax_ops,
 };
 
 /* Audio machine driver */
 static struct snd_soc_card snd_soc_dacmax = {
   .name = DACMAX,
   .driver_name = OMAP4,
   .long_name = TI OMAP4 Board,
   .dai_link = dacmax_dai,
   .num_links = 1,
 };
 
 static struct platform_device *dacmax_snd_device;
 
 static int __init dacmax_soc_init(void)
 {
   int ret;
 
   printk(KERN_INFO DACMAX SoC init\n);
 
   dacmax_snd_device = platform_device_alloc(soc-audio, -1);
   if (!dacmax_snd_device) {
   printk(KERN_ERR Platform device allocation failed\n);
   return -ENOMEM;
   }
 
   platform_set_drvdata(dacmax_snd_device, snd_soc_dacmax);
 
   ret = platform_device_add(dacmax_snd_device);
   if (ret

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On 07/02/2013 05:03 PM, Roger Quadros wrote:
 
 On 07/02/2013 05:49 PM, Michael Trimarchi wrote:
 Hi Roger

 On 07/02/2013 04:42 PM, Roger Quadros wrote:
 On 06/28/2013 07:47 PM, Michael Trimarchi wrote:
 Hi

 

 When you said earlier that the problem doesn't happen when one of the 
 ULPIs is used
 did you try both of them individually. e.g. case 1: port 1 only enabled,
 case 2: port 2 only enabled.

 Did it work in both the cases?

 Yes, so I don't think could be a problem of ulpi pins and why this happen
 on both at the same time? Seems more connected to somenthing else.


 Right. Seems to be related to two things. OFF Mode and 2 ports being used 
 simultaneously.

 I'm not sure how to go about fixing this. How important is OFF Mode for 
 your application.
 Can you keep it always disabled?

 
 

 Right now I delivery without off mode. I will try to fix in long run the usb 
 and I think that it could be a good platform to test omap4 mainline.

 
 Yes, our aim is to get it working with mainline as well.
 
 Last question:
 If one domain is in RET mode and not OFF mode what happen during SAR restore 
 in OFF mode?

 
 SAR restore will only happen when the Device enters OFF mode.
 
 Device OFF mode can only be reached when all voltage domains are switched OFF 
 and that would depend
 if all power domains entered OFF or not. Just a simplistic explanation. You 
 can refer to chapter
 3.9.3 Device OFF State Management in the TRM.

What happen if we ask to go in off mode for all domains but one doesn't go in 
off mode so the device
will not go in off mode and the sar will not be used? How can work the restore?

 

I have added a check of CM_RESTORE_ST. This register need to be clear before
going in OFF mode and then show if the status of phase1 2a and 2b is completed.
So before proceed with system resume and after resetting OFF_MODE bit I have 
tried to wait on this register,
but without success.

Michael

 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: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi Roger

On 07/02/2013 04:42 PM, Roger Quadros wrote:
 On 06/28/2013 07:47 PM, Michael Trimarchi wrote:
 Hi

 On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
 On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
 Hi Roger

 On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
 On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
 mich...@amarulasolutions.com wrote:

 Do you have locks around this software workaround?
 The patch I did against 3.4 linux kernel may be helpful for
 you in such case: http://review.omapzoom.org/28515
 Another patch extends this WA for all OMAP4 SoCs:
 http://review.omapzoom.org/31108

 I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb 
 suspend cycle are done correctly) so
 the problem could be:

 1) SAR usb context restore. I have applied the SAR workaround but the core 
 doesn't go in full retantion
 could be it a problem?

 If core doesn't go in to OFF then SAR will not come into play. Are you 
 still affected by the
 issue if OFF mode is disabled? If yes then it probably is not related to 
 SAR.


 2) idle status of ulpis pins?

 Yes this can be possible.

 When you said earlier that the problem doesn't happen when one of the ULPIs 
 is used
 did you try both of them individually. e.g. case 1: port 1 only enabled,
 case 2: port 2 only enabled.

 Did it work in both the cases?

 Yes, so I don't think could be a problem of ulpi pins and why this happen
 on both at the same time? Seems more connected to somenthing else.

 
 Right. Seems to be related to two things. OFF Mode and 2 ports being used 
 simultaneously.
 
 I'm not sure how to go about fixing this. How important is OFF Mode for your 
 application.
 Can you keep it always disabled?
 

Right now I delivery without off mode. I will try to fix in long run the usb 
and I think that it could be a good platform to test omap4 mainline.

Last question:
If one domain is in RET mode and not OFF mode what happen during SAR restore in 
OFF mode?


Michael


 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: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi Roger

On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
 On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
 mich...@amarulasolutions.com wrote:
  Hi
 
  On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
  Hello guys,
 
  On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
  mich...@amarulasolutions.com wrote:
   Hi Roger
  
   On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote:
   +Ruslan
  
   On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
Hi Roger
   
On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
Hi Michael,
   
On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
Hi
   
I'm working on omap4460 with two ulpi connected to (SMSC3320 - HUB 
SMSC2514) or (TUSB1210 - HUB SMSC2514).
The problem only happen when both port are used and after few 
suspend resume are triggered.
If I use just one port there is no issue on suspend resume. I 
already covered all TI
errata that I know and I'm working on TI kernel.
   
The problem is here
   
[   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
   
Both ports change status from 001005 to 001009 (you have a log just 
after).
So from host point of view both hub connected are not working in HS 
mode.
After that the omap ehci has gone because the bus can not work in 
FS and LS and I can not recover from here.
Status of transceivers are dumped and they are ok after resume.
   
Do you have any suggestion?
   
I'm not very sure but both ports suddenly changing state like that 
look like
a hardware issue. Also, it is strange that you can reproduce it only 
when two
ports are simultaneously in use. Unfortunately, I can't match your 
setup with 2 ULPI
   
Yes I know that TI doesn't have any setup like that.
   
ports.
   
I have a OMAP5 uEVM that uses 2 ports but it won't be identical to 
your setup as
they are on HSIC and not ULPI.
   
Did you try errata i693?
   
Yes I have it. It's not clear if I need to wait after
ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
polling the suspendM of the SMSC or the suspend status of the PORT or 
I can
switch just after this instruction. Because TI kernel use an msleep 
of 4 mseconds and then switch. It could be a timing issue on how 
errata is implemented when I have two ports? How this internal count 
works?
  
  
   The OMAP EHCI controller transparently sets the suspendM bit of the PHY 
   when you
   set the PORT_SUSPEND feature on the EHCI port. So you don't need to 
   poll for anything.
  
  
   A delay is necessary. If we apply the errata to the port before a delay 
   the errata
   doesn't work.
  
   /* Use internal 60Mhz clock ULPIBx */
   temp_reg = omap_readl(L3INIT_HSUSBHOST_CLKCTRL);
   temp_reg |= 1  (8 + port);
   temp_reg = ~(1  (24 + port));
   omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
  
   /* Wait 2ms to have transceiver transaction */
   mdelay(2);
  
   /* Use external clock ULPIBx */
   temp_reg = ~(1  (8 + port));
   temp_reg |= 1  (24 + port);
   omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
  
   Now it's not clear to me what happen if I apply this clock too early 
   (transeceiver still
   driver the clock) or too late. Any clue?
 
  We need to wait 3ms for entire USB bus to go into suspend after
  setting the PORT_SUSPEND bit. During this time, internal OMAP EHCI logic
  will communicate with PHY so it is not safe to switch the clocks to
  internal source.
  That's why with 2ms delay it fails. 4ms delay (3ms + 1ms for safety)
  is enough here
  and is successfully used last few years for production devices.
 
  Well this mdelay is the switch of the clock and not the delay after
  PORT_SUSPEND. So after writing PORT_SUSPEND I need to wait
  4ms and then in 2ms you have a lot of clock to reach the 18 count. Correct?
 
 Yes, sorry for confusing :)
 Moreover, 2ms is more than enough, errata document says about 1ms delay
 (and probably may be decreased up to few useconds)
 
 
  Anyway I understand, but why both hub connected to the smsc3320 move from
  HS to FS? So it's not important if there is a drift of delay but it must
  be = 4ms. Correct?
 
  The code works if I just use one port or remove one hub ;)
 
  Now the code is like this:
 
  temp = ~(PORT_WKCONN_E | PORT_RWC_BITS);
  temp |= PORT_WKDISC_E | PORT_WKOC_E;
  ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
 
  mdelay(4);
  omap_ehci_erratum_i693(ehci, ((wIndex  0xff) - 1));
 
  The code of the function is up on this email.
 
 Do you have locks around this software workaround?
 The patch I did against 3.4 linux kernel may be helpful for
 you in such case: http://review.omapzoom.org/28515
 Another patch extends this WA for all OMAP4 SoCs:
 http://review.omapzoom.org/31108

I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend 
cycle are done correctly) so
the problem could

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
 On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
  Hi Roger
  
  On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
  On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
  mich...@amarulasolutions.com wrote:
 
  Do you have locks around this software workaround?
  The patch I did against 3.4 linux kernel may be helpful for
  you in such case: http://review.omapzoom.org/28515
  Another patch extends this WA for all OMAP4 SoCs:
  http://review.omapzoom.org/31108
  
  I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb 
  suspend cycle are done correctly) so
  the problem could be:
  
  1) SAR usb context restore. I have applied the SAR workaround but the core 
  doesn't go in full retantion
  could be it a problem?
 
 If core doesn't go in to OFF then SAR will not come into play. Are you still 
 affected by the
 issue if OFF mode is disabled? If yes then it probably is not related to SAR.
 

I don't go in full retantion for FSUSB now

[   36.317413]PD_CORE curr=ON prev=ON logic=ON
[   36.317413]PD_L3_INIT curr=ON prev=ON logic=ON
[   36.317413]   CD_L3_INIT mode=SW_SLEEP activity=0x2100
[   36.317413]  FSUSB mode=DISABLED stbyst=STBY idlest=TRANSITION
[   36.317413] Powerdomain (core_pwrdm) didn't enter target state 1 Vs achieved 
state 3. current state 3
[   36.317413] Powerdomain (l3init_pwrdm) didn't enter target state 1 Vs 
achieved state 3. current state 3

This with enable_off_mode equal to 1 and usb stuck

but if I switch to enable_off_mode 0 (debug file), it works. So the problem 
seems somewhere there.

Michael

  
  2) idle status of ulpis pins?
 
 Yes this can be possible.
 
 When you said earlier that the problem doesn't happen when one of the ULPIs 
 is used
 did you try both of them individually. e.g. case 1: port 1 only enabled,
 case 2: port 2 only enabled.
 
 Did it work in both the cases?
 
 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: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On Fri, Jun 28, 2013 at 03:55:08PM +0300, Roger Quadros wrote:
 On 06/28/2013 03:26 PM, Michael Trimarchi wrote:
  Hi
  
  On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
  On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
  Hi Roger
 
  On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
  On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
  mich...@amarulasolutions.com wrote:
 
  Do you have locks around this software workaround?
  The patch I did against 3.4 linux kernel may be helpful for
  you in such case: http://review.omapzoom.org/28515
  Another patch extends this WA for all OMAP4 SoCs:
  http://review.omapzoom.org/31108
 
  I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb 
  suspend cycle are done correctly) so
  the problem could be:
 
  1) SAR usb context restore. I have applied the SAR workaround but the 
  core doesn't go in full retantion
  could be it a problem?
 
  If core doesn't go in to OFF then SAR will not come into play. Are you 
  still affected by the
  issue if OFF mode is disabled? If yes then it probably is not related to 
  SAR.
 
  
  I don't go in full retantion for FSUSB now
  
  [   36.317413]PD_CORE curr=ON prev=ON logic=ON
  [   36.317413]PD_L3_INIT curr=ON prev=ON logic=ON
  [   36.317413]   CD_L3_INIT mode=SW_SLEEP activity=0x2100
  [   36.317413]  FSUSB mode=DISABLED stbyst=STBY idlest=TRANSITION
  [   36.317413] Powerdomain (core_pwrdm) didn't enter target state 1 Vs 
  achieved state 3. current state 3
  [   36.317413] Powerdomain (l3init_pwrdm) didn't enter target state 1 Vs 
  achieved state 3. current state 3
  
  This with enable_off_mode equal to 1 and usb stuck
  
  but if I switch to enable_off_mode 0 (debug file), it works. So the problem 
  seems somewhere there.
 
 OK. Looks like the FSUSB module is stuck in transition. This can happen if 
 the bootloader
 hasn't improperly managed the FSUSB clock.
 
 Can you apply the below patch to your bootloader and make sure FSUSB module 
 is OFF at boot.
 
 Let's see how it behaves with FSUSB out of the picture.

I was having already in the queue. Not was testing because the system is very 
complicated with boot security. BTW now I have fixed the retantion and change 
suspend
state of REGEN1 for a shutdown problem. So now the system
can suspend perfectly but the problem is still there. I have done a very
good step forward ;) anyway (was planned to test the new version of bootloader)

Michael


 
 cheers,
 -roger
 
 From 0e42d3643d531daabd086f7ee451fdda8f22e72a Mon Sep 17 00:00:00 2001
 From: Tero Kristo t-kri...@ti.com
 Date: Wed, 25 Apr 2012 06:05:20 +
 Subject: [PATCH] omap4: do not enable fs-usb module
 
 If this is done in the bootloader, the FS-USB will later be stuck into
 intransition state, which will prevent the device from entering idle.
 
 Signed-off-by: Tero Kristo t-kri...@ti.com
 ---
  arch/arm/cpu/armv7/omap4/clocks.c |2 --
  1 files changed, 0 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/cpu/armv7/omap4/clocks.c 
 b/arch/arm/cpu/armv7/omap4/clocks.c
 index e2189f7..2802559 100644
 --- a/arch/arm/cpu/armv7/omap4/clocks.c
 +++ b/arch/arm/cpu/armv7/omap4/clocks.c
 @@ -355,7 +355,6 @@ void enable_basic_clocks(void)
   prcm-cm_l4per_gptimer2_clkctrl,
   prcm-cm_wkup_wdtimer2_clkctrl,
   prcm-cm_l4per_uart3_clkctrl,
 - prcm-cm_l3init_fsusb_clkctrl,
   prcm-cm_l3init_hsusbhost_clkctrl,
   0
   };
 @@ -482,7 +481,6 @@ void enable_non_essential_clocks(void)
   prcm-cm_dss_dss_clkctrl,
   prcm-cm_sgx_sgx_clkctrl,
   prcm-cm_l3init_hsusbhost_clkctrl,
 - prcm-cm_l3init_fsusb_clkctrl,
   0
   };
  
 -- 
 1.7.4.1

--
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: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
 On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
  Hi Roger
  
  On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
  On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
  mich...@amarulasolutions.com wrote:
 
  Do you have locks around this software workaround?
  The patch I did against 3.4 linux kernel may be helpful for
  you in such case: http://review.omapzoom.org/28515
  Another patch extends this WA for all OMAP4 SoCs:
  http://review.omapzoom.org/31108
  
  I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb 
  suspend cycle are done correctly) so
  the problem could be:
  
  1) SAR usb context restore. I have applied the SAR workaround but the core 
  doesn't go in full retantion
  could be it a problem?
 
 If core doesn't go in to OFF then SAR will not come into play. Are you still 
 affected by the
 issue if OFF mode is disabled? If yes then it probably is not related to SAR.
 
  
  2) idle status of ulpis pins?
 
 Yes this can be possible.
 
 When you said earlier that the problem doesn't happen when one of the ULPIs 
 is used
 did you try both of them individually. e.g. case 1: port 1 only enabled,
 case 2: port 2 only enabled.
 
 Did it work in both the cases?

Yes, so I don't think could be a problem of ulpi pins and why this happen
on both at the same time? Seems more connected to somenthing else.

Michael

 
 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: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On 06/28/2013 01:46 PM, Roger Quadros wrote:
 On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
 Hi Roger

 On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
 On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
 mich...@amarulasolutions.com wrote:
 
 Do you have locks around this software workaround?
 The patch I did against 3.4 linux kernel may be helpful for
 you in such case: http://review.omapzoom.org/28515
 Another patch extends this WA for all OMAP4 SoCs:
 http://review.omapzoom.org/31108

 I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb 
 suspend cycle are done correctly) so
 the problem could be:

 1) SAR usb context restore. I have applied the SAR workaround but the core 
 doesn't go in full retantion
 could be it a problem?
 
 If core doesn't go in to OFF then SAR will not come into play. Are you still 
 affected by the
 issue if OFF mode is disabled? If yes then it probably is not related to SAR.
 

 2) idle status of ulpis pins?
 
 Yes this can be possible.
 
 When you said earlier that the problem doesn't happen when one of the ULPIs 
 is used
 did you try both of them individually. e.g. case 1: port 1 only enabled,
 case 2: port 2 only enabled.
 
 Did it work in both the cases?

off state of the line can make the situation worst ;). What are the idle/off 
state of the lines
on your platforms?

I can use PAD_REMUX flag to change the datax and signal of each port. I think 
that when the core
is in RET_OFF the signal lines are remuxed in off mode. Correct?

Michael


 
 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: AM35xx i2c3 issues

[Michael Trimarchi]

Hi

On Thu, Jun 27, 2013 at 08:29:05AM +, Marc Murphy wrote:
 Hello Grygorii/All,
 
 I have been trying to address an issue I am having with 3.6rc6 kernel and 
 even with the latest 3.9 and trying to use i2c3 channel on an AM3517.
 
 I see that there has been some work done on the OMAP4 and issues with i2c 
 which looks like the controller being suspended during boot.
 
 I would like to know how I can enable the debug so I can see the messages for 
 warning and debug and whether anyone has tested i2c3 channel on an AM3517 ?
 
 I find the problem a little confusing as the system initializes the 
 interfaces 1-3
 
 [0.168182] omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz
 [0.169830] VDCDC1: 1200 -- 1600 mV at 1200 mV normal
 [0.169830] VDCDC1: Voltage range but no REGULATOR_CHANGE_VOLTAGE
 [0.170684] VDCDC2: 3300 mV normal
 [0.171264] VDCDC3: 1800 mV normal
 [0.171905] LDO1: 1800 mV normal
 [0.172729] LDO2: 3300 mV normal
 [0.174102] omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz
 [0.187530] omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz
 
 But when it comes to probe the i2c3 interface for the mpu6050 that is 
 connected it fails
 
 [3.896606] omap_i2c omap_i2c.3: timeout waiting for bus ready
 [3.902832] inv-mpu6050: probe of 3-0068 failed with error -110
 

Can you check if your bus is correctly pull up on the line?

Michael

 If I move the mpu6050 onto the i2c2 channel it’s OK so its not an issue with 
 the core omap_i2c.
 
 I also have a scope connected to the scl line and see no activity.  I have 
 proved to myself that the pin is connected and working by configuring as a 
 GPIO output and toggling 0/1/0 and I can see the output changing on the scope.
 
 The mux is configured correctly from what I can see using debugfs
 #  cat /sys/kernel/debug/omap_mux/i2c3_scl
 name: i2c3_scl.i2c3_scl (0x480021c2/0x192 = 0x0100), b af14, t NA
 mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
 signals: i2c3_scl | NA | NA | NA | gpio_184 | NA | NA | safe_mode
 
 #  cat /sys/kernel/debug/omap_mux/i2c3_sda
 name: i2c3_sda.i2c3_sda (0x480021c4/0x194 = 0x0100), b ag14, t NA
 mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
 signals: i2c3_sda | NA | NA | NA | gpio_185 | NA | NA | safe_mode
 
 
 If I probe with i2cdetect for all 3 buses there is only an issue with i2c3
 # i2cdetect -r 1
 WARNING! This program can confuse your I2C bus, cause data loss and worse!
 I will probe file /dev/i2c-1 using read byte commands.
 I will probe address range 0x03-0x77.
 Continue? [Y/n]
  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 70: -- -- -- -- -- -- -- --
 
 # i2cdetect -r 2
 WARNING! This program can confuse your I2C bus, cause data loss and worse!
 I will probe file /dev/i2c-2 using read byte commands.
 I will probe address range 0x03-0x77.
 Continue? [Y/n]
  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 70: -- -- -- -- -- -- -- --
 
 # i2cdetect -r 3
 WARNING! This program can confuse your I2C bus, cause data loss and worse!
 I will probe file /dev/i2c-3 using read byte commands.
 I will probe address range 0x03-0x77.
 Continue? [Y/n]
  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
 00:  [  837.943481] omap_i2c omap_i2c.3: timeout waiting for bus ready
 -- [  838.958984] omap_i2c omap_i2c.3: timeout waiting for bus ready
 -- [  839.974731] omap_i2c omap_i2c.3: timeout waiting for bus ready
 
 
 Any pointers/help appreciated as I have the accelerometer and RTC chip 
 connected on i2c3 but cannot get anything working.
 
 Kind Regards
 
 Marc
 --
 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
--
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

omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

I'm working on omap4460 with two ulpi connected to (SMSC3320 - HUB SMSC2514) 
or (TUSB1210 - HUB SMSC2514). 
The problem only happen when both port are used and after few suspend resume 
are triggered.
If I use just one port there is no issue on suspend resume. I already covered 
all TI
errata that I know and I'm working on TI kernel.

The problem is here

[   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD

Both ports change status from 001005 to 001009 (you have a log just after). 
So from host point of view both hub connected are not working in HS mode. 
After that the omap ehci has gone because the bus can not work in FS and LS and 
I can not recover from here.
Status of transceivers are dumped and they are ok after resume.

Do you have any suggestion?

Normal case

SUSPEND

DIR HIGH
CLOCK is OFF

AFTER RESUME

DIR has signal

CLOCK is 60 Mhz

Disconnect case

SUSPEND

DIR HIGH
CLOCK is OFF

AFTER RESUME
DIR is LOW
CLOCK is 60Mhz



[   77.593566] ehci-omap ehci-omap.0: ehci_omap_bus_resume
[   77.593658] ehci-omap ehci-omap.0: resume root hub
[   77.615814] hub 2-0:1.0: hub_resume
[   77.639251] hub 1-0:1.0: hub_resume
[   77.639282] ehci-omap ehci-omap.0: GetStatus port:1 status 001885 0  ACK 
POWER sig=j SUSPEND PE CONNECT
[   77.639282] hub 1-0:1.0: port 1: status 0507 change 
[   77.639312] ehci-omap ehci-omap.0: GetStatus port:2 status 001885 0  ACK 
POWER sig=j SUSPEND PE CONNECT
[   77.639312] hub 1-0:1.0: port 2: status 0507 change 
[   77.639312] ehci-omap ehci-omap.0: GetStatus port:3 status 001000 0  ACK 
POWER sig=se0
[   77.639373] ehci-omap ehci-omap.0: GetStatus port:1 status 001885 0  ACK 
POWER sig=j SUSPEND PE CONNECT
[   77.639404] usb 1-1: usb resume
[   77.639434] ehci-omap ehci-omap.0: GetStatus port:2 status 001885 0  ACK 
POWER sig=j SUSPEND PE CONNECT
[   77.639434] usb 1-2: usb resume
[   77.678314] dump_tranceiver --- on port 1
[   77.678314] ULPI_FUNC_CTRL 0x40
[   77.678344] ULPI_IFC_CTRL 0x00
[   77.678344] ULPI_OTG_CTRL 0x06
[   77.678344] ULPI_DEBUG 0x00
[   77.678344] ULPI_USB_INT_STS 0x14
[   77.678344] dump_tranceiver -- on port 1
[   77.678375] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0  ACK 
POWER sig=se0 PE CONNECT
[   77.678405] dump_tranceiver --- on port 2
[   77.678405] ULPI_FUNC_CTRL 0x40
[   77.678405] ULPI_IFC_CTRL 0x00
[   77.678436] ULPI_OTG_CTRL 0x06
[   77.678436] ULPI_DEBUG 0x00
[   77.678436] ULPI_USB_INT_STS 0x14
[   77.678436] dump_tranceiver -- on port 2
[   77.678466] ehci-omap ehci-omap.0: GetStatus port:2 status 001005 0  ACK 
POWER sig=se0 PE CONNECT
[   77.701782] usb 1-1: finish resume
[   77.701812] usb 1-2: finish resume
[   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
[   77.701934] Port 2 Status 0x1000
[   77.701934] Port 1 Status 0x1009
[   77.701965] Port 0 Status 0x1009
[   82.717529] ehci-omap ehci-omap.0: IAA watchdog: status a008 cmd 10065
[   82.717590] usb 1-2: kworker/u:12 timed out on ep0in len=0/2
[   82.717590] usb 1-2: gone after usb resume? status -110
[   82.717590] usb 1-2: can't resume, status -110
[   82.717620] hub 1-0:1.0: logical disconnect on port 2
[   82.717620] Disable PORT_PE
[   82.717651] pm_op(): usb_dev_resume+0x0/0x18 returns -110
[   82.717651] PM: Device 1-2 failed to resume async: error -110
[   82.733154] ehci-omap ehci-omap.0: IAA watchdog: status a008 cmd 10065
[   82.733184] usb 1-1: kworker/u:15 timed out on ep0in len=0/2
[   82.733215] usb 1-1: gone after usb resume? status -110
[   82.733215] usb 1-1: can't resume, status -110
[   82.733215] hub 1-0:1.0: logical disconnect on port 1
[   82.733215] Disable PORT_PE
[   82.733245] pm_op(): usb_dev_resume+0x0/0x18 returns -110
[   82.733245] PM: Device 1-1 failed to resume async: error -110
[   82.734741] PM: resume of devices complete after 5229.652 msecs
[   83.303863] PM: Finishing wakeup.
[   83.307525] Restarting tasks ... 
[   83.311157] hub 2-0:1.0: state 7 ports 1 chg  evt 
[   83.317504] hub 2-0:1.0: hub_resume
[   83.321716] done.
[   83.323974] suspend: exit suspend, ret = 0 (2000-01-02 21:07:12.171992466 
UTC)
[   83.323974] hub 2-0:1.0: activate -- -22
[   83.324005] hub 1-0:1.0: state 7 ports 3 chg 0006 evt 0006
[   83.324035] ehci-omap ehci-omap.0: GetStatus port:1 status 001801 0  ACK 
POWER sig=j CONNECT
[   83.324035] hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s
[   83.324035] usb 1-1: USB disconnect, device number 2
[   83.324066] usb 1-1.2: USB disconnect, device number 4
[   83.324066] usb 1-1.2: unregistering device
[   83.324066] usb 1-1.2: unregistering interface 1-1.2:1.0
[   83.530700] usb 1-1.2: usb_disable_device nuking all URBs
[   83.537200] usb 1-1.3: USB disconnect, device number 5
[   83.542907] usb 1-1.3: unregistering device
[   83.547546] usb 1-1.3: unregistering interface 1-1.3:1.0
[   83.554107] usb 1-1.3: usb_disable_device nuking all URBs
[   83.560577] usb 1-1: unregistering device
[   83.565063] usb 

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi Roger

On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
 Hi Michael,
 
 On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
  Hi
  
  I'm working on omap4460 with two ulpi connected to (SMSC3320 - HUB 
  SMSC2514) or (TUSB1210 - HUB SMSC2514). 
  The problem only happen when both port are used and after few suspend 
  resume are triggered.
  If I use just one port there is no issue on suspend resume. I already 
  covered all TI
  errata that I know and I'm working on TI kernel.
  
  The problem is here
  
  [   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
  
  Both ports change status from 001005 to 001009 (you have a log just after). 
  So from host point of view both hub connected are not working in HS mode. 
  After that the omap ehci has gone because the bus can not work in FS and LS 
  and I can not recover from here.
  Status of transceivers are dumped and they are ok after resume.
  
  Do you have any suggestion?
 
 I'm not very sure but both ports suddenly changing state like that look like
 a hardware issue. Also, it is strange that you can reproduce it only when two
 ports are simultaneously in use. Unfortunately, I can't match your setup with 
 2 ULPI

Yes I know that TI doesn't have any setup like that.

 ports.
 
 I have a OMAP5 uEVM that uses 2 ports but it won't be identical to your setup 
 as
 they are on HSIC and not ULPI.
 
 Did you try errata i693?

Yes I have it. It's not clear if I need to wait after
ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
polling the suspendM of the SMSC or the suspend status of the PORT or I can
switch just after this instruction. Because TI kernel use an msleep of 4 
mseconds and then switch. It could be a timing issue on how errata is 
implemented when I have two ports? How this internal count works?

First time is 18, and then?

 
 Also, are you suspending and resuming only the USB or the entire system?
 

Whole system. Right the only susbsytem that doens't go to suspend is the FSUSB
but this depends on the bootloader.

Michael


 cheers,
 -roger

-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
--
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: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi Roger

On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote:
 +Ruslan
 
 On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
  Hi Roger
  
  On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
  Hi Michael,
 
  On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
  Hi
 
  I'm working on omap4460 with two ulpi connected to (SMSC3320 - HUB 
  SMSC2514) or (TUSB1210 - HUB SMSC2514). 
  The problem only happen when both port are used and after few suspend 
  resume are triggered.
  If I use just one port there is no issue on suspend resume. I already 
  covered all TI
  errata that I know and I'm working on TI kernel.
 
  The problem is here
 
  [   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
 
  Both ports change status from 001005 to 001009 (you have a log just 
  after). 
  So from host point of view both hub connected are not working in HS mode. 
  After that the omap ehci has gone because the bus can not work in FS and 
  LS and I can not recover from here.
  Status of transceivers are dumped and they are ok after resume.
 
  Do you have any suggestion?
 
  I'm not very sure but both ports suddenly changing state like that look 
  like
  a hardware issue. Also, it is strange that you can reproduce it only when 
  two
  ports are simultaneously in use. Unfortunately, I can't match your setup 
  with 2 ULPI
  
  Yes I know that TI doesn't have any setup like that.
  
  ports.
 
  I have a OMAP5 uEVM that uses 2 ports but it won't be identical to your 
  setup as
  they are on HSIC and not ULPI.
 
  Did you try errata i693?
  
  Yes I have it. It's not clear if I need to wait after
  ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
  polling the suspendM of the SMSC or the suspend status of the PORT or I can
  switch just after this instruction. Because TI kernel use an msleep of 4 
  mseconds and then switch. It could be a timing issue on how errata is 
  implemented when I have two ports? How this internal count works?
 
 
 The OMAP EHCI controller transparently sets the suspendM bit of the PHY when 
 you
 set the PORT_SUSPEND feature on the EHCI port. So you don't need to poll for 
 anything.
 

A delay is necessary. If we apply the errata to the port before a delay the 
errata
doesn't work. 

/* Use internal 60Mhz clock ULPIBx */
temp_reg = omap_readl(L3INIT_HSUSBHOST_CLKCTRL);
temp_reg |= 1  (8 + port);
temp_reg = ~(1  (24 + port));
omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);

/* Wait 2ms to have transceiver transaction */
mdelay(2);

/* Use external clock ULPIBx */
temp_reg = ~(1  (8 + port));
temp_reg |= 1  (24 + port);
omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);

Now it's not clear to me what happen if I apply this clock too early 
(transeceiver still
driver the clock) or too late. Any clue?


 What the errata says is that once software sets the PORT_SUSPEND feature, the 
 PHY will
 got into suspend and cut the PHY clock sooner than required for the EHCI 
 controller to
 complete its suspend operations. (NOTE: this is only applicable when the PHY 
 is providing the
 ulpi_clk).
 

Yes this is the case

 What the workaround does is to just wait for a while (don't know why 4ms), 
 and remux the
 ulpi_clock to an internal 60MHz clock for a while so that it can complete its 
 suspend operations.

What happen if I apply a big delay after PORT_SUSPEND. Will the internal state 
machine of the omap
continue to wait the clock?

Michael

 
  
  First time is 18, and then?
 
 I think it is 18 for every port suspend.
  
 
  Also, are you suspending and resuming only the USB or the entire system?
 
  
  Whole system. Right the only susbsytem that doens't go to suspend is the 
  FSUSB
  but this depends on the bootloader.
 
 OK. 
 
 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: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
 Hello guys,
 
 On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
 mich...@amarulasolutions.com wrote:
  Hi Roger
 
  On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote:
  +Ruslan
 
  On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
   Hi Roger
  
   On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
   Hi Michael,
  
   On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
   Hi
  
   I'm working on omap4460 with two ulpi connected to (SMSC3320 - HUB 
   SMSC2514) or (TUSB1210 - HUB SMSC2514).
   The problem only happen when both port are used and after few suspend 
   resume are triggered.
   If I use just one port there is no issue on suspend resume. I already 
   covered all TI
   errata that I know and I'm working on TI kernel.
  
   The problem is here
  
   [   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
  
   Both ports change status from 001005 to 001009 (you have a log just 
   after).
   So from host point of view both hub connected are not working in HS 
   mode.
   After that the omap ehci has gone because the bus can not work in FS 
   and LS and I can not recover from here.
   Status of transceivers are dumped and they are ok after resume.
  
   Do you have any suggestion?
  
   I'm not very sure but both ports suddenly changing state like that look 
   like
   a hardware issue. Also, it is strange that you can reproduce it only 
   when two
   ports are simultaneously in use. Unfortunately, I can't match your 
   setup with 2 ULPI
  
   Yes I know that TI doesn't have any setup like that.
  
   ports.
  
   I have a OMAP5 uEVM that uses 2 ports but it won't be identical to your 
   setup as
   they are on HSIC and not ULPI.
  
   Did you try errata i693?
  
   Yes I have it. It's not clear if I need to wait after
   ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
   polling the suspendM of the SMSC or the suspend status of the PORT or I 
   can
   switch just after this instruction. Because TI kernel use an msleep of 4 
   mseconds and then switch. It could be a timing issue on how errata is 
   implemented when I have two ports? How this internal count works?
 
 
  The OMAP EHCI controller transparently sets the suspendM bit of the PHY 
  when you
  set the PORT_SUSPEND feature on the EHCI port. So you don't need to poll 
  for anything.
 
 
  A delay is necessary. If we apply the errata to the port before a delay the 
  errata
  doesn't work.
 
  /* Use internal 60Mhz clock ULPIBx */
  temp_reg = omap_readl(L3INIT_HSUSBHOST_CLKCTRL);
  temp_reg |= 1  (8 + port);
  temp_reg = ~(1  (24 + port));
  omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
 
  /* Wait 2ms to have transceiver transaction */
  mdelay(2);
 
  /* Use external clock ULPIBx */
  temp_reg = ~(1  (8 + port));
  temp_reg |= 1  (24 + port);
  omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
 
  Now it's not clear to me what happen if I apply this clock too early 
  (transeceiver still
  driver the clock) or too late. Any clue?
 
 We need to wait 3ms for entire USB bus to go into suspend after
 setting the PORT_SUSPEND bit. During this time, internal OMAP EHCI logic
 will communicate with PHY so it is not safe to switch the clocks to
 internal source.
 That's why with 2ms delay it fails. 4ms delay (3ms + 1ms for safety)
 is enough here
 and is successfully used last few years for production devices.

Well this mdelay is the switch of the clock and not the delay after
PORT_SUSPEND. So after writing PORT_SUSPEND I need to wait
4ms and then in 2ms you have a lot of clock to reach the 18 count. Correct?

Anyway I understand, but why both hub connected to the smsc3320 move from
HS to FS? So it's not important if there is a drift of delay but it must
be = 4ms. Correct?

The code works if I just use one port or remove one hub ;)

Now the code is like this:

temp = ~(PORT_WKCONN_E | PORT_RWC_BITS);
temp |= PORT_WKDISC_E | PORT_WKOC_E;
ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);

mdelay(4);
omap_ehci_erratum_i693(ehci, ((wIndex  0xff) - 1));

The code of the function is up on this email.

Michael

 
 -- 
 Best regards,
 Ruslan Bilvol
 
 
 
  What the errata says is that once software sets the PORT_SUSPEND feature, 
  the PHY will
  got into suspend and cut the PHY clock sooner than required for the EHCI 
  controller to
  complete its suspend operations. (NOTE: this is only applicable when the 
  PHY is providing the
  ulpi_clk).
 
 
  Yes this is the case
 
  What the workaround does is to just wait for a while (don't know why 4ms), 
  and remux the
  ulpi_clock to an internal 60MHz clock for a while so that it can complete 
  its suspend operations.
 
  What happen if I apply a big delay after PORT_SUSPEND. Will the internal 
  state machine of the omap
  continue to wait the clock?
 
  Michael
 
 
  
   First time is 18, and then?
  
  I think it is 18 for every port suspend.
 
  
   Also, are you suspending

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
 On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
 mich...@amarulasolutions.com wrote:
  Hi
 
  On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
  Hello guys,
 
  On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
  mich...@amarulasolutions.com wrote:
   Hi Roger
  
   On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote:
   +Ruslan
  
   On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
Hi Roger
   
On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
Hi Michael,
   
On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
Hi
   
I'm working on omap4460 with two ulpi connected to (SMSC3320 - HUB 
SMSC2514) or (TUSB1210 - HUB SMSC2514).
The problem only happen when both port are used and after few 
suspend resume are triggered.
If I use just one port there is no issue on suspend resume. I 
already covered all TI
errata that I know and I'm working on TI kernel.
   
The problem is here
   
[   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
   
Both ports change status from 001005 to 001009 (you have a log just 
after).
So from host point of view both hub connected are not working in HS 
mode.
After that the omap ehci has gone because the bus can not work in 
FS and LS and I can not recover from here.
Status of transceivers are dumped and they are ok after resume.
   
Do you have any suggestion?
   
I'm not very sure but both ports suddenly changing state like that 
look like
a hardware issue. Also, it is strange that you can reproduce it only 
when two
ports are simultaneously in use. Unfortunately, I can't match your 
setup with 2 ULPI
   
Yes I know that TI doesn't have any setup like that.
   
ports.
   
I have a OMAP5 uEVM that uses 2 ports but it won't be identical to 
your setup as
they are on HSIC and not ULPI.
   
Did you try errata i693?
   
Yes I have it. It's not clear if I need to wait after
ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
polling the suspendM of the SMSC or the suspend status of the PORT or 
I can
switch just after this instruction. Because TI kernel use an msleep 
of 4 mseconds and then switch. It could be a timing issue on how 
errata is implemented when I have two ports? How this internal count 
works?
  
  
   The OMAP EHCI controller transparently sets the suspendM bit of the PHY 
   when you
   set the PORT_SUSPEND feature on the EHCI port. So you don't need to 
   poll for anything.
  
  
   A delay is necessary. If we apply the errata to the port before a delay 
   the errata
   doesn't work.
  
   /* Use internal 60Mhz clock ULPIBx */
   temp_reg = omap_readl(L3INIT_HSUSBHOST_CLKCTRL);
   temp_reg |= 1  (8 + port);
   temp_reg = ~(1  (24 + port));
   omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
  
   /* Wait 2ms to have transceiver transaction */
   mdelay(2);
  
   /* Use external clock ULPIBx */
   temp_reg = ~(1  (8 + port));
   temp_reg |= 1  (24 + port);
   omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
  
   Now it's not clear to me what happen if I apply this clock too early 
   (transeceiver still
   driver the clock) or too late. Any clue?
 
  We need to wait 3ms for entire USB bus to go into suspend after
  setting the PORT_SUSPEND bit. During this time, internal OMAP EHCI logic
  will communicate with PHY so it is not safe to switch the clocks to
  internal source.
  That's why with 2ms delay it fails. 4ms delay (3ms + 1ms for safety)
  is enough here
  and is successfully used last few years for production devices.
 
  Well this mdelay is the switch of the clock and not the delay after
  PORT_SUSPEND. So after writing PORT_SUSPEND I need to wait
  4ms and then in 2ms you have a lot of clock to reach the 18 count. Correct?
 
 Yes, sorry for confusing :)
 Moreover, 2ms is more than enough, errata document says about 1ms delay
 (and probably may be decreased up to few useconds)
 
 
  Anyway I understand, but why both hub connected to the smsc3320 move from
  HS to FS? So it's not important if there is a drift of delay but it must
  be = 4ms. Correct?
 
  The code works if I just use one port or remove one hub ;)
 
  Now the code is like this:
 
  temp = ~(PORT_WKCONN_E | PORT_RWC_BITS);
  temp |= PORT_WKDISC_E | PORT_WKOC_E;
  ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
 
  mdelay(4);
  omap_ehci_erratum_i693(ehci, ((wIndex  0xff) - 1));
 
  The code of the function is up on this email.
 
 Do you have locks around this software workaround?
 The patch I did against 3.4 linux kernel may be helpful for
 you in such case: http://review.omapzoom.org/28515
 Another patch extends this WA for all OMAP4 SoCs:
 http://review.omapzoom.org/31108

Yes, I'm using this code already applied to p-android-3.4 tree.
So the code is fine because it works when I use just one port

Re: [PATCH/Resend 2/2] arm: mach-omap2: prevent UART console idle on suspend while using no_console_suspend

[Michael Trimarchi]

Hi 

On 02/04/13 11:50, Sourav Poddar wrote:
 Hi Kevin,
 On Wednesday 20 March 2013 05:36 PM, Sourav Poddar wrote:
 Realised the list  to whom the patch was send got dropped. Ccing them all..
 On Wednesday 20 March 2013 05:18 PM, Sourav Poddar wrote:
 Hi Kevin,
 On Tuesday 19 March 2013 12:24 AM, Kevin Hilman wrote:
 Sourav Poddarsourav.pod...@ti.com  writes:

 With dt boot, uart wakeup after suspend is non functional on omap4/5 
 while using
 no_console_suspend in the bootargs. With no_console_suspend used, 
 od-flags
 should be ORed with OMAP_DEVICE_NO_IDLE_ON_SUSPEND, thereby not 
 allowing the console
 to idle in the suspend path. For non-dt case, this was taken care by 
 platform data.

 Tested on omap5430evm, omap4430sdp.

 Cc: Santosh Shilimkarsantosh.shilim...@ti.com
 Cc: Felipe Balbiba...@ti.com
 Cc: Rajendra nayakrna...@ti.com
 Signed-off-by: Sourav Poddarsourav.pod...@ti.com
 This patch creates a dependency between omap_device (generic,
 device-independent code) and a specific driver (UART.)

 If you need to do something like this that's DT boot specific, then
 we probably need some late initcall in serial.c to handle this.  It does
 not belong in omap_device.

 The following function omap_device_disable_idle_on_suspend(pdev) should 
 only
 be called once the omap device has been build, which in the case of device 
 tree is
 done in omap_device.c file. Moreover, the above call should be executed 
 conditionally
 and should depend on the following two parameter.

 [1]  a. Whether no_console_suspend is set and
  b.  the device build is a console uart.

 When I look closely into the serial.c file, I realised that
 core_initcall(omap_serial_early_init) gets called irrespective
 of dt/non dt boot and will take care of most of the stuff(checking whether
 no_console_suspend is used and which uart is used as a console uart) 
 which the
 $subject patch is proposing.

 But the problem is that we need to exchange the parsed information
 from serial.c to the omap_device file for the condtional execution of
 omap_device_disable_idle_on_suspend

 In this case,
 from serial.c we need
 1. no_console_suspend = true
 2. strcpy(console_name, oh_name), where oh_name corresponds to the 
 console uart.

 then in omap_device.c do
 if (no_console_suspend  !strcmp(oh-name, console_name))
 omap_device_disable_idle_on_suspend(pdev);

 Please correct if I am understanding it incorrectly.

 If the above understanding looks good to you, is there a way we can make 
 this
 exchange of information happen between serial.c and omap_device.c file?
 Any input on this?
 As I explained earlier, that there is a need to parse information in serial.c 
 and use that in
 omap_device.c only after the device is build.
 
 Below is the patch (inlined) which further explains my point. The patch is 
 just for the
 idea I am trying to express.
 I have used extern variables to exchange information between serial.c and 
 omap_device.c.
 Is there is a better way, we can do this information exchange without using 
 extern variables?
 
 
 -
 From: Sourav Poddar sourav.pod...@ti.com
 Date: Wed, 13 Mar 2013 20:32:36 +0530
 Subject: [RFC/PATCH] arm: mach-omap2: prevent UART console idle on suspend 
 while using no_console_suspend
 
 With dt boot on omap5, uart wakeup after suspend is non functional while using
 no_console_suspend in the bootargs. With no_console_suspend used, 
 od-flags
 should be ORed with OMAP_DEVICE_NO_IDLE_ON_SUSPEND, thereby not allowing 
 the console
 to idle in the suspend path. For non-dt case, this was taken care by platform 
 data.
 
 Tested on omap5430evm, omap4430sdp.
 
 Signed-off-by: Sourav Poddar sourav.pod...@ti.com
 ---
 The problem is I need to use couple of extern variables which
 can be used in the omap_device file, after the device is built from dt.
 
  arch/arm/mach-omap2/omap_device.c |7 ++-
  arch/arm/mach-omap2/serial.c  |4 +++-
  2 files changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/omap_device.c 
 b/arch/arm/mach-omap2/omap_device.c
 index e065daa..f4ebf9f 100644
 --- a/arch/arm/mach-omap2/omap_device.c
 +++ b/arch/arm/mach-omap2/omap_device.c
 @@ -96,6 +96,9 @@
  #define USE_WAKEUP_LAT0
  #define IGNORE_WAKEUP_LAT1
 
 +extern u8 no_console_suspend;
 +extern char console_uart_name[];
 +
  static int omap_early_device_register(struct platform_device *pdev);
 
  static struct omap_device_pm_latency omap_default_latency[] = {
 @@ -372,7 +375,9 @@ static int omap_device_build_from_dt(struct 
 platform_device *pdev)
  r-name = dev_name(pdev-dev);
  }
 
 -if (of_get_property(node, ti,no_idle_on_suspend, NULL))
 +if (no_console_suspend  !strcmp(oh-name, console_uart_name))
 +omap_device_disable_idle_on_suspend(pdev);
 +else if (of_get_property(node, ti,no_idle_on_suspend, NULL))
  omap_device_disable_idle_on_suspend(pdev);

Why do not use some flags instead of external 

Re: [PATCH/Resend 2/2] arm: mach-omap2: prevent UART console idle on suspend while using no_console_suspend

[Michael Trimarchi]

Hi

On 02/04/13 12:39, Sourav Poddar wrote:
 Hi,
 On Tuesday 02 April 2013 03:36 PM, Michael Trimarchi wrote:
 Hi

 On 02/04/13 11:50, Sourav Poddar wrote:
 Hi Kevin,
 On Wednesday 20 March 2013 05:36 PM, Sourav Poddar wrote:
 Realised the list  to whom the patch was send got dropped. Ccing them all..
 On Wednesday 20 March 2013 05:18 PM, Sourav Poddar wrote:
 Hi Kevin,
 On Tuesday 19 March 2013 12:24 AM, Kevin Hilman wrote:
 Sourav Poddarsourav.pod...@ti.com   writes:

 With dt boot, uart wakeup after suspend is non functional on omap4/5 
 while using
 no_console_suspend in the bootargs. With no_console_suspend used, 
 od-flags
 should be ORed with OMAP_DEVICE_NO_IDLE_ON_SUSPEND, thereby not 
 allowing the console
 to idle in the suspend path. For non-dt case, this was taken care by 
 platform data.

 Tested on omap5430evm, omap4430sdp.

 Cc: Santosh Shilimkarsantosh.shilim...@ti.com
 Cc: Felipe Balbiba...@ti.com
 Cc: Rajendra nayakrna...@ti.com
 Signed-off-by: Sourav Poddarsourav.pod...@ti.com
 This patch creates a dependency between omap_device (generic,
 device-independent code) and a specific driver (UART.)

 If you need to do something like this that's DT boot specific, then
 we probably need some late initcall in serial.c to handle this.  It does
 not belong in omap_device.

 The following function omap_device_disable_idle_on_suspend(pdev) should 
 only
 be called once the omap device has been build, which in the case of 
 device tree is
 done in omap_device.c file. Moreover, the above call should be executed 
 conditionally
 and should depend on the following two parameter.

 [1]  a. Whether no_console_suspend is set and
   b.  the device build is a console uart.

 When I look closely into the serial.c file, I realised that
 core_initcall(omap_serial_early_init) gets called irrespective
 of dt/non dt boot and will take care of most of the stuff(checking whether
 no_console_suspend is used and which uart is used as a console uart) 
 which the
 $subject patch is proposing.

 But the problem is that we need to exchange the parsed information
 from serial.c to the omap_device file for the condtional execution of
 omap_device_disable_idle_on_suspend

 In this case,
 from serial.c we need
  1. no_console_suspend = true
  2. strcpy(console_name, oh_name), where oh_name corresponds to the 
 console uart.

 then in omap_device.c do
  if (no_console_suspend  !strcmp(oh-name, console_name))
  omap_device_disable_idle_on_suspend(pdev);

 Please correct if I am understanding it incorrectly.

 If the above understanding looks good to you, is there a way we can make 
 this
 exchange of information happen between serial.c and omap_device.c file?
 Any input on this?
 As I explained earlier, that there is a need to parse information in 
 serial.c and use that in
 omap_device.c only after the device is build.

 Below is the patch (inlined) which further explains my point. The patch is 
 just for the
 idea I am trying to express.
 I have used extern variables to exchange information between serial.c and 
 omap_device.c.
 Is there is a better way, we can do this information exchange without 
 using extern variables?


 -
 From: Sourav Poddarsourav.pod...@ti.com
 Date: Wed, 13 Mar 2013 20:32:36 +0530
 Subject: [RFC/PATCH] arm: mach-omap2: prevent UART console idle on suspend 
 while using no_console_suspend

 With dt boot on omap5, uart wakeup after suspend is non functional while 
 using
 no_console_suspend in the bootargs. With no_console_suspend used, 
 od-flags
 should be ORed with OMAP_DEVICE_NO_IDLE_ON_SUSPEND, thereby not allowing 
 the console
 to idle in the suspend path. For non-dt case, this was taken care by 
 platform data.

 Tested on omap5430evm, omap4430sdp.

 Signed-off-by: Sourav Poddarsourav.pod...@ti.com
 ---
 The problem is I need to use couple of extern variables which
 can be used in the omap_device file, after the device is built from dt.

   arch/arm/mach-omap2/omap_device.c |7 ++-
   arch/arm/mach-omap2/serial.c  |4 +++-
   2 files changed, 9 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap_device.c 
 b/arch/arm/mach-omap2/omap_device.c
 index e065daa..f4ebf9f 100644
 --- a/arch/arm/mach-omap2/omap_device.c
 +++ b/arch/arm/mach-omap2/omap_device.c
 @@ -96,6 +96,9 @@
   #define USE_WAKEUP_LAT0
   #define IGNORE_WAKEUP_LAT1

 +extern u8 no_console_suspend;
 +extern char console_uart_name[];
 +
   static int omap_early_device_register(struct platform_device *pdev);

   static struct omap_device_pm_latency omap_default_latency[] = {
 @@ -372,7 +375,9 @@ static int omap_device_build_from_dt(struct 
 platform_device *pdev)
   r-name = dev_name(pdev-dev);
   }

 -if (of_get_property(node, ti,no_idle_on_suspend, NULL))
 +if (no_console_suspend  !strcmp(oh-name, console_uart_name))
 +omap_device_disable_idle_on_suspend(pdev);
 +else if (of_get_property(node, ti

Re: [PATCHv2] arm: mach-omap2: prevent UART console idle on suspend while using no_console_suspend

[Michael Trimarchi]

Hi

On 02/04/13 15:28, Sourav Poddar wrote:
 With dt boot, uart wakeup after suspend is non functional while using
 no_console_suspend in the bootargs. With no_console_suspend used, 
 od-flags
 should be ORed with OMAP_DEVICE_NO_IDLE_ON_SUSPEND, thereby not allowing 
 the console
 to idle in the suspend path.
 
 Tested on omap5430evm, omap4430sdp.
 
 Cc: Santosh Shilimkarsantosh.shilim...@ti.com
 Cc: Felipe Balbiba...@ti.com
 Cc: Rajendra nayakrna...@ti.com
 Signed-off-by: Sourav Poddar sourav.pod...@ti.com
 ---
 v1-v2
 These patches were sent before as a series[1], but realised
 core_initcall(omap_serial_early_init) in serial.c get executed
 irrespective of dt or non dt boot and it will do most of the stuff
 for us.
 As suggested by Kevin Hilman in the previous version, this patch will
 also prevent creating dependency between omap_device
 (generic device-independent code) and a specific driver (UART).
 
 [1]: http://lkml.org/lkml/2013/3/18/294
 
  arch/arm/mach-omap2/omap_device.c |5 +++--
  arch/arm/mach-omap2/omap_hwmod.h  |5 +
  arch/arm/mach-omap2/serial.c  |4 +++-
  3 files changed, 11 insertions(+), 3 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/omap_device.c 
 b/arch/arm/mach-omap2/omap_device.c
 index 381be7a..89be64d 100644
 --- a/arch/arm/mach-omap2/omap_device.c
 +++ b/arch/arm/mach-omap2/omap_device.c
 @@ -170,8 +170,9 @@ static int omap_device_build_from_dt(struct 
 platform_device *pdev)
   r-name = dev_name(pdev-dev);
   }
  
 - if (of_get_property(node, ti,no_idle_on_suspend, NULL))
 - omap_device_disable_idle_on_suspend(pdev);
 + if (oh-flags  HWMOD_DISABLE_IDLE_ON_SUSPEND ||
 + of_get_property(node, ti,no_idle_on_suspend, NULL))
 + omap_device_disable_idle_on_suspend(pdev);
  
   pdev-dev.pm_domain = omap_device_pm_domain;
  
 diff --git a/arch/arm/mach-omap2/omap_hwmod.h 
 b/arch/arm/mach-omap2/omap_hwmod.h
 index d43d9b6..50e6145 100644
 --- a/arch/arm/mach-omap2/omap_hwmod.h
 +++ b/arch/arm/mach-omap2/omap_hwmod.h
 @@ -459,6 +459,10 @@ struct omap_hwmod_omap4_prcm {
   * correctly, or this is being abused to deal with some PM latency
   * issues -- but we're currently suffering from a shortage of
   * folks who are able to track these issues down properly.
 + * HWMOD_DISABLE_IDLE_ON_SUSPEND: don't idle this module on suspend. This is
 + * needed for uart controller, which requires its clock not to be cut
 + * during suspend while using no_console_suspend in bootargs with
 + * device tree boot.
   */
  #define HWMOD_SWSUP_SIDLE(1  0)
  #define HWMOD_SWSUP_MSTANDBY (1  1)
 @@ -471,6 +475,7 @@ struct omap_hwmod_omap4_prcm {
  #define HWMOD_16BIT_REG  (1  8)
  #define HWMOD_EXT_OPT_MAIN_CLK   (1  9)
  #define HWMOD_BLOCK_WFI  (1  10)
 +#define HWMOD_DISABLE_IDLE_ON_SUSPEND(1  12)

Just a comment more. Why 12 and not 11?

Michael

  
  /*
   * omap_hwmod._int_flags definitions
 diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
 index 8396b5b..adbafbd 100644
 --- a/arch/arm/mach-omap2/serial.c
 +++ b/arch/arm/mach-omap2/serial.c
 @@ -236,8 +236,10 @@ static int __init omap_serial_early_init(void)
   uart_name, uart-num);
   }
  
 - if (cmdline_find_option(no_console_suspend))
 + if (cmdline_find_option(no_console_suspend)) {
   no_console_suspend = true;
 + oh-flags |= HWMOD_DISABLE_IDLE_ON_SUSPEND;
 + }
  
   /*
* omap-uart can be used for earlyprintk logs
 

--
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 4/7] usb: otg: twl4030-usb: poll for ID disconnect

[Michael Trimarchi]

Hi

just one comment.

On 10/03/13 02:07, Grazvydas Ignotas wrote:
 On pandora, STS_USB interrupt doesn't arrive on USB host cable disconnect
 for some reason while VBUS is driven by twl itself, but STS_HW_CONDITIONS
 is updated correctly. It does work fine when PHY is powered down though.
 To work around that we have to poll.
 
 TI PSP kernels have similar workarounds, so (many?) more boards are likely
 affected.
 
 Signed-off-by: Grazvydas Ignotas nota...@gmail.com
 ---
  drivers/usb/otg/twl4030-usb.c |   37 +
  1 file changed, 37 insertions(+)
 
 diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
 index 90a19ff..2c1c27e 100644
 --- a/drivers/usb/otg/twl4030-usb.c
 +++ b/drivers/usb/otg/twl4030-usb.c
 @@ -163,6 +163,8 @@ struct twl4030_usb {
   boolvbus_supplied;
   u8  asleep;
   boolirq_enabled;
 +
 + struct delayed_work id_workaround_work;
  };
  
  /* internal define on top of container_of */
 @@ -412,6 +414,16 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
   __twl4030_phy_resume(twl);
   twl-asleep = 0;
   dev_dbg(twl-dev, %s\n, __func__);
 +
 + /*
 +  * XXX When VBUS gets driven after musb goes to A mode,
 +  * ID_PRES related interrupts no longer arrive, why?
 +  * Register itself is updated fine though, so we must poll.
 +  */
 + if (twl-linkstat == OMAP_MUSB_ID_GROUND) {
 + cancel_delayed_work(twl-id_workaround_work);
 + schedule_delayed_work(twl-id_workaround_work, HZ);
 + }
  }
  
  static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 @@ -513,6 +525,28 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
   return IRQ_HANDLED;
  }
  
 +static void twl4030_id_workaround_work(struct work_struct *work)
 +{
 + struct twl4030_usb *twl = container_of(work, struct twl4030_usb,
 + id_workaround_work.work);
 + enum omap_musb_vbus_id_status status_prev = twl-linkstat;
 + enum omap_musb_vbus_id_status status;
 +
 + status = twl4030_usb_linkstat(twl);
 + if (status != status_prev) {
 + dev_dbg(twl-dev, handle missing status change: %d-%d\n,
 + status_prev, status);
 + twl-linkstat = status_prev;
 + twl4030_usb_irq(0, twl);

As I understand from the subject this happen in Pandora board and
many boards can be affected.
do you need any protection between the worker and the irq when
the irq arrive as expected?

 + }
 +
 + /* don't schedule during sleep - irq works right then */
 + if (status == OMAP_MUSB_ID_GROUND  !twl-asleep) {
 + cancel_delayed_work(twl-id_workaround_work);
 + schedule_delayed_work(twl-id_workaround_work, HZ);
 + }
 +}
 +
  static void twl4030_usb_phy_init(struct twl4030_usb *twl)
  {
   enum omap_musb_vbus_id_status status;
 @@ -613,6 +647,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
   /* init spinlock for workqueue */
   spin_lock_init(twl-lock);
  
 + INIT_DELAYED_WORK(twl-id_workaround_work, twl4030_id_workaround_work);
 +
   err = twl4030_usb_ldo_init(twl);
   if (err) {
   dev_err(pdev-dev, ldo init failed\n);
 @@ -653,6 +689,7 @@ static int __exit twl4030_usb_remove(struct 
 platform_device *pdev)
   struct twl4030_usb *twl = platform_get_drvdata(pdev);
   int val;
  
 + cancel_delayed_work(twl-id_workaround_work);
   free_irq(twl-irq, twl);
   device_remove_file(twl-dev, dev_attr_vbus);
  
 

Michael

--
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: Help wanted with USB and OMAP3 off_mode

[Michael Trimarchi]

Hi Neil

On 01/09/2013 11:19 AM, NeilBrown wrote:
 On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
 wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi Neil,
 
 On 01/09/13 00:29, NeilBrown wrote:

 Hi,
  I'm trying to get off_mode working reliably on my gta04 mobile phone.

 My current stumbling block is USB.  The Option GSM module is attached via
 USB (there is a separate transceiver chip attached to port 1 which is placed
 in OMAP_EHCI_PORT_MODE_PHY).
 
 Which PHY is this (vendor/model)?
 
 Hi Igor,
   it is the SMSC USB3322
 
 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
 
 
 BTW I subsequently discovered that keeping USBHOST out off off_mode only
 sometimes avoid the problem, not always.  So there are probably multiple
 issues :-(

Are you sure that you don't have glitch on power, reset pin during suspend?

Michael

 
 NeilBrown
 
 
 
 

 After a suspend/resume cycle with off_mode enabled the GSM module 
 disappears.
 i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
 exist.
 Without off mode, the modem always appears after resume.

 I discovered that the registers set by:

drivers/mfd/omap-usb-host.c

 are not maintained across as suspend/resume so I added the following patch
 (which I can make a formal submission of if it looks right to others), but
 that didn't help (or didn't help enough).

 If I

   echo 1  /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend

 thus keeping just the USBHOST power domain out of off_mode, the GSM module
 doesn't disappear.  So it seems that some context in the usbhost domain is
 not being save and restored.

 This is as far as I can get.  Can someone suggest where I should look to 
 find
 out what is not being saved/restored properly, and how to go about saving 
 and
 restoring?

 Thanks in advance,
 NeilBrown



 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 23cec57..522405e 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -100,6 +100,10 @@ struct usbhs_hcd_omap {
  
 void __iomem*uhh_base;
  
 +   struct {
 +   unsignedhostconfig;
 +   } context;
 +
 struct usbhs_omap_platform_data platdata;
  
 u32 usbhs_rev;
 @@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)
 clk_enable(omap-utmi_p1_fck);
 clk_enable(omap-utmi_p2_fck);
  
 +   usbhs_write(omap-uhh_base,
 +   OMAP_UHH_HOSTCONFIG,
 +   omap-context.hostconfig);
 +
 spin_unlock_irqrestore(omap-lock, flags);
  
 return 0;
 @@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)
 }
  
 spin_lock_irqsave(omap-lock, flags);
 +   omap-context.hostconfig = usbhs_read(omap-uhh_base,
 + OMAP_UHH_HOSTCONFIG);
  
 if (is_ehci_tll_mode(pdata-port_mode[0]))
 clk_disable(omap-usbhost_p1_fck);
 
 - -- 
 Regards,
 Igor.
 

 N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±¢f©Š{ayºʇڙë,j­¢f£¢·hš‹àz¹®w¥¢¸
 ¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾«‘êçzZ+ƒùšŽŠÝ¢j�ú!tml=
 
--
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: Help wanted with USB and OMAP3 off_mode

[Michael Trimarchi]

On 01/09/2013 12:34 PM, NeilBrown wrote:
 On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
 mich...@amarulasolutions.com wrote:
 
 Hi Neil

 On 01/09/2013 11:19 AM, NeilBrown wrote:
 On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
 wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Neil,

 On 01/09/13 00:29, NeilBrown wrote:

 Hi,
  I'm trying to get off_mode working reliably on my gta04 mobile phone.

 My current stumbling block is USB.  The Option GSM module is attached 
 via
 USB (there is a separate transceiver chip attached to port 1 which is 
 placed
 in OMAP_EHCI_PORT_MODE_PHY).

 Which PHY is this (vendor/model)?

 Hi Igor,
   it is the SMSC USB3322

 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf


 BTW I subsequently discovered that keeping USBHOST out off off_mode only
 sometimes avoid the problem, not always.  So there are probably multiple
 issues :-(

 Are you sure that you don't have glitch on power, reset pin during suspend?

 
 No, I don't really have the equipment to measure such things.
 But is it likely?  Would enabling off_mode make it more likely?
 Can you suggest some way I could test the hypothesis?
 
 The power pin is connected to a 3v3 regulator which certainly should stay on
 the whole time and other things which depend on it keep working.
 
 The reset line is connected to GPIO174 which is configured:
 
 # cat /sys/kernel/debug/omap_mux/mcspi1_cs0
 name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA
 mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4
 signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode
 
 The PIN_INPUT seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that
 didn't appear to make any difference.
 

Can you try to add this OMAP_PIN_OFF_OUTPUT_HIGH or LOW? It's suppose to be the 
off_mode status of the pin.
Is it correct?


Michael




 Thanks,
 NeilBrown
 


-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |


--
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: Help wanted with USB and OMAP3 off_mode

[Michael Trimarchi]

Hi Neil

I forget to answer to your questions

On 01/09/2013 12:34 PM, NeilBrown wrote:
 On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
 mich...@amarulasolutions.com wrote:
 
 Hi Neil

 On 01/09/2013 11:19 AM, NeilBrown wrote:
 On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
 wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Neil,

 On 01/09/13 00:29, NeilBrown wrote:

 Hi,
  I'm trying to get off_mode working reliably on my gta04 mobile phone.

 My current stumbling block is USB.  The Option GSM module is attached 
 via
 USB (there is a separate transceiver chip attached to port 1 which is 
 placed
 in OMAP_EHCI_PORT_MODE_PHY).

 Which PHY is this (vendor/model)?

 Hi Igor,
   it is the SMSC USB3322

 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf


 BTW I subsequently discovered that keeping USBHOST out off off_mode only
 sometimes avoid the problem, not always.  So there are probably multiple
 issues :-(

 Are you sure that you don't have glitch on power, reset pin during suspend?

 
 No, I don't really have the equipment to measure such things.
 But is it likely?  Would enabling off_mode make it more likely?

I don't know the reason of the off_mode problem :(

 Can you suggest some way I could test the hypothesis?

I had the same problem on a rugged mobile phone, so it is just experience
Check the modem power and reset gpio too, but if you don't need to unblock it
with the pin after resume we know that modem is not the problem

Michael

 
 The power pin is connected to a 3v3 regulator which certainly should stay on
 the whole time and other things which depend on it keep working.
 
 The reset line is connected to GPIO174 which is configured:
 
 # cat /sys/kernel/debug/omap_mux/mcspi1_cs0
 name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA
 mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4
 signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode
 
 The PIN_INPUT seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that
 didn't appear to make any difference.
 
 Thanks,
 NeilBrown
 

--
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] musb: omap2430: fix the readiness check in omap_musb_mailbox

[Michael Trimarchi]

Hi

Aaro Koskinen aaro.koski...@iki.fi wrote:

The check in omap_musb_mailbox does not properly check if the module
has
been fully initialized. The patch fixes that, and the kernel panic
below:

$ modprobe twl4030-usb
[   13.924743] twl4030_usb twl4030-usb.33: HW_CONDITIONS 0xe0/224; link
3
[   13.940307] Unable to handle kernel NULL pointer dereference at
virtual address 0004
[   13.948883] pgd = ef27c000
[   13.951751] [0004] *pgd=af256831, *pte=, *ppte=
[   13.958374] Internal error: Oops: 17 [#1] ARM
[   13.962921] Modules linked in: twl4030_usb(+) omap2430 libcomposite
[   13.969543] CPU: 0Not tainted 
(3.8.0-rc1-n9xx-11758-ge37a37c-dirty #6)
[   13.976867] PC is at omap_musb_mailbox+0x18/0x54 [omap2430]
[   13.982727] LR is at twl4030_usb_probe+0x240/0x354 [twl4030_usb]
[   13.989013] pc : [bf013b6c]lr : [bf018958]psr: 6013
[   13.989013] sp : ef273cf0  ip : ef273d08  fp : ef273d04
[   14.001068] r10: bf01b000  r9 : bf0191d8  r8 : 0001
[   14.006530] r7 :   r6 : ef140e10  r5 : 0003  r4 :

[   14.013397] r3 : bf0142dc  r2 : 0006  r1 :   r0 :
0003
[   14.020233] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM 
Segment user
[   14.027740] Control: 10c5387d  Table: af27c019  DAC: 0015
[   14.033752] Process modprobe (pid: 616, stack limit = 0xef272238)
[   14.040161] Stack: (0xef273cf0 to 0xef274000)
[   14.044708] 3ce0: ef254310
0001 ef273d34 ef273d08
[   14.053314] 3d00: bf018958 bf013b60 bf0190a4 ef254310 c0101550
c0c3a138 ef140e10 ef140e44
[   14.061889] 3d20: bf019150 0001 ef273d44 ef273d38 c019890c
bf018724 ef273d64 ef273d48
[   14.070495] 3d40: c01974fc c01988f8 ef140e10 bf019150 ef140e44
 ef273d84 ef273d68
[   14.079071] 3d60: c0197728 c019748c c0197694  bf019150
c0197694 ef273dac ef273d88
[   14.087677] 3d80: c0195c38 c01976a0 ef03610c ef143eb0 c0128954
ef254780 bf019150 c0b19548
[   14.096252] 3da0: ef273dbc ef273db0 c0197098 c0195bf0 ef273dec
ef273dc0 c0196c98 c0197080
[   14.104858] 3dc0: bf0190a4 c0b27bc0 ef273dec bf019150 bf019190
c0b27bc0 ef272000 0001
[   14.113433] 3de0: ef273e14 ef273df0 c0197c18 c0196b30 ef273f48
bf019190 c0b27bc0 ef272000
[   14.122039] 3e00: 0001 bf01b000 ef273e24 ef273e18 c0198b28
c0197ba4 ef273e34 ef273e28
[   14.130615] 3e20: bf01b014 c0198ae8 ef273e8c ef273e38 c0008918
bf01b00c c004f730 c012ba1c
[   14.139221] 3e40: ef273e74  c00505b0 c004f72c 
ef273e60 ef273f48 bf019190
[   14.147796] 3e60: 0001 ef273f48 bf019190 0001 ef286340
0001 bf0191d8 c0065414
[   14.156402] 3e80: ef273f44 ef273e90 c0067754 c00087fc bf01919c
7fff c0064794 
[   14.164978] 3ea0: ef273ecc f0064000 0001 ef272000 ef272000
00067f39 bf0192b0 bf01919c
[   14.173583] 3ec0: ef273f0c ef273ed0 c00a6bf0 c00a53fc ff00
00d2 c0067dc8 
[   14.182159] 3ee0:     
  
[   14.190765] 3f00:     
  2968
[   14.199340] 3f20: 00080878 00067f39 0080 c000e2e8 ef272000
 ef273fa4 ef273f48
[   14.207946] 3f40: c0067e54 c0066188 f0064000 2968 f0065530
f0065463 f0065fb0 12c4
[   14.216522] 3f60: 1664    0014
0015 000c 
[   14.225128] 3f80: 0008   00080370 00080878
0007422c  ef273fa8
[   14.233703] 3fa0: c000e140 c0067d80 00080370 00080878 00080878
2968 00067f39 
[   14.242309] 3fc0: 00080370 00080878 0007422c 0080 00074030
00067f39 bec7aef8 
[   14.250885] 3fe0: b6f05300 bec7ab68 e93c b6f05310 6010
00080878 af7fe821 af7fec21
[   14.259460] Backtrace:
[   14.262054] [bf013b54] (omap_musb_mailbox+0x0/0x54 [omap2430])
from [bf018958] (twl4030_usb_probe+0x240/0x354 [twl4030_usb])
[   14.274200]  r5:0001 r4:ef254310
[   14.277984] [bf018718] (twl4030_usb_probe+0x0/0x354 [twl4030_usb])
from [c019890c] (platform_drv_probe+0x20/0x24)
[   14.289123]  r8:0001 r7:bf019150 r6:ef140e44 r5:ef140e10
r4:c0c3a138
[   14.296203] [c01988ec] (platform_drv_probe+0x0/0x24) from
[c01974fc] (driver_probe_device+0x7c/0x214)
[   14.306243] [c0197480] (driver_probe_device+0x0/0x214) from
[c0197728] (__driver_attach+0x94/0x98)
[   14.316009]  r7: r6:ef140e44 r5:bf019150 r4:ef140e10
[   14.321990] [c0197694] (__driver_attach+0x0/0x98) from
[c0195c38] (bus_for_each_dev+0x54/0x88)
[   14.331390]  r6:c0197694 r5:bf019150 r4: r3:c0197694
[   14.337371] [c0195be4] (bus_for_each_dev+0x0/0x88) from
[c0197098] (driver_attach+0x24/0x28)
[   14.346588]  r6:c0b19548 r5:bf019150 r4:ef254780
[   14.351440] [c0197074] (driver_attach+0x0/0x28) from [c0196c98]
(bus_add_driver+0x174/0x244)
[   14.360687] [c0196b24] (bus_add_driver+0x0/0x244) from
[c0197c18] (driver_register+0x80/0x154)
[   14.370086]  r8:0001 r7:ef272000 r6:c0b27bc0 r5:bf019190
r4:bf019150
[   14.377136] 

Re: [PATCH v2 2/3] gpio: twl4030: Cache the direction and output states in private data

[Michael Trimarchi]

Hi

Grant Likely grant.lik...@secretlab.ca wrote:

On Thu, 6 Dec 2012 11:52:06 +0100, Peter Ujfalusi
peter.ujfal...@ti.com wrote:
 Use more coherent locking in the driver. Use bitfield to store the
GPIO
 direction and if the pin is configured as output store the status
also in a
 bitfiled.
 In this way we can just look at these bitfields when we need
information
 about the pin status and only reach out to the chip when it is
needed.
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com

Applied, thanks

g.

 ---
  drivers/gpio/gpio-twl4030.c | 99
++---
  1 file changed, 66 insertions(+), 33 deletions(-)
 
 diff --git a/drivers/gpio/gpio-twl4030.c
b/drivers/gpio/gpio-twl4030.c
 index c092739..a38e6e9c 100644
 --- a/drivers/gpio/gpio-twl4030.c
 +++ b/drivers/gpio/gpio-twl4030.c
 @@ -64,14 +64,15 @@
  /* Mask for GPIO registers when aggregated into a 32-bit integer */
  #define GPIO_32_MASK0x0003
  
 -/* Data structures */
 -static DEFINE_MUTEX(gpio_lock);
 -
  struct gpio_twl4030_priv {
  struct gpio_chip gpio_chip;
 +struct mutex mutex;
  int irq_base;
  
 +/* Bitfields for state caching */
  unsigned int usage_count;
 +unsigned int direction;
 +unsigned int out_state;
  };
  
 
/*--*/
 @@ -130,7 +131,7 @@ static inline int gpio_twl4030_read(u8 address)
  
 
/*--*/
  
 -static u8 cached_leden; /* protected by gpio_lock */
 +static u8 cached_leden;
  
  /* The LED lines are open drain outputs ... a FET pulls to GND, so
an
   * external pullup is needed.  We could also expose the integrated
PWM
 @@ -144,14 +145,12 @@ static void twl4030_led_set_value(int led, int
value)
  if (led)
  mask = 1;
  
 -mutex_lock(gpio_lock);
  if (value)
  cached_leden = ~mask;
  else
  cached_leden |= mask;
  status = twl_i2c_write_u8(TWL4030_MODULE_LED, cached_leden,
TWL4030_LED_LEDEN_REG);
 -mutex_unlock(gpio_lock);
  }
  
  static int twl4030_set_gpio_direction(int gpio, int is_input)
 @@ -162,7 +161,6 @@ static int twl4030_set_gpio_direction(int gpio,
int is_input)
  u8 base = REG_GPIODATADIR1 + d_bnk;
  int ret = 0;
  
 -mutex_lock(gpio_lock);
  ret = gpio_twl4030_read(base);
  if (ret = 0) {
  if (is_input)
 @@ -172,7 +170,6 @@ static int twl4030_set_gpio_direction(int gpio,
int is_input)
  
  ret = gpio_twl4030_write(base, reg);
  }
 -mutex_unlock(gpio_lock);
  return ret;
  }
  
 @@ -212,7 +209,7 @@ static int twl_request(struct gpio_chip *chip,
unsigned offset)
  struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
  int status = 0;
  
 -mutex_lock(gpio_lock);
 +mutex_lock(priv-mutex);
  
  /* Support the two LED outputs as output-only GPIOs. */
  if (offset = TWL4030_GPIO_MAX) {
 @@ -271,7 +268,7 @@ done:
  if (!status)
  priv-usage_count |= BIT(offset);
  
 -mutex_unlock(gpio_lock);
 +mutex_unlock(priv-mutex);
  return status;
  }
  
 @@ -279,64 +276,98 @@ static void twl_free(struct gpio_chip *chip,
unsigned offset)
  {
  struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
  
 +mutex_lock(priv-mutex);
  if (offset = TWL4030_GPIO_MAX) {
  twl4030_led_set_value(offset - TWL4030_GPIO_MAX, 1);

I have the mobile but where is the unlock here?


  return;
  }
  
 -mutex_lock(gpio_lock);
 -
  priv-usage_count = ~BIT(offset);
  
  /* on last use, switch off GPIO module */
  if (!priv-usage_count)
  gpio_twl4030_write(REG_GPIO_CTRL, 0x0);
  
 -mutex_unlock(gpio_lock);
 +mutex_unlock(priv-mutex);
  }
  
  static int twl_direction_in(struct gpio_chip *chip, unsigned offset)
  {
 -return (offset  TWL4030_GPIO_MAX)
 -? twl4030_set_gpio_direction(offset, 1)
 -: -EINVAL;
 +struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
 +int ret;
 +
 +mutex_lock(priv-mutex);
 +if (offset  TWL4030_GPIO_MAX)
 +ret = twl4030_set_gpio_direction(offset, 1);
 +else
 +ret = -EINVAL;
 +
 +if (!ret)
 +priv-direction = ~BIT(offset);
 +
 +mutex_unlock(priv-mutex);
 +
 +return ret;
  }
  
  static int twl_get(struct gpio_chip *chip, unsigned offset)
  {
  struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
 +int ret;
  int status = 0;
  
 -if (!(priv-usage_count  BIT(offset)))
 -return -EPERM;
 +mutex_lock(priv-mutex);
 +if (!(priv-usage_count  BIT(offset))) {
 +ret = -EPERM;
 +goto out;
 +}
  
 -if (offset  TWL4030_GPIO_MAX)
 -status = twl4030_get_gpio_datain(offset);
 -else if (offset == TWL4030_GPIO_MAX)
 -status = cached_leden  

Re: [PATCH 3/8] i2c: omap: fix error checking

[Michael Trimarchi]

Hi

On 10/25/2012 12:10 PM, Felipe Balbi wrote:
 Hi,
 
 On Wed, Oct 24, 2012 at 04:41:11PM +0200, Michael Trimarchi wrote:
 Hi

 On 10/22/2012 11:46 AM, Felipe Balbi wrote:
 It's impossible to have Arbitration Lost,
 Read Overflow, and Tranmist Underflow all
 asserted at the same time.

 Those error conditions are mutually exclusive
 so what the code should be doing, instead, is
 check each error flag separataly.

 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
  drivers/i2c/busses/i2c-omap.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
 index bea0277..e0eab38 100644
 --- a/drivers/i2c/busses/i2c-omap.c
 +++ b/drivers/i2c/busses/i2c-omap.c
 @@ -587,9 +587,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
 goto err_i2c_init;
 }
  
 -   /* We have an error */
 -   if (dev-cmd_err  (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
 -   OMAP_I2C_STAT_XUDF)) {
 +   if ((dev-cmd_err  OMAP_I2C_STAT_AL)
 +   || (dev-cmd_err  OMAP_I2C_STAT_ROVR)
 +   || (dev-cmd_err  OMAP_I2C_STAT_XUDF)) {

 Sorry, what is the difference? I didn't understand the optimisation
 and why now is more clear. Can you just add a comment?
 
 semantically they're not the same, right ? We want to check if each of
 those bits are set, not if all of them are set together.
 
 my 2 cents.

You are doing the same thing, but of course is better with just one *if* as 
before . A general rule is: when you have logic expression you can use 
undefined states to simplify the logic. 

Michael 


--
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] i2c: omap: fix error checking

[Michael Trimarchi]

Hi

On 10/22/2012 11:46 AM, Felipe Balbi wrote:
 It's impossible to have Arbitration Lost,
 Read Overflow, and Tranmist Underflow all
 asserted at the same time.
 
 Those error conditions are mutually exclusive
 so what the code should be doing, instead, is
 check each error flag separataly.
 
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
  drivers/i2c/busses/i2c-omap.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
 index bea0277..e0eab38 100644
 --- a/drivers/i2c/busses/i2c-omap.c
 +++ b/drivers/i2c/busses/i2c-omap.c
 @@ -587,9 +587,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
   goto err_i2c_init;
   }
  
 - /* We have an error */
 - if (dev-cmd_err  (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
 - OMAP_I2C_STAT_XUDF)) {
 + if ((dev-cmd_err  OMAP_I2C_STAT_AL)
 + || (dev-cmd_err  OMAP_I2C_STAT_ROVR)
 + || (dev-cmd_err  OMAP_I2C_STAT_XUDF)) {

Sorry, what is the difference? I didn't understand the optimisation and why now
is more clear. Can you just add a comment?

Michael

   ret = -EIO;
   goto err_i2c_init;
   }
 
--
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] mfd: twl4030: Driver for twl4030 madc module

[Michael Trimarchi]

Hi all

Janakiram Sistla wrote:

On Mon, Jul 19, 2010 at 10:46 AM, Michael Trimarchi 
mich...@panicking.kicks-ass.org wrote:

Janakiram Sistla wrote:

 drivers/mfd/Kconfig  |   21 ++
 drivers/mfd/Makefile |3 +-
 drivers/mfd/twl4030-madc.c   |  548
++
 include/linux/i2c/twl4030-madc.h |  126 +
 4 files changed, 697 insertions(+), 1 deletions(-)
 create mode 100644 drivers/mfd/twl4030-madc.c
 create mode 100644 include/linux/i2c/twl4030-madc.h


We have just tried to adopt this driver to our custom OMAP3 board, but
were unable to get any interrupts.
Any ideas on what is missing? We've checked whole TRM and found
nothing wrong yet :(


we tried the same driver for Omap zoom platform ,I too dont see any
interrupts from this driver.I also observe that duing bluetooth file
transfer i see the below crash from twl4030-madc driver.

Once i disable the madc driver in kernel configuration my Bluetooth
works fine,while Bluetooth has nothing to do with i2c or madc driver.A
similar crash is also observed during GFX operation

Regards,
Ram.

here is the log:
i2c_omap i2c_omap.1: controller timed out waiting for start condition to
finish
twl: i2c_write failed to transfer all messages
Unable to handle kernel NULL pointer dereference at virtual address
0044
pgd = c0004000
[0044] *pgd=
Internal error: Oops: 17 [#1] PREEMPT
last sysfs file: /sys/devices/platform/kim/firmware/kim/loading
Modules linked in: bt_drv st_drv
CPU: 0Not tainted  (2.6.32-14922-g86eec44 #1)
PC is at dev_driver_string+0x0/0x38
LR is at twl4030_madc_write+0x2c/0x4c
pc : [c01f2bc0]lr : [c01fede0]psr: a013
sp : cf02bf08  ip : 738f  fp : 
r10: cf002cc8  r9 : c038a839  r8 : 
r7 : cf02bf3c  r6 : c04edff8  r5 : 0007  r4 : cf227a00
r3 : 0007  r2 : 02070002  r1 : 0007  r0 : 
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 8d23c019  DAC: 0017
Process events/0 (pid: 5, stack limit = 0xcf02a2e8)
Stack: (0xcf02bf08 to 0xcf02c000)
bf00:   0006 0002 c04edff8 c01fef6c cf179680
cf179680
bf20: cf02a000 cf002cc0 c028a5a8  cf002cc8 c028a5dc 
0200
bf40: cf020001  cf020d40 0017 cf0213c0 c007f1dc 
cd277e40
bf60: cf02bf94 c036e58c cd0bac9c cf020ed4 6013 cf002cc0 cf002cbc
cf02a000
bf80: cf002cc0 c01dcc00 cf002cc0  cf179684 c0076ff4 cf02bfcc

bfa0: cf020d40 c007a660 cf02bfa8 cf02bfa8 cf023f60 cf02bfd4 cf023f60
cf002cc0
bfc0: c0076e8c   c007a334   cf02bfd8
cf02bfd8
bfe0:      c0035f80 

[c01f2bc0] (dev_driver_string+0x0/0x38) from [c01fede0]
(twl4030_madc_write+
0x2c/0x4c)
[c01fede0] (twl4030_madc_write+0x2c/0x4c) from [c01fef6c]
(twl4030_madc_conv
ersion+0x74/0x288)
[c01fef6c] (twl4030_madc_conversion+0x74/0x288) from [c028a5dc]
(twl4030_bk_
bci_battery_work+0x34/0x60)
[c028a5dc] (twl4030_bk_bci_battery_work+0x34/0x60) from [c0076ff4]
(worker_t
hread+0x168/0x214)
[c0076ff4] (worker_thread+0x168/0x214) from [c007a334]
(kthread+0x7c/0x84)
[c007a334] (kthread+0x7c/0x84) from [c0035f80]
(kernel_thread_exit+0x0/0x8)
Code: c04edd3c c04eddcc c042bef5 c040d709 (e5903044)
--
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

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 2d2aa87..e12ac1a 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -478,6 +478,7 @@ static int __init twl4030_madc_probe(struct
platform_device
  madc-imr = (pdata-irq_line == 1) ? TWL4030_MADC_IMR1 :
TWL4030_MADC_IM
  madc-isr = (pdata-irq_line == 1) ? TWL4030_MADC_ISR1 :
TWL4030_MADC_IS
+   madc-dev = pdev-dev;

  ret = misc_register(twl4030_madc_device);
  if (ret) {

This is the reason of the crash

Michael Trimarchi






I think its fixed already.. ..



I'm testing in overo and I have notice varius issue:

+#if 0
   if (dev-rev = OMAP_I2C_REV_ON_3430) {
   while (!(stat  OMAP_I2C_STAT_XU
   if (stat  (OMAP_I2C_STA
@@ -826,7 +826,7 @@ complete:
   stat = omap_i2c_read_reg
   }
   }
-
+#endif

I need to comment out this code, because it loop and it doesn't have an exit 
condition. This couse
the kernel to stuck, but after comment out this I have every 5sec/10 seconds 
some error on i2c bus
during write

Michael

--
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

Re: Serial console not working after waking up from sleep

[Michael Trimarchi]

-omap-hs mmci-omap-hs.0: EARLY resume
mmci-omap-hs mmci-omap-hs.1: EARLY resume
twl_reg twl_reg.17: EARLY resume
twl_reg twl_reg.18: EARLY resume
twl_reg twl_reg.19: EARLY resume
twl4030_usb twl4030_usb: EARLY resume
twl_reg twl_reg.6: EARLY resume
i2c i2c-3: EARLY resume
serial8250 serial8250: EARLY resume
PM: early resume of devices complete after 97.625 msecs
i2c_omap i2c_omap.1: resume
i2c_omap i2c_omap.3: resume
platform overo_lcd: resume
serial8250 serial8250.0: resume
serial8250 serial8250.1: resume
serial8250 serial8250.2: resume
×uV=V=ý_½hþ¼þ¼.?ýR®HlÒÒ¾»®=¾=½´®¿Q*^¼þQ¾99:¾ÒÒýRN÷õt®¨¨:;;T»?ÉQQ·´Ö´Ë\¿véÝÿ
(garbage string...)


The problem is releated to no_debug_console option.

Michael Trimarchi



Thanks,


--
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: Serial console not working after waking up from sleep

[Michael Trimarchi]

Hi

Han Wang wrote:

Hi, michael,

   I have the no_console_suspend option in my boot command line, I am
not sure if that is the option you were trying to point me to in the
last email?


I have said that i have no problem when I remove that option.
Can you try to echo 0 to timeout of the serial device?

Michael



   anyway, I added no_debug_console into my boot command arg, but that
doesn't seem to help with my problem.

   any ideas?

Thanks,
Han
On Wed, Jun 16, 2010 at 2:09 AM, Michael Trimarchi
mich...@panicking.kicks-ass.org wrote:

Han Wang wrote:

Hi,

 I am testing the 2.6.35-rc1 pm branch code on Overo. The system
boots ok. (I can provide booting log if that is necessary) However,
when I use echo mem  /sys/power/state to send overo to sleep and
wake it up by enter a key into serial console. I got garbage
characters in the serial console, and I can not enter anything into
the console anymore. I wonder if anyone has encountered a similar
problem, and please give me some suggestion.

I have appended command log below.

r...@overo:~# echo mem  /sys/power/state
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
PM: Adding info for No Bus:vcs63
PM: Adding info for No Bus:vcsa63
Freezing user space processes ... (elapsed 0.02 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: Entering mem sleep
i2c_omap i2c_omap.1: preparing suspend
i2c_omap i2c_omap.3: preparing suspend
platform overo_lcd: preparing suspend
serial8250 serial8250.0: preparing suspend, may wakeup
serial8250 serial8250.1: preparing suspend, may wakeup
serial8250 serial8250.2: preparing suspend, may wakeup
platform omap2-nand: preparing suspend
platform musb_hdrc: preparing suspend
platform smsc911x.0: preparing suspend
platform smsc911x.1: preparing suspend
platform omap2_mcspi.1: preparing suspend
platform omap2_mcspi.2: preparing suspend
platform omap2_mcspi.3: preparing suspend
platform omap2_mcspi.4: preparing suspend
arm-pmu arm-pmu.0: preparing suspend
platform omap_rng: preparing suspend
platform omapfb: preparing suspend
twl4030_gpio twl4030_gpio: preparing suspend
mmci-omap-hs mmci-omap-hs.0: preparing suspend
mmci-omap-hs mmci-omap-hs.1: preparing suspend
twl_reg twl_reg.17: preparing suspend
twl_reg twl_reg.18: preparing suspend
twl_reg twl_reg.19: preparing suspend
twl4030_usb twl4030_usb: preparing suspend, may wakeup
twl_reg twl_reg.6: preparing suspend
serial8250 serial8250: preparing suspend
mmcblk mmc0:fb2a: legacy suspend
serial8250 serial8250: suspend
i2c i2c-3: suspend
twl_reg twl_reg.6: suspend
twl4030_usb twl4030_usb: suspend, may wakeup
twl_reg twl_reg.19: suspend
twl_reg twl_reg.18: suspend
twl_reg twl_reg.17: suspend
mmci-omap-hs mmci-omap-hs.1: suspend
mmci-omap-hs mmci-omap-hs.0: suspend
twl4030_gpio twl4030_gpio: suspend
dummy 1-004b: suspend
dummy 1-004a: suspend
dummy 1-0049: suspend
twl 1-0048: suspend, may wakeup
i2c i2c-1: suspend
platform omapfb: suspend
platform omap_rng: suspend
arm-pmu arm-pmu.0: suspend
platform omap2_mcspi.4: suspend
platform omap2_mcspi.3: suspend
platform omap2_mcspi.2: suspend
platform omap2_mcspi.1: suspend
platform smsc911x.1: suspend
platform smsc911x.0: suspend
platform musb_hdrc: suspend
platform omap2-nand: suspend
serial8250 serial8250.2: suspend, may wakeup
serial8250 serial8250.1: suspend, may wakeup
serial8250 serial8250.0: suspend, may wakeup
platform overo_lcd: suspend
i2c_omap i2c_omap.3: suspend
i2c_omap i2c_omap.1: suspend
PM: suspend of devices complete after 201.965 msecs
serial8250 serial8250: LATE suspend
i2c i2c-3: LATE suspend
twl_reg twl_reg.6: LATE suspend
twl4030_usb twl4030_usb: LATE suspend, may wakeup
twl_reg twl_reg.19: LATE suspend
twl_reg twl_reg.18: LATE suspend
twl_reg twl_reg.17: LATE suspend
mmci-omap-hs mmci-omap-hs.1: LATE suspend
mmci-omap-hs mmci-omap-hs.0: LATE suspend
twl4030_gpio twl4030_gpio: LATE suspend
dummy 1-004b: LATE suspend
dummy 1-004a: LATE suspend
dummy 1-0049: LATE suspend
twl 1-0048: LATE suspend, may wakeup
i2c i2c-1: LATE suspend
platform omapfb: LATE suspend
platform omap_rng: LATE suspend
arm-pmu arm-pmu.0: LATE suspend
platform omap2_mcspi.4: LATE suspend
platform omap2_mcspi.3: LATE suspend
platform omap2_mcspi.2: LATE suspend
platform omap2_mcspi.1: LATE suspend
platform smsc911x.1: LATE suspend
platform smsc911x.0: LATE suspend
platform musb_hdrc: LATE suspend
platform omap2-nand: LATE suspend
serial8250 serial8250.2: LATE suspend, may wakeup
serial8250 serial8250.1: LATE suspend, may wakeup
serial8250 serial8250.0: LATE suspend, may wakeup
platform overo_lcd: LATE suspend
i2c_omap i2c_omap.3: LATE suspend
i2c_omap i2c_omap.1: LATE suspend
PM: late suspend of devices complete after 103.088 msecs
Successfully put all powerdomains to target state
i2c_omap i2c_omap.1: EARLY resume
i2c_omap i2c_omap.3: EARLY resume
platform overo_lcd: EARLY resume
serial8250 serial8250.0: EARLY resume
serial8250 serial8250.1: EARLY resume
serial8250 serial8250.2: EARLY resume
platform

Re: Gumstix Overo non-responsive TTY after resume

[Michael Trimarchi]

Robert Lukassen wrote:

Hi,

I've just started with the linux-omap-pm branch, and are experiencing problems 
with the keyboard when resuming from sleep. There seems to be an earlier post 
on this matter:


4) Suspend to memory (echo mem  /sys/power/state) works now, but when I
wake up the board (via a keypress), I am no longer able to type anything
at the prompt. Any clue about this one?

Indeed, I was able to reproduce this as well and seems to be a new
regression in the PM branch.  I see the same on omap3evm and n900 now
too.mount 


If you enable the UART timeouts + sleep_while_idle, you should avoid
this problem while I try and figure out what's going on:

echo 5  /sys/devices/platform/serial8250.0/sleep_timeout
echo 5  /sys/devices/platform/serial8250.1/sleep_timeout
echo 5  /sys/devices/platform/serial8250.2/sleep_timeout
echo 1  /debug/pm_debug/sleep_while_idle


I've been following these lines as well, using the kernel from linux-pm-omap 
(tag: b1ce30edb70d1572d314b6a70de257150f5b20d1).
I'm using an Overo Fire (OMAP3530 + OpenGL + Wifi/BT gumstix) on a Tobi board. 
The rootfs is straight from the org.openembedded.com build result.

The lines above do not seem to help. After suspend (echo mem  
/sys/power/state), the Overo resumes when waking it up with a key press on the 
console. However, after resume, the console does not accept any input from the 
keyboard. I've also experimented with a parallel 'ssh' session via the Ethernet 
connection of the Tobi. After resume, this session is still responsive, albeit 
somewhat sluggish compared to the state before the suspend.

Has there been any development on this issue? I saw the reference to an OMAP3: 
Serial: improved sleep thread that mentions an update to the PM branch, but in the 
git log of the linux-omap-pm branch, I do not see a change related to it.

I am also interested in results concerning waking the Overo from suspend using 
a USB device connected to the USB Host port (not the USB OTG port).


I have the same problem using the experimental android 2.6.34 branch. The 
console send garbage to the serial device. I will try tomorrow to investigate a 
little bit more

Michael Trimarchi



Regards,

Robert Lukassen
--
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



--
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: USB lockup on OMAP3530

[Michael Trimarchi]

Hi

Gadiyar, Anand wrote:

snip


So far I have tried many versions of the linux-omap and linux-omap-pm
kernel, from about 2.6.30 to the latest git version. They all exhibit
the USB OTG death bug.
I've used kernels with openembedded patches and without, currently
without. Yesterday I discovered the musb_hdrc.fifo_mode parameter and
played around with it. I also modified the given configurations. Result:
- FIFO configurations including .mode = BUF_DOUBLE don't work at all - no
 devices work.
- the USB death bug is not fixed by:
 - using only one endpoint
 - using no TXRX entries but only separate RX and TX
   (every endpoint gets a TX and an RX entry though)
 - using a large number of endpoints with same maxpacket value
... still no solution.

Enabling debug output of the musb_hdrc driver (yes I've also compiled in
debug messages) is not very practical due to the high volume of
messages; also, when the bug occurs nothing special is printed. The
first error usually comes from the memory manager / filesystem
complaining that it can't do IO to offline device, i.e. the
disappeared external harddisk (which contains the swapfile).

I would *really* appreciate somebody looking into this because this
currently makes the hardware as useful as a brick for me. I can supply
debug output and test patches.


Would you care to try these two patches please?

http://marc.info/?l=linux-usbm=125957336716915w=2

And

The dependency patch:
http://marc.info/?l=linux-usbm=125879861004131w=2


Let me know if these fix the bug for you.



Use an hub with external power and connect the hub to the OTG and the device to 
the HUB.
Is it the same?



- Anand
--
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



--
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: ISP OMAP3 camera support ov7690

[Michael Trimarchi]

Hi,

I have done a step ahead maybe:

The camera has this output format:

YUYV --- the first use the CCDC_OTHERS_MEM, so seems that it needs the WEN 
signal to syncronize (I don't have this one)
RGB565   --- is not supported
RAW8 --- is supported by the ISP but seems that is not implemented as a 
isp formats

So I can't use the first one but I can use the last one because the pipeline 
support RAW format,
the data path is the same of RAW10 expet for the autofocus module. If all is 
correct what are the steps?

- add the isp_format
- add in the if confidition this data format and use the same path of RAW10
...

Regards

Michael
--
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: ISP OMAP3 camera support ov7690

[Michael Trimarchi]

Hi all,

Aguirre, Sergio wrote:



-Original Message-
From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
Sent: Tuesday, January 12, 2010 7:15 AM
To: Aguirre, Sergio
Cc: Nishanth Menon; linux-omap@vger.kernel.org; linux-
me...@vger.kernel.org
Subject: Re: ISP OMAP3 camera support ov7690

Hi all,

Now I have a good camera pcb and I can test again the driver. My board is
an overo gumstix board.


Excellent!

Please let me know if you're having issues with it.

Thanks for your interest!

Regards,
Sergio



maybe I have done some mistake during writing the email, but I have asked few 
things inside the email.
The camera part is ok because I have written a driver using the ov538 bridge 
but I have some problem
in configuring the isp omap3 device. It opens correctly the camera, and set 
xclk frequency. Then
seems that vsync and hsync are not routed to the engine because I don't receive any interrupt. 


Aguirre Rodriguez, Sergio Alberto wrote:

Hi Michael,


-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of michael
Sent: Sunday, October 04, 2009 7:29 PM
To: Nishanth Menon
Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org
Subject: Re: ISP OMAP3 camera support ov7690

Hi,

cc: linux-media

Nishanth Menon wrote:

michael said the following on 10/03/2009 06:13 PM:

I'm writing a driver to support the ov7690 camera and I have some
question about the meaning of:

- datalane configuration

CSI2 Data lanes - each CSI2 lane is a differential pair.

And, at least 1

clock and data lane is used in devices.

Sorry can you explain a little bit more. I have the camera
connected to the
cam_hs and cam_vs and the data is 8Bit. I use the the isp init
structure. The sccb bus works great and I can send
configuration to it,
but I don't receive any interrupt from the ics, seems that it
doen't see
the transaction:

The ISPCCDC: ###CCDC SYN_MODE=0x31704 seems ok.


static struct isp_interface_config ov7690_if_config = {
.ccdc_par_ser   = ISP_CSIA,
.dataline_shift = 0x0,
.hsvs_syncdetect= ISPCTRL_SYNC_DETECT_VSFALL,

Can you try with ISPCTRL_SYNC_DETECT_VSRISE ?


.strobe = 0x0,
.prestrobe  = 0x0,
.shutter= 0x0,
.wenlog = ISPCCDC_CFG_WENLOG_AND,
.wait_hs_vs = 0x4,
.raw_fmt_in = ISPCCDC_INPUT_FMT_GR_BG,
.u.csi.crc  = 0x0,
.u.csi.mode = 0x0,
.u.csi.edge = 0x0,
.u.csi.signalling   = 0x0,
.u.csi.strobe_clock_inv = 0x0,
.u.csi.vs_edge  = 0x0,
.u.csi.channel  = 0x0,
.u.csi.vpclk= 0x1,
.u.csi.data_start   = 0x0,
.u.csi.data_size= 0x0,
.u.csi.format   = V4L2_PIX_FMT_YUYV,
};

and I don't know the meaning of

lanecfg.clk.pol = OV7690_CSI2_CLOCK_POLARITY;
lanecfg.clk.pos = OV7690_CSI2_CLOCK_LANE;
lanecfg.data[0].pol = OV7690_CSI2_DATA0_POLARITY;
lanecfg.data[0].pos = OV7690_CSI2_DATA0_LANE;
lanecfg.data[1].pol = OV7690_CSI2_DATA1_POLARITY;
lanecfg.data[1].pos = OV7690_CSI2_DATA1_LANE;
lanecfg.data[2].pol = 0;
lanecfg.data[2].pos = 0;
lanecfg.data[3].pol = 0;
lanecfg.data[3].pos = 0;


This is the physical connection details:

- The .pol field stands for the differntial pair polarity.
  (i.e. the order in which the negative and positive connections
  are pugged in to the CSI2 ComplexIO module)

What exact the meaning of the pol, sorry? I have a signal that is
connected
to a pin. If the pos is avalaible can I use it?
It's not important how to route the signal but don't route on the same
lane.
Is it right?

This is the timing of the camera so I can check signal, but I don't
receive interrupt
of isp engine

The camera is direct connected to the
camera omap camera signal and using the oscilloscope I can see the hs/vs
signal
The hs is low and go up, like the vs signal. I have only one camera
with that use D0 to D7 data bit.

http://www.gumstix.net/Hardware/view/I/O-connectors-cabling/Gumstix-Overo-
27-pin-connector-J5-to-manage-camera-controls/112.html

static struct isp_interface_config ov7690_if_config = {
.ccdc_par_ser   = ISP_CSIA,
.dataline_shift = 0x0,
.hsvs_syncdetect= ISPCTRL_SYNC_DETECT_VSRISE,
.strobe = 0x0,
.prestrobe  = 0x0,
.shutter= 0x0,
.wenlog = ISPCCDC_CFG_WENLOG_AND,
.wait_hs_vs = 0x4,
.raw_fmt_in = ISPCCDC_INPUT_FMT_GR_BG,
.u.csi.crc  = 0x0,
.u.csi.mode = 0x0,
.u.csi.edge = 0x0,
.u.csi.signalling   = 0x0,
.u.csi.strobe_clock_inv = 0x0,
.u.csi.vs_edge  = 0x0,
.u.csi.channel  = 0x0

Re: ISP OMAP3 camera support ov7690

[Michael Trimarchi]

Hi,

Michael Trimarchi wrote:

Hi all,

Aguirre, Sergio wrote:



-Original Message-
From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
Sent: Tuesday, January 12, 2010 7:15 AM
To: Aguirre, Sergio
Cc: Nishanth Menon; linux-omap@vger.kernel.org; linux-
me...@vger.kernel.org
Subject: Re: ISP OMAP3 camera support ov7690

Hi all,

Now I have a good camera pcb and I can test again the driver. My 
board is

an overo gumstix board.


Excellent!

Please let me know if you're having issues with it.

Thanks for your interest!

Regards,
Sergio



maybe I have done some mistake during writing the email, but I have 
asked few things inside the email.
The camera part is ok because I have written a driver using the ov538 
bridge but I have some problem
in configuring the isp omap3 device. It opens correctly the camera, and 
set xclk frequency. Then
seems that vsync and hsync are not routed to the engine because I don't 
receive any interrupt.


--- a/drivers/media/video/isp/isp.c
+++ b/drivers/media/video/isp/isp.c
@@ -299,6 +299,7 @@ static void isp_enable_interrupts(struct device *dev)
   | IRQ0ENABLE_CSIA_IRQ
   | IRQ0ENABLE_CSIB_IRQ | IRQ0ENABLE_HIST_DONE_IRQ
   | IRQ0ENABLE_H3A_AWB_DONE_IRQ | IRQ0ENABLE_H3A_AF_DONE_IRQ
+   | IRQ0ENABLE_HS_VS_IRQ
   | isp-interrupts;

   if (CCDC_PREV_CAPTURE(isp))
@@ -328,6 +329,7 @@ static void isp_disable_interrupts(struct device *dev)
   | IRQ0ENABLE_CSIA_IRQ
   | IRQ0ENABLE_CSIB_IRQ | IRQ0ENABLE_HIST_DONE_IRQ
   | IRQ0ENABLE_H3A_AWB_DONE_IRQ | IRQ0ENABLE_H3A_AF_DONE_IRQ
+   | IRQ0ENABLE_HS_VS_IRQ
   | isp-interrupts);

Adding this in the irq mask give me interrupt from the camera, but I don't 
undestarstand
why they are disabled. Are they disabled in the latest git code?

how can I get the vrise?

.hsvs_syncdetect= ISPCTRL_SYNC_DETECT_VSFALL,


Michael


Aguirre Rodriguez, Sergio Alberto wrote:

Hi Michael,


-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of michael
Sent: Sunday, October 04, 2009 7:29 PM
To: Nishanth Menon
Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org
Subject: Re: ISP OMAP3 camera support ov7690

Hi,

cc: linux-media

Nishanth Menon wrote:

michael said the following on 10/03/2009 06:13 PM:

I'm writing a driver to support the ov7690 camera and I have some
question about the meaning of:

- datalane configuration

CSI2 Data lanes - each CSI2 lane is a differential pair.

And, at least 1

clock and data lane is used in devices.

Sorry can you explain a little bit more. I have the camera
connected to the
cam_hs and cam_vs and the data is 8Bit. I use the the isp init
structure. The sccb bus works great and I can send
configuration to it,
but I don't receive any interrupt from the ics, seems that it
doen't see
the transaction:

The ISPCCDC: ###CCDC SYN_MODE=0x31704 seems ok.


static struct isp_interface_config ov7690_if_config = {
.ccdc_par_ser   = ISP_CSIA,
.dataline_shift = 0x0,
.hsvs_syncdetect= ISPCTRL_SYNC_DETECT_VSFALL,

Can you try with ISPCTRL_SYNC_DETECT_VSRISE ?


.strobe = 0x0,
.prestrobe  = 0x0,
.shutter= 0x0,
.wenlog = ISPCCDC_CFG_WENLOG_AND,
.wait_hs_vs = 0x4,
.raw_fmt_in = ISPCCDC_INPUT_FMT_GR_BG,
.u.csi.crc  = 0x0,
.u.csi.mode = 0x0,
.u.csi.edge = 0x0,
.u.csi.signalling   = 0x0,
.u.csi.strobe_clock_inv = 0x0,
.u.csi.vs_edge  = 0x0,
.u.csi.channel  = 0x0,
.u.csi.vpclk= 0x1,
.u.csi.data_start   = 0x0,
.u.csi.data_size= 0x0,
.u.csi.format   = V4L2_PIX_FMT_YUYV,
};

and I don't know the meaning of

lanecfg.clk.pol = OV7690_CSI2_CLOCK_POLARITY;
lanecfg.clk.pos = OV7690_CSI2_CLOCK_LANE;
lanecfg.data[0].pol = OV7690_CSI2_DATA0_POLARITY;
lanecfg.data[0].pos = OV7690_CSI2_DATA0_LANE;
lanecfg.data[1].pol = OV7690_CSI2_DATA1_POLARITY;
lanecfg.data[1].pos = OV7690_CSI2_DATA1_LANE;
lanecfg.data[2].pol = 0;
lanecfg.data[2].pos = 0;
lanecfg.data[3].pol = 0;
lanecfg.data[3].pos = 0;


This is the physical connection details:

- The .pol field stands for the differntial pair polarity.
  (i.e. the order in which the negative and positive connections
  are pugged in to the CSI2 ComplexIO module)

What exact the meaning of the pol, sorry? I have a signal that is
connected
to a pin. If the pos is avalaible can I use it?
It's not important how to route the signal but don't route on the same
lane.
Is it right?

This is the timing of the camera so I can check signal, but I don't
receive interrupt
of isp engine

The camera is direct connected to the
camera omap camera signal and using

Re: CPUfreq deosn't change the current frequency

[Michael Trimarchi]

Hi tataki

tarek attia wrote:

Hi all,

CPUfreq doesn't work,,I downloaded the PM Linux kernel ,and enabled
the CPUFREQ driver before compilation .

However every writting in the scaling_setspeed doesn't get any
return,,doesn't change the frequency however without errors .

Any Idea??

--
tarek
--
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


I have a board to test but now I don't have time, I just give the info to debug 
such
issue

Michael
--
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: hub 2-0:1.0: port 2 disabled by hub (EMI?), re-enabling...

[Michael Trimarchi]

Michael Trimarchi wrote:

Hi all,

I'm working on a overo board + a palo43 daughter board. I connect a 
camera to hit with the following result:


hub 2-0:1.0: port 2 disabled by hub (EMI?), 
re-enabling...  usb 2-2: USB disconnect, address 
16 gspca: disconnect 
complete usb 2-2: new high speed USB device using ehci-omap and address 
16   usb 2-2: New USB device found, idVendor=05a9, 
idProduct=a538usb 2-2: New USB device strings: 
Mfr=1, Product=2, SerialNumber=0   usb 2-2: Product: OV538 
USB camera-013008-1 usb 2-2: 
Manufacturer: OmniVision Application Team  
usb 2-2: configuration #1 chosen from 1 
choice  gspca: probing 
05a9:a538ov538: 
sensor is ov7691 
gspca: probe ok 
every time...
This sometimes happen and simetimes in some boot is ok. But when I start 
some transaction
I have similar problem write packet on the usb device. Can you have any 
idea?


Ok I use isoc transfer to the sensor and I use a 2.6.29 kernel openembedded 
tree.

# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_OMAP_EHCI_PHY_MODE=y
# CONFIG_OMAP_EHCI_TLL_MODE is not set
CONFIG_USB_EHCI_ROOT_HUB_TT=y

Is there a part of the support patched where I can check?

Michael



Michael
--
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



--
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