Re: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Lucas Stach]

Am Freitag, den 25.09.2015, 20:44 + schrieb Woodruff, Richard:
> > From: Menon, Nishanth
> > Sent: Friday, September 25, 2015 9:44 AM
> 
> > > If I688 is not needed on am335x, then it seems there are still some
> > > mysteries remaining with this erratum to unravel. Something like
> > > difference in the L3 implementation. Maybe somebody from TI can
> > > investigate which SoCs this is really needed on?
> 
> > + Richard who probably has the oldest history on the topic.
> > 
> > I suspect strongly that the erratum was discovered during A9 OMAP4 days,
> > but never percolated to older SoC erratum documentation. The need of
> > barrier logic was clarified with SoC folks to confirm the behavior though.
> 
> -0-
> After looking up i688 in data base and reviewing AM335x SOC I do NOT think 
> i688 will exhibit for AM335x.
>  - it appears not to be using pieces which have issues on path.
> 
> I688 could impact SOCs which use a DMM and the interconnect infrastructure 
> which supports it.
> 
> I believe hang issues on path could be mapped to 3 sources:
>   - asyncbrige used from MPUSS to Arteris NOC to DMM
>   - Dual EMIF idle (ocp-connect/disconnect) policy on path
>   - PL310 idle signal usage on path
> 
> SOCs using similar chassis components of OMAP4430 time are impacted.  Errata 
> aspect in generic bridge map to Aegis, J5E, ...
> 
> The hangs are brought out by enabling power management features which causes 
> micro-idles on path which can trigger a lock up.
> 
> Later SOCs pulled in fixes in one or all areas.  Some SOCs are not using 
> components.

So please help me to get this straight:

Errata I688 only affects OMAP4 which is consequently the only user of
omap_interconnect_sync() in it's WFI enter sequence, which in turn is
the only user of the SRAM scratch area to work around the erratum.

The OMAP specific barrier implementation which should be used also on
other SoCs does not need any SRAM scratch, but uses a part of DRAM to do
the strongly ordered access.

So it is safe to say that we only ever need to run the initcall
allocating the SRAM scratch area on OMAP4.

Is this conclusion correct?

Thanks,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
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] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Russell King - ARM Linux]

On Tue, Oct 13, 2015 at 12:10:45PM +, Woodruff, Richard wrote:
> > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > Sent: Tuesday, October 13, 2015 5:01 AM
> 
> > So please help me to get this straight:
> > 
> > Errata I688 only affects OMAP4 which is consequently the only user of
> > omap_interconnect_sync() in it's WFI enter sequence, which in turn is
> > the only user of the SRAM scratch area to work around the erratum.
> > 
> > The OMAP specific barrier implementation which should be used also on
> > other SoCs does not need any SRAM scratch, but uses a part of DRAM to do
> > the strongly ordered access.
> > 
> > So it is safe to say that we only ever need to run the initcall
> > allocating the SRAM scratch area on OMAP4.
> 
> There are 2 separate things here.  One is the bus sync function and the
> other is the errata which requires a bus sync near WFI to avoid an errata.
> 
> The rational for the bus sync is similar to why there is a writel() and a
> writel_releaxed().  The bus sync has been used for a long time to ensure
> writes have landed and are not stuck in some posting buffer on path.
> 
> A lot of historical drivers use a writel() where perhaps they could choose
> a more granular construct.  If drivers were audited maybe the bus sync
> could be minimized on writel() path.

No, we're not going around that discussion loop again.

Linux requirements are that writel() at the CPU should be ordered with
respect to other writel()s and memory accesses which occur before the
writel().

However, buffering of the write by down-stream busses is permitted, and
where drivers want to ensure that the write has hit the device, a
read-back must be performed.  This requirement comes directly from the
PCI specification, and is *not* actually something that is specific to
Linux.  Linux only adopts it from PCI.

We're not going to ever relax these rules: if people want to perform
accesses which do not conform to the above, they are free to - if they
don't care about the timing of the write hitting the device, they can
omit the read-back.  If they don't care about the write being ordered,
they can use writel_relaxed() (relaxed, because it doesn't have the
ordering guarantees of standard writel().)

It's up to the driver author to use the correct accessor(s) in their
drivers.  It's not for the architecture to decide that it can relax
these rules (if it does, it risks breaking a load of drivers out there.)

