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 <rogerq@xxxxxx>:
> 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
>>
>>
>>
--
"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
