| Message ID | 1314169643-23425-5-git-send-email-b32955@freescale.com |
|---|---|
| State | Not Applicable |
| Headers | show |
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?
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.
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.
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?
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.
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.
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.
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.
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.
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.
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!
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?
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
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 --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 */
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(-)