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. <danielhilst@xxxxxxxxx>: >> 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 <michael@xxxxxxxxxxxxxxxxxxxx>: >>> Hi >>> >>> Can you check if you have this patch in? >>> >>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2 >>> Author: Paul Walmsley <paul@xxxxxxxxx> >>> 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 100000 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. <danielhilst@xxxxxxxxx> wrote: >>>> Hi, >>>> >>>> Building as built-in doesn't solve my problem. The difference is that >>>> when compiled as module the dump shows up when I load it, and when is >>>> built-in the dump shows up at boot time. Also when built-in the >>>> problem seems to ocurr when device is reseted (on ehci_omap_stop) and >>>> the first stack dump is followed by much more other dumps. At the end >>>> I can see something like: "Fixing recursive fault but reboot is >>>> needed!" >>>> >>>> >>>> Here is the module info: >>>> root@csi:~# modinfo ehci-hcd >>>> filename: /lib/modules/2.6.37+/kernel/drivers/usb/host/ehci-hcd.ko >>>> author: Felipe Balbi <felipe.balbi@xxxxxxxxx> >>>> 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 <michael@xxxxxxxxxxxxxxxxxxxx>: >>>>> Hi >>>>> >>>>> On Mon, Nov 23, 2015 at 8:05 PM, Daniel. <danielhilst@xxxxxxxxx> 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 <michael@xxxxxxxxxxxxxxxxxxxx>: >>>>>>> Hi Daniel >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 23, 2015 at 7:45 PM, Daniel. <danielhilst@xxxxxxxxx> 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 100000 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 majordomo@xxxxxxxxxxxxxxx >>>>>>>> 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 majordomo@xxxxxxxxxxxxxxx >>>>>> 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 >>> >>> >>> >>> -- >>> | 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
