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

[Daniel.]

Hi Tony and Rogers, thanks for the reply.

I found this:

(clock3xxx_data.c)
static struct clk usbhost_48m_fck = {
.name   = "usbhost_48m_fck",
.ops= _omap3430es2_dss_usbhost_wait,
.parent = _48m_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430ES2_USBHOST_MOD,
CM_FCLKEN),
.enable_bit = OMAP3430ES2_EN_USBHOST1_SHIFT,
.clkdm_name = "usbhost_clkdm",
.recalc = _recalc,
};


Where  _omap3430es2_dss_usbhost_wait is
(clock34xx.c)
const struct clkops clkops_omap3430es2_dss_usbhost_wait = {
.enable = omap2_dflt_clk_enable,
.disable= omap2_dflt_clk_disable,
.find_idlest= omap3430es2_clk_dss_usbhost_find_idlest,
.find_companion = omap2_clk_dflt_find_companion,
};

I tried to use this instead of clkops_omap3430es2_dss_usbhost_wait,
but without success
const struct clkops clkops_omap2_dflt = {
.enable = omap2_dflt_clk_enable,
.disable= omap2_dflt_clk_disable,
};


The crash happens while trying to read UHH registers, at this line:
http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=drivers/usb/host/ehci-omap.c;h=07db0d80d8f6a4b186d3de6638cb3affc2c4812f;hb=HEAD#l583

The clock *seems* enabled, since is an internal clock I think I can't
use an oscilloscope to see it clocking, right?

BR,

- dhs

2015-11-26 7:22 GMT-02:00 Roger Quadros :
> Daniel,
>
> On 24/11/15 15:36, Daniel. wrote:
>> Hi Michael
>>
>> About this:
>> "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."
>>
>> My chip is ES1. I think that ES2+ code is running since I see these waits
>> ocurring on code... I'll take a better look in this, thanks again!
>
> Did you figure out if this clock is really present in the ES1 TRM?
> If it is not then why is the kernel trying to enable this clock?
>
> If it is present in the ES1 TRM then why is the kernel trying to wait
> for it to be enabled? AFAIK there is no need to wait for the clock to be
> enabled as there is no such status bit on ES1.
>
> cheers,
> -roger
>
>>
>> Does anyone know how to check if a clock is enabled?
>>
>> Regards,
>>
>> 2015-11-23 18:24 GMT-02:00 Daniel. :
>>> I've already tried, it fails to apply. My tree is based on last commit from
>>> TI linux-omap3 (4f1fb3bea4cc381c76e8e439f8af393c1a698dfc) so I *think*
>>> that this is already applied (since come from the same tree).
>>>
>>> I will try to apply it by hand
>>> Thanks!
>>> Regards,
>>>
>>> 2015-11-23 18:10 GMT-02:00 Michael Trimarchi :
 Hi

 Can you check if you have this patch in?

 commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
 Author: Paul Walmsley 
 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.  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 

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

[Roger Quadros]

Daniel,

On 24/11/15 15:36, Daniel. wrote:
> Hi Michael
> 
> About this:
> "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."
> 
> My chip is ES1. I think that ES2+ code is running since I see these waits
> ocurring on code... I'll take a better look in this, thanks again!

Did you figure out if this clock is really present in the ES1 TRM?
If it is not then why is the kernel trying to enable this clock?

If it is present in the ES1 TRM then why is the kernel trying to wait
for it to be enabled? AFAIK there is no need to wait for the clock to be
enabled as there is no such status bit on ES1.

cheers,
-roger

> 
> Does anyone know how to check if a clock is enabled?
> 
> Regards,
> 
> 2015-11-23 18:24 GMT-02:00 Daniel. :
>> I've already tried, it fails to apply. My tree is based on last commit from
>> TI linux-omap3 (4f1fb3bea4cc381c76e8e439f8af393c1a698dfc) so I *think*
>> that this is already applied (since come from the same tree).
>>
>> I will try to apply it by hand
>> Thanks!
>> Regards,
>>
>> 2015-11-23 18:10 GMT-02:00 Michael Trimarchi :
>>> Hi
>>>
>>> Can you check if you have this patch in?
>>>
>>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
>>> Author: Paul Walmsley 
>>> 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.  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 
 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 
 :
