From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5294E7E4.3060600@ti.com> Date: Tue, 26 Nov 2013 13:26:44 -0500 From: Santosh Shilimkar MIME-Version: 1.0 To: Sekhar Nori Subject: Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver References: <1384187188-5776-1-git-send-email-ivan.khoronzhuk@ti.com>, <1384187188-5776-8-git-send-email-ivan.khoronzhuk@ti.com> <4F5844B3A985794BA902E12C070812375F8D2E@DNCE04.ent.ti.com> <52944BD3.90105@ti.com> <5294B8C4.6040803@ti.com> <5294D8AD.5030106@ti.com> In-Reply-To: <5294D8AD.5030106@ti.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Mark Rutland , "devicetree@vger.kernel.org" , "Strashko, Grygorii" , Russell King , Pawel Moll , Stephen Warren , Ian Campbell , Kumar Gala , Rob Herring , "linux-kernel@vger.kernel.org" , "linux-mtd@lists.infradead.org" , Rob Landley , "Khoronzhuk, Ivan" , "linux-arm-kernel@lists.infradead.org" List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tuesday 26 November 2013 12:21 PM, Sekhar Nori wrote: > On 11/26/2013 8:35 PM, Santosh Shilimkar wrote: >> On Tuesday 26 November 2013 02:20 AM, Sekhar Nori wrote: >>> On Monday 11 November 2013 10:36 PM, Khoronzhuk, Ivan wrote: >>>> Add new AEMIF driver for EMIF16 davinci controller. The EMIF16 module >>>> is intended to provide a glue-less interface to a variety of >>>> asynchronous memory devices like ASRA M, NOR and NAND memory. A total >>>> of 256M bytes of any of these memories can be accessed at any given >>>> time via four chip selects with 64M byte access per chip select. >>>> >>>> Synchronous memories such as DDR1 SD RAM, SDR SDRAM and Mobile SDR >>>> are not supported. >>>> >>>> See http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf >>>> >>>> Signed-off-by: Ivan Khoronzhuk >>>> --- >> >> [...] >> >>>> +static int davinci_aemif_probe(struct platform_device *pdev) >>>> +{ >>>> + int ret = -ENODEV, i; >>>> + struct resource *res; >>>> + struct device *dev = &pdev->dev; >>>> + struct device_node *np = dev->of_node; >>>> + >>>> + if (np == NULL) >>>> + return 0; >>>> + >>>> + if (aemif) { >>>> + dev_err(dev, "davinci_aemif driver is in use currently\n"); >>>> + return -EBUSY; >>>> + } >>> >>> Why expressly prevent multiple AEMIF devices? Its entirely conceivable >>> to have two memories like NAND and NOR flash connect to two different >>> AEMIF interfaces. >>> >> Ivan wanted me to clarify the Keystone hardware which supports >> 1 instance of controller with 4 CS. That allows already four >> devices to be connected. Currently NAND and NOR are connected on it >> and two more slots are free. >> >> Since driver support what hardware is, lets not build a driver for >> hardware which don't exist. And if at all such a support would be >> needed in future, we can always add it. > > I understand the lack of hardware part, but its common to write the > driver such that it can handle multiple instances. Is there any gain on > current hardware because of this check? From what I am hearing, the code > in question wont be exercised at all. So why go all the way and add it > in first place? > Fair enough. The check can be dropped. Regards, Santosh From mboxrd@z Thu Jan 1 00:00:00 1970 From: santosh.shilimkar@ti.com (Santosh Shilimkar) Date: Tue, 26 Nov 2013 13:26:44 -0500 Subject: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver In-Reply-To: <5294D8AD.5030106@ti.com> References: <1384187188-5776-1-git-send-email-ivan.khoronzhuk@ti.com>, <1384187188-5776-8-git-send-email-ivan.khoronzhuk@ti.com> <4F5844B3A985794BA902E12C070812375F8D2E@DNCE04.ent.ti.com> <52944BD3.90105@ti.com> <5294B8C4.6040803@ti.com> <5294D8AD.5030106@ti.com> Message-ID: <5294E7E4.3060600@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tuesday 26 November 2013 12:21 PM, Sekhar Nori wrote: > On 11/26/2013 8:35 PM, Santosh Shilimkar wrote: >> On Tuesday 26 November 2013 02:20 AM, Sekhar Nori wrote: >>> On Monday 11 November 2013 10:36 PM, Khoronzhuk, Ivan wrote: >>>> Add new AEMIF driver for EMIF16 davinci controller. The EMIF16 module >>>> is intended to provide a glue-less interface to a variety of >>>> asynchronous memory devices like ASRA M, NOR and NAND memory. A total >>>> of 256M bytes of any of these memories can be accessed at any given >>>> time via four chip selects with 64M byte access per chip select. >>>> >>>> Synchronous memories such as DDR1 SD RAM, SDR SDRAM and Mobile SDR >>>> are not supported. >>>> >>>> See http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf >>>> >>>> Signed-off-by: Ivan Khoronzhuk >>>> --- >> >> [...] >> >>>> +static int davinci_aemif_probe(struct platform_device *pdev) >>>> +{ >>>> + int ret = -ENODEV, i; >>>> + struct resource *res; >>>> + struct device *dev = &pdev->dev; >>>> + struct device_node *np = dev->of_node; >>>> + >>>> + if (np == NULL) >>>> + return 0; >>>> + >>>> + if (aemif) { >>>> + dev_err(dev, "davinci_aemif driver is in use currently\n"); >>>> + return -EBUSY; >>>> + } >>> >>> Why expressly prevent multiple AEMIF devices? Its entirely conceivable >>> to have two memories like NAND and NOR flash connect to two different >>> AEMIF interfaces. >>> >> Ivan wanted me to clarify the Keystone hardware which supports >> 1 instance of controller with 4 CS. That allows already four >> devices to be connected. Currently NAND and NOR are connected on it >> and two more slots are free. >> >> Since driver support what hardware is, lets not build a driver for >> hardware which don't exist. And if at all such a support would be >> needed in future, we can always add it. > > I understand the lack of hardware part, but its common to write the > driver such that it can handle multiple instances. Is there any gain on > current hardware because of this check? From what I am hearing, the code > in question wont be exercised at all. So why go all the way and add it > in first place? > Fair enough. The check can be dropped. Regards, Santosh From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Shilimkar Subject: Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver Date: Tue, 26 Nov 2013 13:26:44 -0500 Message-ID: <5294E7E4.3060600@ti.com> References: <1384187188-5776-1-git-send-email-ivan.khoronzhuk@ti.com>, <1384187188-5776-8-git-send-email-ivan.khoronzhuk@ti.com> <4F5844B3A985794BA902E12C070812375F8D2E@DNCE04.ent.ti.com> <52944BD3.90105@ti.com> <5294B8C4.6040803@ti.com> <5294D8AD.5030106@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5294D8AD.5030106-l0cyMroinI0@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Sekhar Nori Cc: "Khoronzhuk, Ivan" , Rob Landley , Russell King , Mark Rutland , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "Strashko, Grygorii" , Pawel Moll , Stephen Warren , Ian Campbell , Kumar Gala , Rob Herring , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org On Tuesday 26 November 2013 12:21 PM, Sekhar Nori wrote: > On 11/26/2013 8:35 PM, Santosh Shilimkar wrote: >> On Tuesday 26 November 2013 02:20 AM, Sekhar Nori wrote: >>> On Monday 11 November 2013 10:36 PM, Khoronzhuk, Ivan wrote: >>>> Add new AEMIF driver for EMIF16 davinci controller. The EMIF16 module >>>> is intended to provide a glue-less interface to a variety of >>>> asynchronous memory devices like ASRA M, NOR and NAND memory. A total >>>> of 256M bytes of any of these memories can be accessed at any given >>>> time via four chip selects with 64M byte access per chip select. >>>> >>>> Synchronous memories such as DDR1 SD RAM, SDR SDRAM and Mobile SDR >>>> are not supported. >>>> >>>> See http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf >>>> >>>> Signed-off-by: Ivan Khoronzhuk >>>> --- >> >> [...] >> >>>> +static int davinci_aemif_probe(struct platform_device *pdev) >>>> +{ >>>> + int ret = -ENODEV, i; >>>> + struct resource *res; >>>> + struct device *dev = &pdev->dev; >>>> + struct device_node *np = dev->of_node; >>>> + >>>> + if (np == NULL) >>>> + return 0; >>>> + >>>> + if (aemif) { >>>> + dev_err(dev, "davinci_aemif driver is in use currently\n"); >>>> + return -EBUSY; >>>> + } >>> >>> Why expressly prevent multiple AEMIF devices? Its entirely conceivable >>> to have two memories like NAND and NOR flash connect to two different >>> AEMIF interfaces. >>> >> Ivan wanted me to clarify the Keystone hardware which supports >> 1 instance of controller with 4 CS. That allows already four >> devices to be connected. Currently NAND and NOR are connected on it >> and two more slots are free. >> >> Since driver support what hardware is, lets not build a driver for >> hardware which don't exist. And if at all such a support would be >> needed in future, we can always add it. > > I understand the lack of hardware part, but its common to write the > driver such that it can handle multiple instances. Is there any gain on > current hardware because of this check? From what I am hearing, the code > in question wont be exercised at all. So why go all the way and add it > in first place? > Fair enough. The check can be dropped. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932449Ab3KZS13 (ORCPT ); Tue, 26 Nov 2013 13:27:29 -0500 Received: from comal.ext.ti.com ([198.47.26.152]:47418 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752492Ab3KZS10 (ORCPT ); Tue, 26 Nov 2013 13:27:26 -0500 Message-ID: <5294E7E4.3060600@ti.com> Date: Tue, 26 Nov 2013 13:26:44 -0500 From: Santosh Shilimkar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Sekhar Nori CC: "Khoronzhuk, Ivan" , Rob Landley , Russell King , Mark Rutland , "devicetree@vger.kernel.org" , "Strashko, Grygorii" , Pawel Moll , Stephen Warren , Ian Campbell , Kumar Gala , Rob Herring , "linux-kernel@vger.kernel.org" , "linux-mtd@lists.infradead.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver References: <1384187188-5776-1-git-send-email-ivan.khoronzhuk@ti.com>, <1384187188-5776-8-git-send-email-ivan.khoronzhuk@ti.com> <4F5844B3A985794BA902E12C070812375F8D2E@DNCE04.ent.ti.com> <52944BD3.90105@ti.com> <5294B8C4.6040803@ti.com> <5294D8AD.5030106@ti.com> In-Reply-To: <5294D8AD.5030106@ti.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 26 November 2013 12:21 PM, Sekhar Nori wrote: > On 11/26/2013 8:35 PM, Santosh Shilimkar wrote: >> On Tuesday 26 November 2013 02:20 AM, Sekhar Nori wrote: >>> On Monday 11 November 2013 10:36 PM, Khoronzhuk, Ivan wrote: >>>> Add new AEMIF driver for EMIF16 davinci controller. The EMIF16 module >>>> is intended to provide a glue-less interface to a variety of >>>> asynchronous memory devices like ASRA M, NOR and NAND memory. A total >>>> of 256M bytes of any of these memories can be accessed at any given >>>> time via four chip selects with 64M byte access per chip select. >>>> >>>> Synchronous memories such as DDR1 SD RAM, SDR SDRAM and Mobile SDR >>>> are not supported. >>>> >>>> See http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf >>>> >>>> Signed-off-by: Ivan Khoronzhuk >>>> --- >> >> [...] >> >>>> +static int davinci_aemif_probe(struct platform_device *pdev) >>>> +{ >>>> + int ret = -ENODEV, i; >>>> + struct resource *res; >>>> + struct device *dev = &pdev->dev; >>>> + struct device_node *np = dev->of_node; >>>> + >>>> + if (np == NULL) >>>> + return 0; >>>> + >>>> + if (aemif) { >>>> + dev_err(dev, "davinci_aemif driver is in use currently\n"); >>>> + return -EBUSY; >>>> + } >>> >>> Why expressly prevent multiple AEMIF devices? Its entirely conceivable >>> to have two memories like NAND and NOR flash connect to two different >>> AEMIF interfaces. >>> >> Ivan wanted me to clarify the Keystone hardware which supports >> 1 instance of controller with 4 CS. That allows already four >> devices to be connected. Currently NAND and NOR are connected on it >> and two more slots are free. >> >> Since driver support what hardware is, lets not build a driver for >> hardware which don't exist. And if at all such a support would be >> needed in future, we can always add it. > > I understand the lack of hardware part, but its common to write the > driver such that it can handle multiple instances. Is there any gain on > current hardware because of this check? From what I am hearing, the code > in question wont be exercised at all. So why go all the way and add it > in first place? > Fair enough. The check can be dropped. Regards, Santosh