Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash
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= &clkops_omap3430es2_dss_usbhost_wait,
.parent = &omap_48m_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430ES2_USBHOST_MOD,
CM_FCLKEN),
.enable_bit = OMAP3430ES2_EN_USBHOST1_SHIFT,
.clkdm_name = "usbhost_clkdm",
.recalc = &followparent_recalc,
};
Where &clkops_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 like: "Fixing recursive fault but reboot is
> needed!"
>
>
>
Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash
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 parallel. >> > > Can you point me to te module description? I think that the module > is working if it's compiled in. Correct? > > Michael > >
Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash
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 (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
Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash
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 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
Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash
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 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.
Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash
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 >>> (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 >
Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash
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 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? >>
Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash
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 http://vger.kernel.org/majordomo-info.html -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder
Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash
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
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
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
Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash
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
