Regressions for older OMAP3503 silicon

Regressions for older OMAP3503 silicon

[Dave Hylands]

Hi,

I have an older overo board, which has an OMAP3503

U-booot reports:
OMAP3503-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz

In order to get the 2.6.39 kernel to boot, I had to make 2 modifications:

In arch/arm/mach-omap2/pm34xx.c, in the omap_sram_idle routine I had
to put an #if 0 around:

#if 0
       if (omap3_has_io_wakeup() &&
           (per_next_state < PWRDM_POWER_ON ||
            core_next_state < PWRDM_POWER_ON)) {
               omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK,
WKUP_MOD, PM_WKEN);
               omap3_enable_io_chain();
       }
#endif

or I would get continuous

Wake up daisy chain activation failed.

messages on the console.

I then also had to modify drivers/mmc/card/block.c and initializing
disable_multi to 1 in the mmc_blk_issue_rw_rq function to get rid of
the following messages for every I/O request.

mmcblk0: retrying using single block read
mmcblk0: retrying using single block read
mmcblk0: retrying using single block read
mmcblk0: retrying using single block read

(since this revision of the silicon doesn't support multi-block MMC reads).

Looking at the code in LXR, it appears that the same problems would
also appear in 3.0.4.

I threw in some printks in the id.c omap3_check_features function:

        printk( KERN_INFO "%s: cpu_is_omap3503() = %d\n", __func__,
cpu_is_omap3503() );
        printk( KERN_INFO "%s: cpu_is_omap3505() = %d\n", __func__,
cpu_is_omap3505() );
        printk( KERN_INFO "%s: cpu_is_omap3517() = %d\n", __func__,
cpu_is_omap3517() );
        printk( KERN_INFO "%s: omap3_features = 0x%08x\n", __func__, status );
        printk( KERN_INFO "%s: HAS_IO_WAKEUP = %d\n", __func__,
(omap3_features & OMAP3_HAS_IO_WAKEUP) != 0 );

and it reports:

omap3_check_features: cpu_is_omap3503() = 1
omap3_check_features: cpu_is_omap3505() = 0
omap3_check_features: cpu_is_omap3517() = 0
omap3_check_features: omap3_features = 0x00005c00
omap3_check_features: HAS_IO_WAKEUP = 1

and the print from the end of omap3_cpuinfo reports:

OMAP3503 ES2.1 (l2cache neon isp )


-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com

Re: Regressions for older OMAP3503 silicon

[Tony Lindgren]

* Dave Hylands <dhylands@gmail.com> [111004 23:41]:
> Hi,
> 
> I have an older overo board, which has an OMAP3503
> 
> U-booot reports:
> OMAP3503-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
> 
> In order to get the 2.6.39 kernel to boot, I had to make 2 modifications:
> 
> In arch/arm/mach-omap2/pm34xx.c, in the omap_sram_idle routine I had
> to put an #if 0 around:
> 
> #if 0
>        if (omap3_has_io_wakeup() &&
>            (per_next_state < PWRDM_POWER_ON ||
>             core_next_state < PWRDM_POWER_ON)) {
>                omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK,
> WKUP_MOD, PM_WKEN);
>                omap3_enable_io_chain();
>        }
> #endif
> 
> or I would get continuous
> 
> Wake up daisy chain activation failed.
> 
> messages on the console.

No idea why this fails..
 
