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 0x00000000 $ cat flags rate usecount $ cat rate 48000000 $ cat usecount 1 $ Regards, - dhs 2015-11-24 17:32 GMT-02:00 Michael Trimarchi <michael@xxxxxxxxxxxxxxxxxxxx>: > Hi > > Do you have /sys/kernel/debug/clk/clock_summary? > > Michael > > On Tue, Nov 24, 2015 at 7:50 PM, Daniel. <danielhilst@xxxxxxxxx> 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 <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 > > > > -- > | 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
