MPC8313: fsl_elbc_nand and MDR

MPC8313: fsl_elbc_nand and MDR

[Ron Madrid]

I am having what appears to be a little conflict
with this driver, particularly with the MDR.  My
hardware uses NAND flash and an FPGA connected
through the UPM.  After the kernel is up and
running, sometimes I cannot verify the data in
the UPM RAM array.  I am guessing right now that
this is due to a use conflict between my
application and the fsl_elbc_nand driver both
trying to use the MDR at once.

Is there currently any sort of coordination that
exists for the MDR in the fsl_elbc_nand driver?
I have been looking through the code and have
not been able to find any.

Any ideas on how to solve this would be
appreciated as well.

Ron

Re: MPC8313: fsl_elbc_nand and MDR

[Scott Wood]

Ron Madrid wrote:
> I am having what appears to be a little conflict
> with this driver, particularly with the MDR.  My
> hardware uses NAND flash and an FPGA connected
> through the UPM.  After the kernel is up and
> running, sometimes I cannot verify the data in
> the UPM RAM array.  I am guessing right now that
> this is due to a use conflict between my
> application and the fsl_elbc_nand driver both
> trying to use the MDR at once.
> 
> Is there currently any sort of coordination that
> exists for the MDR in the fsl_elbc_nand driver?
> I have been looking through the code and have
> not been able to find any.

There is not yet any such coordination.  The current UPM code does not 
use MDR that I can see.

> Any ideas on how to solve this would be
> appreciated as well.

Probably just add a mutex that protects the shared resources.

-Scott

Re: MPC8313: fsl_elbc_nand and MDR

[Ron Madrid]

> From: Scott Wood <scottwood@freescale.com>
> Subject: Re: MPC8313: fsl_elbc_nand and MDR
> To: "Ron Madrid" <ron_madrid@sbcglobal.net>
> Cc: linuxppc-dev@ozlabs.org
> Date: Monday, April 26, 2010, 11:34 AM
> Ron Madrid wrote:
> > I am having what appears to be a little conflict
> > with this driver, particularly with the MDR.  My
> > hardware uses NAND flash and an FPGA connected
> > through the UPM.  After the kernel is up and
> > running, sometimes I cannot verify the data in
> > the UPM RAM array.  I am guessing right now that
> > this is due to a use conflict between my
> > application and the fsl_elbc_nand driver both
> > trying to use the MDR at once.
> > 
> > Is there currently any sort of coordination that
> > exists for the MDR in the fsl_elbc_nand driver?
> > I have been looking through the code and have
> > not been able to find any.
> 
> There is not yet any such coordination.  The current
> UPM code does not use MDR that I can see.

When you say current UPM code are you talking about
fsl_upm.c?  Cause that's only for a NAND device on the
UPM right?  If there's different code, I don't know
where it is.

> > Any ideas on how to solve this would be
> > appreciated as well.
> 
> Probably just add a mutex that protects the shared
> resources.

That's what I thought might need to happen.

Ron

Re: MPC8313: fsl_elbc_nand and MDR

[Scott Wood]

Ron Madrid wrote:
> When you say current UPM code are you talking about
> fsl_upm.c?  Cause that's only for a NAND device on the
> UPM right?  If there's different code, I don't know
> where it is.

There's also arch/powerpc/sysdev/fsl_lbc.c

-Scott

Re: MPC8313: fsl_elbc_nand and MDR

[Ron Madrid]

> From: Scott Wood <scottwood@freescale.com>
> Subject: Re: MPC8313: fsl_elbc_nand and MDR
> To: "Ron Madrid" <ron_madrid@sbcglobal.net>
> Cc: linuxppc-dev@ozlabs.org
> Date: Monday, April 26, 2010, 12:10 PM
> Ron Madrid wrote:
> > When you say current UPM code are you talking about
> > fsl_upm.c?  Cause that's only for a NAND device
> on the
> > UPM right?  If there's different code, I don't
> know
> > where it is.
> 
> There's also arch/powerpc/sysdev/fsl_lbc.c

Thanks.  Although this doesn't handle programming the
UPM, which is where my conflict is occurring.  MDR is
used when programming the UPM.  Do you think I would
be better served to program the UPM in U-boot and
therefore preempt this conflict?

Ron

Re: MPC8313: fsl_elbc_nand and MDR

[Scott Wood]

Ron Madrid wrote:
> Thanks.  Although this doesn't handle programming the
> UPM, which is where my conflict is occurring.  MDR is
> used when programming the UPM.  Do you think I would
> be better served to program the UPM in U-boot and
> therefore preempt this conflict?

If you don't need to reprogram it dynamically, doing it either in u-boot 
or early in platform code is probably best.

I guess the UPM NAND code relies on U-Boot doing this?

-Scott

Re: MPC8313: fsl_elbc_nand and MDR

[Anton Vorontsov]

On Mon, Apr 26, 2010 at 02:28:00PM -0500, Scott Wood wrote:
> Ron Madrid wrote:
> >Thanks.  Although this doesn't handle programming the
> >UPM, which is where my conflict is occurring.  MDR is
> >used when programming the UPM.  Do you think I would
> >be better served to program the UPM in U-boot and
> >therefore preempt this conflict?
> 
> If you don't need to reprogram it dynamically, doing it either in
> u-boot or early in platform code is probably best.
> 
> I guess the UPM NAND code relies on U-Boot doing this?

Yep, u-boot or platform code.

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

Re: MPC8313: fsl_elbc_nand and MDR

[Ron Madrid]

> From: Anton Vorontsov <cbouatmailru@gmail.com>
> Subject: Re: MPC8313: fsl_elbc_nand and MDR
> To: "Scott Wood" <scottwood@freescale.com>
> Cc: linuxppc-dev@ozlabs.org, "Ron Madrid" <ron_madrid@sbcglobal.net>
> Date: Monday, April 26, 2010, 12:29 PM
> On Mon, Apr 26, 2010 at 02:28:00PM
> -0500, Scott Wood wrote:
> > Ron Madrid wrote:
> > >Thanks.  Although this doesn't handle
> programming the
> > >UPM, which is where my conflict is
> occurring.  MDR is
> > >used when programming the UPM.  Do you think
> I would
> > >be better served to program the UPM in U-boot and
> > >therefore preempt this conflict?
> > 
> > If you don't need to reprogram it dynamically, doing
> it either in
> > u-boot or early in platform code is probably best.
> > 
> > I guess the UPM NAND code relies on U-Boot doing
> this?
> 
> Yep, u-boot or platform code.

Thank you both.  This is an easier (and probably better)
solution.

Ron