diff mbox

[v8,4/4] ARM: mxs/mx28evk: add GPMI-NAND device

Message ID 1314169643-23425-5-git-send-email-b32955@freescale.com
State New
Headers show

Commit Message

Huang Shijie Aug. 24, 2011, 7:07 a.m. UTC
add GPMI-NAND device for mx28evk board.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 arch/arm/mach-mxs/Kconfig        |    1 +
 arch/arm/mach-mxs/mach-mx28evk.c |   36 ++++++++++++++++++++++++++++++++++++
 2 files changed, 37 insertions(+), 0 deletions(-)

Comments

Fabio Estevam April 5, 2012, 12:44 a.m. UTC | #1
Hi Shawn,

On Wed, Aug 24, 2011 at 4:07 AM, Huang Shijie <b32955@freescale.com> wrote:
> add GPMI-NAND device for mx28evk board.
>
> Signed-off-by: Huang Shijie <b32955@freescale.com>

Can this one be applied now?
Fabio Estevam April 5, 2012, 12:45 a.m. UTC | #2
On Wed, Apr 4, 2012 at 9:44 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Shawn,
>
> On Wed, Aug 24, 2011 at 4:07 AM, Huang Shijie <b32955@freescale.com> wrote:
>> add GPMI-NAND device for mx28evk board.
>>
>> Signed-off-by: Huang Shijie <b32955@freescale.com>
>
> Can this one be applied now?

Adding Shawn.
Shawn Guo April 5, 2012, 1:08 a.m. UTC | #3
On Wed, Apr 04, 2012 at 09:44:52PM -0300, Fabio Estevam wrote:
> Hi Shawn,
> 
> On Wed, Aug 24, 2011 at 4:07 AM, Huang Shijie <b32955@freescale.com> wrote:
> > add GPMI-NAND device for mx28evk board.
> >
> > Signed-off-by: Huang Shijie <b32955@freescale.com>
> 
> Can this one be applied now?
> 
No.

1) The pin confliction between gpmi and lcdif remains.
2) I intend to freeze the board file updates, as we are on the way to
   device tree.

So instead of patching board file, please contribute to device tree
conversion.
Fabio Estevam April 5, 2012, 1:19 a.m. UTC | #4
On Wed, Apr 4, 2012 at 10:08 PM, Shawn Guo <shawn.guo@linaro.org> wrote:

> No.
>
> 1) The pin confliction between gpmi and lcdif remains.
> 2) I intend to freeze the board file updates, as we are on the way to
>   device tree.
>
> So instead of patching board file, please contribute to device tree
> conversion.

I don't see mx28 dts support in mainline yet.

Does it mean my spi patches will not be accepted as well?
Shawn Guo April 5, 2012, 1:23 a.m. UTC | #5
On Wed, Apr 04, 2012 at 10:19:25PM -0300, Fabio Estevam wrote:
> On Wed, Apr 4, 2012 at 10:08 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> 
> > No.
> >
> > 1) The pin confliction between gpmi and lcdif remains.
> > 2) I intend to freeze the board file updates, as we are on the way to
> >   device tree.
> >
> > So instead of patching board file, please contribute to device tree
> > conversion.
> 
> I don't see mx28 dts support in mainline yet.
> 
I will be soon on arm-soc and in turn linux-next.

> Does it mean my spi patches will not be accepted as well?

Yes and sorry.
Fabio Estevam April 5, 2012, 4:12 p.m. UTC | #6
On Wed, Apr 4, 2012 at 10:23 PM, Shawn Guo <shawn.guo@linaro.org> wrote:

>> I don't see mx28 dts support in mainline yet.
>>
> I will be soon on arm-soc and in turn linux-next.

I will be glad to help on the conversion of mxs into dt.