So, if people want to avoid the expensive OMAP bus sync on every access
in their drivers, they _have_ to consider whether each load or store
needs to be ordered.  In general, a sequence of writes to a device
should be implemented as a sequence of writel_relaxed(), and if it needs
to be ordered, the last write should be a writel() or accompanied by a
barrier.  An example of this would be writing DMA controller configuration.
All those writes should be writel_relaxed() except for the final writel()
which kicks off the DMA operation.

If you implement drivers using nothing but writel() and readl(), then your
performance _will_ suck, but that's entirely the driver's fault.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Woodruff, Richard]

> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: Tuesday, October 13, 2015 5:01 AM

> So please help me to get this straight:
> 
> Errata I688 only affects OMAP4 which is consequently the only user of
> omap_interconnect_sync() in it's WFI enter sequence, which in turn is
> the only user of the SRAM scratch area to work around the erratum.
> 
> The OMAP specific barrier implementation which should be used also on
> other SoCs does not need any SRAM scratch, but uses a part of DRAM to do
> the strongly ordered access.
> 
> So it is safe to say that we only ever need to run the initcall
> allocating the SRAM scratch area on OMAP4.

There are 2 separate things here.  One is the bus sync function and the other 
is the errata which requires a bus sync near WFI to avoid an errata.

The rational for the bus sync is similar to why there is a writel() and a 
writel_releaxed().  The bus sync has been used for a long time to ensure writes 
have landed and are not stuck in some posting buffer on path.   

A lot of historical drivers use a writel() where perhaps they could choose a 
more granular construct.  If drivers were audited maybe the bus sync could be 
minimized on writel() path.  Some writel's could be converted to use something 
like an mmiowb () or some appropriate option.  There is a lot of good 
information in the 
http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt 
document.  It seems every time I scan it some new aspect comes out.   

For many product launches I was part of in mobile >24 hour robustness was not 
achievable in non-trivial use cases without the serializing bus sync.  For 
CortexA9 ARM pushed in pl310sync and we added a bit to flush the interconnect 
posting buffer.   For a time in the mainline tree the bus sync's fell out as it 
seemed to complicate single kernel booting.   This has the effect of opening up 
folks to sparse hang issues like found in i688.  Re-closing this issue is the 
point of this mail series.

Regards,
Richard W.

N�r��yb�X��ǧv�^�)޺{.n�+{��f��{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

RE: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Woodruff, Richard]

> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Tuesday, October 13, 2015 7:24 AM



> If you implement drivers using nothing but writel() and readl(), then your
> performance _will_ suck, but that's entirely the driver's fault.

Your above analysis seems correct.

Perhaps it is wrongheaded but part of the rationalization I used in the past 
was many of the ARM SW drivers evolved from low performance bus architectures 
which didn't punish drivers for forgetting to use a barrier or a read back.  
Many driver porters assumed what was there was good and built atop that.  The 
result was a lot of hidden issues during production ramps.  This is a mix of 
errata, missing read backs, wrong macro choice  (and many valid macro usage 
instances).  A couple SOCs I sampled in the past just used StronlgyOrdered and 
didn't buffer.  This created a lot of 'it works for me not sure of your problem 
is' inputs.

In that environment the question was realized performance vs. correctness.  The 
promotion in heaviness for some of the valid macro usages tended to not be an 
issue as they are sparse.  In cases they were not were in places where a DMA 
engine should have been in use anyway.  The end result of promotion was the 
ability to work around many of the bad with one knob.  I recall consulting 
Linux PowerPC folks (production users of weak memory model) in that time frame 
and they indicated they over synchronized also.  I don't know what they do 
today.

Today, maybe the code has been refactored/evolved enough that the older issues 
have been boiled away but this seems a bit optimistic given history.

Regards,
Richard W.

--
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] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Woodruff, Richard]

Hello Robert,

> From: Robert Schwebel [mailto:r.schwe...@pengutronix.de]
> Sent: Tuesday, September 29, 2015 12:50 PM
> > -1-
> > Barrier side effects of the patch may be beneficial for other reasons.  But
> AM335x should be immune from this particular issue.
> 
> Is this a matter of fact, or just an assumption?
> Could you clarify this with the TI hardware folks?

Which point are you asking for clarification on?

