| Message ID | 1457654203-20856-2-git-send-email-fcooper@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Franklin, On 11/03/16 01:56, Franklin S Cooper Jr wrote: > The dma channel information is located within the GPMC node which is the > NAND's parent node. The NAND driver requires a handle to the GPMC's dev > to properly parse the DMA properties. Therefore, set the NAND's parent dev > to the GPMC's dev so it can be referenced within the driver. > > Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> > --- > Version 4 changes: > Instead of storing the GPMC dev in a new property simply grab a reference > to it and set omap2-nand's dev.parent to it. > > arch/arm/mach-omap2/gpmc-nand.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c > index 72918c4..77e453c 100644 > --- a/arch/arm/mach-omap2/gpmc-nand.c > +++ b/arch/arm/mach-omap2/gpmc-nand.c > @@ -15,6 +15,7 @@ > #include <linux/omap-gpmc.h> > #include <linux/mtd/nand.h> > #include <linux/platform_data/mtd-nand-omap2.h> > +#include <linux/of_platform.h> > > #include <asm/mach/flash.h> > > @@ -77,6 +78,9 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data, > int err = 0; > struct gpmc_settings s; > struct platform_device *pdev; > + struct platform_device *gpmc_dev; > + struct device_node *gpmc_node; > + > struct resource gpmc_nand_res[] = { > { .flags = IORESOURCE_MEM, }, > { .flags = IORESOURCE_IRQ, }, > @@ -134,8 +138,18 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data, > if (pdev) { > err = platform_device_add_resources(pdev, gpmc_nand_res, > ARRAY_SIZE(gpmc_nand_res)); > - if (!err) > + if (!err) { > pdev->dev.platform_data = gpmc_nand_data; > + > + gpmc_node = of_get_parent(gpmc_nand_data->of_node); I'm afraid that we can't use this method as we want to restrict gpmc_nand_init() to non-DT boots. > + > + if (gpmc_node) { > + gpmc_dev = of_find_device_by_node(gpmc_node); > + > + if (gpmc_dev) > + pdev->dev.parent = &gpmc_dev->dev; > + } > + } > } else { > err = -ENOMEM; > } > cheers, -roger -- 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
On 03/11/2016 07:52 AM, Roger Quadros wrote: > Franklin, > > On 11/03/16 01:56, Franklin S Cooper Jr wrote: >> The dma channel information is located within the GPMC node which is the >> NAND's parent node. The NAND driver requires a handle to the GPMC's dev >> to properly parse the DMA properties. Therefore, set the NAND's parent dev >> to the GPMC's dev so it can be referenced within the driver. >> >> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> >> --- >> Version 4 changes: >> Instead of storing the GPMC dev in a new property simply grab a reference >> to it and set omap2-nand's dev.parent to it. >> >> arch/arm/mach-omap2/gpmc-nand.c | 16 +++++++++++++++- >> 1 file changed, 15 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c >> index 72918c4..77e453c 100644 >> --- a/arch/arm/mach-omap2/gpmc-nand.c >> +++ b/arch/arm/mach-omap2/gpmc-nand.c >> @@ -15,6 +15,7 @@ >> #include <linux/omap-gpmc.h> >> #include <linux/mtd/nand.h> >> #include <linux/platform_data/mtd-nand-omap2.h> >> +#include <linux/of_platform.h> >> >> #include <asm/mach/flash.h> >> >> @@ -77,6 +78,9 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data, >> int err = 0; >> struct gpmc_settings s; >> struct platform_device *pdev; >> + struct platform_device *gpmc_dev; >> + struct device_node *gpmc_node; >> + >> struct resource gpmc_nand_res[] = { >> { .flags = IORESOURCE_MEM, }, >> { .flags = IORESOURCE_IRQ, }, >> @@ -134,8 +138,18 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data, >> if (pdev) { >> err = platform_device_add_resources(pdev, gpmc_nand_res, >> ARRAY_SIZE(gpmc_nand_res)); >> - if (!err) >> + if (!err) { >> pdev->dev.platform_data = gpmc_nand_data; >> + >> + gpmc_node = of_get_parent(gpmc_nand_data->of_node); > I'm afraid that we can't use this method as we want to restrict > gpmc_nand_init() to non-DT boots. The only users of the parent GPMC driver are already using DT. The gpmc_probe_nand_child function in the GPMC driver which calls gpmc_nand_init is already DT only. The only other caller to gpmc_nand_init is board-flash.c. The driver doesn't utilize xfer_type to even switch to any other modes including DMA prefetch mode. Looking at it closer there isn't a dev from some kind of parent for me to pass along. Board_nand_init which calls gpmc_nand_init just takes raw NAND values with no relation to its parent. With that being said are you ok with leaving it as is? > >> + >> + if (gpmc_node) { >> + gpmc_dev = of_find_device_by_node(gpmc_node); >> + >> + if (gpmc_dev) >> + pdev->dev.parent = &gpmc_dev->dev; >> + } >> + } >> } else { >> err = -ENOMEM; >> } >> > cheers, > -roger -- 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
Franklin, Tony, On 11/03/16 17:39, Franklin S Cooper Jr. wrote: > > > On 03/11/2016 07:52 AM, Roger Quadros wrote: >> Franklin, >> >> On 11/03/16 01:56, Franklin S Cooper Jr wrote: >>> The dma channel information is located within the GPMC node which is the >>> NAND's parent node. The NAND driver requires a handle to the GPMC's dev >>> to properly parse the DMA properties. Therefore, set the NAND's parent dev >>> to the GPMC's dev so it can be referenced within the driver. >>> >>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> >>> --- >>> Version 4 changes: >>> Instead of storing the GPMC dev in a new property simply grab a reference >>> to it and set omap2-nand's dev.parent to it. >>> >>> arch/arm/mach-omap2/gpmc-nand.c | 16 +++++++++++++++- >>> 1 file changed, 15 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c >>> index 72918c4..77e453c 100644 >>> --- a/arch/arm/mach-omap2/gpmc-nand.c >>> +++ b/arch/arm/mach-omap2/gpmc-nand.c >>> @@ -15,6 +15,7 @@ >>> #include <linux/omap-gpmc.h> >>> #include <linux/mtd/nand.h> >>> #include <linux/platform_data/mtd-nand-omap2.h> >>> +#include <linux/of_platform.h> >>> >>> #include <asm/mach/flash.h> >>> >>> @@ -77,6 +78,9 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data, >>> int err = 0; >>> struct gpmc_settings s; >>> struct platform_device *pdev; >>> + struct platform_device *gpmc_dev; >>> + struct device_node *gpmc_node; >>> + >>> struct resource gpmc_nand_res[] = { >>> { .flags = IORESOURCE_MEM, }, >>> { .flags = IORESOURCE_IRQ, }, >>> @@ -134,8 +138,18 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data, >>> if (pdev) { >>> err = platform_device_add_resources(pdev, gpmc_nand_res, >>> ARRAY_SIZE(gpmc_nand_res)); >>> - if (!err) >>> + if (!err) { >>> pdev->dev.platform_data = gpmc_nand_data; >>> + >>> + gpmc_node = of_get_parent(gpmc_nand_data->of_node); >> I'm afraid that we can't use this method as we want to restrict >> gpmc_nand_init() to non-DT boots. > > The only users of the parent GPMC driver are already using > DT. The gpmc_probe_nand_child function in the GPMC driver > which calls gpmc_nand_init is already DT only. > > The only other caller to gpmc_nand_init is board-flash.c. > The driver doesn't utilize xfer_type to even switch to any > other modes including DMA prefetch mode. Looking at it > closer there isn't a dev from some kind of parent for me to > pass along. Board_nand_init which calls gpmc_nand_init just > takes raw NAND values with no relation to its parent. > > > With that being said are you ok with leaving it as is? I think it is OK to assume that NAND DMA won't work with legacy boot. Tony any objections? I see that board-ldp.c is the only legacy user of NAND. When can we drop support for it? I want to keep gpmc_nand_init() as it is and don't want to add any device tree specific calls here. So I think it is still best if you rebase your series on top of [1] so that you are assured NAND controller's parent is the GPMC device in the DT case without requiring the $subject patch. [1] https://lkml.org/lkml/2016/2/19/599 The series has been Acked by all maintainers and will go in v4.6 cheers, -roger -- 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
* Roger Quadros <rogerq@ti.com> [160314 02:16]: > > I think it is OK to assume that NAND DMA won't work with legacy boot. > Tony any objections? I see that board-ldp.c is the only legacy user > of NAND. When can we drop support for it? Sorry for the delay, just nocied this one. Let's not touch the board-*.c files until we just remove them except for fixes. It's OK to assume legacy booting does not support DMA. Regards, Tony -- 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
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c index 72918c4..77e453c 100644 --- a/arch/arm/mach-omap2/gpmc-nand.c +++ b/arch/arm/mach-omap2/gpmc-nand.c @@ -15,6 +15,7 @@ #include <linux/omap-gpmc.h> #include <linux/mtd/nand.h> #include <linux/platform_data/mtd-nand-omap2.h> +#include <linux/of_platform.h> #include <asm/mach/flash.h> @@ -77,6 +78,9 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data, int err = 0; struct gpmc_settings s; struct platform_device *pdev; + struct platform_device *gpmc_dev; + struct device_node *gpmc_node; + struct resource gpmc_nand_res[] = { { .flags = IORESOURCE_MEM, }, { .flags = IORESOURCE_IRQ, }, @@ -134,8 +138,18 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data, if (pdev) { err = platform_device_add_resources(pdev, gpmc_nand_res, ARRAY_SIZE(gpmc_nand_res)); - if (!err) + if (!err) { pdev->dev.platform_data = gpmc_nand_data; + + gpmc_node = of_get_parent(gpmc_nand_data->of_node); + + if (gpmc_node) { + gpmc_dev = of_find_device_by_node(gpmc_node); + + if (gpmc_dev) + pdev->dev.parent = &gpmc_dev->dev; + } + } } else { err = -ENOMEM; }
The dma channel information is located within the GPMC node which is the NAND's parent node. The NAND driver requires a handle to the GPMC's dev to properly parse the DMA properties. Therefore, set the NAND's parent dev to the GPMC's dev so it can be referenced within the driver. Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> --- Version 4 changes: Instead of storing the GPMC dev in a new property simply grab a reference to it and set omap2-nand's dev.parent to it. arch/arm/mach-omap2/gpmc-nand.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)