However, I think it is a bit early to block acceptance of non-DT code
for mxs especially because there is no mx28 nor mx28evk in mainline
yet.
Shawn Guo April 6, 2012, 2:31 a.m. UTC | #7
On Thu, Apr 05, 2012 at 01:12:03PM -0300, Fabio Estevam wrote:
...
> However, I think it is a bit early to block acceptance of non-DT code
> for mxs especially because there is no mx28 nor mx28evk in mainline
> yet.

I have to do that to motivate people to add DT support for the drivers
they submit from the beginning.

Also I do not see much point to keep patching board files which are
to be removed.
Shawn Guo April 6, 2012, 3:35 a.m. UTC | #8
On Thu, Apr 05, 2012 at 08:08:52PM -0700, Subodh Nijsure wrote:
> 
> Hello Shawn,
> 
> You also have to consider that folks who are using MX28 based design might be just now shifting from freescale provided 2.6.35 SDK to the latest 3.4-rcX train on their own (my case). To make them wait for 3.5 to get all the iMX driver seems like hard thing to do.
>  
I'm pretty sure that even 3.5 will not have all the imx28 drivers
support.  Also freezing board file update does not block anyone adding
new driver support in any way.  I do not understand what your argument
is.

Please note, the gpmi nand mx28evk board patch was not accept because
it has pin confliction issue to be resolved.
Fabio Estevam April 6, 2012, 5:49 a.m. UTC | #9
On Thu, Apr 5, 2012 at 11:31 PM, Shawn Guo <shawn.guo@linaro.org> wrote:

> I have to do that to motivate people to add DT support for the drivers
> they submit from the beginning.

Understand your point for new drivers.

If you take the GPMI driver for example: it has been available for a
long time and there is no board using it in mainline.

So how can people easily test it and find bugs with this driver?
Patching their own trees themselves? Sam Gandhi did extensive tests on
NAND and found some DMA issues with it.

If we could have mx28evk supporting GPMI driver today it would
estimulate people to use it and more issues can be found and fixed.

Waiting for DT support to be in place is just blocking the progress for mx28.

Please note that right now there is no dt support for mx28 in mainline.

If what blocks this patch "ARM: mxs/mx28evk: add GPMI-NAND device" to
be accepted is the pin mux conflict, that would be easy to fix and
Huang could do a v5 if you agree.

> Also I do not see much point to keep patching board files which are
> to be removed.

I understand your point, but again, right now there is no dt support,
so the only mechanism we have to register driver is via board files
for mx28.

So it would be nice if you could still accept patches for mx28 while
mx28 dt does not show up in mainline.
Shawn Guo April 6, 2012, 6:53 a.m. UTC | #10
On Fri, Apr 06, 2012 at 02:49:05AM -0300, Fabio Estevam wrote:
> On Thu, Apr 5, 2012 at 11:31 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> 
> > I have to do that to motivate people to add DT support for the drivers
> > they submit from the beginning.
> 
> Understand your point for new drivers.
> 
> If you take the GPMI driver for example: it has been available for a
> long time and there is no board using it in mainline.
> 
> So how can people easily test it and find bugs with this driver?
> Patching their own trees themselves? Sam Gandhi did extensive tests on
> NAND and found some DMA issues with it.
> 
Look, people can still test and find issue with no board in mainline
using it.

> If we could have mx28evk supporting GPMI driver today it would
> estimulate people to use it and more issues can be found and fixed.
> 
> Waiting for DT support to be in place is just blocking the progress for mx28.
> 
Please tell me what are exactly being blocked there.

> Please note that right now there is no dt support for mx28 in mainline.
> 
There are still no spi-mxs driver in mainline, why are you sending me
spi board file patches?

> If what blocks this patch "ARM: mxs/mx28evk: add GPMI-NAND device" to
> be accepted is the pin mux conflict, that would be easy to fix and
> Huang could do a v5 if you agree.
> 
We had the discussion and agreed that migrating to pinctrl subsystem is
the right solution.  I will be more than happy to accept if someone
send me mxs pinctrl support rather than any "easy" fix.