-0- is factual.  The conditions to trigger bridge bugs are specific and tied to 
cited component issues. These factors can lead to a HW clock gate before 
completion of bus protocol.  The result is a misaligned of HW FIFO pointer 
inside of the retiming bridge. At hang it is possible to attach through 
JTAG-DAP and see writes going to the wrong address due to misalignment.  The 
bridge component did fail in simulation and was fixed per hw-bug database as I 
mention.  In my sampling of customers which ramped with aggressive power 
management ~10/10 I worked with hit this issue on 4430 on robustness tests.  We 
did verify signatures at hang.

There may be other errata which have a hang condition which users experience 
but their root cause is not the same as i688.   Really any action which results 
in a bus protocol violation can end up in a hang.  For instance a wrong 
sequencing of DSS pipeline/DMA control can cause the IP to crash.  If the IP 
crashes while in the middle of talking with DDR a hang will result.  There is 
no timeout on the interconnect so a watchdog will be needed to recover from 
such events.

-1- is partially an assumption based on previous Linux macros and code 
structure.

Regards,
Richard W.

--
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] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Robert Schwebel]

Hi Richard,

On Fri, Sep 25, 2015 at 08:44:29PM +, Woodruff, Richard wrote:
> > From: Menon, Nishanth
> > Sent: Friday, September 25, 2015 9:44 AM
> 
> > > If I688 is not needed on am335x, then it seems there are still some
> > > mysteries remaining with this erratum to unravel. Something like
> > > difference in the L3 implementation. Maybe somebody from TI can
> > > investigate which SoCs this is really needed on?
> 
> > + Richard who probably has the oldest history on the topic.
> > 
> > I suspect strongly that the erratum was discovered during A9 OMAP4 days,
> > but never percolated to older SoC erratum documentation. The need of
> > barrier logic was clarified with SoC folks to confirm the behavior though.
> 
> -0-
> After looking up i688 in data base and reviewing AM335x SOC I do NOT think 
> i688 will exhibit for AM335x.
>  - it appears not to be using pieces which have issues on path.
> 
> I688 could impact SOCs which use a DMM and the interconnect infrastructure 
> which supports it.
> 
> I believe hang issues on path could be mapped to 3 sources:
>   - asyncbrige used from MPUSS to Arteris NOC to DMM
>   - Dual EMIF idle (ocp-connect/disconnect) policy on path
>   - PL310 idle signal usage on path
> 
> SOCs using similar chassis components of OMAP4430 time are impacted.  Errata 
> aspect in generic bridge map to Aegis, J5E, ...
> 
> The hangs are brought out by enabling power management features which causes 
> micro-idles on path which can trigger a lock up.
> 
> Later SOCs pulled in fixes in one or all areas.  Some SOCs are not using 
> components.
> 
> -1-
> Barrier side effects of the patch may be beneficial for other reasons.  But 
> AM335x should be immune from this particular issue.

Is this a matter of fact, or just an assumption?
Could you clarify this with the TI hardware folks?

rsc
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Robert Schwebel]

On Tue, Sep 29, 2015 at 06:06:36PM +, Woodruff, Richard wrote:
> > From: Robert Schwebel [mailto:r.schwe...@pengutronix.de]
> > Sent: Tuesday, September 29, 2015 12:50 PM
> > > -1-
> > > Barrier side effects of the patch may be beneficial for other reasons.  
> > > But
> > AM335x should be immune from this particular issue.
> > 
> > Is this a matter of fact, or just an assumption?
> > Could you clarify this with the TI hardware folks?
> 
> Which point are you asking for clarification on?
> 
> -0- is factual.  The conditions to trigger bridge bugs are specific and tied 
> to cited component issues. These factors can lead to a HW clock gate before 
> completion of bus protocol.  The result is a misaligned of HW FIFO pointer 
> inside of the retiming bridge. At hang it is possible to attach through 
> JTAG-DAP and see writes going to the wrong address due to misalignment.  The 
> bridge component did fail in simulation and was fixed per hw-bug database as 
> I mention.  In my sampling of customers which ramped with aggressive power 
> management ~10/10 I worked with hit this issue on 4430 on robustness tests.  
> We did verify signatures at hang.
> 
> There may be other errata which have a hang condition which users experience 
> but their root cause is not the same as i688.   Really any action which 
> results in a bus protocol violation can end up in a hang.  For instance a 
> wrong sequencing of DSS pipeline/DMA control can cause the IP to crash.  If 
> the IP crashes while in the middle of talking with DDR a hang will result.  
> There is no timeout on the interconnect so a watchdog will be needed to 
> recover from such events.
> 
> -1- is partially an assumption based on previous Linux macros and code 
> structure.

Thanks for the explanation!