> I then also had to modify drivers/mmc/card/block.c and initializing
> disable_multi to 1 in the mmc_blk_issue_rw_rq function to get rid of
> the following messages for every I/O request.
> 
> mmcblk0: retrying using single block read
> mmcblk0: retrying using single block read
> mmcblk0: retrying using single block read
> mmcblk0: retrying using single block read
> 
> (since this revision of the silicon doesn't support multi-block MMC reads).

..but this one is usually a problem muxing the MMC data lines.

Are you sure this revision only supports one data line?

Tony

Re: Regressions for older OMAP3503 silicon

[Paul Walmsley]

On Wed, 5 Oct 2011, Tony Lindgren wrote:

> * Dave Hylands <dhylands@gmail.com> [111004 23:41]:
>  
> > I then also had to modify drivers/mmc/card/block.c and initializing
> > disable_multi to 1 in the mmc_blk_issue_rw_rq function to get rid of
> > the following messages for every I/O request.
> > 
> > mmcblk0: retrying using single block read
> > mmcblk0: retrying using single block read
> > mmcblk0: retrying using single block read
> > mmcblk0: retrying using single block read
> > 
> > (since this revision of the silicon doesn't support multi-block MMC reads).
> 
> ..but this one is usually a problem muxing the MMC data lines.
> 
> Are you sure this revision only supports one data line?

Just as a data point, the MMC/SD/SDIO chapter of the OMAP35x TRM rev U 
(SPRUF98U, available from http://www.ti.com/litv/pdf/spruf98u ) mentions 
multiple block transfers quite often, so it seems likely that the IP block 
does support it.  It would be pretty surprising if the OMAP35x chips 
didn't use the same MMC IP block as the OMAP34xx chips.


- Paul

Re: Regressions for older OMAP3503 silicon

[Paul Walmsley]

Hi Dave,

On Wed, 5 Oct 2011, Dave Hylands wrote:

> I have an older overo board, which has an OMAP3503
> 
> U-booot reports:
> OMAP3503-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
> 
> In order to get the 2.6.39 kernel to boot, I had to make 2 modifications:
> 
> In arch/arm/mach-omap2/pm34xx.c, in the omap_sram_idle routine I had
> to put an #if 0 around:
> 
> #if 0
>        if (omap3_has_io_wakeup() &&
>            (per_next_state < PWRDM_POWER_ON ||
>             core_next_state < PWRDM_POWER_ON)) {
>                omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK,
> WKUP_MOD, PM_WKEN);
>                omap3_enable_io_chain();
>        }
> #endif
> 
> or I would get continuous
> 
> Wake up daisy chain activation failed.
> 
> messages on the console.

Looking at the 2.6.39 kernel sources, those messages are coming from 
mach-omap2/pm34xx.c:omap3_enable_io_chain().  That means that something is 
seriously wrong since that code should only be executing on ES3.1 chips 
and higher.

Could you put something similar to a

pr_err("** omap_rev is %08x\n", omap_rev());

in your pm34xx.c right above the #if 0 that you added and let us know what 
it says?


thanks

- Paul

Re: Regressions for older OMAP3503 silicon

[Kevin Hilman]

Dave Hylands <dhylands@gmail.com> writes:

> Hi,
>
> I have an older overo board, which has an OMAP3503
>
> U-booot reports:
> OMAP3503-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
>
> In order to get the 2.6.39 kernel to boot, I had to make 2 modifications:
>
> In arch/arm/mach-omap2/pm34xx.c, in the omap_sram_idle routine I had
> to put an #if 0 around:
>
> #if 0
>        if (omap3_has_io_wakeup() &&
>            (per_next_state < PWRDM_POWER_ON ||
>             core_next_state < PWRDM_POWER_ON)) {
>                omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK,
> WKUP_MOD, PM_WKEN);
>                omap3_enable_io_chain();
>        }
> #endif
>
> or I would get continuous
>
> Wake up daisy chain activation failed.
>
> messages on the console.

The need to comment this out suggests that omap3_has_io_wakeup() is
returning true for this SoC but should not.

Looking at mach-omap2/io.c, that feature flag is not set on the 3505 and
3517, but is set on the 3503:

	if (!cpu_is_omap3505() && !cpu_is_omap3517())
		omap_features |= OMAP3_HAS_IO_WAKEUP;

Adding a case for the 3503 here should fix this problem.

Maybe check other checks for cpu_is_omap3505() and see if those should
also be checking for the 3503.

Kevin

Re: Regressions for older OMAP3503 silicon

[Steve Sakoman]

On Wed, Oct 5, 2011 at 9:26 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Dave Hylands <dhylands@gmail.com> [111004 23:41]:

>> I then also had to modify drivers/mmc/card/block.c and initializing
>> disable_multi to 1 in the mmc_blk_issue_rw_rq function to get rid of
>> the following messages for every I/O request.
>>
>> mmcblk0: retrying using single block read
>> mmcblk0: retrying using single block read
>> mmcblk0: retrying using single block read
>> mmcblk0: retrying using single block read
>>
>> (since this revision of the silicon doesn't support multi-block MMC reads).
>
> ..but this one is usually a problem muxing the MMC data lines.
>
> Are you sure this revision only supports one data line?

No, I think you misunderstood the issue!

The issue is that multi-block mmc reads are broken and the code falls
back to single block reads but prints a warning each time.

Looking for a definitive source for this errata with Google I find:

"According to the TI docs, multiple block read transfer
does not work correctly in CPU revisions 2.1 and earlier (TI advisory
2.1.1.128)."

So the correct fix is probably to use multi-block reads only on
revisions post 2.1.

Steve

Re: Regressions for older OMAP3503 silicon

[Paul Walmsley]

On Wed, 5 Oct 2011, Kevin Hilman wrote:

> The need to comment this out suggests that omap3_has_io_wakeup() is
> returning true for this SoC but should not.
> 
> Looking at mach-omap2/io.c, that feature flag is not set on the 3505 and
> 3517, but is set on the 3503:
> 
> 	if (!cpu_is_omap3505() && !cpu_is_omap3517())
> 		omap_features |= OMAP3_HAS_IO_WAKEUP;
> 
> Adding a case for the 3503 here should fix this problem.
> 
> Maybe check other checks for cpu_is_omap3505() and see if those should
> also be checking for the 3503.

I think 3503 supports I/O wakeup, but just doesn't support the I/O chain 
enable sequence.  So as I understand it, there's a window where wakeup 
events could be lost.

- Paul

Re: Regressions for older OMAP3503 silicon

[Tony Lindgren]

* Steve Sakoman <sakoman@gmail.com> [111005 10:46]:
> On Wed, Oct 5, 2011 at 9:26 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Dave Hylands <dhylands@gmail.com> [111004 23:41]:
> 
> >> I then also had to modify drivers/mmc/card/block.c and initializing
> >> disable_multi to 1 in the mmc_blk_issue_rw_rq function to get rid of
> >> the following messages for every I/O request.
> >>
> >> mmcblk0: retrying using single block read
> >> mmcblk0: retrying using single block read
> >> mmcblk0: retrying using single block read
> >> mmcblk0: retrying using single block read
> >>
> >> (since this revision of the silicon doesn't support multi-block MMC reads).
> >
> > ..but this one is usually a problem muxing the MMC data lines.
> >
> > Are you sure this revision only supports one data line?
> 
> No, I think you misunderstood the issue!
> 
> The issue is that multi-block mmc reads are broken and the code falls
> back to single block reads but prints a warning each time.
> 
> Looking for a definitive source for this errata with Google I find:
> 
> "According to the TI docs, multiple block read transfer
> does not work correctly in CPU revisions 2.1 and earlier (TI advisory
> 2.1.1.128)."

OK, thanks for correcting me.
 
> So the correct fix is probably to use multi-block reads only on
> revisions post 2.1.

Or just permanently switch to single-block reads if the multi-block
reads fail?

Regards,

Tony

Re: Regressions for older OMAP3503 silicon

[Steve Sakoman]

On Wed, Oct 5, 2011 at 11:10 AM, Kevin Hilman <khilman@ti.com> wrote:

> The need to comment this out suggests that omap3_has_io_wakeup() is
> returning true for this SoC but should not.
>
> Looking at mach-omap2/io.c, that feature flag is not set on the 3505 and
> 3517, but is set on the 3503:
>
>        if (!cpu_is_omap3505() && !cpu_is_omap3517())
>                omap_features |= OMAP3_HAS_IO_WAKEUP;
>
> Adding a case for the 3503 here should fix this problem.
>
> Maybe check other checks for cpu_is_omap3505() and see if those should
> also be checking for the 3503.

I only see this error on ES2.1 3503 based Overo COMs.

So I am wondering if there might be an errata in this area for early
3503 processors?

Do you have access to errata that you might check?  Or pointers to
publicly available errata that I could check?

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regressions for older OMAP3503 silicon

[Paul Walmsley]

On Wed, 5 Oct 2011, Steve Sakoman wrote:

> So I am wondering if there might be an errata in this area for early
> 3503 processors?
> 
> Do you have access to errata that you might check?  Or pointers to
> publicly available errata that I could check?

AFAIK the OMAP3503 errata is here:

http://focus.ti.com/lit/er/sprz278f/sprz278f.pdf 


- Paul

Re: Regressions for older OMAP3503 silicon

[Kevin Hilman]

Steve Sakoman <sakoman@gmail.com> writes:

> On Wed, Oct 5, 2011 at 11:10 AM, Kevin Hilman <khilman@ti.com> wrote:
>
>> The need to comment this out suggests that omap3_has_io_wakeup() is
>> returning true for this SoC but should not.
>>
>> Looking at mach-omap2/io.c, that feature flag is not set on the 3505 and
>> 3517, but is set on the 3503:
>>
>>        if (!cpu_is_omap3505() && !cpu_is_omap3517())
>>                omap_features |= OMAP3_HAS_IO_WAKEUP;
>>
>> Adding a case for the 3503 here should fix this problem.
>>
>> Maybe check other checks for cpu_is_omap3505() and see if those should
>> also be checking for the 3503.
>
> I only see this error on ES2.1 3503 based Overo COMs.
>
> So I am wondering if there might be an errata in this area for early
> 3503 processors?

The IO daisy chain feature was added in later revisions (for 34xx, it
only exists for >= ES3.1.)  Sounds like enabling that feature flag
should have some revision checks added.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regressions for older OMAP3503 silicon

[Dave Hylands]

Hi Paul,

On Wed, Oct 5, 2011 at 11:09 AM, Paul Walmsley <paul@pwsan.com> wrote:
> Hi Dave,
>
> On Wed, 5 Oct 2011, Dave Hylands wrote:
>
>> I have an older overo board, which has an OMAP3503
>>
>> U-booot reports:
>> OMAP3503-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
>>
>> In order to get the 2.6.39 kernel to boot, I had to make 2 modifications:
>>
>> In arch/arm/mach-omap2/pm34xx.c, in the omap_sram_idle routine I had
>> to put an #if 0 around:
>>
>> #if 0
>>        if (omap3_has_io_wakeup() &&
>>            (per_next_state < PWRDM_POWER_ON ||
>>             core_next_state < PWRDM_POWER_ON)) {
>>                omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK,
>> WKUP_MOD, PM_WKEN);
>>                omap3_enable_io_chain();
>>        }
>> #endif
>>
>> or I would get continuous
>>
>> Wake up daisy chain activation failed.
>>
>> messages on the console.
>
> Looking at the 2.6.39 kernel sources, those messages are coming from
> mach-omap2/pm34xx.c:omap3_enable_io_chain().  That means that something is
> seriously wrong since that code should only be executing on ES3.1 chips
> and higher.
>
> Could you put something similar to a
>
> pr_err("** omap_rev is %08x\n", omap_rev());
>
> in your pm34xx.c right above the #if 0 that you added and let us know what
> it says?

It reports

** omap_rev is 35030234

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regressions for older OMAP3503 silicon

[Dave Hylands]

Hi guys,

On Wed, Oct 5, 2011 at 11:19 AM, Steve Sakoman <sakoman@gmail.com> wrote:
> On Wed, Oct 5, 2011 at 9:26 AM, Tony Lindgren <tony@atomide.com> wrote:
>> * Dave Hylands <dhylands@gmail.com> [111004 23:41]:
>
>>> I then also had to modify drivers/mmc/card/block.c and initializing
>>> disable_multi to 1 in the mmc_blk_issue_rw_rq function to get rid of
>>> the following messages for every I/O request.
>>>
>>> mmcblk0: retrying using single block read
>>> mmcblk0: retrying using single block read
>>> mmcblk0: retrying using single block read
>>> mmcblk0: retrying using single block read
>>>
>>> (since this revision of the silicon doesn't support multi-block MMC reads).
>>
>> ..but this one is usually a problem muxing the MMC data lines.
>>
>> Are you sure this revision only supports one data line?
>
> No, I think you misunderstood the issue!
>
> The issue is that multi-block mmc reads are broken and the code falls
> back to single block reads but prints a warning each time.
>
> Looking for a definitive source for this errata with Google I find:
>
> "According to the TI docs, multiple block read transfer
> does not work correctly in CPU revisions 2.1 and earlier (TI advisory
> 2.1.1.128)."
>
> So the correct fix is probably to use multi-block reads only on
> revisions post 2.1.

And uboot does a very specific check for the silicon revision and only
does single block reads.
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/omap_hsmmc.c;h=5d4cf51104a7936377dc27a2f18e8240ada9a24a;hb=HEAD#l497
(look at line 497)

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com

Re: Regressions for older OMAP3503 silicon

[Steve Sakoman]

On Wed, Oct 5, 2011 at 11:09 AM, Paul Walmsley <paul@pwsan.com> wrote:

> Looking at the 2.6.39 kernel sources, those messages are coming from
> mach-omap2/pm34xx.c:omap3_enable_io_chain().  That means that something is
> seriously wrong since that code should only be executing on ES3.1 chips
> and higher.
>
> Could you put something similar to a
>
> pr_err("** omap_rev is %08x\n", omap_rev());
>
> in your pm34xx.c right above the #if 0 that you added and let us know what
> it says?

I think that what is seriously wrong is the way that the revision test is done:

	if (omap_rev() >= OMAP3430_REV_ES3_1) {

For 3505 ES2.1 omap_rev() returns 35030234 and it is being compared to 34300434.

This sort of revision check really should be looking at cpu type and
revision.  I suspect there are a number of other similar tests in the
kernel that have this issue.

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regressions for older OMAP3503 silicon

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2343 bytes --]

Hi Dave,

On Wed, 5 Oct 2011, Dave Hylands wrote:

> On Wed, Oct 5, 2011 at 11:09 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Wed, 5 Oct 2011, Dave Hylands wrote:
> >
> >> I have an older overo board, which has an OMAP3503
> >>
> >> U-booot reports:
> >> OMAP3503-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
> >>
> >> In order to get the 2.6.39 kernel to boot, I had to make 2 modifications:
> >>
> >> In arch/arm/mach-omap2/pm34xx.c, in the omap_sram_idle routine I had
> >> to put an #if 0 around:
> >>
> >> #if 0
> >>        if (omap3_has_io_wakeup() &&
> >>            (per_next_state < PWRDM_POWER_ON ||
> >>             core_next_state < PWRDM_POWER_ON)) {
> >>                omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK,
> >> WKUP_MOD, PM_WKEN);
> >>                omap3_enable_io_chain();
> >>        }
> >> #endif
> >>
> >> or I would get continuous
> >>
> >> Wake up daisy chain activation failed.
> >>
> >> messages on the console.
> >
> > Looking at the 2.6.39 kernel sources, those messages are coming from
> > mach-omap2/pm34xx.c:omap3_enable_io_chain().  That means that something is
> > seriously wrong since that code should only be executing on ES3.1 chips
> > and higher.
> >
> > Could you put something similar to a
> >
> > pr_err("** omap_rev is %08x\n", omap_rev());
> >
> > in your pm34xx.c right above the #if 0 that you added and let us know what
> > it says?
> 
> It reports
> 
> ** omap_rev is 35030234

Thanks.  This particular problem (for the 35xx series) was fixed by commit 
1f1b0353aa3ba5dfc35641452484ea4158ee3c9c ("OMAP3: id: remove 
identification codes that only correspond to marketing names"), which 
should go upstream during the 3.2 merge window.

For your local kernel, since you seem okay with modifying it, I'd simply 
suggest commenting out the call to omap3_enable_io_chain().  You'll 
probably want to leave in the line that sets the EN_IO bit.

But Steve is correct that these types of unbounded range comparisons 
shouldn't be done with omap_rev(), at least not without further 
restrictions as to the SoC type under consideration.  Most of these seem 
to be located in arch/arm/mach-omap2/pm34xx.c, so what's needed is a patch 
to clean these up that can also go into the stable kernel release series.


- Paul