* MPC8313: fsl_elbc_nand and MDR
@ 2010-04-26 18:04 Ron Madrid
2010-04-26 18:34 ` Scott Wood
0 siblings, 1 reply; 8+ messages in thread
From: Ron Madrid @ 2010-04-26 18:04 UTC (permalink / raw)
To: linuxppc-dev
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MPC8313: fsl_elbc_nand and MDR
2010-04-26 18:04 MPC8313: fsl_elbc_nand and MDR Ron Madrid
@ 2010-04-26 18:34 ` Scott Wood
2010-04-26 19:08 ` Ron Madrid
0 siblings, 1 reply; 8+ messages in thread
From: Scott Wood @ 2010-04-26 18:34 UTC (permalink / raw)
To: Ron Madrid; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MPC8313: fsl_elbc_nand and MDR
2010-04-26 18:34 ` Scott Wood
@ 2010-04-26 19:08 ` Ron Madrid
2010-04-26 19:10 ` Scott Wood
0 siblings, 1 reply; 8+ messages in thread
From: Ron Madrid @ 2010-04-26 19:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MPC8313: fsl_elbc_nand and MDR
2010-04-26 19:08 ` Ron Madrid
@ 2010-04-26 19:10 ` Scott Wood
2010-04-26 19:24 ` Ron Madrid
0 siblings, 1 reply; 8+ messages in thread
From: Scott Wood @ 2010-04-26 19:10 UTC (permalink / raw)
To: Ron Madrid; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MPC8313: fsl_elbc_nand and MDR
2010-04-26 19:10 ` Scott Wood
@ 2010-04-26 19:24 ` Ron Madrid
2010-04-26 19:28 ` Scott Wood
0 siblings, 1 reply; 8+ messages in thread
From: Ron Madrid @ 2010-04-26 19:24 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MPC8313: fsl_elbc_nand and MDR
2010-04-26 19:24 ` Ron Madrid
@ 2010-04-26 19:28 ` Scott Wood
2010-04-26 19:29 ` Anton Vorontsov
0 siblings, 1 reply; 8+ messages in thread
From: Scott Wood @ 2010-04-26 19:28 UTC (permalink / raw)
To: Ron Madrid; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MPC8313: fsl_elbc_nand and MDR
2010-04-26 19:28 ` Scott Wood
@ 2010-04-26 19:29 ` Anton Vorontsov
2010-04-26 23:46 ` Ron Madrid
0 siblings, 1 reply; 8+ messages in thread
From: Anton Vorontsov @ 2010-04-26 19:29 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Ron Madrid
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MPC8313: fsl_elbc_nand and MDR
2010-04-26 19:29 ` Anton Vorontsov
@ 2010-04-26 23:46 ` Ron Madrid
0 siblings, 0 replies; 8+ messages in thread
From: Ron Madrid @ 2010-04-26 23:46 UTC (permalink / raw)
To: Scott Wood, Anton Vorontsov; +Cc: linuxppc-dev
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-04-26 23:46 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-26 18:04 MPC8313: fsl_elbc_nand and MDR Ron Madrid
2010-04-26 18:34 ` Scott Wood
2010-04-26 19:08 ` Ron Madrid
2010-04-26 19:10 ` Scott Wood
2010-04-26 19:24 ` Ron Madrid
2010-04-26 19:28 ` Scott Wood
2010-04-26 19:29 ` Anton Vorontsov
2010-04-26 23:46 ` Ron Madrid
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.