Re: Beagleboard rev C memory timings & suspend/resume

[Jean Pihet <jpihet@mvista.com>]

Paul,

On Thursday 07 May 2009 20:59:43 Paul Walmsley wrote:
> Hello Jean
>
> On Thu, 7 May 2009, Jean Pihet wrote:
> > From the OMAP datasheet it looks like the ARCV setting is off: shouldn't
> > it be (tREFI/tCK)+50=(7800/6)+50=0x546?
>
> Could you elaborate further what you're seeing?  It would help to
> see the register value that you're using to come to this conclusion.
The SDRC_RFR_CTRL_p registers are now programmed with 0x4dc01, which means the 
fiel ARCV has the value 0x4dc=1244.
>From the DDR datasheet we need an average refresh period of 7.8us and a clock 
period of 6ns (166MHz). From the definition of the ARCV field in the OMAP TRM 
I need to program ARCV with: (tREFI/tCK)+50 = (7800/6)+50=1350=0x546.
The SDRC_RFR_CTRL_p registers would then have the value of 0x54601.

Does that make sense? Am I wrong with the calculation?

>
> - Paul
Regards,
Jean
>
> > Is there a way to know if the self refresh works on both parts?
> >
> > Regards,
> > Jean
> >
> > On Thursday 07 May 2009 13:18:30 Jean Pihet wrote:
> > > Hi Paul,
> > >
> > > On Thursday 07 May 2009 01:39:02 Paul Walmsley wrote:
> > > > Hello Jean,
> > > >
> > > > sorry about the delay,
> > >
> > > Thanks for replying!
> > >
> > > > On Wed, 29 Apr 2009, Jean Pihet wrote:
> > > > > The suspend/resume on Beagleboard has some problem due to bad
> > > > > memory timings. Suspending for more than 5 to 10 seconds shows
> > > > > memory corruption.
> > > > >
> > > > > The new chips on rev Cx boards are using 2 DDR chip selects and it
> > > > > looks like the 2nd memory part is not correctly put into self
> > > > > refresh. As an experimentation I tried the same kernel with
> > > > > 'mem=128M' and it resumes correctly after 1 min in suspend.
> > > >
> > > > Nice work, this seems likely to be the cause.
> > > >
> > > > > I could not find the latest DDR detailed specs from Micron. The
> > > > > part number is MT29C2G48MAKLCJI-6 IT. Are those available? Is this
> > > > > part identical to 2 1Gb parts?
> > > >
> > > > The combined part's web page is:
> > > >
> > > > http://www.micron.com/products/partdetail?part=MT29C2G48MAKLCJI-6%20I
> > > >T
> > > >
> > > > The SDRAM datasheet is the same that is used for all the other Micron
> > > > parts that we've run across so far:
> > > >
> > > > http://download.micron.com/pdf/datasheets/dram/mobile/1gb_ddr_mobile_
> > > >sdra m_ t48m.pdf
> > >
> > > Ok so we have 2 DDRs combined.
> > > That does not explain why the self-refresh is ok with only 1 part while
> > > it fails with the 2 parts.
> > > Could it be that the timings are too tight? Is there something special
> > > for the SDRC to support the 2 CSes correctly?
> > >
> > > We already have used the self refresh with 2 parts hooked on a 3430,
> > > not Micron parts though, so the code looks correct.
> > >
> > > I think we need help from the HW vendors here to identify the root
> > > cause: SDRC, DDR parts, connections?
> > >
> > > > > Now for the code in the kernel, there are some changes needed to
> > > > > support 2 CS'es:
> > > > > - the SDRC parameters need to be updated for the new memory part
> > > > > - the SDRC parameters need to include the ACTIM_CTRL_A_0,
> > > > > ACTIM_CTRL_A_1, ACTIM_CTRL_B_0, ACTIM_CTRL_B_1, RFR_CTRL_0 and
> > > > > RFR_CTRL_1 registers. Since the parameters for the 2nd CS are the
> > > > > same, this can be avoided by writing the same values to the 2 sets
> > > > > of registers
> > > > > - is there a need to differentiate between 1Gb and 2Gb chips, or
> > > > > can we just write the same params for both CS'es even if only one
> > > > > is being used? - the 'configure_sdrc' function in
> > > > > arch/arm/mach-omap2/sram34xx.S needs to program the 2 sets of
> > > > > registers. Here is a patch excerpt below. This patch only does not
> > > > > help the suspend/resume though.
> > > > >
> > > > > Any idea or suggestion?
> > > >
> > > > Looks like a good start.  Since the two SDRC chip-selects can
> > > > technically address parts with different timings, we should not
> > > > assume that the two chip selects will be the same.  Admittedly this
> > > > seems like an unlikely situation, but it's not impossible for non-POP
> > > > OMAPs.
> > >
> > > Makes sense. It is better to have correct and generic code.
> > >
> > > > Re: suspend/resume, if you're talking about the code in sleep34xx.S,
> > > > it looks like this is already in good shape.
> > > >
> > > > Re: board & SDRC changes: would suggest modifying omap2_sdrc_init()
> > > > to take either two struct omap_sdrc_params pointers, or one struct
> > > > with two pointers.  omap2_init_common_hw() will also need to be
> > > > updated for that, and all of the board-*.c files also.
> > > >
> > > > Sound reasonable?
> > >
> > > Sure. I can write the new code, but I prefer to have the self refresh
> > > working first.
> > >
> > > > >         ldr     r11, omap3_sdrc_mr_0
> > > > >         str     r6, [r11]
> > > > >         ldr     r6, [r11]               @ posted-write barrier for
> > > > > SDRC +       ldr     r11, omap3_sdrc_mr_1
> > > > > +       str     r6, [r11]
> > > > > +       ldr     r6, [r11]               @ posted-write barrier for
> > > > > SDRC bx      lr
> > > >
> > > > By the way, there's no need to duplicate the posted-write barrier. 
> > > > There should only be one, appearing right before the 'bx lr'.
> > >
> > > Ok I will take it into account.
> > >
> > > > regards,
> > > >
> > > > - Paul
> > >
> > > Regards,
> > > Jean
> > >
> > > --
> > > 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
>
> - Paul