> > Also I do not see much point to keep patching board files which are
> > to be removed.
> 
> I understand your point, but again, right now there is no dt support,
> so the only mechanism we have to register driver is via board files
> for mx28.
> 
> So it would be nice if you could still accept patches for mx28 while
> mx28 dt does not show up in mainline.

I could accept your spi board file patch when spi-mxs driver hit
mainline while mx28 dt does not.
Fabio Estevam April 6, 2012, 1:16 p.m. UTC | #11
On Fri, Apr 6, 2012 at 3:53 AM, Shawn Guo <shawn.guo@linaro.org> wrote:

> Look, people can still test and find issue with no board in mainline
> using it.

Sure they can, then you need to assume that everyone who uses the
kernel is a kernel developer, which is not the case.

Please think on a user's perspective too, where people want just to
get the kernel from kernel.org and use it without doing any hacks to
it.

>> If we could have mx28evk supporting GPMI driver today it would
>> estimulate people to use it and more issues can be found and fixed.
>>
>> Waiting for DT support to be in place is just blocking the progress for mx28.
>>
> Please tell me what are exactly being blocked there.

The whole point of this discussion started when you stated the reasons
for not applying this patch of the thread:

"1) The pin confliction between gpmi and lcdif remains.
2) I intend to freeze the board file updates, as we are on the way to
  device tree."

1) is easily understood and can be fixed

2) is what we have been discussing.

So not accepting patches to mx28 board files while mx28 dt is not in
place will at least block: GPMI and SPI for mx28.

>> Please note that right now there is no dt support for mx28 in mainline.
>
> There are still no spi-mxs driver in mainline, why are you sending me
> spi board file patches?

I have it locally and I was ready to submit it till I read this
thread. I haven't made the mxs spi driver dt aware.

Since there is no dt support for mx28 yet, I cannot submit it now, so
this will have to wait.

It is like the "chicken-and-egg problem".

> I could accept your spi board file patch when spi-mxs driver hit
> mainline while mx28 dt does not.

Excellent, that's good news and we come to an agreement  :-) Thanks!
Shawn Guo April 6, 2012, 1:46 p.m. UTC | #12
On Fri, Apr 06, 2012 at 10:16:48AM -0300, Fabio Estevam wrote:
> On Fri, Apr 6, 2012 at 3:53 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
...
> > I could accept your spi board file patch when spi-mxs driver hit
> > mainline while mx28 dt does not.
> 
> Excellent, that's good news and we come to an agreement  :-) Thanks!

I'm pretty sure that imx28 dt patch from Dong Aisheng will hit mainline
with v3.5-rc1, which could be the earliest time for spi-mxs to hit
mainline.  In that case, I do not have any reason to take your board
file patch from there, so what's point of the while argument?
Fabio Estevam April 6, 2012, 1:56 p.m. UTC | #13
On Fri, Apr 6, 2012 at 10:46 AM, Shawn Guo <shawn.guo@linaro.org> wrote:

> I'm pretty sure that imx28 dt patch from Dong Aisheng will hit mainline
> with v3.5-rc1, which could be the earliest time for spi-mxs to hit
> mainline.  In that case, I do not have any reason to take your board
> file patch from there, so what's point of the while argument?

Ok, will submit the mxs spi driver (non-dt aware) next week when I
come back to the office.

You can drop all of the arch mxs spi patches I sent you
Marek Vasut April 18, 2012, 9:46 p.m. UTC | #14
Dear Fabio Estevam,

> On Thu, Apr 5, 2012 at 11:31 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > I have to do that to motivate people to add DT support for the drivers
> > they submit from the beginning.
> 
> Understand your point for new drivers.
> 
> If you take the GPMI driver for example: it has been available for a
> long time and there is no board using it in mainline.
> 
> So how can people easily test it and find bugs with this driver?
> Patching their own trees themselves? Sam Gandhi did extensive tests on
> NAND and found some DMA issues with it.
> 
> If we could have mx28evk supporting GPMI driver today it would
> estimulate people to use it and more issues can be found and fixed.
> 
> Waiting for DT support to be in place is just blocking the progress for
> mx28.

