Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On 11/27/2013 02:37 AM, Brian Norris wrote:
On Tue, Nov 26, 2013 at 01:26:44PM -0500, Santosh Shilimkar wrote:
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:
+static int davinci_aemif_probe(struct platform_device *pdev)
+{
+ int ret = -ENODEV, i;
+ struct resource *res;
+ struct device *dev = >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.
Hmm, while the sentiment expressed by Sekhar is noble (to avoid
unnecessarily constraining the driver), removing the check is not
enough. You're still using a global static variable 'aemif', and it is
important not to accidentally re-use this struct if a second device ever
becomes available. So for the current implementation, the check is
necessary IMO. If instead, you were to make 'aemif' a per-device struct
(like with platform_set_drvdata()), then you would not have this issue.
Brian
Yes, that is the plan to make it a per-device.
--
Regards,
Ivan Khoronzhuk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On 11/27/2013 02:37 AM, Brian Norris wrote:
On Tue, Nov 26, 2013 at 01:26:44PM -0500, Santosh Shilimkar wrote:
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:
+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.
Hmm, while the sentiment expressed by Sekhar is noble (to avoid
unnecessarily constraining the driver), removing the check is not
enough. You're still using a global static variable 'aemif', and it is
important not to accidentally re-use this struct if a second device ever
becomes available. So for the current implementation, the check is
necessary IMO. If instead, you were to make 'aemif' a per-device struct
(like with platform_set_drvdata()), then you would not have this issue.
Brian
Yes, that is the plan to make it a per-device.
--
Regards,
Ivan Khoronzhuk
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On Tuesday 26 November 2013 11:14 PM, ivan.khoronzhuk wrote:
>>> +static int davinci_aemif_probe(struct platform_device *pdev)
>>> +{
>>> + int ret = -ENODEV, i;
>>> + struct resource *res;
>>> + struct device *dev = >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.
>>
>
> It can be, but I'm not sure if it is needed. Currently I've not seen case
> where
> more than 2 cses were used, I mean we have 2 cs free, why do we need the
> second AEMIF
> controller?
One usual reason is pinmux constraints. Its probably not a concern on
the device you are working with right now but as devices get smaller,
functionality on pins is multiplexed to handle multiple different use cases.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On Tue, Nov 26, 2013 at 01:26:44PM -0500, Santosh Shilimkar wrote:
> 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:
> +static int davinci_aemif_probe(struct platform_device *pdev)
> +{
> + int ret = -ENODEV, i;
> + struct resource *res;
> + struct device *dev = >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.
Hmm, while the sentiment expressed by Sekhar is noble (to avoid
unnecessarily constraining the driver), removing the check is not
enough. You're still using a global static variable 'aemif', and it is
important not to accidentally re-use this struct if a second device ever
becomes available. So for the current implementation, the check is
necessary IMO. If instead, you were to make 'aemif' a per-device struct
(like with platform_set_drvdata()), then you would not have this issue.
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On 11/26/2013 08:30 PM, Santosh Shilimkar wrote:
Ivan,
On Tuesday 26 November 2013 12:44 PM, ivan.khoronzhuk wrote:
On 11/26/2013 09:20 AM, Sekhar Nori wrote:
On Monday 11 November 2013 10:36 PM, Khoronzhuk, Ivan wrote:
+static struct platform_driver davinci_aemif_driver = {
+ .probe = davinci_aemif_probe,
+ .remove = davinci_aemif_remove,
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(davinci_aemif_of_match),
+ },
+};
+
+module_platform_driver(davinci_aemif_driver);
+
+MODULE_AUTHOR("Murali Karicheri ");
Is this correct? If yes, I would have expected him to sign-off on the
patch too. If not, please drop this.
I will add sign-off
Please add you as a MODULE_AUTHOR as well since you re-wrote the
downstream driver. Ok to have both of you sign of on it.
Regards,
Santosh
Ok
--
Regards,
Ivan Khoronzhuk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On 11/26/2013 08:26 PM, Santosh Shilimkar wrote: Fair enough Ok, I will do -- Regards, Ivan Khoronzhuk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
Ivan,
On Tuesday 26 November 2013 12:44 PM, ivan.khoronzhuk wrote:
> On 11/26/2013 09:20 AM, Sekhar Nori wrote:
>> On Monday 11 November 2013 10:36 PM, Khoronzhuk, Ivan wrote:
>>> +static struct platform_driver davinci_aemif_driver = {
>>> + .probe = davinci_aemif_probe,
>>> + .remove = davinci_aemif_remove,
>>> + .driver = {
>>> + .name = DRV_NAME,
>>> + .owner = THIS_MODULE,
>>> + .of_match_table = of_match_ptr(davinci_aemif_of_match),
>>> + },
>>> +};
>>> +
>>> +module_platform_driver(davinci_aemif_driver);
>>> +
>>> +MODULE_AUTHOR("Murali Karicheri ");
>>
>> Is this correct? If yes, I would have expected him to sign-off on the
>> patch too. If not, please drop this.
>
> I will add sign-off
>
Please add you as a MODULE_AUTHOR as well since you re-wrote the
downstream driver. Ok to have both of you sign of on it.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
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 = >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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On 11/26/2013 09: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 >> --- >> drivers/memory/Kconfig | 11 ++ >> drivers/memory/Makefile|1 + >> drivers/memory/davinci-aemif.c | 415 >> >> 3 files changed, 427 insertions(+) >> create mode 100644 drivers/memory/davinci-aemif.c >> >> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig >> index 29a11db..010e75e 100644 >> --- a/drivers/memory/Kconfig >> +++ b/drivers/memory/Kconfig >> @@ -7,6 +7,17 @@ menuconfig MEMORY >> >> if MEMORY >> >> +config TI_DAVINCI_AEMIF >> + bool "Texas Instruments DaVinci AEMIF driver" > > This driver cannot be a module? If not, why not? > Yes it can be a module, I will correct it. >> + depends on (ARCH_DAVINCI || ARCH_KEYSTONE) && OF >> + help >> + This driver is for the AEMIF module available in Texas Instruments >> + SoCs. AEMIF stands for Asynchronous External Memory Interface and >> + is intended to provide a glue-less interface to a variety of >> + asynchronuous memory devices like ASRAM, NOR and NAND memory. A >> total >> + of 256M bytes of any of these memories can be accessed at a given >> + time via four chip selects with 64M byte access per chip select. >> + >> config TI_EMIF >> tristate "Texas Instruments EMIF driver" >> depends on ARCH_OMAP2PLUS >> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile >> index 969d923..af14126 100644 >> --- a/drivers/memory/Makefile >> +++ b/drivers/memory/Makefile >> @@ -5,6 +5,7 @@ >> ifeq ($(CONFIG_DDR),y) >> obj-$(CONFIG_OF) += of_memory.o >> endif >> +obj-$(CONFIG_TI_DAVINCI_AEMIF) += davinci-aemif.o >> obj-$(CONFIG_TI_EMIF) += emif.o >> obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o >> obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o >> diff --git a/drivers/memory/davinci-aemif.c b/drivers/memory/davinci-aemif.c >> new file mode 100644 >> index 000..e36b74b >> --- /dev/null >> +++ b/drivers/memory/davinci-aemif.c >> @@ -0,0 +1,415 @@ >> +/* >> + * DaVinci/Keystone AEMIF driver >> + * >> + * Copyright (C) 2010 - 2013 Texas Instruments Incorporated. >> http://www.ti.com/ >> + * Copyright (C) Heiko Schocher >> + * Copyright (C) Ivan Khoronzhuk > > Just checking: You meant Author: ? Code is already copyrighted to TI by > line above. > It will be Author: Heiko Schocher Ivan Khoronzhuk >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define TA_SHIFT 2 >> +#define RHOLD_SHIFT4 >> +#define RSTROBE_SHIFT 7 >> +#define RSETUP_SHIFT 13 >> +#define WHOLD_SHIFT17 >> +#define WSTROBE_SHIFT 20 >> +#define WSETUP_SHIFT 26 >> +#define EW_SHIFT 30 >> +#define SS_SHIFT 31 >> + >> +#define TA(x) ((x) << TA_SHIFT) >> +#define RHOLD(x) ((x) << RHOLD_SHIFT) >> +#define RSTROBE(x) ((x) << RSTROBE_SHIFT) >> +#define RSETUP(x) ((x) << RSETUP_SHIFT) >> +#define WHOLD(x) ((x) << WHOLD_SHIFT) >> +#define WSTROBE(x) ((x) << WSTROBE_SHIFT) >> +#define WSETUP(x) ((x) << WSETUP_SHIFT) >> +#define EW(x) ((x) << EW_SHIFT) >> +#define SS(x) ((x) << SS_SHIFT) >> + >> +#define ASIZE_MAX 0x1 >> +#define TA_MAX 0x3 >> +#define RHOLD_MAX 0x7 >> +#define RSTROBE_MAX0x3f >> +#define RSETUP_MAX 0xf >> +#define WHOLD_MAX 0x7 >> +#define WSTROBE_MAX0x3f >> +#define WSETUP_MAX 0xf >> +#define EW_MAX 0x1 >> +#define SS_MAX 0x1 >> +#define NUM_CS 4 >> + >> +#define TA_VAL(x) (((x) & TA(TA_MAX)) >> TA_SHIFT) >> +#define RHOLD_VAL(x) (((x) & RHOLD(RHOLD_MAX)) >> RHOLD_SHIFT) >> +#define RSTROBE_VAL(x) (((x) & RSTROBE(RSTROBE_MAX)) >> RSTROBE_SHIFT) >> +#define RSETUP_VAL(x) (((x) & RSETUP(RSETUP_MAX)) >> RSETUP_SHIFT) >> +#define WHOLD_VAL(x) (((x) & WHOLD(WHOLD_MAX)) >> WHOLD_SHIFT) >> +#define WSTROBE_VAL(x) (((x) & WSTROBE(WSTROBE_MAX)) >> WSTROBE_SHIFT) >> +#define WSETUP_VAL(x) (((x) & WSETUP(WSETUP_MAX)) >> WSETUP_SHIFT) >> +#define EW_VAL(x) (((x) & EW(EW_MAX)) >> EW_SHIFT) >>
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
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 = >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?
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
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 = >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.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
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 ivan.khoronz...@ti.com
---
[...]
+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.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
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 ivan.khoronz...@ti.com
---
[...]
+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?
Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On 11/26/2013 09: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 ivan.khoronz...@ti.com --- drivers/memory/Kconfig | 11 ++ drivers/memory/Makefile|1 + drivers/memory/davinci-aemif.c | 415 3 files changed, 427 insertions(+) create mode 100644 drivers/memory/davinci-aemif.c diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 29a11db..010e75e 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -7,6 +7,17 @@ menuconfig MEMORY if MEMORY +config TI_DAVINCI_AEMIF + bool Texas Instruments DaVinci AEMIF driver This driver cannot be a module? If not, why not? Yes it can be a module, I will correct it. + depends on (ARCH_DAVINCI || ARCH_KEYSTONE) OF + help + This driver is for the AEMIF module available in Texas Instruments + SoCs. AEMIF stands for Asynchronous External Memory Interface and + is intended to provide a glue-less interface to a variety of + asynchronuous memory devices like ASRAM, NOR and NAND memory. A total + of 256M bytes of any of these memories can be accessed at a given + time via four chip selects with 64M byte access per chip select. + config TI_EMIF tristate Texas Instruments EMIF driver depends on ARCH_OMAP2PLUS diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index 969d923..af14126 100644 --- a/drivers/memory/Makefile +++ b/drivers/memory/Makefile @@ -5,6 +5,7 @@ ifeq ($(CONFIG_DDR),y) obj-$(CONFIG_OF) += of_memory.o endif +obj-$(CONFIG_TI_DAVINCI_AEMIF) += davinci-aemif.o obj-$(CONFIG_TI_EMIF) += emif.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o diff --git a/drivers/memory/davinci-aemif.c b/drivers/memory/davinci-aemif.c new file mode 100644 index 000..e36b74b --- /dev/null +++ b/drivers/memory/davinci-aemif.c @@ -0,0 +1,415 @@ +/* + * DaVinci/Keystone AEMIF driver + * + * Copyright (C) 2010 - 2013 Texas Instruments Incorporated. http://www.ti.com/ + * Copyright (C) Heiko Schocher h...@denx.de + * Copyright (C) Ivan Khoronzhuk ivan.khoronz...@ti.com Just checking: You meant Author: ? Code is already copyrighted to TI by line above. It will be Author: Heiko Schocher h...@denx.de Ivan Khoronzhuk ivan.khoronz...@ti.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/clk.h +#include linux/err.h +#include linux/io.h +#include linux/kernel.h +#include linux/module.h +#include linux/of.h +#include linux/of_platform.h +#include linux/platform_device.h + +#define TA_SHIFT 2 +#define RHOLD_SHIFT4 +#define RSTROBE_SHIFT 7 +#define RSETUP_SHIFT 13 +#define WHOLD_SHIFT17 +#define WSTROBE_SHIFT 20 +#define WSETUP_SHIFT 26 +#define EW_SHIFT 30 +#define SS_SHIFT 31 + +#define TA(x) ((x) TA_SHIFT) +#define RHOLD(x) ((x) RHOLD_SHIFT) +#define RSTROBE(x) ((x) RSTROBE_SHIFT) +#define RSETUP(x) ((x) RSETUP_SHIFT) +#define WHOLD(x) ((x) WHOLD_SHIFT) +#define WSTROBE(x) ((x) WSTROBE_SHIFT) +#define WSETUP(x) ((x) WSETUP_SHIFT) +#define EW(x) ((x) EW_SHIFT) +#define SS(x) ((x) SS_SHIFT) + +#define ASIZE_MAX 0x1 +#define TA_MAX 0x3 +#define RHOLD_MAX 0x7 +#define RSTROBE_MAX0x3f +#define RSETUP_MAX 0xf +#define WHOLD_MAX 0x7 +#define WSTROBE_MAX0x3f +#define WSETUP_MAX 0xf +#define EW_MAX 0x1 +#define SS_MAX 0x1 +#define NUM_CS 4 + +#define TA_VAL(x) (((x) TA(TA_MAX)) TA_SHIFT) +#define RHOLD_VAL(x) (((x) RHOLD(RHOLD_MAX)) RHOLD_SHIFT) +#define RSTROBE_VAL(x) (((x) RSTROBE(RSTROBE_MAX)) RSTROBE_SHIFT) +#define RSETUP_VAL(x) (((x) RSETUP(RSETUP_MAX)) RSETUP_SHIFT) +#define WHOLD_VAL(x) (((x) WHOLD(WHOLD_MAX)) WHOLD_SHIFT) +#define WSTROBE_VAL(x) (((x) WSTROBE(WSTROBE_MAX)) WSTROBE_SHIFT) +#define WSETUP_VAL(x) (((x) WSETUP(WSETUP_MAX)) WSETUP_SHIFT) +#define EW_VAL(x) (((x) EW(EW_MAX)) EW_SHIFT) +#define SS_VAL(x) (((x) SS(SS_MAX)) SS_SHIFT) + +#define NRCSR_OFFSET 0x00 +#define
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
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 ivan.khoronz...@ti.com
---
[...]
+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 linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
Ivan,
On Tuesday 26 November 2013 12:44 PM, ivan.khoronzhuk wrote:
On 11/26/2013 09:20 AM, Sekhar Nori wrote:
On Monday 11 November 2013 10:36 PM, Khoronzhuk, Ivan wrote:
+static struct platform_driver davinci_aemif_driver = {
+ .probe = davinci_aemif_probe,
+ .remove = davinci_aemif_remove,
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(davinci_aemif_of_match),
+ },
+};
+
+module_platform_driver(davinci_aemif_driver);
+
+MODULE_AUTHOR(Murali Karicheri m-kariche...@ti.com);
Is this correct? If yes, I would have expected him to sign-off on the
patch too. If not, please drop this.
I will add sign-off
Please add you as a MODULE_AUTHOR as well since you re-wrote the
downstream driver. Ok to have both of you sign of on it.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On 11/26/2013 08:30 PM, Santosh Shilimkar wrote:
Ivan,
On Tuesday 26 November 2013 12:44 PM, ivan.khoronzhuk wrote:
On 11/26/2013 09:20 AM, Sekhar Nori wrote:
On Monday 11 November 2013 10:36 PM, Khoronzhuk, Ivan wrote:
+static struct platform_driver davinci_aemif_driver = {
+ .probe = davinci_aemif_probe,
+ .remove = davinci_aemif_remove,
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(davinci_aemif_of_match),
+ },
+};
+
+module_platform_driver(davinci_aemif_driver);
+
+MODULE_AUTHOR(Murali Karicheri m-kariche...@ti.com);
Is this correct? If yes, I would have expected him to sign-off on the
patch too. If not, please drop this.
I will add sign-off
Please add you as a MODULE_AUTHOR as well since you re-wrote the
downstream driver. Ok to have both of you sign of on it.
Regards,
Santosh
Ok
--
Regards,
Ivan Khoronzhuk
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On 11/26/2013 08:26 PM, Santosh Shilimkar wrote: Fair enough Ok, I will do -- Regards, Ivan Khoronzhuk -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On Tue, Nov 26, 2013 at 01:26:44PM -0500, Santosh Shilimkar wrote:
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:
+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.
Hmm, while the sentiment expressed by Sekhar is noble (to avoid
unnecessarily constraining the driver), removing the check is not
enough. You're still using a global static variable 'aemif', and it is
important not to accidentally re-use this struct if a second device ever
becomes available. So for the current implementation, the check is
necessary IMO. If instead, you were to make 'aemif' a per-device struct
(like with platform_set_drvdata()), then you would not have this issue.
Brian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On Tuesday 26 November 2013 11:14 PM, ivan.khoronzhuk wrote:
+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.
It can be, but I'm not sure if it is needed. Currently I've not seen case
where
more than 2 cses were used, I mean we have 2 cs free, why do we need the
second AEMIF
controller?
One usual reason is pinmux constraints. Its probably not a concern on
the device you are working with right now but as devices get smaller,
functionality on pins is multiplexed to handle multiple different use cases.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
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 > --- > drivers/memory/Kconfig | 11 ++ > drivers/memory/Makefile|1 + > drivers/memory/davinci-aemif.c | 415 > > 3 files changed, 427 insertions(+) > create mode 100644 drivers/memory/davinci-aemif.c > > diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig > index 29a11db..010e75e 100644 > --- a/drivers/memory/Kconfig > +++ b/drivers/memory/Kconfig > @@ -7,6 +7,17 @@ menuconfig MEMORY > > if MEMORY > > +config TI_DAVINCI_AEMIF > + bool "Texas Instruments DaVinci AEMIF driver" This driver cannot be a module? If not, why not? > + depends on (ARCH_DAVINCI || ARCH_KEYSTONE) && OF > + help > + This driver is for the AEMIF module available in Texas Instruments > + SoCs. AEMIF stands for Asynchronous External Memory Interface and > + is intended to provide a glue-less interface to a variety of > + asynchronuous memory devices like ASRAM, NOR and NAND memory. A > total > + of 256M bytes of any of these memories can be accessed at a given > + time via four chip selects with 64M byte access per chip select. > + > config TI_EMIF > tristate "Texas Instruments EMIF driver" > depends on ARCH_OMAP2PLUS > diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile > index 969d923..af14126 100644 > --- a/drivers/memory/Makefile > +++ b/drivers/memory/Makefile > @@ -5,6 +5,7 @@ > ifeq ($(CONFIG_DDR),y) > obj-$(CONFIG_OF) += of_memory.o > endif > +obj-$(CONFIG_TI_DAVINCI_AEMIF) += davinci-aemif.o > obj-$(CONFIG_TI_EMIF) += emif.o > obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o > obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o > diff --git a/drivers/memory/davinci-aemif.c b/drivers/memory/davinci-aemif.c > new file mode 100644 > index 000..e36b74b > --- /dev/null > +++ b/drivers/memory/davinci-aemif.c > @@ -0,0 +1,415 @@ > +/* > + * DaVinci/Keystone AEMIF driver > + * > + * Copyright (C) 2010 - 2013 Texas Instruments Incorporated. > http://www.ti.com/ > + * Copyright (C) Heiko Schocher > + * Copyright (C) Ivan Khoronzhuk Just checking: You meant Author: ? Code is already copyrighted to TI by line above. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define TA_SHIFT 2 > +#define RHOLD_SHIFT4 > +#define RSTROBE_SHIFT 7 > +#define RSETUP_SHIFT 13 > +#define WHOLD_SHIFT17 > +#define WSTROBE_SHIFT 20 > +#define WSETUP_SHIFT 26 > +#define EW_SHIFT 30 > +#define SS_SHIFT 31 > + > +#define TA(x) ((x) << TA_SHIFT) > +#define RHOLD(x) ((x) << RHOLD_SHIFT) > +#define RSTROBE(x) ((x) << RSTROBE_SHIFT) > +#define RSETUP(x) ((x) << RSETUP_SHIFT) > +#define WHOLD(x) ((x) << WHOLD_SHIFT) > +#define WSTROBE(x) ((x) << WSTROBE_SHIFT) > +#define WSETUP(x) ((x) << WSETUP_SHIFT) > +#define EW(x) ((x) << EW_SHIFT) > +#define SS(x) ((x) << SS_SHIFT) > + > +#define ASIZE_MAX 0x1 > +#define TA_MAX 0x3 > +#define RHOLD_MAX 0x7 > +#define RSTROBE_MAX0x3f > +#define RSETUP_MAX 0xf > +#define WHOLD_MAX 0x7 > +#define WSTROBE_MAX0x3f > +#define WSETUP_MAX 0xf > +#define EW_MAX 0x1 > +#define SS_MAX 0x1 > +#define NUM_CS 4 > + > +#define TA_VAL(x) (((x) & TA(TA_MAX)) >> TA_SHIFT) > +#define RHOLD_VAL(x) (((x) & RHOLD(RHOLD_MAX)) >> RHOLD_SHIFT) > +#define RSTROBE_VAL(x) (((x) & RSTROBE(RSTROBE_MAX)) >> RSTROBE_SHIFT) > +#define RSETUP_VAL(x) (((x) & RSETUP(RSETUP_MAX)) >> RSETUP_SHIFT) > +#define WHOLD_VAL(x) (((x) & WHOLD(WHOLD_MAX)) >> WHOLD_SHIFT) > +#define WSTROBE_VAL(x) (((x) & WSTROBE(WSTROBE_MAX)) >> WSTROBE_SHIFT) > +#define WSETUP_VAL(x) (((x) & WSETUP(WSETUP_MAX)) >> WSETUP_SHIFT) > +#define EW_VAL(x) (((x) & EW(EW_MAX)) >> EW_SHIFT) > +#define SS_VAL(x) (((x) & SS(SS_MAX)) >> SS_SHIFT) > + > +#define NRCSR_OFFSET 0x00 > +#define AWCCR_OFFSET 0x04 > +#define A1CR_OFFSET0x10 > + > +#define ACR_ASIZE_MASK 0x3 > +#define ACR_EW_MASKBIT(30) > +#define ACR_SS_MASKBIT(31) > +#define ASIZE_16BIT1 > + >
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
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 ivan.khoronz...@ti.com --- drivers/memory/Kconfig | 11 ++ drivers/memory/Makefile|1 + drivers/memory/davinci-aemif.c | 415 3 files changed, 427 insertions(+) create mode 100644 drivers/memory/davinci-aemif.c diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 29a11db..010e75e 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -7,6 +7,17 @@ menuconfig MEMORY if MEMORY +config TI_DAVINCI_AEMIF + bool Texas Instruments DaVinci AEMIF driver This driver cannot be a module? If not, why not? + depends on (ARCH_DAVINCI || ARCH_KEYSTONE) OF + help + This driver is for the AEMIF module available in Texas Instruments + SoCs. AEMIF stands for Asynchronous External Memory Interface and + is intended to provide a glue-less interface to a variety of + asynchronuous memory devices like ASRAM, NOR and NAND memory. A total + of 256M bytes of any of these memories can be accessed at a given + time via four chip selects with 64M byte access per chip select. + config TI_EMIF tristate Texas Instruments EMIF driver depends on ARCH_OMAP2PLUS diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index 969d923..af14126 100644 --- a/drivers/memory/Makefile +++ b/drivers/memory/Makefile @@ -5,6 +5,7 @@ ifeq ($(CONFIG_DDR),y) obj-$(CONFIG_OF) += of_memory.o endif +obj-$(CONFIG_TI_DAVINCI_AEMIF) += davinci-aemif.o obj-$(CONFIG_TI_EMIF) += emif.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o diff --git a/drivers/memory/davinci-aemif.c b/drivers/memory/davinci-aemif.c new file mode 100644 index 000..e36b74b --- /dev/null +++ b/drivers/memory/davinci-aemif.c @@ -0,0 +1,415 @@ +/* + * DaVinci/Keystone AEMIF driver + * + * Copyright (C) 2010 - 2013 Texas Instruments Incorporated. http://www.ti.com/ + * Copyright (C) Heiko Schocher h...@denx.de + * Copyright (C) Ivan Khoronzhuk ivan.khoronz...@ti.com Just checking: You meant Author: ? Code is already copyrighted to TI by line above. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/clk.h +#include linux/err.h +#include linux/io.h +#include linux/kernel.h +#include linux/module.h +#include linux/of.h +#include linux/of_platform.h +#include linux/platform_device.h + +#define TA_SHIFT 2 +#define RHOLD_SHIFT4 +#define RSTROBE_SHIFT 7 +#define RSETUP_SHIFT 13 +#define WHOLD_SHIFT17 +#define WSTROBE_SHIFT 20 +#define WSETUP_SHIFT 26 +#define EW_SHIFT 30 +#define SS_SHIFT 31 + +#define TA(x) ((x) TA_SHIFT) +#define RHOLD(x) ((x) RHOLD_SHIFT) +#define RSTROBE(x) ((x) RSTROBE_SHIFT) +#define RSETUP(x) ((x) RSETUP_SHIFT) +#define WHOLD(x) ((x) WHOLD_SHIFT) +#define WSTROBE(x) ((x) WSTROBE_SHIFT) +#define WSETUP(x) ((x) WSETUP_SHIFT) +#define EW(x) ((x) EW_SHIFT) +#define SS(x) ((x) SS_SHIFT) + +#define ASIZE_MAX 0x1 +#define TA_MAX 0x3 +#define RHOLD_MAX 0x7 +#define RSTROBE_MAX0x3f +#define RSETUP_MAX 0xf +#define WHOLD_MAX 0x7 +#define WSTROBE_MAX0x3f +#define WSETUP_MAX 0xf +#define EW_MAX 0x1 +#define SS_MAX 0x1 +#define NUM_CS 4 + +#define TA_VAL(x) (((x) TA(TA_MAX)) TA_SHIFT) +#define RHOLD_VAL(x) (((x) RHOLD(RHOLD_MAX)) RHOLD_SHIFT) +#define RSTROBE_VAL(x) (((x) RSTROBE(RSTROBE_MAX)) RSTROBE_SHIFT) +#define RSETUP_VAL(x) (((x) RSETUP(RSETUP_MAX)) RSETUP_SHIFT) +#define WHOLD_VAL(x) (((x) WHOLD(WHOLD_MAX)) WHOLD_SHIFT) +#define WSTROBE_VAL(x) (((x) WSTROBE(WSTROBE_MAX)) WSTROBE_SHIFT) +#define WSETUP_VAL(x) (((x) WSETUP(WSETUP_MAX)) WSETUP_SHIFT) +#define EW_VAL(x) (((x) EW(EW_MAX)) EW_SHIFT) +#define SS_VAL(x) (((x) SS(SS_MAX)) SS_SHIFT) + +#define NRCSR_OFFSET 0x00 +#define AWCCR_OFFSET 0x04 +#define A1CR_OFFSET0x10 + +#define ACR_ASIZE_MASK 0x3 +#define ACR_EW_MASKBIT(30) +#define ACR_SS_MASKBIT(31) +#define ASIZE_16BIT1 + +#define
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On 11/12/2013 06:08 PM, Santosh Shilimkar wrote:
> + Greg KH (drivers/memory/* patches goes through his queue)
>
> On Monday 11 November 2013 12:06 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
>> ---
>> drivers/memory/Kconfig | 11 ++
>> drivers/memory/Makefile|1 +
>> drivers/memory/davinci-aemif.c | 415
>>
>> 3 files changed, 427 insertions(+)
>> create mode 100644 drivers/memory/davinci-aemif.c
>>
>> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
>> index 29a11db..010e75e 100644
>> --- a/drivers/memory/Kconfig
>> +++ b/drivers/memory/Kconfig
>> @@ -7,6 +7,17 @@ menuconfig MEMORY
>>
>> if MEMORY
>>
>> +config TI_DAVINCI_AEMIF
> s/TI_DAVINCI_AEMIF/TI_AEMIF
>
Ok
>> + bool "Texas Instruments DaVinci AEMIF driver"
> Drop DaVinci above since its used on more SOCs.
>> + depends on (ARCH_DAVINCI || ARCH_KEYSTONE) && OF
>> + help
>> + This driver is for the AEMIF module available in Texas Instruments
>> + SoCs. AEMIF stands for Asynchronous External Memory Interface and
>> + is intended to provide a glue-less interface to a variety of
>> + asynchronuous memory devices like ASRAM, NOR and NAND memory. A
>> total
>> + of 256M bytes of any of these memories can be accessed at a given
>> + time via four chip selects with 64M byte access per chip select.
>> +
>> config TI_EMIF
>> tristate "Texas Instruments EMIF driver"
>> depends on ARCH_OMAP2PLUS
>> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
>> index 969d923..af14126 100644
>> --- a/drivers/memory/Makefile
>> +++ b/drivers/memory/Makefile
>> @@ -5,6 +5,7 @@
>> ifeq ($(CONFIG_DDR),y)
>> obj-$(CONFIG_OF) += of_memory.o
>> endif
>> +obj-$(CONFIG_TI_DAVINCI_AEMIF) += davinci-aemif.o
>
> Change this accordingly once the config is renamed.
>
Ok
>> obj-$(CONFIG_TI_EMIF) += emif.o
>> obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
>> obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
>> diff --git a/drivers/memory/davinci-aemif.c b/drivers/memory/davinci-aemif.c
>> new file mode 100644
>> index 000..e36b74b
>> --- /dev/null
>> +++ b/drivers/memory/davinci-aemif.c
>> @@ -0,0 +1,415 @@
>> +/*
>> + * DaVinci/Keystone AEMIF driver
> s/{DaVinci/Keystone}/TI
>> + *
>> + * Copyright (C) 2010 - 2013 Texas Instruments Incorporated.
>> http://www.ti.com/
>> + * Copyright (C) Heiko Schocher
>> + * Copyright (C) Ivan Khoronzhuk
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define TA_SHIFT 2
>> +#define RHOLD_SHIFT4
>> +#define RSTROBE_SHIFT 7
>> +#define RSETUP_SHIFT 13
>> +#define WHOLD_SHIFT17
>> +#define WSTROBE_SHIFT 20
>> +#define WSETUP_SHIFT 26
>> +#define EW_SHIFT 30
>> +#define SS_SHIFT 31
>> +
>> +#define TA(x) ((x) << TA_SHIFT)
>> +#define RHOLD(x) ((x) << RHOLD_SHIFT)
>> +#define RSTROBE(x) ((x) << RSTROBE_SHIFT)
>> +#define RSETUP(x) ((x) << RSETUP_SHIFT)
>> +#define WHOLD(x) ((x) << WHOLD_SHIFT)
>> +#define WSTROBE(x) ((x) << WSTROBE_SHIFT)
>> +#define WSETUP(x) ((x) << WSETUP_SHIFT)
>> +#define EW(x) ((x) << EW_SHIFT)
>> +#define SS(x) ((x) << SS_SHIFT)
>> +
>> +#define ASIZE_MAX 0x1
>> +#define TA_MAX 0x3
>> +#define RHOLD_MAX 0x7
>> +#define RSTROBE_MAX0x3f
>> +#define RSETUP_MAX 0xf
>> +#define WHOLD_MAX 0x7
>> +#define WSTROBE_MAX0x3f
>> +#define WSETUP_MAX 0xf
>> +#define EW_MAX 0x1
>> +#define SS_MAX 0x1
>> +#define NUM_CS 4
>> +
>> +#define TA_VAL(x) (((x) & TA(TA_MAX)) >> TA_SHIFT)
>> +#define RHOLD_VAL(x) (((x) & RHOLD(RHOLD_MAX)) >> RHOLD_SHIFT)
>> +#define RSTROBE_VAL(x) (((x) & RSTROBE(RSTROBE_MAX)) >> RSTROBE_SHIFT)
>> +#define RSETUP_VAL(x) (((x) & RSETUP(RSETUP_MAX)) >> RSETUP_SHIFT)
>> +#define WHOLD_VAL(x) (((x) & WHOLD(WHOLD_MAX)) >> WHOLD_SHIFT)
>> +#define WSTROBE_VAL(x) (((x) & WSTROBE(WSTROBE_MAX)) >> WSTROBE_SHIFT)
>> +#define WSETUP_VAL(x) (((x) & WSETUP(WSETUP_MAX)) >> WSETUP_SHIFT)
>> +#define EW_VAL(x) (((x) & EW(EW_MAX)) >> EW_SHIFT)
>>
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
On 11/12/2013 06:08 PM, Santosh Shilimkar wrote:
+ Greg KH (drivers/memory/* patches goes through his queue)
On Monday 11 November 2013 12:06 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 ivan.khoronz...@ti.com
---
drivers/memory/Kconfig | 11 ++
drivers/memory/Makefile|1 +
drivers/memory/davinci-aemif.c | 415
3 files changed, 427 insertions(+)
create mode 100644 drivers/memory/davinci-aemif.c
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 29a11db..010e75e 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -7,6 +7,17 @@ menuconfig MEMORY
if MEMORY
+config TI_DAVINCI_AEMIF
s/TI_DAVINCI_AEMIF/TI_AEMIF
Ok
+ bool Texas Instruments DaVinci AEMIF driver
Drop DaVinci above since its used on more SOCs.
+ depends on (ARCH_DAVINCI || ARCH_KEYSTONE) OF
+ help
+ This driver is for the AEMIF module available in Texas Instruments
+ SoCs. AEMIF stands for Asynchronous External Memory Interface and
+ is intended to provide a glue-less interface to a variety of
+ asynchronuous memory devices like ASRAM, NOR and NAND memory. A
total
+ of 256M bytes of any of these memories can be accessed at a given
+ time via four chip selects with 64M byte access per chip select.
+
config TI_EMIF
tristate Texas Instruments EMIF driver
depends on ARCH_OMAP2PLUS
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 969d923..af14126 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -5,6 +5,7 @@
ifeq ($(CONFIG_DDR),y)
obj-$(CONFIG_OF) += of_memory.o
endif
+obj-$(CONFIG_TI_DAVINCI_AEMIF) += davinci-aemif.o
Change this accordingly once the config is renamed.
Ok
obj-$(CONFIG_TI_EMIF) += emif.o
obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
diff --git a/drivers/memory/davinci-aemif.c b/drivers/memory/davinci-aemif.c
new file mode 100644
index 000..e36b74b
--- /dev/null
+++ b/drivers/memory/davinci-aemif.c
@@ -0,0 +1,415 @@
+/*
+ * DaVinci/Keystone AEMIF driver
s/{DaVinci/Keystone}/TI
+ *
+ * Copyright (C) 2010 - 2013 Texas Instruments Incorporated.
http://www.ti.com/
+ * Copyright (C) Heiko Schocher h...@denx.de
+ * Copyright (C) Ivan Khoronzhuk ivan.khoronz...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+
+#define TA_SHIFT 2
+#define RHOLD_SHIFT4
+#define RSTROBE_SHIFT 7
+#define RSETUP_SHIFT 13
+#define WHOLD_SHIFT17
+#define WSTROBE_SHIFT 20
+#define WSETUP_SHIFT 26
+#define EW_SHIFT 30
+#define SS_SHIFT 31
+
+#define TA(x) ((x) TA_SHIFT)
+#define RHOLD(x) ((x) RHOLD_SHIFT)
+#define RSTROBE(x) ((x) RSTROBE_SHIFT)
+#define RSETUP(x) ((x) RSETUP_SHIFT)
+#define WHOLD(x) ((x) WHOLD_SHIFT)
+#define WSTROBE(x) ((x) WSTROBE_SHIFT)
+#define WSETUP(x) ((x) WSETUP_SHIFT)
+#define EW(x) ((x) EW_SHIFT)
+#define SS(x) ((x) SS_SHIFT)
+
+#define ASIZE_MAX 0x1
+#define TA_MAX 0x3
+#define RHOLD_MAX 0x7
+#define RSTROBE_MAX0x3f
+#define RSETUP_MAX 0xf
+#define WHOLD_MAX 0x7
+#define WSTROBE_MAX0x3f
+#define WSETUP_MAX 0xf
+#define EW_MAX 0x1
+#define SS_MAX 0x1
+#define NUM_CS 4
+
+#define TA_VAL(x) (((x) TA(TA_MAX)) TA_SHIFT)
+#define RHOLD_VAL(x) (((x) RHOLD(RHOLD_MAX)) RHOLD_SHIFT)
+#define RSTROBE_VAL(x) (((x) RSTROBE(RSTROBE_MAX)) RSTROBE_SHIFT)
+#define RSETUP_VAL(x) (((x) RSETUP(RSETUP_MAX)) RSETUP_SHIFT)
+#define WHOLD_VAL(x) (((x) WHOLD(WHOLD_MAX)) WHOLD_SHIFT)
+#define WSTROBE_VAL(x) (((x) WSTROBE(WSTROBE_MAX)) WSTROBE_SHIFT)
+#define WSETUP_VAL(x) (((x) WSETUP(WSETUP_MAX)) WSETUP_SHIFT)
+#define EW_VAL(x) (((x) EW(EW_MAX)) EW_SHIFT)
+#define SS_VAL(x) (((x) SS(SS_MAX)) SS_SHIFT)
+
+#define NRCSR_OFFSET 0x00
+#define AWCCR_OFFSET 0x04
+#define A1CR_OFFSET
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
+ Greg KH (drivers/memory/* patches goes through his queue)
On Monday 11 November 2013 12:06 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
> ---
> drivers/memory/Kconfig | 11 ++
> drivers/memory/Makefile|1 +
> drivers/memory/davinci-aemif.c | 415
>
> 3 files changed, 427 insertions(+)
> create mode 100644 drivers/memory/davinci-aemif.c
>
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index 29a11db..010e75e 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -7,6 +7,17 @@ menuconfig MEMORY
>
> if MEMORY
>
> +config TI_DAVINCI_AEMIF
s/TI_DAVINCI_AEMIF/TI_AEMIF
> + bool "Texas Instruments DaVinci AEMIF driver"
Drop DaVinci above since its used on more SOCs.
> + depends on (ARCH_DAVINCI || ARCH_KEYSTONE) && OF
> + help
> + This driver is for the AEMIF module available in Texas Instruments
> + SoCs. AEMIF stands for Asynchronous External Memory Interface and
> + is intended to provide a glue-less interface to a variety of
> + asynchronuous memory devices like ASRAM, NOR and NAND memory. A
> total
> + of 256M bytes of any of these memories can be accessed at a given
> + time via four chip selects with 64M byte access per chip select.
> +
> config TI_EMIF
> tristate "Texas Instruments EMIF driver"
> depends on ARCH_OMAP2PLUS
> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
> index 969d923..af14126 100644
> --- a/drivers/memory/Makefile
> +++ b/drivers/memory/Makefile
> @@ -5,6 +5,7 @@
> ifeq ($(CONFIG_DDR),y)
> obj-$(CONFIG_OF) += of_memory.o
> endif
> +obj-$(CONFIG_TI_DAVINCI_AEMIF) += davinci-aemif.o
Change this accordingly once the config is renamed.
> obj-$(CONFIG_TI_EMIF) += emif.o
> obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
> obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
> diff --git a/drivers/memory/davinci-aemif.c b/drivers/memory/davinci-aemif.c
> new file mode 100644
> index 000..e36b74b
> --- /dev/null
> +++ b/drivers/memory/davinci-aemif.c
> @@ -0,0 +1,415 @@
> +/*
> + * DaVinci/Keystone AEMIF driver
s/{DaVinci/Keystone}/TI
> + *
> + * Copyright (C) 2010 - 2013 Texas Instruments Incorporated.
> http://www.ti.com/
> + * Copyright (C) Heiko Schocher
> + * Copyright (C) Ivan Khoronzhuk
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define TA_SHIFT 2
> +#define RHOLD_SHIFT4
> +#define RSTROBE_SHIFT 7
> +#define RSETUP_SHIFT 13
> +#define WHOLD_SHIFT17
> +#define WSTROBE_SHIFT 20
> +#define WSETUP_SHIFT 26
> +#define EW_SHIFT 30
> +#define SS_SHIFT 31
> +
> +#define TA(x) ((x) << TA_SHIFT)
> +#define RHOLD(x) ((x) << RHOLD_SHIFT)
> +#define RSTROBE(x) ((x) << RSTROBE_SHIFT)
> +#define RSETUP(x) ((x) << RSETUP_SHIFT)
> +#define WHOLD(x) ((x) << WHOLD_SHIFT)
> +#define WSTROBE(x) ((x) << WSTROBE_SHIFT)
> +#define WSETUP(x) ((x) << WSETUP_SHIFT)
> +#define EW(x) ((x) << EW_SHIFT)
> +#define SS(x) ((x) << SS_SHIFT)
> +
> +#define ASIZE_MAX 0x1
> +#define TA_MAX 0x3
> +#define RHOLD_MAX 0x7
> +#define RSTROBE_MAX0x3f
> +#define RSETUP_MAX 0xf
> +#define WHOLD_MAX 0x7
> +#define WSTROBE_MAX0x3f
> +#define WSETUP_MAX 0xf
> +#define EW_MAX 0x1
> +#define SS_MAX 0x1
> +#define NUM_CS 4
> +
> +#define TA_VAL(x) (((x) & TA(TA_MAX)) >> TA_SHIFT)
> +#define RHOLD_VAL(x) (((x) & RHOLD(RHOLD_MAX)) >> RHOLD_SHIFT)
> +#define RSTROBE_VAL(x) (((x) & RSTROBE(RSTROBE_MAX)) >> RSTROBE_SHIFT)
> +#define RSETUP_VAL(x) (((x) & RSETUP(RSETUP_MAX)) >> RSETUP_SHIFT)
> +#define WHOLD_VAL(x) (((x) & WHOLD(WHOLD_MAX)) >> WHOLD_SHIFT)
> +#define WSTROBE_VAL(x) (((x) & WSTROBE(WSTROBE_MAX)) >> WSTROBE_SHIFT)
> +#define WSETUP_VAL(x) (((x) & WSETUP(WSETUP_MAX)) >> WSETUP_SHIFT)
> +#define EW_VAL(x) (((x) & EW(EW_MAX)) >> EW_SHIFT)
> +#define SS_VAL(x) (((x) & SS(SS_MAX)) >> SS_SHIFT)
> +
> +#define NRCSR_OFFSET 0x00
> +#define AWCCR_OFFSET 0x04
> +#define A1CR_OFFSET0x10
> +
> +#define ACR_ASIZE_MASK 0x3
> +#define ACR_EW_MASK
Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
+ Greg KH (drivers/memory/* patches goes through his queue)
On Monday 11 November 2013 12:06 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 ivan.khoronz...@ti.com
---
drivers/memory/Kconfig | 11 ++
drivers/memory/Makefile|1 +
drivers/memory/davinci-aemif.c | 415
3 files changed, 427 insertions(+)
create mode 100644 drivers/memory/davinci-aemif.c
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 29a11db..010e75e 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -7,6 +7,17 @@ menuconfig MEMORY
if MEMORY
+config TI_DAVINCI_AEMIF
s/TI_DAVINCI_AEMIF/TI_AEMIF
+ bool Texas Instruments DaVinci AEMIF driver
Drop DaVinci above since its used on more SOCs.
+ depends on (ARCH_DAVINCI || ARCH_KEYSTONE) OF
+ help
+ This driver is for the AEMIF module available in Texas Instruments
+ SoCs. AEMIF stands for Asynchronous External Memory Interface and
+ is intended to provide a glue-less interface to a variety of
+ asynchronuous memory devices like ASRAM, NOR and NAND memory. A
total
+ of 256M bytes of any of these memories can be accessed at a given
+ time via four chip selects with 64M byte access per chip select.
+
config TI_EMIF
tristate Texas Instruments EMIF driver
depends on ARCH_OMAP2PLUS
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 969d923..af14126 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -5,6 +5,7 @@
ifeq ($(CONFIG_DDR),y)
obj-$(CONFIG_OF) += of_memory.o
endif
+obj-$(CONFIG_TI_DAVINCI_AEMIF) += davinci-aemif.o
Change this accordingly once the config is renamed.
obj-$(CONFIG_TI_EMIF) += emif.o
obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
diff --git a/drivers/memory/davinci-aemif.c b/drivers/memory/davinci-aemif.c
new file mode 100644
index 000..e36b74b
--- /dev/null
+++ b/drivers/memory/davinci-aemif.c
@@ -0,0 +1,415 @@
+/*
+ * DaVinci/Keystone AEMIF driver
s/{DaVinci/Keystone}/TI
+ *
+ * Copyright (C) 2010 - 2013 Texas Instruments Incorporated.
http://www.ti.com/
+ * Copyright (C) Heiko Schocher h...@denx.de
+ * Copyright (C) Ivan Khoronzhuk ivan.khoronz...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+
+#define TA_SHIFT 2
+#define RHOLD_SHIFT4
+#define RSTROBE_SHIFT 7
+#define RSETUP_SHIFT 13
+#define WHOLD_SHIFT17
+#define WSTROBE_SHIFT 20
+#define WSETUP_SHIFT 26
+#define EW_SHIFT 30
+#define SS_SHIFT 31
+
+#define TA(x) ((x) TA_SHIFT)
+#define RHOLD(x) ((x) RHOLD_SHIFT)
+#define RSTROBE(x) ((x) RSTROBE_SHIFT)
+#define RSETUP(x) ((x) RSETUP_SHIFT)
+#define WHOLD(x) ((x) WHOLD_SHIFT)
+#define WSTROBE(x) ((x) WSTROBE_SHIFT)
+#define WSETUP(x) ((x) WSETUP_SHIFT)
+#define EW(x) ((x) EW_SHIFT)
+#define SS(x) ((x) SS_SHIFT)
+
+#define ASIZE_MAX 0x1
+#define TA_MAX 0x3
+#define RHOLD_MAX 0x7
+#define RSTROBE_MAX0x3f
+#define RSETUP_MAX 0xf
+#define WHOLD_MAX 0x7
+#define WSTROBE_MAX0x3f
+#define WSETUP_MAX 0xf
+#define EW_MAX 0x1
+#define SS_MAX 0x1
+#define NUM_CS 4
+
+#define TA_VAL(x) (((x) TA(TA_MAX)) TA_SHIFT)
+#define RHOLD_VAL(x) (((x) RHOLD(RHOLD_MAX)) RHOLD_SHIFT)
+#define RSTROBE_VAL(x) (((x) RSTROBE(RSTROBE_MAX)) RSTROBE_SHIFT)
+#define RSETUP_VAL(x) (((x) RSETUP(RSETUP_MAX)) RSETUP_SHIFT)
+#define WHOLD_VAL(x) (((x) WHOLD(WHOLD_MAX)) WHOLD_SHIFT)
+#define WSTROBE_VAL(x) (((x) WSTROBE(WSTROBE_MAX)) WSTROBE_SHIFT)
+#define WSETUP_VAL(x) (((x) WSETUP(WSETUP_MAX)) WSETUP_SHIFT)
+#define EW_VAL(x) (((x) EW(EW_MAX)) EW_SHIFT)
+#define SS_VAL(x) (((x) SS(SS_MAX)) SS_SHIFT)
+
+#define NRCSR_OFFSET 0x00
+#define AWCCR_OFFSET 0x04
+#define A1CR_OFFSET0x10
+
+#define ACR_ASIZE_MASK 0x3
+#define ACR_EW_MASKBIT(30)
[PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
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 --- drivers/memory/Kconfig | 11 ++ drivers/memory/Makefile|1 + drivers/memory/davinci-aemif.c | 415 3 files changed, 427 insertions(+) create mode 100644 drivers/memory/davinci-aemif.c diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 29a11db..010e75e 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -7,6 +7,17 @@ menuconfig MEMORY if MEMORY +config TI_DAVINCI_AEMIF + bool "Texas Instruments DaVinci AEMIF driver" + depends on (ARCH_DAVINCI || ARCH_KEYSTONE) && OF + help + This driver is for the AEMIF module available in Texas Instruments + SoCs. AEMIF stands for Asynchronous External Memory Interface and + is intended to provide a glue-less interface to a variety of + asynchronuous memory devices like ASRAM, NOR and NAND memory. A total + of 256M bytes of any of these memories can be accessed at a given + time via four chip selects with 64M byte access per chip select. + config TI_EMIF tristate "Texas Instruments EMIF driver" depends on ARCH_OMAP2PLUS diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index 969d923..af14126 100644 --- a/drivers/memory/Makefile +++ b/drivers/memory/Makefile @@ -5,6 +5,7 @@ ifeq ($(CONFIG_DDR),y) obj-$(CONFIG_OF) += of_memory.o endif +obj-$(CONFIG_TI_DAVINCI_AEMIF) += davinci-aemif.o obj-$(CONFIG_TI_EMIF) += emif.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o diff --git a/drivers/memory/davinci-aemif.c b/drivers/memory/davinci-aemif.c new file mode 100644 index 000..e36b74b --- /dev/null +++ b/drivers/memory/davinci-aemif.c @@ -0,0 +1,415 @@ +/* + * DaVinci/Keystone AEMIF driver + * + * Copyright (C) 2010 - 2013 Texas Instruments Incorporated. http://www.ti.com/ + * Copyright (C) Heiko Schocher + * Copyright (C) Ivan Khoronzhuk + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define TA_SHIFT 2 +#define RHOLD_SHIFT4 +#define RSTROBE_SHIFT 7 +#define RSETUP_SHIFT 13 +#define WHOLD_SHIFT17 +#define WSTROBE_SHIFT 20 +#define WSETUP_SHIFT 26 +#define EW_SHIFT 30 +#define SS_SHIFT 31 + +#define TA(x) ((x) << TA_SHIFT) +#define RHOLD(x) ((x) << RHOLD_SHIFT) +#define RSTROBE(x) ((x) << RSTROBE_SHIFT) +#define RSETUP(x) ((x) << RSETUP_SHIFT) +#define WHOLD(x) ((x) << WHOLD_SHIFT) +#define WSTROBE(x) ((x) << WSTROBE_SHIFT) +#define WSETUP(x) ((x) << WSETUP_SHIFT) +#define EW(x) ((x) << EW_SHIFT) +#define SS(x) ((x) << SS_SHIFT) + +#define ASIZE_MAX 0x1 +#define TA_MAX 0x3 +#define RHOLD_MAX 0x7 +#define RSTROBE_MAX0x3f +#define RSETUP_MAX 0xf +#define WHOLD_MAX 0x7 +#define WSTROBE_MAX0x3f +#define WSETUP_MAX 0xf +#define EW_MAX 0x1 +#define SS_MAX 0x1 +#define NUM_CS 4 + +#define TA_VAL(x) (((x) & TA(TA_MAX)) >> TA_SHIFT) +#define RHOLD_VAL(x) (((x) & RHOLD(RHOLD_MAX)) >> RHOLD_SHIFT) +#define RSTROBE_VAL(x) (((x) & RSTROBE(RSTROBE_MAX)) >> RSTROBE_SHIFT) +#define RSETUP_VAL(x) (((x) & RSETUP(RSETUP_MAX)) >> RSETUP_SHIFT) +#define WHOLD_VAL(x) (((x) & WHOLD(WHOLD_MAX)) >> WHOLD_SHIFT) +#define WSTROBE_VAL(x) (((x) & WSTROBE(WSTROBE_MAX)) >> WSTROBE_SHIFT) +#define WSETUP_VAL(x) (((x) & WSETUP(WSETUP_MAX)) >> WSETUP_SHIFT) +#define EW_VAL(x) (((x) & EW(EW_MAX)) >> EW_SHIFT) +#define SS_VAL(x) (((x) & SS(SS_MAX)) >> SS_SHIFT) + +#define NRCSR_OFFSET 0x00 +#define AWCCR_OFFSET 0x04 +#define A1CR_OFFSET0x10 + +#define ACR_ASIZE_MASK 0x3 +#define ACR_EW_MASKBIT(30) +#define ACR_SS_MASKBIT(31) +#define ASIZE_16BIT1 + +#define CONFIG_MASK(TA(TA_MAX) | \ + RHOLD(RHOLD_MAX) | \ + RSTROBE(RSTROBE_MAX) | \ + RSETUP(RSETUP_MAX) | \ + WHOLD(WHOLD_MAX) | \ + WSTROBE(WSTROBE_MAX) | \ + WSETUP(WSETUP_MAX) | \ + EW(EW_MAX) | SS(SS_MAX) | \ +
[PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver
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 ivan.khoronz...@ti.com --- drivers/memory/Kconfig | 11 ++ drivers/memory/Makefile|1 + drivers/memory/davinci-aemif.c | 415 3 files changed, 427 insertions(+) create mode 100644 drivers/memory/davinci-aemif.c diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 29a11db..010e75e 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -7,6 +7,17 @@ menuconfig MEMORY if MEMORY +config TI_DAVINCI_AEMIF + bool Texas Instruments DaVinci AEMIF driver + depends on (ARCH_DAVINCI || ARCH_KEYSTONE) OF + help + This driver is for the AEMIF module available in Texas Instruments + SoCs. AEMIF stands for Asynchronous External Memory Interface and + is intended to provide a glue-less interface to a variety of + asynchronuous memory devices like ASRAM, NOR and NAND memory. A total + of 256M bytes of any of these memories can be accessed at a given + time via four chip selects with 64M byte access per chip select. + config TI_EMIF tristate Texas Instruments EMIF driver depends on ARCH_OMAP2PLUS diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index 969d923..af14126 100644 --- a/drivers/memory/Makefile +++ b/drivers/memory/Makefile @@ -5,6 +5,7 @@ ifeq ($(CONFIG_DDR),y) obj-$(CONFIG_OF) += of_memory.o endif +obj-$(CONFIG_TI_DAVINCI_AEMIF) += davinci-aemif.o obj-$(CONFIG_TI_EMIF) += emif.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o diff --git a/drivers/memory/davinci-aemif.c b/drivers/memory/davinci-aemif.c new file mode 100644 index 000..e36b74b --- /dev/null +++ b/drivers/memory/davinci-aemif.c @@ -0,0 +1,415 @@ +/* + * DaVinci/Keystone AEMIF driver + * + * Copyright (C) 2010 - 2013 Texas Instruments Incorporated. http://www.ti.com/ + * Copyright (C) Heiko Schocher h...@denx.de + * Copyright (C) Ivan Khoronzhuk ivan.khoronz...@ti.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/clk.h +#include linux/err.h +#include linux/io.h +#include linux/kernel.h +#include linux/module.h +#include linux/of.h +#include linux/of_platform.h +#include linux/platform_device.h + +#define TA_SHIFT 2 +#define RHOLD_SHIFT4 +#define RSTROBE_SHIFT 7 +#define RSETUP_SHIFT 13 +#define WHOLD_SHIFT17 +#define WSTROBE_SHIFT 20 +#define WSETUP_SHIFT 26 +#define EW_SHIFT 30 +#define SS_SHIFT 31 + +#define TA(x) ((x) TA_SHIFT) +#define RHOLD(x) ((x) RHOLD_SHIFT) +#define RSTROBE(x) ((x) RSTROBE_SHIFT) +#define RSETUP(x) ((x) RSETUP_SHIFT) +#define WHOLD(x) ((x) WHOLD_SHIFT) +#define WSTROBE(x) ((x) WSTROBE_SHIFT) +#define WSETUP(x) ((x) WSETUP_SHIFT) +#define EW(x) ((x) EW_SHIFT) +#define SS(x) ((x) SS_SHIFT) + +#define ASIZE_MAX 0x1 +#define TA_MAX 0x3 +#define RHOLD_MAX 0x7 +#define RSTROBE_MAX0x3f +#define RSETUP_MAX 0xf +#define WHOLD_MAX 0x7 +#define WSTROBE_MAX0x3f +#define WSETUP_MAX 0xf +#define EW_MAX 0x1 +#define SS_MAX 0x1 +#define NUM_CS 4 + +#define TA_VAL(x) (((x) TA(TA_MAX)) TA_SHIFT) +#define RHOLD_VAL(x) (((x) RHOLD(RHOLD_MAX)) RHOLD_SHIFT) +#define RSTROBE_VAL(x) (((x) RSTROBE(RSTROBE_MAX)) RSTROBE_SHIFT) +#define RSETUP_VAL(x) (((x) RSETUP(RSETUP_MAX)) RSETUP_SHIFT) +#define WHOLD_VAL(x) (((x) WHOLD(WHOLD_MAX)) WHOLD_SHIFT) +#define WSTROBE_VAL(x) (((x) WSTROBE(WSTROBE_MAX)) WSTROBE_SHIFT) +#define WSETUP_VAL(x) (((x) WSETUP(WSETUP_MAX)) WSETUP_SHIFT) +#define EW_VAL(x) (((x) EW(EW_MAX)) EW_SHIFT) +#define SS_VAL(x) (((x) SS(SS_MAX)) SS_SHIFT) + +#define NRCSR_OFFSET 0x00 +#define AWCCR_OFFSET 0x04 +#define A1CR_OFFSET0x10 + +#define ACR_ASIZE_MASK 0x3 +#define ACR_EW_MASKBIT(30) +#define ACR_SS_MASKBIT(31) +#define ASIZE_16BIT1 + +#define CONFIG_MASK(TA(TA_MAX) | \ + RHOLD(RHOLD_MAX) | \ + RSTROBE(RSTROBE_MAX) | \ + RSETUP(RSETUP_MAX) | \ + WHOLD(WHOLD_MAX) | \ + WSTROBE(WSTROBE_MAX) | \ +
