[patch] OMAPDSS: DSI: cleanup DSI_IRQ_ERROR_MASK define

[Dan Carpenter]

DSI_IRQ_SYNC_LOST was ORed twice so we can remove one.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/video/fbdev/omap2/dss/dsi.c 
b/drivers/video/fbdev/omap2/dss/dsi.c
index b3606de..e86df6d 100644
--- a/drivers/video/fbdev/omap2/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/dss/dsi.c
@@ -144,7 +144,7 @@ struct dsi_reg { u16 module; u16 idx; };
 #define DSI_IRQ_TA_TIMEOUT (1 << 20)
 #define DSI_IRQ_ERROR_MASK \
(DSI_IRQ_HS_TX_TIMEOUT | DSI_IRQ_LP_RX_TIMEOUT | DSI_IRQ_SYNC_LOST | \
-   DSI_IRQ_TA_TIMEOUT | DSI_IRQ_SYNC_LOST)
+   DSI_IRQ_TA_TIMEOUT)
 #define DSI_IRQ_CHANNEL_MASK   0xf
 
 /* Virtual channel interrupts */
--
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

[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   |
--
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

[Daniel.]

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

[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. 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  

Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[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 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 

Re: [PATCH v2] hw_random: omap3-rom-rng: convert timer to delayed work

[Herbert Xu]

On Wed, Nov 18, 2015 at 09:59:01PM +0200, Aaro Koskinen wrote:
> We cannot put the HW RNG to idle using a timer because we cannot disable
> clocks from atomic context. Use a delayed work instead.
> 
> Fixes a warning with CONFIG_DEBUG_MUTEXES on Nokia N900 during boot.
> 
> Reported-by: Sebastian Reichel 
> Signed-off-by: Aaro Koskinen 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Pali Rohár]

On Sunday 22 November 2015 07:51:46 Pavel Machek wrote:
> On Wed 2015-11-11 17:10:46, Frank Rowand wrote:
> > Adding devicetree list.
> > 
> > Thread starts at
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html
> > 
> > On 11/5/2015 8:17 AM, Tony Lindgren wrote:
> > > * Pali Rohár  [151105 03:41]:
> > >> On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote:
> > >>> On Monday 12 October 2015 13:45:09 Tony Lindgren wrote:
> >  * Pali Rohár  [151012 13:29]:
> > > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote:
> > >>
> > >> Pali, any news on posting an updated series with the comments
> > >> addressed in this thread? It seems that we all pretty much agree
> > >> what needs to be done.
> > 
> > I'm not real happy with the concept of patches 4 and 5 in this series.
> > My concern is that those two patches are using the FDT as a transport
> > mechanism for a binary blob (the atags object).
> 
> Umm. Ok. Do you have alternative proposal that works for everyone?
> 
> I mean. This discussion was going for quite a long time, and it would
> be nice to have some solution... patch proposal... something.
>   Pavel

Yes, discussion is going for a long time! So should I spend time for
adding documentation to my solution (this is last one thing which is
missing)? Or my solution is wrong and somebody else will propose new?
I do not want to spend time on something which will be rejected and
discarded.

-- 
Pali Rohár
pali.ro...@gmail.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: [PATCH v4 0/3] ARM: OMAP2+ McASP(3) support for DRA7xx family

[Peter Ujfalusi]

Tony,

On 11/12/2015 08:00 PM, Tony Lindgren wrote:
> * Peter Ujfalusi  [15 23:33]:
>> Hi Tony,
>>
>> Changes since v3:
>> - rebased on mainline's HEAD
>> - Added Tested-by from Felipe
>> - Added Acked-by from Paul for the hwmod patches
>>
>> Changes since v2:
>> - DTS patch added which is needed because of the clock handling changes
>>
>> Felip Balbi reported that linux-next is broken right now since the DTS part 
>> of
>> the earlier series has been applied, but we do not have the mcasp hwmod in 
>> the
>> kernel:
>> ...
>> [0.181029] platform 48468000.mcasp: Cannot lookup hwmod 'mcasp3'
>> ...
>> [6.121072] davinci-mcasp 48468000.mcasp: _od_fail_runtime_resume: FIXME: 
>> missing hwmod/omap_dev info
>> [6.130790] [ cut here ]
>> [6.135643] WARNING: CPU: 0 PID: 244 at drivers/bus/omap_l3_noc.c:147 
>> l3_interrupt_handler+0x220/0x34c()
>> [6.145576] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER2_P3 
>> (Read): Data Access in User mode during Functional access
> 
> 
> Thanks applying all three into omap-for-v4.4/fixes.

Do you know when these patches are going to be merged to mainline? 4.4-rc2 is
out, but it does not include them.

-- 
Péter
--
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

Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Daniel.]

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

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

Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[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   |
--
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

[Daniel.]

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

[PATCH] ARM: OMAP: RX-51: fix a typo in log writing

[Aaro Koskinen]

Fix a typo when registering HW RNG.

Signed-off-by: Aaro Koskinen 
---
 arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
 arch/arm/mach-omap2/pdata-quirks.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 14edcd7..ff1520b 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1257,7 +1257,7 @@ static struct platform_device omap3_rom_rng_device = {
 static void __init rx51_init_omap3_rom_rng(void)
 {
if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
-   pr_info("RX-51: Registring OMAP3 HWRNG device\n");
+   pr_info("RX-51: Registering OMAP3 HWRNG device\n");
platform_device_register(_rom_rng_device);
}
 }
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 1dfe346..35ea6c0 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -268,7 +268,7 @@ static void __init nokia_n900_legacy_init(void)
pr_warn("Thumb binaries may crash randomly without this 
workaround\n");
}
 
-   pr_info("RX-51: Registring OMAP3 HWRNG device\n");
+   pr_info("RX-51: Registering OMAP3 HWRNG device\n");
platform_device_register(_rom_rng_device);
 
}
-- 
2.4.0

--
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