From: "Franklin S Cooper Jr." <fcooper@ti.com>
To: Roger Quadros <rogerq@ti.com>
Cc: <nsekhar@ti.com>, <dwmw2@infradead.org>,
<computersforpeace@gmail.com>, <tony@atomide.com>,
<devicetree@vger.kernel.org>, <linux-omap@vger.kernel.org>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/6] memory: omap-gpmc: Store handle to GPMC dev
Date: Thu, 10 Mar 2016 09:24:44 -0600 [thread overview]
Message-ID: <56E191BC.4070705@ti.com> (raw)
In-Reply-To: <56E19148.9060207@ti.com>
On 03/10/2016 09:22 AM, Roger Quadros wrote:
> Franklin,
>
> On 10/03/16 15:40, Franklin S Cooper Jr. wrote:
>>
>> On 03/10/2016 06:40 AM, Roger Quadros wrote:
>>> Franklin,
>>>
>>> On 10/03/16 06:07, Franklin S Cooper Jr wrote:
>>>> The dma channel information is located within the GPMC node. The NAND
>>>> driver requires a handle to the GPMC's dev to properly parse the DMA
>>>> properties. Therefore, store a handle to the dev so it can be referenced
>>>> within the NAND driver.
>>>>
>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>>> ---
>>>> drivers/memory/omap-gpmc.c | 1 +
>>>> include/linux/platform_data/mtd-nand-omap2.h | 2 ++
>>>> 2 files changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
>>>> index 6515dfc..2932d13 100644
>>>> --- a/drivers/memory/omap-gpmc.c
>>>> +++ b/drivers/memory/omap-gpmc.c
>>>> @@ -1796,6 +1796,7 @@ static int gpmc_probe_nand_child(struct platform_device *pdev,
>>>>
>>>> gpmc_nand_data->cs = val;
>>>> gpmc_nand_data->of_node = child;
>>>> + gpmc_nand_data->gpmc_dev = &pdev->dev;
>>>>
>>>> /* Detect availability of ELM module */
>>>> gpmc_nand_data->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
>>>> diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
>>>> index 090bbab..534b984 100644
>>>> --- a/include/linux/platform_data/mtd-nand-omap2.h
>>>> +++ b/include/linux/platform_data/mtd-nand-omap2.h
>>>> @@ -80,5 +80,7 @@ struct omap_nand_platform_data {
>>>> /* for passing the partitions */
>>>> struct device_node *of_node;
>>>> struct device_node *elm_of_node;
>>>> +
>>>> + struct device *gpmc_dev;
>>>> };
>>>> #endif
>>>>
>>> Why do you need this? Can't we just use dev->parent in the omap2-nand driver?
>> The omap2-nand platform_device is created by
>> platform_device_alloc. The created platform_device dev
>> parent isn't by default set to the GPMC dev. I didn't think
>> this was the right approach to manually set the parent
>> property. However, taking a look at other usages of
>> platform_device_alloc it seems this is actually pretty
>> common. If your ok with this then I can go that route.
> After my DT cleanup we no longer use platform_dev_alloc for DT cases.
> As Nand node is child of GPMC node, omap2 nand's parent is guaranteed to be the
> GPMC device.
>
> But for legacy boot we still use gpmc_nand_init() which calls platform_device_add()
> without setting pdev->parent and so it will set the parent to platform bus.
>
> Maybe we could patch gpmc_nand_init() to set NAND's parent to GPMC device?
Yup that was my plan. I'll send a rev 4 with this change and
also your comments on PATCH 2.
>
> cheers,
> -roger
WARNING: multiple messages have this Message-ID (diff)
From: "Franklin S Cooper Jr." <fcooper@ti.com>
To: Roger Quadros <rogerq@ti.com>
Cc: nsekhar@ti.com, dwmw2@infradead.org, computersforpeace@gmail.com,
tony@atomide.com, devicetree@vger.kernel.org,
linux-omap@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/6] memory: omap-gpmc: Store handle to GPMC dev
Date: Thu, 10 Mar 2016 09:24:44 -0600 [thread overview]
Message-ID: <56E191BC.4070705@ti.com> (raw)
In-Reply-To: <56E19148.9060207@ti.com>
On 03/10/2016 09:22 AM, Roger Quadros wrote:
> Franklin,
>
> On 10/03/16 15:40, Franklin S Cooper Jr. wrote:
>>
>> On 03/10/2016 06:40 AM, Roger Quadros wrote:
>>> Franklin,
>>>
>>> On 10/03/16 06:07, Franklin S Cooper Jr wrote:
>>>> The dma channel information is located within the GPMC node. The NAND
>>>> driver requires a handle to the GPMC's dev to properly parse the DMA
>>>> properties. Therefore, store a handle to the dev so it can be referenced
>>>> within the NAND driver.
>>>>
>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>>> ---
>>>> drivers/memory/omap-gpmc.c | 1 +
>>>> include/linux/platform_data/mtd-nand-omap2.h | 2 ++
>>>> 2 files changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
>>>> index 6515dfc..2932d13 100644
>>>> --- a/drivers/memory/omap-gpmc.c
>>>> +++ b/drivers/memory/omap-gpmc.c
>>>> @@ -1796,6 +1796,7 @@ static int gpmc_probe_nand_child(struct platform_device *pdev,
>>>>
>>>> gpmc_nand_data->cs = val;
>>>> gpmc_nand_data->of_node = child;
>>>> + gpmc_nand_data->gpmc_dev = &pdev->dev;
>>>>
>>>> /* Detect availability of ELM module */
>>>> gpmc_nand_data->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
>>>> diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
>>>> index 090bbab..534b984 100644
>>>> --- a/include/linux/platform_data/mtd-nand-omap2.h
>>>> +++ b/include/linux/platform_data/mtd-nand-omap2.h
>>>> @@ -80,5 +80,7 @@ struct omap_nand_platform_data {
>>>> /* for passing the partitions */
>>>> struct device_node *of_node;
>>>> struct device_node *elm_of_node;
>>>> +
>>>> + struct device *gpmc_dev;
>>>> };
>>>> #endif
>>>>
>>> Why do you need this? Can't we just use dev->parent in the omap2-nand driver?
>> The omap2-nand platform_device is created by
>> platform_device_alloc. The created platform_device dev
>> parent isn't by default set to the GPMC dev. I didn't think
>> this was the right approach to manually set the parent
>> property. However, taking a look at other usages of
>> platform_device_alloc it seems this is actually pretty
>> common. If your ok with this then I can go that route.
> After my DT cleanup we no longer use platform_dev_alloc for DT cases.
> As Nand node is child of GPMC node, omap2 nand's parent is guaranteed to be the
> GPMC device.
>
> But for legacy boot we still use gpmc_nand_init() which calls platform_device_add()
> without setting pdev->parent and so it will set the parent to platform bus.
>
> Maybe we could patch gpmc_nand_init() to set NAND's parent to GPMC device?
Yup that was my plan. I'll send a rev 4 with this change and
also your comments on PATCH 2.
>
> cheers,
> -roger
next prev parent reply other threads:[~2016-03-10 15:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 4:07 [PATCH v3 0/6] mtd: nand: Fix support for NAND DMA prefetch Franklin S Cooper Jr
2016-03-10 4:07 ` Franklin S Cooper Jr
2016-03-10 4:07 ` [PATCH v3 1/6] memory: omap-gpmc: Store handle to GPMC dev Franklin S Cooper Jr
2016-03-10 12:40 ` Roger Quadros
2016-03-10 12:40 ` Roger Quadros
2016-03-10 13:18 ` Franklin S Cooper Jr.
2016-03-10 13:18 ` Franklin S Cooper Jr.
2016-03-10 13:40 ` Franklin S Cooper Jr.
2016-03-10 13:40 ` Franklin S Cooper Jr.
2016-03-10 15:22 ` Roger Quadros
2016-03-10 15:22 ` Roger Quadros
2016-03-10 15:24 ` Franklin S Cooper Jr. [this message]
2016-03-10 15:24 ` Franklin S Cooper Jr.
2016-03-10 4:07 ` [PATCH v3 2/6] ARM: dts: am437x/am33xx: Fix GPMC dma properties Franklin S Cooper Jr
2016-03-10 12:51 ` Roger Quadros
2016-03-10 12:51 ` Roger Quadros
2016-03-10 13:21 ` Franklin S Cooper Jr.
2016-03-10 13:21 ` Franklin S Cooper Jr.
2016-03-10 4:07 ` [PATCH v3 3/6] mtd: nand: omap2: Support parsing dma channel information from DT Franklin S Cooper Jr
2016-03-10 4:07 ` Franklin S Cooper Jr
2016-03-10 4:07 ` [PATCH v3 4/6] mtd: nand: omap2: Start dma request before enabling prefetch Franklin S Cooper Jr
2016-03-10 4:07 ` [PATCH v3 5/6] mtd: nand: omap2: Fix high memory dma prefetch transfer Franklin S Cooper Jr
2016-03-10 4:07 ` [PATCH v3 6/6] ARM: OMAP2+: Update GPMC and NAND DT binding documentation Franklin S Cooper Jr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E191BC.4070705@ti.com \
--to=fcooper@ti.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=rogerq@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.