rsc
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Tony Lindgren]

* Bastian Stender  [150925 05:40]:
> Hi,
> 
> On 09/25/2015 02:08 PM, Russell King - ARM Linux wrote:
> >On Fri, Sep 25, 2015 at 12:01:13PM +0200, Bastian Stender wrote:
> >>Signed-off-by: Bastian Stender 
> >>---
> >>  arch/arm/mach-omap2/omap4-common.c | 6 ++
> >>  1 file changed, 6 insertions(+)
> >>
> >>diff --git a/arch/arm/mach-omap2/omap4-common.c 
> >>b/arch/arm/mach-omap2/omap4-common.c
> >>index 949696b..a3a0cd1 100644
> >>--- a/arch/arm/mach-omap2/omap4-common.c
> >>+++ b/arch/arm/mach-omap2/omap4-common.c
> >>@@ -131,6 +131,12 @@ static int __init omap4_sram_init(void)
> >>struct device_node *np;
> >>struct gen_pool *sram_pool;
> >>
> >>+   /* AM335x is OMAP2+, so no erratum I688 handling needed
> >>+* (see CONFIG_OMAP4_ERRATA_I688) needed
> >
> >This makes no sense.  OMAP4 is OMAP2+ as well, but it needs the erratum.
> >In fact, all code in mach-omap2 is "OMAP2+".
> >
> >So, AM335x being "OMAP2+" is no reason at all why I688 should be disabled.
> 
> So, the Device Tree for AM335x does need a compatible = "ti,omap4-mpu" node
> + sram property for I688 handling?

If the errata is interconnect related and applies for omap4+, then
the interconnects are the same also on dm81xx and am335x AFAIK.

If I688 is not needed on am335x, then it seems there are still some
mysteries remaining with this erratum to unravel. Something like
difference in the L3 implementation. Maybe somebody from TI
can investigate which SoCs this is really needed on?

Regards,

Tony
--
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] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Nishanth Menon]

On 09/25/2015 09:35 AM, Tony Lindgren wrote:
> * Bastian Stender  [150925 05:40]:
>> Hi,
>>
>> On 09/25/2015 02:08 PM, Russell King - ARM Linux wrote:
>>> On Fri, Sep 25, 2015 at 12:01:13PM +0200, Bastian Stender wrote:
 Signed-off-by: Bastian Stender 
 ---
  arch/arm/mach-omap2/omap4-common.c | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap4-common.c 
 b/arch/arm/mach-omap2/omap4-common.c
 index 949696b..a3a0cd1 100644
 --- a/arch/arm/mach-omap2/omap4-common.c
 +++ b/arch/arm/mach-omap2/omap4-common.c
 @@ -131,6 +131,12 @@ static int __init omap4_sram_init(void)
struct device_node *np;
struct gen_pool *sram_pool;

 +  /* AM335x is OMAP2+, so no erratum I688 handling needed
 +   * (see CONFIG_OMAP4_ERRATA_I688) needed
>>>
>>> This makes no sense.  OMAP4 is OMAP2+ as well, but it needs the erratum.
>>> In fact, all code in mach-omap2 is "OMAP2+".
>>>
>>> So, AM335x being "OMAP2+" is no reason at all why I688 should be disabled.
>>
>> So, the Device Tree for AM335x does need a compatible = "ti,omap4-mpu" node
>> + sram property for I688 handling?
> 
> If the errata is interconnect related and applies for omap4+, then
> the interconnects are the same also on dm81xx and am335x AFAIK.
> 
> If I688 is not needed on am335x, then it seems there are still some
> mysteries remaining with this erratum to unravel. Something like
> difference in the L3 implementation. Maybe somebody from TI
> can investigate which SoCs this is really needed on?
> 
> Regards,
> 
> Tony
> 

+ Richard who probably has the oldest history on the topic.

I suspect strongly that the erratum was discovered during A9 OMAP4 days,
but never percolated to older SoC erratum documentation. The need of
barrier logic was clarified with SoC folks to confirm the behavior though.

Regards,
Nishanth Menon
--
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] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Woodruff, Richard]

> From: Menon, Nishanth
> Sent: Friday, September 25, 2015 9:44 AM

> > If I688 is not needed on am335x, then it seems there are still some
> > mysteries remaining with this erratum to unravel. Something like
> > difference in the L3 implementation. Maybe somebody from TI can
> > investigate which SoCs this is really needed on?

> + Richard who probably has the oldest history on the topic.
> 
> I suspect strongly that the erratum was discovered during A9 OMAP4 days,
> but never percolated to older SoC erratum documentation. The need of
> barrier logic was clarified with SoC folks to confirm the behavior though.

-0-
After looking up i688 in data base and reviewing AM335x SOC I do NOT think i688 
will exhibit for AM335x.
 - it appears not to be using pieces which have issues on path.

I688 could impact SOCs which use a DMM and the interconnect infrastructure 
which supports it.

I believe hang issues on path could be mapped to 3 sources:
- asyncbrige used from MPUSS to Arteris NOC to DMM
- Dual EMIF idle (ocp-connect/disconnect) policy on path
- PL310 idle signal usage on path

SOCs using similar chassis components of OMAP4430 time are impacted.  Errata 
aspect in generic bridge map to Aegis, J5E, ...

The hangs are brought out by enabling power management features which causes 
micro-idles on path which can trigger a lock up.

Later SOCs pulled in fixes in one or all areas.  Some SOCs are not using 
components.

-1-
Barrier side effects of the patch may be beneficial for other reasons.  But 
AM335x should be immune from this particular issue.

Regards,
Richard W.

--
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] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Bastian Stender]

Hi,

On 09/25/2015 02:08 PM, Russell King - ARM Linux wrote:

On Fri, Sep 25, 2015 at 12:01:13PM +0200, Bastian Stender wrote:

Signed-off-by: Bastian Stender 
---
  arch/arm/mach-omap2/omap4-common.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/omap4-common.c 
b/arch/arm/mach-omap2/omap4-common.c
index 949696b..a3a0cd1 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -131,6 +131,12 @@ static int __init omap4_sram_init(void)
struct device_node *np;
struct gen_pool *sram_pool;

+   /* AM335x is OMAP2+, so no erratum I688 handling needed
+* (see CONFIG_OMAP4_ERRATA_I688) needed


This makes no sense.  OMAP4 is OMAP2+ as well, but it needs the erratum.
In fact, all code in mach-omap2 is "OMAP2+".

So, AM335x being "OMAP2+" is no reason at all why I688 should be disabled.


So, the Device Tree for AM335x does need a compatible = "ti,omap4-mpu" 
node + sram property for I688 handling?



Please fix this comment.  Please also put something in the commit message
which explains fully why you are making this change.


If this is the case, the patch is probably useless.

Regards,
Bastian
--
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] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Russell King - ARM Linux]

On Fri, Sep 25, 2015 at 12:01:13PM +0200, Bastian Stender wrote:
> Signed-off-by: Bastian Stender 
> ---
>  arch/arm/mach-omap2/omap4-common.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap4-common.c 
> b/arch/arm/mach-omap2/omap4-common.c
> index 949696b..a3a0cd1 100644
> --- a/arch/arm/mach-omap2/omap4-common.c
> +++ b/arch/arm/mach-omap2/omap4-common.c
> @@ -131,6 +131,12 @@ static int __init omap4_sram_init(void)
>   struct device_node *np;
>   struct gen_pool *sram_pool;
>  
> + /* AM335x is OMAP2+, so no erratum I688 handling needed
> +  * (see CONFIG_OMAP4_ERRATA_I688) needed

This makes no sense.  OMAP4 is OMAP2+ as well, but it needs the erratum.
In fact, all code in mach-omap2 is "OMAP2+".

So, AM335x being "OMAP2+" is no reason at all why I688 should be disabled.

Please fix this comment.  Please also put something in the commit message
which explains fully why you are making this change.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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: OMAP2: erratum I688 handling disabled for AM335x

[Bastian Stender]

Signed-off-by: Bastian Stender 
---
 arch/arm/mach-omap2/omap4-common.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/omap4-common.c 
b/arch/arm/mach-omap2/omap4-common.c
index 949696b..a3a0cd1 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -131,6 +131,12 @@ static int __init omap4_sram_init(void)
struct device_node *np;
struct gen_pool *sram_pool;
 
+   /* AM335x is OMAP2+, so no erratum I688 handling needed
+* (see CONFIG_OMAP4_ERRATA_I688) needed
+*/
+   if (soc_is_am335x())
+   return 0;
+
np = of_find_compatible_node(NULL, NULL, "ti,omap4-mpu");
if (!np)
pr_warn("%s:Unable to allocate sram needed to handle errata 
I688\n",
-- 
2.5.1

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