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. <danielhi...@gmail.com>:
> 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 <mich...@amarulasolutions.com>:
>> Hi
>>
>> Can you check if you have this patch in?
>>
>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
>> Author: Paul Walmsley <p...@pwsan.com>
>> 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. <danielhi...@gmail.com> 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.ba...@nokia.com>
>>> 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 <mich...@amarulasolutions.com>:
>>>> Hi
>>>>
>>>> On Mon, Nov 23, 2015 at 8:05 PM, Daniel. <danielhi...@gmail.com> 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
>>>>> <mich...@amarulasolutions.com>:
>>>>>> Hi Daniel
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 23, 2015 at 7:45 PM, Daniel. <danielhi...@gmail.com> 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 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
>>
>>
>>
>> --
>> | 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