> Hi
>
> On Mon, Nov 23, 2015 at 8:05 PM, Daniel.  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 

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

[Daniel.]

Hi Michael,

Thanks for the help,

The clock_summary is not there but I found these files:
$ pwd
/sys/kernel/debug/clock/virt_26m_ck/osc_sys_ck/sys_ck/dpll4_ck/dpll4_m2_ck/dpll4_m2x2_ck/omap_96m_alwon_fck/cm_96m_fck/omap_48m_fck/usbhost_48m_fck
$ cat flags
0x
$ cat
flags rate  usecount
$ cat rate
4800
$ cat usecount
1
$


Regards,

- dhs

2015-11-24 17:32 GMT-02:00 Michael Trimarchi :
> Hi
>
> Do you have /sys/kernel/debug/clk/clock_summary?
>
> Michael
>
> On Tue, Nov 24, 2015 at 7:50 PM, Daniel.  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 :
>>> Hi
>>>
>>> Can you check if you have this patch in?
>>>
>>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
>>> Author: Paul Walmsley 
>>> 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.  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 
 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 
 :
> Hi
>
> On Mon, Nov 23, 2015 at 8:05 PM, Daniel.  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 
>> :
>>> 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

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

[Daniel.]

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 :
> Hi
>
> Can you check if you have this patch in?
>
> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
> Author: Paul Walmsley 
> 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.  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 
>> 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 :
>>> Hi
>>>
>>> On Mon, Nov 23, 2015 at 8:05 PM, Daniel.  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 
 :
> 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 

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.  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 :
>> Hi
>>
>> Can you check if you have this patch in?
>>
>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
>> Author: Paul Walmsley 
>> 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.  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 
>>> 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 :
 Hi

 On Mon, Nov 23, 2015 at 8:05 PM, Daniel.  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 
> :
>> 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 

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

[Daniel.]

Hi Michael

About this:
"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."

My chip is ES1. I think that ES2+ code is running since I see these waits
ocurring on code... I'll take a better look in this, thanks again!

Does anyone know how to check if a clock is enabled?

Regards,

2015-11-23 18:24 GMT-02:00 Daniel. :
> I've already tried, it fails to apply. My tree is based on last commit from
> TI linux-omap3 (4f1fb3bea4cc381c76e8e439f8af393c1a698dfc) so I *think*
> that this is already applied (since come from the same tree).
>
> I will try to apply it by hand
> Thanks!
> Regards,
>
> 2015-11-23 18:10 GMT-02:00 Michael Trimarchi :
>> Hi
>>
>> Can you check if you have this patch in?
>>
>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
>> Author: Paul Walmsley 
>> 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.  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 
>>> 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 :
 Hi

 On Mon, Nov 23, 2015 at 8:05 PM, Daniel.  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 
> :
>> 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

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.  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 :
>> 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   |
>
>
>
> --
> "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

[Daniel.]

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 
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 :
> Hi
>
> On Mon, Nov 23, 2015 at 8:05 PM, Daniel.  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 :
>>> 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   |
>>
>>
>>
>> --
>> "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

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 
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.  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 
> 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 :
>> Hi
>>
>> On Mon, Nov 23, 2015 at 8:05 PM, Daniel.  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 :
 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  

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

[Daniel.]

I've already tried, it fails to apply. My tree is based on last commit from
TI linux-omap3 (4f1fb3bea4cc381c76e8e439f8af393c1a698dfc) so I *think*
that this is already applied (since come from the same tree).

I will try to apply it by hand
Thanks!
Regards,

2015-11-23 18:10 GMT-02:00 Michael Trimarchi :
> Hi
>
> Can you check if you have this patch in?
>
> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
> Author: Paul Walmsley 
> 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.  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 
>> 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 :
>>> Hi
>>>
>>> On Mon, Nov 23, 2015 at 8:05 PM, Daniel.  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 
 :
> 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 

Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Daniel.]

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

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

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: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Daniel.]

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.

Thanks for your reply, best regards!

2015-11-23 16:57 GMT-02:00 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   |



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