Sadly, I have to agree. I'm not against DT, but blocking it now is bogus.

> Please note that right now there is no dt support for mx28 in mainline.
> 
> If what blocks this patch "ARM: mxs/mx28evk: add GPMI-NAND device" to
> be accepted is the pin mux conflict, that would be easy to fix and
> Huang could do a v5 if you agree.
> 
> > Also I do not see much point to keep patching board files which are
> > to be removed.
> 
> I understand your point, but again, right now there is no dt support,
> so the only mechanism we have to register driver is via board files
> for mx28.
> 
> So it would be nice if you could still accept patches for mx28 while
> mx28 dt does not show up in mainline.
> 

Agreed


Best regards,
Marek Vasut
diff mbox

Patch

diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index 8bf202a..f76710e 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -47,6 +47,7 @@  config MACH_MX28EVK
 	select MXS_HAVE_PLATFORM_AUART
 	select MXS_HAVE_PLATFORM_FEC
 	select MXS_HAVE_PLATFORM_FLEXCAN
+	select MXS_HAVE_PLATFORM_GPMI_NAND
 	select MXS_HAVE_PLATFORM_MXS_MMC
 	select MXS_HAVE_PLATFORM_MXSFB
 	select MXS_OCOTP
diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
index eaaf6ff..d26bc22 100644
--- a/arch/arm/mach-mxs/mach-mx28evk.c
+++ b/arch/arm/mach-mxs/mach-mx28evk.c
@@ -314,6 +314,41 @@  static const struct flexcan_platform_data
 	}
 };
 
+/* gpmi-nand */
+static iomux_cfg_t mx28evk_gpmi_nand_pads[] = {
+	MX28_PAD_GPMI_D00__GPMI_D0 | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_D01__GPMI_D1 | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_D02__GPMI_D2 | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_D03__GPMI_D3 | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_D04__GPMI_D4 | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_D05__GPMI_D5 | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_D06__GPMI_D6 | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_D07__GPMI_D7 | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_ALE__GPMI_ALE | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_CLE__GPMI_CLE | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_CE0N__GPMI_CE0N | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_CE1N__GPMI_CE1N | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_RDY0__GPMI_READY0 | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_RDY1__GPMI_READY1 | MXS_PAD_CTRL,
+	MX28_PAD_GPMI_RDN__GPMI_RDN | MXS_PAD_CTRL_12MA,
+	MX28_PAD_GPMI_WRN__GPMI_WRN | MXS_PAD_CTRL_12MA,
+	MX28_PAD_GPMI_RESETN__GPMI_RESETN | MXS_PAD_CTRL_12MA,
+};
+
+static int mx28evk_gpmi_nand_platform_init(void)
+{
+	return mxs_iomux_setup_multiple_pads(mx28evk_gpmi_nand_pads,
+				ARRAY_SIZE(mx28evk_gpmi_nand_pads));
+}
+
+static const struct gpmi_nand_platform_data
+mx28evk_gpmi_nand_data __initconst = {
+	.platform_init		= mx28evk_gpmi_nand_platform_init,
+	.min_prop_delay_in_ns	= 5,
+	.max_prop_delay_in_ns	= 9,
+	.max_chip_count		= 1,
+};
+
 /* mxsfb (lcdif) */
 static struct fb_videomode mx28evk_video_modes[] = {
 	{
@@ -390,6 +425,7 @@  static void __init mx28evk_init(void)
 	else
 		gpio_set_value(MX28EVK_BL_ENABLE, 1);
 
+	mx28_add_gpmi_nand(&mx28evk_gpmi_nand_data);
 	mx28_add_mxsfb(&mx28evk_mxsfb_pdata);
 
 	/* power on mmc slot by writing 0 to the gpio */