* [RFC PATCH 1/7] ARM: davinci, intc: Add OF support for TI interrupt controller
2012-01-23 8:56 [RFC PATCH 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
@ 2012-01-23 8:56 ` Heiko Schocher
2012-02-02 4:54 ` Grant Likely
2012-01-23 8:56 ` [RFC PATCH 2/7 v2] ARM: davinci: configure davinci aemif chipselects through OF Heiko Schocher
` (5 subsequent siblings)
6 siblings, 1 reply; 37+ messages in thread
From: Heiko Schocher @ 2012-01-23 8:56 UTC (permalink / raw)
To: linux-arm-kernel
Add a function to initialize the davinci interrupt controller (INTC)
using a device tree node.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
---
.../devicetree/bindings/arm/davinci/intc.txt | 26 ++++++++++
arch/arm/mach-davinci/cp_intc.c | 51 ++++++++++++++++++++
arch/arm/mach-davinci/include/mach/cp_intc.h | 1 +
3 files changed, 78 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt
diff --git a/Documentation/devicetree/bindings/arm/davinci/intc.txt b/Documentation/devicetree/bindings/arm/davinci/intc.txt
new file mode 100644
index 0000000..dac2f69
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/intc.txt
@@ -0,0 +1,26 @@
+* TI Davinci Interrupt Controller
+
+davinci are using a TI interrupt controller that can support several
+configurable number of interrupts.
+
+Main node required properties:
+
+- compatible : should be:
+ "ti,davinci-intc"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a <u32> and the value shall be 1.
+
+ The cell contains the interrupt number in the range [0-128].
+- ti,intc-size: Number of interrupts handled by the interrupt controller.
+- reg: physical base address and size of the intc registers map.
+
+Example:
+
+ intc: interrupt-controller at 1 {
+ compatible = "ti,davinci-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ ti,intc-size = <101>;
+ reg = <0xfffee000 0x2000>;
+ };
diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
index f83152d..2c6e2e4 100644
--- a/arch/arm/mach-davinci/cp_intc.c
+++ b/arch/arm/mach-davinci/cp_intc.c
@@ -11,7 +11,11 @@
#include <linux/init.h>
#include <linux/irq.h>
+#include <linux/irqdomain.h>
#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
#include <mach/common.h>
#include <mach/cp_intc.h>
@@ -175,3 +179,50 @@ void __init cp_intc_init(void)
/* Enable global interrupt */
cp_intc_write(1, CP_INTC_GLOBAL_ENABLE);
}
+
+#ifdef CONFIG_OF
+int __init dv_intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ struct resource res;
+ u32 nr_irqs;
+
+ if (WARN_ON(!node))
+ return -ENODEV;
+
+ if (of_address_to_resource(node, 0, &res)) {
+ WARN(1, "unable to get intc registers\n");
+ return -EINVAL;
+ }
+
+ davinci_soc_info.intc_base = res.start;
+ if (WARN_ON(!davinci_soc_info.intc_base))
+ return -EINVAL;
+
+ if (of_property_read_u32(node, "ti,intc-size", &nr_irqs)) {
+ WARN(1, "unable to get intc-size\n");
+ return -EINVAL;
+ }
+ davinci_soc_info.intc_irq_num = nr_irqs;
+ davinci_soc_info.intc_type = DAVINCI_INTC_TYPE_CP_INTC;
+
+ cp_intc_init();
+ irq_domain_add_simple(node, 0);
+
+ return 0;
+}
+
+static struct of_device_id irq_match[] __initdata = {
+ { .compatible = "ti,davinci-intc", .data = dv_intc_of_init, },
+ { }
+};
+
+void __init davinci_init_irq(void)
+{
+ of_irq_init(irq_match);
+}
+#else
+void __init davinci_init_irq(void)
+{
+ cp_intc_init();
+}
+#endif
diff --git a/arch/arm/mach-davinci/include/mach/cp_intc.h b/arch/arm/mach-davinci/include/mach/cp_intc.h
index 4e8190e..d674b95 100644
--- a/arch/arm/mach-davinci/include/mach/cp_intc.h
+++ b/arch/arm/mach-davinci/include/mach/cp_intc.h
@@ -52,5 +52,6 @@
#define CP_INTC_VECTOR_ADDR(n) (0x2000 + (n << 2))
void __init cp_intc_init(void);
+void __init davinci_init_irq(void);
#endif /* __ASM_HARDWARE_CP_INTC_H */
--
1.7.7.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [RFC PATCH 1/7] ARM: davinci, intc: Add OF support for TI interrupt controller
2012-01-23 8:56 ` [RFC PATCH 1/7] ARM: davinci, intc: Add OF support for TI interrupt controller Heiko Schocher
@ 2012-02-02 4:54 ` Grant Likely
2012-02-06 6:36 ` Heiko Schocher
0 siblings, 1 reply; 37+ messages in thread
From: Grant Likely @ 2012-02-02 4:54 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 23, 2012 at 09:56:01AM +0100, Heiko Schocher wrote:
> Add a function to initialize the davinci interrupt controller (INTC)
> using a device tree node.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Wolfgang Denk <wd@denx.de>
> ---
> .../devicetree/bindings/arm/davinci/intc.txt | 26 ++++++++++
> arch/arm/mach-davinci/cp_intc.c | 51 ++++++++++++++++++++
> arch/arm/mach-davinci/include/mach/cp_intc.h | 1 +
> 3 files changed, 78 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/davinci/intc.txt b/Documentation/devicetree/bindings/arm/davinci/intc.txt
> new file mode 100644
> index 0000000..dac2f69
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/intc.txt
> @@ -0,0 +1,26 @@
> +* TI Davinci Interrupt Controller
> +
> +davinci are using a TI interrupt controller that can support several
> +configurable number of interrupts.
> +
> +Main node required properties:
> +
> +- compatible : should be:
> + "ti,davinci-intc"
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> + interrupt source. The type shall be a <u32> and the value shall be 1.
> +
> + The cell contains the interrupt number in the range [0-128].
> +- ti,intc-size: Number of interrupts handled by the interrupt controller.
> +- reg: physical base address and size of the intc registers map.
> +
> +Example:
> +
> + intc: interrupt-controller at 1 {
> + compatible = "ti,davinci-intc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + ti,intc-size = <101>;
> + reg = <0xfffee000 0x2000>;
> + };
> diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
> index f83152d..2c6e2e4 100644
> --- a/arch/arm/mach-davinci/cp_intc.c
> +++ b/arch/arm/mach-davinci/cp_intc.c
> @@ -11,7 +11,11 @@
>
> #include <linux/init.h>
> #include <linux/irq.h>
> +#include <linux/irqdomain.h>
> #include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
>
> #include <mach/common.h>
> #include <mach/cp_intc.h>
> @@ -175,3 +179,50 @@ void __init cp_intc_init(void)
> /* Enable global interrupt */
> cp_intc_write(1, CP_INTC_GLOBAL_ENABLE);
> }
> +
> +#ifdef CONFIG_OF
> +int __init dv_intc_of_init(struct device_node *node, struct device_node *parent)
> +{
> + struct resource res;
> + u32 nr_irqs;
> +
> + if (WARN_ON(!node))
> + return -ENODEV;
> +
> + if (of_address_to_resource(node, 0, &res)) {
> + WARN(1, "unable to get intc registers\n");
> + return -EINVAL;
> + }
> +
> + davinci_soc_info.intc_base = res.start;
> + if (WARN_ON(!davinci_soc_info.intc_base))
> + return -EINVAL;
> +
> + if (of_property_read_u32(node, "ti,intc-size", &nr_irqs)) {
> + WARN(1, "unable to get intc-size\n");
> + return -EINVAL;
> + }
> + davinci_soc_info.intc_irq_num = nr_irqs;
> + davinci_soc_info.intc_type = DAVINCI_INTC_TYPE_CP_INTC;
> +
> + cp_intc_init();
> + irq_domain_add_simple(node, 0);
Take a look at the irq_domain patches that will be (probably) merged
in v3.4. Instead of calling irq_domain_add_simple(), you should
migrate the whole interrupt controller to natively use an irq_domain
for hwirq <--> irq mapping.
g.
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 1/7] ARM: davinci, intc: Add OF support for TI interrupt controller
2012-02-02 4:54 ` Grant Likely
@ 2012-02-06 6:36 ` Heiko Schocher
2012-02-14 7:15 ` Heiko Schocher
0 siblings, 1 reply; 37+ messages in thread
From: Heiko Schocher @ 2012-02-06 6:36 UTC (permalink / raw)
To: linux-arm-kernel
Hello Grant,
Grant Likely wrote:
> On Mon, Jan 23, 2012 at 09:56:01AM +0100, Heiko Schocher wrote:
>> Add a function to initialize the davinci interrupt controller (INTC)
>> using a device tree node.
>>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree-discuss at lists.ozlabs.org
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Cc: Wolfgang Denk <wd@denx.de>
>> ---
>> .../devicetree/bindings/arm/davinci/intc.txt | 26 ++++++++++
>> arch/arm/mach-davinci/cp_intc.c | 51 ++++++++++++++++++++
>> arch/arm/mach-davinci/include/mach/cp_intc.h | 1 +
>> 3 files changed, 78 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt
[...]
>> diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
>> index f83152d..2c6e2e4 100644
>> --- a/arch/arm/mach-davinci/cp_intc.c
>> +++ b/arch/arm/mach-davinci/cp_intc.c
[...]
>> + cp_intc_init();
>> + irq_domain_add_simple(node, 0);
>
> Take a look at the irq_domain patches that will be (probably) merged
> in v3.4. Instead of calling irq_domain_add_simple(), you should
> migrate the whole interrupt controller to natively use an irq_domain
> for hwirq <--> irq mapping.
I rebased my hole patchset to:
git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
and reworked the arch/arm/mach-davinci/cp_intc.c irq driver to use
irq_domain, works good on the enbw_cmc board :-)
Waiting for your comment to my question to the
[RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
patch, see:
http://www.mail-archive.com/linux-i2c at vger.kernel.org/msg07132.html
and resend the hole reworked patchserie. Is it OK, if I use the above
branch as base for sending this patchserie, or should I use another
tree/branch for it?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 1/7] ARM: davinci, intc: Add OF support for TI interrupt controller
2012-02-06 6:36 ` Heiko Schocher
@ 2012-02-14 7:15 ` Heiko Schocher
0 siblings, 0 replies; 37+ messages in thread
From: Heiko Schocher @ 2012-02-14 7:15 UTC (permalink / raw)
To: linux-arm-kernel
Hello Grant,
Heiko Schocher wrote:
> Hello Grant,
>
> Grant Likely wrote:
>> On Mon, Jan 23, 2012 at 09:56:01AM +0100, Heiko Schocher wrote:
>>> Add a function to initialize the davinci interrupt controller (INTC)
>>> using a device tree node.
>>>
>>> Signed-off-by: Heiko Schocher <hs@denx.de>
>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: devicetree-discuss at lists.ozlabs.org
>>> Cc: Grant Likely <grant.likely@secretlab.ca>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Cc: Wolfgang Denk <wd@denx.de>
>>> ---
>>> .../devicetree/bindings/arm/davinci/intc.txt | 26 ++++++++++
>>> arch/arm/mach-davinci/cp_intc.c | 51 ++++++++++++++++++++
>>> arch/arm/mach-davinci/include/mach/cp_intc.h | 1 +
>>> 3 files changed, 78 insertions(+), 0 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt
> [...]
>>> diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
>>> index f83152d..2c6e2e4 100644
>>> --- a/arch/arm/mach-davinci/cp_intc.c
>>> +++ b/arch/arm/mach-davinci/cp_intc.c
> [...]
>>> + cp_intc_init();
>>> + irq_domain_add_simple(node, 0);
>> Take a look at the irq_domain patches that will be (probably) merged
>> in v3.4. Instead of calling irq_domain_add_simple(), you should
>> migrate the whole interrupt controller to natively use an irq_domain
>> for hwirq <--> irq mapping.
>
> I rebased my hole patchset to:
>
> git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
> and reworked the arch/arm/mach-davinci/cp_intc.c irq driver to use
> irq_domain, works good on the enbw_cmc board :-)
>
> Waiting for your comment to my question to the
> [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
> patch, see:
> http://www.mail-archive.com/linux-i2c at vger.kernel.org/msg07132.html
>
> and resend the hole reworked patchserie. Is it OK, if I use the above
> branch as base for sending this patchserie, or should I use another
> tree/branch for it?
Ping?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 2/7 v2] ARM: davinci: configure davinci aemif chipselects through OF
2012-01-23 8:56 [RFC PATCH 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
2012-01-23 8:56 ` [RFC PATCH 1/7] ARM: davinci, intc: Add OF support for TI interrupt controller Heiko Schocher
@ 2012-01-23 8:56 ` Heiko Schocher
2012-01-23 8:56 ` [RFC PATCH 3/7] ARM: davinci: mux: add OF support Heiko Schocher
` (4 subsequent siblings)
6 siblings, 0 replies; 37+ messages in thread
From: Heiko Schocher @ 2012-01-23 8:56 UTC (permalink / raw)
To: linux-arm-kernel
Add support for configuring the aemif timing registers
through device tree. Introduce new compatible property
"ti,davinci-cs", see full description in
Documentation/devicetree/bindings/arm/davinci/aemif.txt
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
---
- changes for v2
- add comment from Sergei Shtylyov:
- use of_property_read_u32()
- Conding Style changes
- add comment from Sekhar Nori:
- add patch description
- use davinci_aemif_setup_timing
- change compatible node to "ti,davinci-aemif"
- not moved to mfd, as mentioned in this discussion:
http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-td7059739.html
instead use a phandle in the DTS, so drivers which
uses the davinci aemif, can call davinci_aemif_setup_timing_of()
This is just thought as an RFC ... The enbw_cmc board
support not really need to setup this bus timings, as
they are setup in U-Boot ... but I want to post this,
as I think, it is a nice to have ... as an example used
in the davinci nand controller OF support patch, in this
patchserie.
.../devicetree/bindings/arm/davinci/aemif.txt | 119 ++++++++++++++++++++
arch/arm/mach-davinci/aemif.c | 86 ++++++++++++++-
arch/arm/mach-davinci/include/mach/aemif.h | 1 +
3 files changed, 205 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt
diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt b/Documentation/devicetree/bindings/arm/davinci/aemif.txt
new file mode 100644
index 0000000..0dbb842
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt
@@ -0,0 +1,119 @@
+* Texas Instruments Davinci AEMIF
+
+This file provides information, what the device node for the
+davinci aemif interface contain.
+
+Required properties:
+- compatible: "ti,davinci-aemif";
+- #address-cells : Should be either two or three. The first cell is the
+ chipselect number, and the remaining cells are the
+ offset into the chipselect.
+- #size-cells : Either one or two, depending on how large each chipselect
+ can be.
+- ranges : Each range corresponds to a single chipselect, and cover
+ the entire access window as configured.
+
+Optional properties:
+- none
+
+Optional subnodes:
+- Chipselect setup:
+ - compatible: "ti,davinci-cs";
+ - #address-cells = <1>;
+ - #size-cells = <1>;
+
+ Timing setup, all timings in nanoseconds
+ - cs: chipselect (value 2,3,4 or 5)
+ - asize: Asynchronous Data Bus Width.
+ value:
+ 0: 8 bit
+ 1: 16 bit
+ - ta: Minimum Turn-Around time.
+ - rhold: Read hold width
+ - rstrobe: Read strobe width
+ - rsetup: Read setup width
+ - whold: Write hold width
+ - wstrobe: Write strobe width
+ - wsetup: Write setup width
+ - ew: Extend Wait bit
+ value:
+ 0: Extended wait cycles disabled.
+ 1: Extended wait cycles enabled.
+ - ss: Select Strobe bit.
+ value:
+ 0: Normal Mode enabled.
+ 1: Select Strobe Mode enabled.
+- CFI driver:
+ see: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+
+Example (enbw_cmc board):
+ aemif at 60000000 {
+ compatible = "ti,davinci-aemif";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x68000000 0x80000>;
+ ranges = <2 0 0x60000000 0x02000000
+ 3 0 0x62000000 0x02000000
+ 4 0 0x64000000 0x02000000
+ 5 0 0x66000000 0x02000000
+ 6 0 0x68000000 0x02000000>;
+ cs2 at 68000000 {
+ compatible = "ti,davinci-cs";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* all timings in nanoseconds */
+ cs = <2>;
+ asize = <1>;
+ ta = <0>;
+ rhold = <7>;
+ rstrobe = <42>;
+ rsetup = <14>;
+ whold = <7>;
+ wstrobe = <42>;
+ wsetup = <14>;
+ ew = <0>;
+ ss = <0>;
+ };
+ flash at 2,0 {
+ compatible = "cfi-flash";
+ reg = <2 0x0 0x400000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <2>;
+ device-width = <2>;
+ };
+ nand_cs: cs3 at 68000000 {
+ compatible = "ti,davinci-cs";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* all timings in nanoseconds */
+ cs = <3>;
+ asize = <0>;
+ ta = <0>;
+ rhold = <7>;
+ rstrobe = <42>;
+ rsetup = <7>;
+ whold = <7>;
+ wstrobe = <14>;
+ wsetup = <7>;
+ ew = <0>;
+ ss = <0>;
+ };
+ nandflash at 3,0 {
+ compatible = "ti,davinci-nand";
+ reg = <3 0x0 0x807ff
+ 6 0x0 0x8000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ mask_ale = <0>;
+ mask_cle = <0>;
+ mask_chipsel = <0>;
+ ecc_mode = <2>;
+ ecc_bits = <4>;
+ options = <0>;
+ bbt_options = <0x20000>;
+ pinmux-handle = <&nand_pins>;
+ timing-handle = <&nand_cs>;
+ };
+
+ };
diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
index 1ce70a9..e3d94a5 100644
--- a/arch/arm/mach-davinci/aemif.c
+++ b/arch/arm/mach-davinci/aemif.c
@@ -13,12 +13,14 @@
#include <linux/err.h>
#include <linux/clk.h>
#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/time.h>
#include <mach/aemif.h>
/* Timing value configuration */
-
+#define ASIZE(x) (x)
#define TA(x) ((x) << 2)
#define RHOLD(x) ((x) << 4)
#define RSTROBE(x) ((x) << 7)
@@ -26,7 +28,10 @@
#define WHOLD(x) ((x) << 17)
#define WSTROBE(x) ((x) << 20)
#define WSETUP(x) ((x) << 26)
+#define EW(x) ((x) << 30)
+#define SS(x) ((x) << 31)
+#define ASIZE_MAX 0x1
#define TA_MAX 0x3
#define RHOLD_MAX 0x7
#define RSTROBE_MAX 0x3f
@@ -34,6 +39,8 @@
#define WHOLD_MAX 0x7
#define WSTROBE_MAX 0x3f
#define WSETUP_MAX 0xf
+#define EW_MAX 0x1
+#define SS_MAX 0x1
#define TIMING_MASK (TA(TA_MAX) | \
RHOLD(RHOLD_MAX) | \
@@ -131,3 +138,80 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
return 0;
}
EXPORT_SYMBOL(davinci_aemif_setup_timing);
+
+#if defined(CONFIG_OF)
+static int dv_get_value(struct device_node *np, const char *name)
+{
+ u32 data;
+ int ret;
+
+ ret = of_property_read_u32(np, name, &data);
+ if (ret != 0)
+ return ret;
+
+ return data;
+}
+
+int davinci_aemif_setup_timing_of(struct device_node *np)
+{
+ struct device_node *parent;
+ struct davinci_aemif_timing t;
+ void __iomem *base;
+ unsigned val;
+ int asize, ew, ss;
+ int cs;
+ unsigned offset;
+ int ret;
+
+ if (!np)
+ return -ENODEV;
+
+ parent = np->parent;
+ if (!np)
+ return -ENODEV;
+
+ base = of_iomap(parent, 0);
+ if (!base)
+ return -EINVAL;
+
+ cs = dv_get_value(np, "cs");
+ if (cs < 2)
+ return -EINVAL;
+
+ t.ta = dv_get_value(np, "ta");
+ t.rhold = dv_get_value(np, "rhold");
+ t.rstrobe = dv_get_value(np, "rstrobe");
+ t.rsetup = dv_get_value(np, "rsetup");
+ t.whold = dv_get_value(np, "whold");
+ t.wstrobe = dv_get_value(np, "wstrobe");
+ t.wsetup = dv_get_value(np, "wsetup");
+
+ ret = davinci_aemif_setup_timing(&t, base, cs);
+ if (ret != 0)
+ return ret;
+
+ /* setup none timing paramters */
+ offset = A1CR_OFFSET + cs * 4;
+ asize = dv_get_value(np, "asize");
+ ew = dv_get_value(np, "ew");
+ ss = dv_get_value(np, "ss");
+ val = __raw_readl(base + offset);
+ val &= TIMING_MASK;
+ val |= (asize & ACR_ASIZE_MASK);
+ if (ew)
+ val |= ACR_EW_MASK;
+ if (ss)
+ val |= ACR_SS_MASK;
+
+ __raw_writel(val, base + offset);
+
+ iounmap(base);
+ return 0;
+}
+#else
+int davinci_aemif_setup_timing_of(struct device_node *np)
+{
+ return 0;
+}
+#endif
+EXPORT_SYMBOL(davinci_aemif_setup_timing_of);
diff --git a/arch/arm/mach-davinci/include/mach/aemif.h b/arch/arm/mach-davinci/include/mach/aemif.h
index 05b2934..f3bbec6 100644
--- a/arch/arm/mach-davinci/include/mach/aemif.h
+++ b/arch/arm/mach-davinci/include/mach/aemif.h
@@ -33,4 +33,5 @@ struct davinci_aemif_timing {
int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
void __iomem *base, unsigned cs);
+int davinci_aemif_setup_timing_of(struct device_node *np);
#endif
--
1.7.7.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [RFC PATCH 3/7] ARM: davinci: mux: add OF support
2012-01-23 8:56 [RFC PATCH 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
2012-01-23 8:56 ` [RFC PATCH 1/7] ARM: davinci, intc: Add OF support for TI interrupt controller Heiko Schocher
2012-01-23 8:56 ` [RFC PATCH 2/7 v2] ARM: davinci: configure davinci aemif chipselects through OF Heiko Schocher
@ 2012-01-23 8:56 ` Heiko Schocher
2012-01-23 8:56 ` [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: " Heiko Schocher
` (3 subsequent siblings)
6 siblings, 0 replies; 37+ messages in thread
From: Heiko Schocher @ 2012-01-23 8:56 UTC (permalink / raw)
To: linux-arm-kernel
add support for configuring the pinmux on davinci SoC
through OF.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
---
This patch is just a RFC, as I want to get rid of the pin
setup code in board code ... This patch introduces a
davinci_cfg_reg_of() function, which davinci drivers can call,
if they found a pinmux-handle, so used in the following
drivers in this patchserie:
drivers/net/ethernet/ti/davinci_emac
drivers/i2c/busses/i2c-davinci.c
drivers/mtd/nand/davinci_nand.c
Comments are welcome.
.../devicetree/bindings/arm/davinci/mux.txt | 40 +++++++++++
arch/arm/mach-davinci/include/mach/mux.h | 2 +
arch/arm/mach-davinci/mux.c | 73 +++++++++++++++++++-
3 files changed, 114 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/davinci/mux.txt
diff --git a/Documentation/devicetree/bindings/arm/davinci/mux.txt b/Documentation/devicetree/bindings/arm/davinci/mux.txt
new file mode 100644
index 0000000..ecb026a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/mux.txt
@@ -0,0 +1,40 @@
+* Texas Instruments Davinci pinmux
+
+This file provides information, what the device node for the
+davinci pinmux interface contain.
+
+Required properties:
+- compatible: "ti,davinci-pinmux";
+- pins : contains a table with the following colums:
+ mux register: pinmux register
+ register offset: offset in register, which to change
+ mode mask: mode mask
+ mode value: mode value
+
+Optional properties:
+- none
+
+Example (enbw_cmc board):
+ emac_pins: pinmux at 1c14120 {
+ compatible = "ti,davinci-pinmux";
+ reg = <0x14120 0x1000>;
+ pins = < /* muxreg maskoff modemsk muxmode */
+ 2 4 15 8 /* MII TXEN */
+ 2 8 15 8 /* MII TXCLK */
+ 2 12 15 8 /* MII COL */
+ 2 16 15 8 /* MII TXD_3 */
+ 2 20 15 8 /* MII TXD_2 */
+ 2 24 15 8 /* MII TXD_1 */
+ 2 28 15 8 /* MII TXD_0 */
+ 3 8 15 8 /* MII RXER */
+ 3 12 15 8 /* MII CRS */
+ 3 0 15 8 /* MII RXCLK */
+ 3 4 15 8 /* MII RXDV */
+ 3 16 15 8 /* MII RXD_3 */
+ 3 20 15 8 /* MII RXD_2 */
+ 3 24 15 8 /* MII RXD_1 */
+ 3 28 15 8 /* MII RXD_0 */
+ 4 0 15 8 /* MDIO CLK */
+ 4 4 15 8 /* MDIO D */
+ >;
+ };
diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
index a7e92fc..3a62857 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -1205,6 +1205,7 @@ enum davinci_tnetv107x_index {
/* setup pin muxing */
extern int davinci_cfg_reg(unsigned long reg_cfg);
extern int davinci_cfg_reg_list(const short pins[]);
+extern int davinci_cfg_reg_of(struct device_node *);
#else
/* boot loader does it all (no warnings from CONFIG_DAVINCI_MUX_WARNINGS) */
static inline int davinci_cfg_reg(unsigned long reg_cfg) { return 0; }
@@ -1212,6 +1213,7 @@ static inline int davinci_cfg_reg_list(const short pins[])
{
return 0;
}
+static int davinci_cfg_reg_of(struct device_node *) { return 0; };
#endif
#endif /* __INC_MACH_MUX_H */
diff --git a/arch/arm/mach-davinci/mux.c b/arch/arm/mach-davinci/mux.c
index f34a8dc..6b38072 100644
--- a/arch/arm/mach-davinci/mux.c
+++ b/arch/arm/mach-davinci/mux.c
@@ -18,18 +18,21 @@
#include <linux/io.h>
#include <linux/module.h>
#include <linux/spinlock.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
#include <mach/mux.h>
#include <mach/common.h>
static void __iomem *pinmux_base;
+static DEFINE_SPINLOCK(mux_spin_lock);
/*
* Sets the DAVINCI MUX register based on the table
*/
int __init_or_module davinci_cfg_reg(const unsigned long index)
{
- static DEFINE_SPINLOCK(mux_spin_lock);
struct davinci_soc_info *soc_info = &davinci_soc_info;
unsigned long flags;
const struct mux_config *cfg;
@@ -98,6 +101,74 @@ int __init_or_module davinci_cfg_reg(const unsigned long index)
}
EXPORT_SYMBOL(davinci_cfg_reg);
+#ifdef CONFIG_OF
+int davinci_cfg_reg_of(struct device_node *np)
+{
+ unsigned long flags;
+ int pinmux_map_len;
+ const unsigned int *pinmux_map;
+ u32 muxreg, maskoff, modemsk, muxmode;
+ unsigned int reg_orig = 0, reg = 0;
+ unsigned int mask, warn = 0;
+
+ pinmux_map = of_get_property(np, "pins", &pinmux_map_len);
+ if (pinmux_map == NULL) {
+ printk(KERN_ERR "pins is not set!\n");
+ return -EINVAL;
+ }
+
+ pinmux_map_len /= sizeof(unsigned int);
+ if ((pinmux_map_len % 4) != 0) {
+ printk(KERN_ERR "pins format wrong!\n");
+ return -EINVAL;
+ }
+
+ if (!pinmux_base) {
+ pinmux_base = of_iomap(np, 0);
+ if (WARN_ON(!pinmux_base))
+ return -ENOMEM;
+ }
+
+ while (pinmux_map_len > 0) {
+ muxreg = be32_to_cpu(pinmux_map[0]);
+ maskoff = be32_to_cpu(pinmux_map[1]);
+ modemsk = be32_to_cpu(pinmux_map[2]);
+ muxmode = be32_to_cpu(pinmux_map[3]);
+
+ /* Update the mux register in question */
+ if (modemsk) {
+ unsigned tmp1, tmp2;
+
+ spin_lock_irqsave(&mux_spin_lock, flags);
+ reg_orig = __raw_readl(pinmux_base + muxreg);
+
+ mask = (modemsk << maskoff);
+ tmp1 = reg_orig & mask;
+ reg = reg_orig & ~mask;
+
+ tmp2 = (muxmode << maskoff);
+ reg |= tmp2;
+
+ if (tmp1 != tmp2)
+ warn = 1;
+
+ __raw_writel(reg, pinmux_base + muxreg);
+ spin_unlock_irqrestore(&mux_spin_lock, flags);
+ }
+ pinmux_map += 4;
+ pinmux_map_len -= 4;
+ }
+
+ return 0;
+}
+#else
+int davinci_cfg_reg_of(struct device_node *np)
+{
+ return 0;
+}
+#endif
+EXPORT_SYMBOL(davinci_cfg_reg_of);
+
int __init_or_module davinci_cfg_reg_list(const short pins[])
{
int i, error = -EINVAL;
--
1.7.7.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: add OF support
2012-01-23 8:56 [RFC PATCH 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
` (2 preceding siblings ...)
2012-01-23 8:56 ` [RFC PATCH 3/7] ARM: davinci: mux: add OF support Heiko Schocher
@ 2012-01-23 8:56 ` Heiko Schocher
2012-01-23 19:20 ` Anatoly Sivov
2012-01-30 20:22 ` Grant Likely
2012-01-23 8:56 ` [RFC PATCH 5/7] ARM: davinci: i2c: " Heiko Schocher
` (2 subsequent siblings)
6 siblings, 2 replies; 37+ messages in thread
From: Heiko Schocher @ 2012-01-23 8:56 UTC (permalink / raw)
To: linux-arm-kernel
add of support for the davinci_emac driver.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: netdev at vger.kernel.org
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
---
.../bindings/arm/davinci/davinci_emac.txt | 46 ++++++++
drivers/net/ethernet/ti/davinci_emac.c | 111 +++++++++++++++++++-
2 files changed, 156 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
diff --git a/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
new file mode 100644
index 0000000..4e5dc8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
@@ -0,0 +1,46 @@
+* Texas Instruments Davinci EMAC
+
+This file provides information, what the davice node
+for the davinci_emac interface contain.
+
+Required properties:
+- compatible: "ti,davinci-emac";
+- reg: Offset and length of the register set for the device
+- ctrl_reg_offset: offset to control register
+- ctrl_mod_reg_offset: offset to control module register
+- ctrl_ram_offset: offset to control module ram
+- hw_ram_addr: hardware ram addr
+- ctrl_ram_size: size of control module ram
+- version: 1 (EMAC_VERSION_1 for DM644x)
+ 2 (EMAC_VERSION_2 for DM646x)
+- phy-handle: Contains a phandle to an Ethernet PHY.
+ if not, davinci_emac driver defaults to 100/FULL
+- interrupts: interrupt mapping for the davinci emac interrupts sources:
+ 4 sources: <Receive Threshold Interrupt
+ Receive Interrupt
+ Transmit Interrupt
+ Miscellaneous Interrupt>
+- pinmux-handle: Contains a handle to configure the pinmux settings.
+
+Optional properties:
+- local-mac-address : 6 bytes, mac address
+
+Example (enbw_cmc board):
+ eth0: emac at 1e20000 {
+ compatible = "ti,davinci-emac";
+ reg = <0x220000 0x4000>;
+ ctrl_reg_offset = <0x3000>;
+ ctrl_mod_reg_offset = <0x2000>;
+ ctrl_ram_offset = <0>;
+ hw_ram_addr = <0>;
+ ctrl_ram_size = <0x2000>;
+ version = <1>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <33
+ 34
+ 35
+ 36
+ >;
+ interrupt-parent = <&intc>;
+ pinmux-handle = <&emac_pins>;
+ };
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 794ac30..cad7a96 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -58,6 +58,12 @@
#include <linux/io.h>
#include <linux/uaccess.h>
#include <linux/davinci_emac.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_net.h>
+
+#include <mach/mux.h>
#include <asm/irq.h>
#include <asm/page.h>
@@ -339,6 +345,9 @@ struct emac_priv {
u32 rx_addr_type;
atomic_t cur_tx;
const char *phy_id;
+#ifdef CONFIG_OF
+ struct device_node *phy_node;
+#endif
struct phy_device *phydev;
spinlock_t lock;
/*platform specific members*/
@@ -1582,6 +1591,7 @@ static int emac_dev_open(struct net_device *ndev)
cpdma_ctlr_start(priv->dma);
priv->phydev = NULL;
+
/* use the first phy on the bus if pdata did not give us a phy id */
if (!priv->phy_id) {
struct device *phy;
@@ -1759,6 +1769,104 @@ static const struct net_device_ops emac_netdev_ops = {
#endif
};
+#ifdef CONFIG_OF
+static struct emac_platform_data
+ *davinci_emac_of_get_pdata(struct platform_device *pdev,
+ struct emac_priv *priv)
+{
+ struct device_node *np;
+ struct device_node *pinmux_np;
+ struct emac_platform_data *pdata = NULL;
+ const u8 *mac_addr;
+ u32 data;
+ int ret;
+ struct resource temp_res;
+ int irq;
+ int index = 0;
+
+ np = of_find_compatible_node(NULL, NULL, "ti,davinci-emac");
+ if (!np)
+ goto nodata;
+
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ pdata = kzalloc(sizeof(struct emac_platform_data), GFP_KERNEL);
+ if (!pdata)
+ goto nodata;
+ }
+
+ mac_addr = of_get_mac_address(np);
+ if (mac_addr)
+ memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
+
+ ret = of_property_read_u32(np, "ctrl_reg_offset", &data);
+ if (!ret)
+ pdata->ctrl_reg_offset = data;
+
+ ret = of_property_read_u32(np, "ctrl_mod_reg_offset", &data);
+ if (!ret)
+ pdata->ctrl_mod_reg_offset = data;
+
+ ret = of_property_read_u32(np, "ctrl_ram_offset", &data);
+ if (!ret)
+ pdata->ctrl_ram_offset = data;
+
+ ret = of_property_read_u32(np, "hw_ram_addr", &data);
+ if (!ret)
+ pdata->hw_ram_addr = data;
+
+ ret = of_property_read_u32(np, "ctrl_ram_size", &data);
+ if (!ret)
+ pdata->ctrl_ram_size = data;
+
+ ret = of_property_read_u32(np, "rmii_en", &data);
+ if (!ret)
+ pdata->rmii_en = data;
+
+ ret = of_property_read_u32(np, "version", &data);
+ if (!ret)
+ pdata->version = data;
+
+ ret = of_property_read_u32(np, "no_bd_ram", &data);
+ if (!ret)
+ pdata->ctrl_mod_reg_offset = data;
+
+ priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
+ if (!priv->phy_node)
+ pdata->phy_id = "";
+
+ if (!of_address_to_resource(np, 0, &temp_res))
+ memcpy(&pdev->resource[0], &temp_res, sizeof(struct resource));
+
+ index = 0;
+ while (index < 4) {
+ irq = irq_of_parse_and_map(np, index);
+ if (irq > 0) {
+ temp_res.start = irq;
+ temp_res.end = irq;
+ temp_res.flags = IORESOURCE_IRQ;
+ memcpy(&pdev->resource[index + 1], &temp_res,
+ sizeof(struct resource));
+ }
+ index++;
+ }
+
+ pinmux_np = of_parse_phandle(np, "pinmux-handle", 0);
+ if (pinmux_np)
+ davinci_cfg_reg_of(pinmux_np);
+
+ pdev->dev.platform_data = pdata;
+nodata:
+ return pdata;
+}
+#else
+static struct emac_platform_data
+ *davinci_emac_of_get_pdata(struct platform_device *pdev,
+ struct emac_priv *priv)
+{
+ return pdev->dev.platform_data;
+}
+#endif
/**
* davinci_emac_probe: EMAC device probe
* @pdev: The DaVinci EMAC device that we are removing
@@ -1802,7 +1910,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
spin_lock_init(&priv->lock);
- pdata = pdev->dev.platform_data;
+ pdata = davinci_emac_of_get_pdata(pdev, priv);
if (!pdata) {
dev_err(&pdev->dev, "no platform data\n");
rc = -ENODEV;
@@ -1811,6 +1919,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
/* MAC addr and PHY mask , RMII enable info from platform_data */
memcpy(priv->mac_addr, pdata->mac_addr, 6);
+
priv->phy_id = pdata->phy_id;
priv->rmii_en = pdata->rmii_en;
priv->version = pdata->version;
--
1.7.7.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: add OF support
2012-01-23 8:56 ` [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: " Heiko Schocher
@ 2012-01-23 19:20 ` Anatoly Sivov
2012-01-24 6:14 ` Heiko Schocher
2012-01-30 20:22 ` Grant Likely
1 sibling, 1 reply; 37+ messages in thread
From: Anatoly Sivov @ 2012-01-23 19:20 UTC (permalink / raw)
To: linux-arm-kernel
Hello Heiko,
> +* Texas Instruments Davinci EMAC
> +
> +This file provides information, what the davice node
> +for the davinci_emac interface contain.
Please, fix the typo. (davice -> device)
BR, Anatoly
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: add OF support
2012-01-23 19:20 ` Anatoly Sivov
@ 2012-01-24 6:14 ` Heiko Schocher
0 siblings, 0 replies; 37+ messages in thread
From: Heiko Schocher @ 2012-01-24 6:14 UTC (permalink / raw)
To: linux-arm-kernel
Hello Anatoly,
Anatoly Sivov wrote:
> Hello Heiko,
>
>> +* Texas Instruments Davinci EMAC
>> +
>> +This file provides information, what the davice node
>> +for the davinci_emac interface contain.
> Please, fix the typo. (davice -> device)
Ups, thanks! Fix this in the next version, just waiting for more
comments...
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: add OF support
2012-01-23 8:56 ` [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: " Heiko Schocher
2012-01-23 19:20 ` Anatoly Sivov
@ 2012-01-30 20:22 ` Grant Likely
2012-01-31 11:27 ` Heiko Schocher
1 sibling, 1 reply; 37+ messages in thread
From: Grant Likely @ 2012-01-30 20:22 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 23, 2012 at 09:56:04AM +0100, Heiko Schocher wrote:
> add of support for the davinci_emac driver.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: netdev at vger.kernel.org
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Wolfgang Denk <wd@denx.de>
> ---
> .../bindings/arm/davinci/davinci_emac.txt | 46 ++++++++
> drivers/net/ethernet/ti/davinci_emac.c | 111 +++++++++++++++++++-
> 2 files changed, 156 insertions(+), 1 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
> new file mode 100644
> index 0000000..4e5dc8d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
> @@ -0,0 +1,46 @@
> +* Texas Instruments Davinci EMAC
> +
> +This file provides information, what the davice node
> +for the davinci_emac interface contain.
> +
> +Required properties:
> +- compatible: "ti,davinci-emac";
> +- reg: Offset and length of the register set for the device
> +- ctrl_reg_offset: offset to control register
> +- ctrl_mod_reg_offset: offset to control module register
> +- ctrl_ram_offset: offset to control module ram
Should these be explicit properties, or can they be discerned from the
compatible string (which should include the hardware version; see
below).
Also, any custom properties that are specific to a binding really
should include a vendor prefix ('ti,') to avoid namespace collisions
with common bindings.
> +- hw_ram_addr: hardware ram addr
Can this be added as a second tuple in the reg property?
> +- ctrl_ram_size: size of control module ram
> +- version: 1 (EMAC_VERSION_1 for DM644x)
> + 2 (EMAC_VERSION_2 for DM646x)
Don't use a version property. Encode it into the compatible property. ie:
compatible = "ti,davinci-dm6440-emac"; or
compatible = "ti,davinci-dm6460-emac";
You'll also note that I did not use a 'x' as a wildcard. It is always
safer to be explicit about the part number. And have newer parts
claim compatibility with older ones like so:
compatible = "ti,davinci-dm6443-emac", "ti,davinci-dm6440-emac"; (I am
obviously making up numbers here. Fill in appropriate numbers for
your device.
> +- phy-handle: Contains a phandle to an Ethernet PHY.
> + if not, davinci_emac driver defaults to 100/FULL
> +- interrupts: interrupt mapping for the davinci emac interrupts sources:
> + 4 sources: <Receive Threshold Interrupt
> + Receive Interrupt
> + Transmit Interrupt
> + Miscellaneous Interrupt>
> +- pinmux-handle: Contains a handle to configure the pinmux settings.
> +
> +Optional properties:
> +- local-mac-address : 6 bytes, mac address
> +
> +Example (enbw_cmc board):
> + eth0: emac at 1e20000 {
> + compatible = "ti,davinci-emac";
> + reg = <0x220000 0x4000>;
> + ctrl_reg_offset = <0x3000>;
> + ctrl_mod_reg_offset = <0x2000>;
> + ctrl_ram_offset = <0>;
> + hw_ram_addr = <0>;
> + ctrl_ram_size = <0x2000>;
> + version = <1>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <33
> + 34
> + 35
> + 36
> + >;
> + interrupt-parent = <&intc>;
> + pinmux-handle = <&emac_pins>;
> + };
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
> index 794ac30..cad7a96 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
> @@ -58,6 +58,12 @@
> #include <linux/io.h>
> #include <linux/uaccess.h>
> #include <linux/davinci_emac.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_net.h>
> +
> +#include <mach/mux.h>
>
> #include <asm/irq.h>
> #include <asm/page.h>
> @@ -339,6 +345,9 @@ struct emac_priv {
> u32 rx_addr_type;
> atomic_t cur_tx;
> const char *phy_id;
> +#ifdef CONFIG_OF
> + struct device_node *phy_node;
> +#endif
> struct phy_device *phydev;
> spinlock_t lock;
> /*platform specific members*/
> @@ -1582,6 +1591,7 @@ static int emac_dev_open(struct net_device *ndev)
> cpdma_ctlr_start(priv->dma);
>
> priv->phydev = NULL;
> +
> /* use the first phy on the bus if pdata did not give us a phy id */
> if (!priv->phy_id) {
> struct device *phy;
> @@ -1759,6 +1769,104 @@ static const struct net_device_ops emac_netdev_ops = {
> #endif
> };
>
> +#ifdef CONFIG_OF
> +static struct emac_platform_data
> + *davinci_emac_of_get_pdata(struct platform_device *pdev,
> + struct emac_priv *priv)
> +{
> + struct device_node *np;
> + struct device_node *pinmux_np;
> + struct emac_platform_data *pdata = NULL;
> + const u8 *mac_addr;
> + u32 data;
> + int ret;
> + struct resource temp_res;
> + int irq;
> + int index = 0;
> +
> + np = of_find_compatible_node(NULL, NULL, "ti,davinci-emac");
> + if (!np)
> + goto nodata;
> +
> + pdata = pdev->dev.platform_data;
> + if (!pdata) {
> + pdata = kzalloc(sizeof(struct emac_platform_data), GFP_KERNEL);
devm_kzalloc()
> + if (!pdata)
> + goto nodata;
> + }
> +
> + mac_addr = of_get_mac_address(np);
> + if (mac_addr)
> + memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
> +
> + ret = of_property_read_u32(np, "ctrl_reg_offset", &data);
> + if (!ret)
> + pdata->ctrl_reg_offset = data;
> +
> + ret = of_property_read_u32(np, "ctrl_mod_reg_offset", &data);
> + if (!ret)
> + pdata->ctrl_mod_reg_offset = data;
> +
> + ret = of_property_read_u32(np, "ctrl_ram_offset", &data);
> + if (!ret)
> + pdata->ctrl_ram_offset = data;
> +
> + ret = of_property_read_u32(np, "hw_ram_addr", &data);
> + if (!ret)
> + pdata->hw_ram_addr = data;
> +
> + ret = of_property_read_u32(np, "ctrl_ram_size", &data);
> + if (!ret)
> + pdata->ctrl_ram_size = data;
> +
> + ret = of_property_read_u32(np, "rmii_en", &data);
> + if (!ret)
> + pdata->rmii_en = data;
> +
> + ret = of_property_read_u32(np, "version", &data);
> + if (!ret)
> + pdata->version = data;
> +
> + ret = of_property_read_u32(np, "no_bd_ram", &data);
> + if (!ret)
> + pdata->ctrl_mod_reg_offset = data;
Not all these properties are mentioned in the documentation.
> +
> + priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
> + if (!priv->phy_node)
> + pdata->phy_id = "";
> +
> + if (!of_address_to_resource(np, 0, &temp_res))
> + memcpy(&pdev->resource[0], &temp_res, sizeof(struct resource));
Don't use of_address_to_resource. The platform device resource table
will already be populated by the core code so you don't need to call
it here. Besides, it is illegal for drivers to overwrite the
pdev->resource[] table.
> +
> + index = 0;
> + while (index < 4) {
> + irq = irq_of_parse_and_map(np, index);
> + if (irq > 0) {
> + temp_res.start = irq;
> + temp_res.end = irq;
> + temp_res.flags = IORESOURCE_IRQ;
> + memcpy(&pdev->resource[index + 1], &temp_res,
> + sizeof(struct resource));
Same here, the core code will have already populated the irqs into the
resource table for you.
> + }
> + index++;
> + }
> +
> + pinmux_np = of_parse_phandle(np, "pinmux-handle", 0);
> + if (pinmux_np)
> + davinci_cfg_reg_of(pinmux_np);
> +
> + pdev->dev.platform_data = pdata;
> +nodata:
> + return pdata;
> +}
> +#else
> +static struct emac_platform_data
> + *davinci_emac_of_get_pdata(struct platform_device *pdev,
> + struct emac_priv *priv)
> +{
> + return pdev->dev.platform_data;
> +}
> +#endif
> /**
> * davinci_emac_probe: EMAC device probe
> * @pdev: The DaVinci EMAC device that we are removing
> @@ -1802,7 +1910,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
>
> spin_lock_init(&priv->lock);
>
> - pdata = pdev->dev.platform_data;
> + pdata = davinci_emac_of_get_pdata(pdev, priv);
> if (!pdata) {
> dev_err(&pdev->dev, "no platform data\n");
> rc = -ENODEV;
> @@ -1811,6 +1919,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
>
> /* MAC addr and PHY mask , RMII enable info from platform_data */
> memcpy(priv->mac_addr, pdata->mac_addr, 6);
> +
Nit: There are a few instances of unrelated whitespace changes in this
patch.
g.
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: add OF support
2012-01-30 20:22 ` Grant Likely
@ 2012-01-31 11:27 ` Heiko Schocher
2012-02-02 0:19 ` Grant Likely
0 siblings, 1 reply; 37+ messages in thread
From: Heiko Schocher @ 2012-01-31 11:27 UTC (permalink / raw)
To: linux-arm-kernel
Hello Grant,
Grant Likely wrote:
> On Mon, Jan 23, 2012 at 09:56:04AM +0100, Heiko Schocher wrote:
>> add of support for the davinci_emac driver.
>>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree-discuss at lists.ozlabs.org
>> Cc: netdev at vger.kernel.org
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Cc: Wolfgang Denk <wd@denx.de>
>> ---
>> .../bindings/arm/davinci/davinci_emac.txt | 46 ++++++++
>> drivers/net/ethernet/ti/davinci_emac.c | 111 +++++++++++++++++++-
>> 2 files changed, 156 insertions(+), 1 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
>> new file mode 100644
>> index 0000000..4e5dc8d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
>> @@ -0,0 +1,46 @@
>> +* Texas Instruments Davinci EMAC
>> +
>> +This file provides information, what the davice node
>> +for the davinci_emac interface contain.
>> +
>> +Required properties:
>> +- compatible: "ti,davinci-emac";
>> +- reg: Offset and length of the register set for the device
>> +- ctrl_reg_offset: offset to control register
>> +- ctrl_mod_reg_offset: offset to control module register
>> +- ctrl_ram_offset: offset to control module ram
>
> Should these be explicit properties, or can they be discerned from the
> compatible string (which should include the hardware version; see
> below).
Hmm.. I do not know all davinci SoCs ... maybe someone from TI
could answer this? But I think, we could discern this from
the compatible string. I prepare this for v2. Maybe it is Ok,
if I do this only for my hardwareversion and others add this,
if needed? (maybe the better approach, as I can code it, but
have no hw for testing it ... so it maybe is buggy)
> Also, any custom properties that are specific to a binding really
> should include a vendor prefix ('ti,') to avoid namespace collisions
> with common bindings.
Yep, is "ti,davinci-" ok? Also I should use dashes instead
underscores, right?
>> +- hw_ram_addr: hardware ram addr
>
> Can this be added as a second tuple in the reg property?
No, if I know this right, this is used for DMA, and also could be RAM.
>> +- ctrl_ram_size: size of control module ram
>> +- version: 1 (EMAC_VERSION_1 for DM644x)
>> + 2 (EMAC_VERSION_2 for DM646x)
>
> Don't use a version property. Encode it into the compatible property. ie:
>
> compatible = "ti,davinci-dm6440-emac"; or
> compatible = "ti,davinci-dm6460-emac";
>
> You'll also note that I did not use a 'x' as a wildcard. It is always
> safer to be explicit about the part number. And have newer parts
> claim compatibility with older ones like so:
>
> compatible = "ti,davinci-dm6443-emac", "ti,davinci-dm6440-emac"; (I am
> obviously making up numbers here. Fill in appropriate numbers for
> your device.
Ok.
[...]
>> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
>> index 794ac30..cad7a96 100644
>> --- a/drivers/net/ethernet/ti/davinci_emac.c
>> +++ b/drivers/net/ethernet/ti/davinci_emac.c
>> @@ -58,6 +58,12 @@
[...]
>> + pdata = pdev->dev.platform_data;
>> + if (!pdata) {
>> + pdata = kzalloc(sizeof(struct emac_platform_data), GFP_KERNEL);
>
> devm_kzalloc()
fixed.
>> + if (!pdata)
>> + goto nodata;
>> + }
>> +
>> + mac_addr = of_get_mac_address(np);
>> + if (mac_addr)
>> + memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
>> +
>> + ret = of_property_read_u32(np, "ctrl_reg_offset", &data);
>> + if (!ret)
>> + pdata->ctrl_reg_offset = data;
>> +
>> + ret = of_property_read_u32(np, "ctrl_mod_reg_offset", &data);
>> + if (!ret)
>> + pdata->ctrl_mod_reg_offset = data;
>> +
>> + ret = of_property_read_u32(np, "ctrl_ram_offset", &data);
>> + if (!ret)
>> + pdata->ctrl_ram_offset = data;
>> +
>> + ret = of_property_read_u32(np, "hw_ram_addr", &data);
>> + if (!ret)
>> + pdata->hw_ram_addr = data;
>> +
>> + ret = of_property_read_u32(np, "ctrl_ram_size", &data);
>> + if (!ret)
>> + pdata->ctrl_ram_size = data;
>> +
>> + ret = of_property_read_u32(np, "rmii_en", &data);
>> + if (!ret)
>> + pdata->rmii_en = data;
>> +
>> + ret = of_property_read_u32(np, "version", &data);
>> + if (!ret)
>> + pdata->version = data;
>> +
>> + ret = of_property_read_u32(np, "no_bd_ram", &data);
>> + if (!ret)
>> + pdata->ctrl_mod_reg_offset = data;
>
> Not all these properties are mentioned in the documentation.
fixed.
>> +
>> + priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
>> + if (!priv->phy_node)
>> + pdata->phy_id = "";
>> +
>> + if (!of_address_to_resource(np, 0, &temp_res))
>> + memcpy(&pdev->resource[0], &temp_res, sizeof(struct resource));
>
> Don't use of_address_to_resource. The platform device resource table
> will already be populated by the core code so you don't need to call
> it here. Besides, it is illegal for drivers to overwrite the
> pdev->resource[] table.
fix this.
>> +
>> + index = 0;
>> + while (index < 4) {
>> + irq = irq_of_parse_and_map(np, index);
>> + if (irq > 0) {
>> + temp_res.start = irq;
>> + temp_res.end = irq;
>> + temp_res.flags = IORESOURCE_IRQ;
>> + memcpy(&pdev->resource[index + 1], &temp_res,
>> + sizeof(struct resource));
>
> Same here, the core code will have already populated the irqs into the
> resource table for you.
and this. Currently it don't work after this fix, searching
for the reason ...
>> + }
>> + index++;
>> + }
>> +
>> + pinmux_np = of_parse_phandle(np, "pinmux-handle", 0);
>> + if (pinmux_np)
>> + davinci_cfg_reg_of(pinmux_np);
>> +
>> + pdev->dev.platform_data = pdata;
>> +nodata:
>> + return pdata;
>> +}
>> +#else
>> +static struct emac_platform_data
>> + *davinci_emac_of_get_pdata(struct platform_device *pdev,
>> + struct emac_priv *priv)
>> +{
>> + return pdev->dev.platform_data;
>> +}
>> +#endif
>> /**
>> * davinci_emac_probe: EMAC device probe
>> * @pdev: The DaVinci EMAC device that we are removing
>> @@ -1802,7 +1910,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
>>
>> spin_lock_init(&priv->lock);
>>
>> - pdata = pdev->dev.platform_data;
>> + pdata = davinci_emac_of_get_pdata(pdev, priv);
>> if (!pdata) {
>> dev_err(&pdev->dev, "no platform data\n");
>> rc = -ENODEV;
>> @@ -1811,6 +1919,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
>>
>> /* MAC addr and PHY mask , RMII enable info from platform_data */
>> memcpy(priv->mac_addr, pdata->mac_addr, 6);
>> +
>
> Nit: There are a few instances of unrelated whitespace changes in this
> patch.
fixed.
Thanks for the review!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: add OF support
2012-01-31 11:27 ` Heiko Schocher
@ 2012-02-02 0:19 ` Grant Likely
0 siblings, 0 replies; 37+ messages in thread
From: Grant Likely @ 2012-02-02 0:19 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jan 31, 2012 at 12:27:11PM +0100, Heiko Schocher wrote:
> Hello Grant,
>
> Grant Likely wrote:
> > On Mon, Jan 23, 2012 at 09:56:04AM +0100, Heiko Schocher wrote:
> >> add of support for the davinci_emac driver.
> >>
> >> Signed-off-by: Heiko Schocher <hs@denx.de>
> >> Cc: davinci-linux-open-source at linux.davincidsp.com
> >> Cc: linux-arm-kernel at lists.infradead.org
> >> Cc: devicetree-discuss at lists.ozlabs.org
> >> Cc: netdev at vger.kernel.org
> >> Cc: Grant Likely <grant.likely@secretlab.ca>
> >> Cc: Sekhar Nori <nsekhar@ti.com>
> >> Cc: Wolfgang Denk <wd@denx.de>
> >> ---
> >> .../bindings/arm/davinci/davinci_emac.txt | 46 ++++++++
> >> drivers/net/ethernet/ti/davinci_emac.c | 111 +++++++++++++++++++-
> >> 2 files changed, 156 insertions(+), 1 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
> >> new file mode 100644
> >> index 0000000..4e5dc8d
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
> >> @@ -0,0 +1,46 @@
> >> +* Texas Instruments Davinci EMAC
> >> +
> >> +This file provides information, what the davice node
> >> +for the davinci_emac interface contain.
> >> +
> >> +Required properties:
> >> +- compatible: "ti,davinci-emac";
> >> +- reg: Offset and length of the register set for the device
> >> +- ctrl_reg_offset: offset to control register
> >> +- ctrl_mod_reg_offset: offset to control module register
> >> +- ctrl_ram_offset: offset to control module ram
> >
> > Should these be explicit properties, or can they be discerned from the
> > compatible string (which should include the hardware version; see
> > below).
>
> Hmm.. I do not know all davinci SoCs ... maybe someone from TI
> could answer this? But I think, we could discern this from
> the compatible string. I prepare this for v2. Maybe it is Ok,
> if I do this only for my hardwareversion and others add this,
> if needed? (maybe the better approach, as I can code it, but
> have no hw for testing it ... so it maybe is buggy)
>
> > Also, any custom properties that are specific to a binding really
> > should include a vendor prefix ('ti,') to avoid namespace collisions
> > with common bindings.
>
> Yep, is "ti,davinci-" ok? Also I should use dashes instead
> underscores, right?
Correct.
>
> >> +- hw_ram_addr: hardware ram addr
> >
> > Can this be added as a second tuple in the reg property?
>
> No, if I know this right, this is used for DMA, and also could be RAM.
Not getting what you mean here. The second tuple could be omitted if there
isn't a physical address for hardware ram.
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
2012-01-23 8:56 [RFC PATCH 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
` (3 preceding siblings ...)
2012-01-23 8:56 ` [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: " Heiko Schocher
@ 2012-01-23 8:56 ` Heiko Schocher
2012-01-23 20:35 ` Sylwester Nawrocki
` (2 more replies)
2012-01-23 8:56 ` [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller Heiko Schocher
2012-01-23 8:56 ` [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
6 siblings, 3 replies; 37+ messages in thread
From: Heiko Schocher @ 2012-01-23 8:56 UTC (permalink / raw)
To: linux-arm-kernel
add of support for the davinci i2c driver.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-i2c at vger.kernel.org
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
---
.../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++
drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++
2 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
new file mode 100644
index 0000000..94ec670
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
@@ -0,0 +1,39 @@
+* Texas Instruments Davinci I2C
+
+This file provides information, what the device node for the
+davinci i2c interface contain.
+
+Required properties:
+- compatible: "ti,davinci-i2c";
+- reg : Offset and length of the register set for the device
+- id: id of the controller
+
+Recommended properties :
+- interrupts : <a b> where a is the interrupt number and b is a
+ field that represents an encoding of the sense and level
+ information for the interrupt.
+- interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+- clock-frequency : desired I2C bus clock frequency in Hz.
+
+Optional properties:
+- bus-delay: bus delay in usec
+- pinmux-handle: Contains a handle to configure the pinmux settings.
+
+Example (enbw_cmc board):
+ i2c at 1c22000 {
+ compatible = "ti,davinci-i2c";
+ reg = <0x22000 0x1000>;
+ clock-frequency = <100000>;
+ interrupts = <15 2>;
+ interrupt-parent = <&intc>;
+ id = <1>;
+ pinmux-handle = <&i2c1_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dtt at 48 {
+ compatible = "national,lm75";
+ reg = <0x48>;
+ };
+ };
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index a76d85f..6f59fae 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -38,9 +38,12 @@
#include <linux/slab.h>
#include <linux/cpufreq.h>
#include <linux/gpio.h>
+#include <linux/of_i2c.h>
+#include <linux/of_device.h>
#include <mach/hardware.h>
#include <mach/i2c.h>
+#include <mach/mux.h>
/* ----- global defines ----------------------------------------------- */
@@ -635,6 +638,16 @@ static struct i2c_algorithm i2c_davinci_algo = {
.functionality = i2c_davinci_func,
};
+#if defined(CONFIG_OF)
+static const struct of_device_id davinci_i2c_of_match[] = {
+ {.compatible = "ti,davinci-i2c", },
+ {},
+}
+MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
+#else
+#define davinci_i2c_of_match NULL
+#endif
+
static int davinci_i2c_probe(struct platform_device *pdev)
{
struct davinci_i2c_dev *dev;
@@ -676,7 +689,34 @@ static int davinci_i2c_probe(struct platform_device *pdev)
dev->irq = irq->start;
platform_set_drvdata(pdev, dev);
+ if ((dev->dev->platform_data == NULL) &&
+ (pdev->dev.of_node)) {
+ struct device_node *pinmux_np;
+ struct davinci_i2c_platform_data *pdata;
+ u32 prop;
+
+ dev->dev->platform_data = &davinci_i2c_platform_data_default;
+ pdata = &davinci_i2c_platform_data_default;
+ if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
+ &prop))
+ pdata->bus_freq = prop / 1000;
+ if (!of_property_read_u32(pdev->dev.of_node, "bus-delay",
+ &prop))
+ pdata->bus_delay = prop;
+ if (!of_property_read_u32(pdev->dev.of_node, "id",
+ &prop)) {
+ pdev->id = prop;
+ pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
+ sprintf((char *)pdev->dev.init_name,
+ "i2c_davinci.%d", pdev->id);
+ }
+ pinmux_np = of_parse_phandle(pdev->dev.of_node,
+ "pinmux-handle", 0);
+ if (pinmux_np)
+ davinci_cfg_reg_of(pinmux_np);
+ }
dev->clk = clk_get(&pdev->dev, NULL);
+
if (IS_ERR(dev->clk)) {
r = -ENODEV;
goto err_free_mem;
@@ -711,6 +751,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
adap->algo = &i2c_davinci_algo;
adap->dev.parent = &pdev->dev;
adap->timeout = DAVINCI_I2C_TIMEOUT;
+ adap->dev.of_node = pdev->dev.of_node;
adap->nr = pdev->id;
r = i2c_add_numbered_adapter(adap);
@@ -718,6 +759,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failure adding adapter\n");
goto err_free_irq;
}
+ of_i2c_register_devices(adap);
return 0;
@@ -809,6 +851,7 @@ static struct platform_driver davinci_i2c_driver = {
.name = "i2c_davinci",
.owner = THIS_MODULE,
.pm = davinci_i2c_pm_ops,
+ .of_match_table = davinci_i2c_of_match,
},
};
--
1.7.7.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
2012-01-23 8:56 ` [RFC PATCH 5/7] ARM: davinci: i2c: " Heiko Schocher
@ 2012-01-23 20:35 ` Sylwester Nawrocki
2012-01-24 7:18 ` Heiko Schocher
2012-01-30 20:04 ` Grant Likely
2012-02-13 23:37 ` Ben Dooks
2 siblings, 1 reply; 37+ messages in thread
From: Sylwester Nawrocki @ 2012-01-23 20:35 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On 01/23/2012 09:56 AM, Heiko Schocher wrote:
> add of support for the davinci i2c driver.
>
> Signed-off-by: Heiko Schocher<hs@denx.de>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-i2c at vger.kernel.org
> Cc: Ben Dooks<ben-linux@fluff.org>
> Cc: Wolfram Sang<w.sang@pengutronix.de>
> Cc: Grant Likely<grant.likely@secretlab.ca>
> Cc: Sekhar Nori<nsekhar@ti.com>
> Cc: Wolfgang Denk<wd@denx.de>
> ---
> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++
> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++
> 2 files changed, 82 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> new file mode 100644
> index 0000000..94ec670
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> @@ -0,0 +1,39 @@
> +* Texas Instruments Davinci I2C
> +
> +This file provides information, what the device node for the
> +davinci i2c interface contain.
> +
> +Required properties:
> +- compatible: "ti,davinci-i2c";
> +- reg : Offset and length of the register set for the device
> +- id: id of the controller
I was wondering whether we're supposed to use "cell-index" property name
for such a device instance index? or doesn't it really matter and "id" is
fine? Such an IP instance index seems quite common so I thought it could
be easier to follow to use standard name.
--
Regards,
Sylwester
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
2012-01-23 20:35 ` Sylwester Nawrocki
@ 2012-01-24 7:18 ` Heiko Schocher
2012-01-24 9:51 ` Sylwester Nawrocki
0 siblings, 1 reply; 37+ messages in thread
From: Heiko Schocher @ 2012-01-24 7:18 UTC (permalink / raw)
To: linux-arm-kernel
Hello Sylwester,
Sylwester Nawrocki wrote:
> Hello,
>
> On 01/23/2012 09:56 AM, Heiko Schocher wrote:
>> add of support for the davinci i2c driver.
>>
>> Signed-off-by: Heiko Schocher<hs@denx.de>
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree-discuss at lists.ozlabs.org
>> Cc: linux-i2c at vger.kernel.org
>> Cc: Ben Dooks<ben-linux@fluff.org>
>> Cc: Wolfram Sang<w.sang@pengutronix.de>
>> Cc: Grant Likely<grant.likely@secretlab.ca>
>> Cc: Sekhar Nori<nsekhar@ti.com>
>> Cc: Wolfgang Denk<wd@denx.de>
>> ---
>> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++
>> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++
>> 2 files changed, 82 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
>> new file mode 100644
>> index 0000000..94ec670
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
>> @@ -0,0 +1,39 @@
>> +* Texas Instruments Davinci I2C
>> +
>> +This file provides information, what the device node for the
>> +davinci i2c interface contain.
>> +
>> +Required properties:
>> +- compatible: "ti,davinci-i2c";
>> +- reg : Offset and length of the register set for the device
>> +- id: id of the controller
>
> I was wondering whether we're supposed to use "cell-index" property name
> for such a device instance index? or doesn't it really matter and "id" is
> fine? Such an IP instance index seems quite common so I thought it could
> be easier to follow to use standard name.
I just copied the "name" from "struct davinci_nand_pdata" ... it is
used in the davinci_nand driver as chipselect ... maybe it is better
I rename this to "chipselect" ?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
2012-01-24 7:18 ` Heiko Schocher
@ 2012-01-24 9:51 ` Sylwester Nawrocki
2012-01-30 20:13 ` Grant Likely
0 siblings, 1 reply; 37+ messages in thread
From: Sylwester Nawrocki @ 2012-01-24 9:51 UTC (permalink / raw)
To: linux-arm-kernel
Hello Heiko,
On 01/24/2012 08:18 AM, Heiko Schocher wrote:
>> On 01/23/2012 09:56 AM, Heiko Schocher wrote:
>>> add of support for the davinci i2c driver.
>>>
>>> Signed-off-by: Heiko Schocher<hs@denx.de>
>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: devicetree-discuss at lists.ozlabs.org
>>> Cc: linux-i2c at vger.kernel.org
>>> Cc: Ben Dooks<ben-linux@fluff.org>
>>> Cc: Wolfram Sang<w.sang@pengutronix.de>
>>> Cc: Grant Likely<grant.likely@secretlab.ca>
>>> Cc: Sekhar Nori<nsekhar@ti.com>
>>> Cc: Wolfgang Denk<wd@denx.de>
>>> ---
>>> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++
>>> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++
>>> 2 files changed, 82 insertions(+), 0 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
>>> new file mode 100644
>>> index 0000000..94ec670
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
>>> @@ -0,0 +1,39 @@
>>> +* Texas Instruments Davinci I2C
>>> +
>>> +This file provides information, what the device node for the
>>> +davinci i2c interface contain.
>>> +
>>> +Required properties:
>>> +- compatible: "ti,davinci-i2c";
>>> +- reg : Offset and length of the register set for the device
>>> +- id: id of the controller
>>
>> I was wondering whether we're supposed to use "cell-index" property name
>> for such a device instance index? or doesn't it really matter and "id" is
>> fine? Such an IP instance index seems quite common so I thought it could
>> be easier to follow to use standard name.
>
> I just copied the "name" from "struct davinci_nand_pdata" ... it is
> used in the davinci_nand driver as chipselect ... maybe it is better
> I rename this to "chipselect" ?
>From what I can see the 'id' property is used to determine I2C adapter
number. In that case 'id' seems more correct than "chipselect". Are you
sure there is a chip select functionality in I2C controller ?
It seems that your id is just an index of I2C controller in hardware.
I would personally just use cell-index for that, but I'm not a dt expert,
someone nay correct me.
For instance, this is how "cell-index" semantics is described in case
of MPC5200 Programmable Serial Controllers (from Documentation/devicetree/
bindings/powerpc/fsl/mpc5200.txt):
"fsl,mpc5200-psc nodes
---------------------
The PSCs should include a cell-index which is the index of the PSC in
hardware. cell-index is used to determine which shared SoC registers to
use when setting up PSC clocking. cell-index number starts at '0'. ie:
PSC1 has 'cell-index = <0>'
PSC4 has 'cell-index = <3>'"
Moreover you seem to overwrite platform device name and id,
if (!of_property_read_u32(pdev->dev.of_node, "id",
+ &prop)) {
+ pdev->id = prop;
+ pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
+ sprintf((char *)pdev->dev.init_name,
+ "i2c_davinci.%d", pdev->id);
I'm not sure if it is a good practice. If you want to pre-define platform
device name (likely for the clock API to work), it might be more appropriate
to use OF_DEV_AUXDATA in the machine code, until there are clock bindings
available.
Then you would just use your 'id'/'cell-index' property to set an I2C adapter
number.
--
Regards,
Sylwester
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
2012-01-24 9:51 ` Sylwester Nawrocki
@ 2012-01-30 20:13 ` Grant Likely
2012-01-31 7:31 ` Heiko Schocher
2012-02-05 20:44 ` Sylwester Nawrocki
0 siblings, 2 replies; 37+ messages in thread
From: Grant Likely @ 2012-01-30 20:13 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jan 24, 2012 at 10:51:50AM +0100, Sylwester Nawrocki wrote:
> Hello Heiko,
>
> On 01/24/2012 08:18 AM, Heiko Schocher wrote:
> >> On 01/23/2012 09:56 AM, Heiko Schocher wrote:
> >>> add of support for the davinci i2c driver.
> >>>
> >>> Signed-off-by: Heiko Schocher<hs@denx.de>
> >>> Cc: davinci-linux-open-source at linux.davincidsp.com
> >>> Cc: linux-arm-kernel at lists.infradead.org
> >>> Cc: devicetree-discuss at lists.ozlabs.org
> >>> Cc: linux-i2c at vger.kernel.org
> >>> Cc: Ben Dooks<ben-linux@fluff.org>
> >>> Cc: Wolfram Sang<w.sang@pengutronix.de>
> >>> Cc: Grant Likely<grant.likely@secretlab.ca>
> >>> Cc: Sekhar Nori<nsekhar@ti.com>
> >>> Cc: Wolfgang Denk<wd@denx.de>
> >>> ---
> >>> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++
> >>> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++
> >>> 2 files changed, 82 insertions(+), 0 deletions(-)
> >>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> >>> new file mode 100644
> >>> index 0000000..94ec670
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> >>> @@ -0,0 +1,39 @@
> >>> +* Texas Instruments Davinci I2C
> >>> +
> >>> +This file provides information, what the device node for the
> >>> +davinci i2c interface contain.
> >>> +
> >>> +Required properties:
> >>> +- compatible: "ti,davinci-i2c";
> >>> +- reg : Offset and length of the register set for the device
> >>> +- id: id of the controller
> >>
> >> I was wondering whether we're supposed to use "cell-index" property name
> >> for such a device instance index? or doesn't it really matter and "id" is
> >> fine? Such an IP instance index seems quite common so I thought it could
> >> be easier to follow to use standard name.
> >
> > I just copied the "name" from "struct davinci_nand_pdata" ... it is
> > used in the davinci_nand driver as chipselect ... maybe it is better
> > I rename this to "chipselect" ?
>
> From what I can see the 'id' property is used to determine I2C adapter
> number. In that case 'id' seems more correct than "chipselect". Are you
> sure there is a chip select functionality in I2C controller ?
>
> It seems that your id is just an index of I2C controller in hardware.
> I would personally just use cell-index for that, but I'm not a dt expert,
> someone nay correct me.
The whole 'cell-index' or 'id' thing is a BadIdea(tm). Don't use it, and tell
others not to do it when you see it. There are some legacy uses in powerpc,
but those were written before I and others knew better.
The *only* situation where cell-index is acceptable is when the driver
absolutely must know which hardware instance it is driving because it
needs to calculate offsets in a shared register or something, and even
then it should not be used to set the pdev->id field. That situation
does not look to be the case here.
If you're using the DT, then let the core code dynamically assign the
i2c adapter number.
> Moreover you seem to overwrite platform device name and id,
>
> if (!of_property_read_u32(pdev->dev.of_node, "id",
> + &prop)) {
> + pdev->id = prop;
> + pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
> + sprintf((char *)pdev->dev.init_name,
> + "i2c_davinci.%d", pdev->id);
>
> I'm not sure if it is a good practice.
No, it is not good practice. At this point the device is already
registered. Changing the value of pdev->id will cause problems in the
core code because the /sysfs files will have already been created.
> If you want to pre-define platform
> device name (likely for the clock API to work), it might be more appropriate
> to use OF_DEV_AUXDATA in the machine code, until there are clock bindings
> available.
Yes, use OF_DEV_AUXDATA, but *only* if you need it for hooking up
clocks, regulators, or similar. Don't use it just because you want
the device to have a different name for cosmetic reasons. The need
for AUXDATA should go away once the DT clock binding code is merged.
g.
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
2012-01-30 20:13 ` Grant Likely
@ 2012-01-31 7:31 ` Heiko Schocher
2012-02-05 20:44 ` Sylwester Nawrocki
1 sibling, 0 replies; 37+ messages in thread
From: Heiko Schocher @ 2012-01-31 7:31 UTC (permalink / raw)
To: linux-arm-kernel
Hello Grant,
Grant Likely wrote:
> On Tue, Jan 24, 2012 at 10:51:50AM +0100, Sylwester Nawrocki wrote:
>> Hello Heiko,
>>
>> On 01/24/2012 08:18 AM, Heiko Schocher wrote:
>>>> On 01/23/2012 09:56 AM, Heiko Schocher wrote:
>>>>> add of support for the davinci i2c driver.
>>>>>
>>>>> Signed-off-by: Heiko Schocher<hs@denx.de>
>>>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>>>> Cc: linux-arm-kernel at lists.infradead.org
>>>>> Cc: devicetree-discuss at lists.ozlabs.org
>>>>> Cc: linux-i2c at vger.kernel.org
>>>>> Cc: Ben Dooks<ben-linux@fluff.org>
>>>>> Cc: Wolfram Sang<w.sang@pengutronix.de>
>>>>> Cc: Grant Likely<grant.likely@secretlab.ca>
>>>>> Cc: Sekhar Nori<nsekhar@ti.com>
>>>>> Cc: Wolfgang Denk<wd@denx.de>
>>>>> ---
>>>>> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++
>>>>> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++
>>>>> 2 files changed, 82 insertions(+), 0 deletions(-)
>>>>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
[...]
>> Moreover you seem to overwrite platform device name and id,
>>
>> if (!of_property_read_u32(pdev->dev.of_node, "id",
>> + &prop)) {
>> + pdev->id = prop;
>> + pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
>> + sprintf((char *)pdev->dev.init_name,
>> + "i2c_davinci.%d", pdev->id);
>>
>> I'm not sure if it is a good practice.
>
> No, it is not good practice. At this point the device is already
> registered. Changing the value of pdev->id will cause problems in the
> core code because the /sysfs files will have already been created.
>
>> If you want to pre-define platform
>> device name (likely for the clock API to work), it might be more appropriate
>> to use OF_DEV_AUXDATA in the machine code, until there are clock bindings
>> available.
>
> Yes, use OF_DEV_AUXDATA, but *only* if you need it for hooking up
> clocks, regulators, or similar. Don't use it just because you want
> the device to have a different name for cosmetic reasons. The need
> for AUXDATA should go away once the DT clock binding code is merged.
I now use OF_DEV_AUXDATA in board code, "id" nor "cell-index" used:
struct of_dev_auxdata enbw_cmc_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01e28000, "i2c_davinci.2", NULL),
{}
};
This is needed for hooking up clocks, see:
arch/arm/mach-davinci/da850.c
static struct clk_lookup da850_clks
[...]
CLK("i2c_davinci.1", NULL, &i2c0_clk),
[...]
CLK("i2c_davinci.2", NULL, &i2c1_clk),
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
2012-01-30 20:13 ` Grant Likely
2012-01-31 7:31 ` Heiko Schocher
@ 2012-02-05 20:44 ` Sylwester Nawrocki
1 sibling, 0 replies; 37+ messages in thread
From: Sylwester Nawrocki @ 2012-02-05 20:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi Grant,
On 01/30/2012 09:13 PM, Grant Likely wrote:
> The whole 'cell-index' or 'id' thing is a BadIdea(tm). Don't use it, and tell
> others not to do it when you see it. There are some legacy uses in powerpc,
> but those were written before I and others knew better.
>
> The *only* situation where cell-index is acceptable is when the driver
> absolutely must know which hardware instance it is driving because it
> needs to calculate offsets in a shared register or something, and even
> then it should not be used to set the pdev->id field. That situation
> does not look to be the case here.
Thanks a lot for the clarification. Some media device drivers use the pdev->id
field to enumerate hardware entities which are shown to user space libraries/
applications through the media device interface:
<http://linuxtv.org/downloads/v4l-dvb-apis/media-ioc-enum-entities.html>
The entity name is initialized from dev_name(&pdev->dev), which in DT case
will be rather random string AFAICS. Is using 'cell-index' property justified
in such cases ?
> If you're using the DT, then let the core code dynamically assign the
> i2c adapter number.
Then it means that all uses if i2c_get_adapter() that take an I2C adapter
number as an argument need to be converted accordingly, e.g. we need an OF
version of i2c_get_adapter() ?
The V4L core provides v4l2_i2c_new_subdev_board() function which is used
by the video bridge drivers to register its sub-devices - I2C clients
(usually image sensors or video encoders). The I2C bus ids are usually
provided as platform data to the bridge driver. Sounds like all this will
need to be reworked quite significantly for DT support.
---
Thanks,
Sylwester
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
2012-01-23 8:56 ` [RFC PATCH 5/7] ARM: davinci: i2c: " Heiko Schocher
2012-01-23 20:35 ` Sylwester Nawrocki
@ 2012-01-30 20:04 ` Grant Likely
2012-01-31 7:14 ` Heiko Schocher
2012-02-13 23:37 ` Ben Dooks
2 siblings, 1 reply; 37+ messages in thread
From: Grant Likely @ 2012-01-30 20:04 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 23, 2012 at 09:56:05AM +0100, Heiko Schocher wrote:
> add of support for the davinci i2c driver.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-i2c at vger.kernel.org
> Cc: Ben Dooks <ben-linux@fluff.org>
> Cc: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Wolfgang Denk <wd@denx.de>
Hi Heiko,
comments below.
> ---
> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++
> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++
> 2 files changed, 82 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> new file mode 100644
> index 0000000..94ec670
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> @@ -0,0 +1,39 @@
> +* Texas Instruments Davinci I2C
> +
> +This file provides information, what the device node for the
> +davinci i2c interface contain.
> +
> +Required properties:
> +- compatible: "ti,davinci-i2c";
> +- reg : Offset and length of the register set for the device
> +- id: id of the controller
Don't use an 'id' property. i2c bus numbers should be dynamically
assigned when using the device tree.
> +
> +Recommended properties :
> +- interrupts : <a b> where a is the interrupt number and b is a
> + field that represents an encoding of the sense and level
> + information for the interrupt.
This is inaccurate. It is entirely defined by the interrupt
controller. All you need to say here is that this is a standard
interrupts property.
> +- interrupt-parent : the phandle for the interrupt controller that
> + services interrupts for this device.
Don't even mention this one. It can often be inherited from a parent
node.
> +- clock-frequency : desired I2C bus clock frequency in Hz.
> +
> +Optional properties:
> +- bus-delay: bus delay in usec
> +- pinmux-handle: Contains a handle to configure the pinmux settings.
> +
> +Example (enbw_cmc board):
> + i2c at 1c22000 {
> + compatible = "ti,davinci-i2c";
> + reg = <0x22000 0x1000>;
> + clock-frequency = <100000>;
> + interrupts = <15 2>;
> + interrupt-parent = <&intc>;
> + id = <1>;
> + pinmux-handle = <&i2c1_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dtt at 48 {
> + compatible = "national,lm75";
> + reg = <0x48>;
> + };
> + };
> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
> index a76d85f..6f59fae 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -38,9 +38,12 @@
> #include <linux/slab.h>
> #include <linux/cpufreq.h>
> #include <linux/gpio.h>
> +#include <linux/of_i2c.h>
> +#include <linux/of_device.h>
>
> #include <mach/hardware.h>
> #include <mach/i2c.h>
> +#include <mach/mux.h>
>
> /* ----- global defines ----------------------------------------------- */
>
> @@ -635,6 +638,16 @@ static struct i2c_algorithm i2c_davinci_algo = {
> .functionality = i2c_davinci_func,
> };
>
> +#if defined(CONFIG_OF)
> +static const struct of_device_id davinci_i2c_of_match[] = {
> + {.compatible = "ti,davinci-i2c", },
> + {},
> +}
> +MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
> +#else
> +#define davinci_i2c_of_match NULL
> +#endif
The #else clause can be dropped if you use the of_match_ptr() macro
when referencing it.
> +
> static int davinci_i2c_probe(struct platform_device *pdev)
> {
> struct davinci_i2c_dev *dev;
> @@ -676,7 +689,34 @@ static int davinci_i2c_probe(struct platform_device *pdev)
> dev->irq = irq->start;
> platform_set_drvdata(pdev, dev);
>
> + if ((dev->dev->platform_data == NULL) &&
> + (pdev->dev.of_node)) {
> + struct device_node *pinmux_np;
> + struct davinci_i2c_platform_data *pdata;
> + u32 prop;
> +
> + dev->dev->platform_data = &davinci_i2c_platform_data_default;
Don't do this. What if a davinci part shows up with two i2c busses?
Use devm_kzalloc() instead.
> + pdata = &davinci_i2c_platform_data_default;
> + if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
> + &prop))
> + pdata->bus_freq = prop / 1000;
> + if (!of_property_read_u32(pdev->dev.of_node, "bus-delay",
> + &prop))
> + pdata->bus_delay = prop;
> + if (!of_property_read_u32(pdev->dev.of_node, "id",
> + &prop)) {
> + pdev->id = prop;
> + pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
> + sprintf((char *)pdev->dev.init_name,
> + "i2c_davinci.%d", pdev->id);
Blech! Drop this. Leave the core code to set the device name.
> dev->clk = clk_get(&pdev->dev, NULL);
> +
> if (IS_ERR(dev->clk)) {
Nit: unrelated whitespace change
> r = -ENODEV;
> goto err_free_mem;
> @@ -711,6 +751,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
> adap->algo = &i2c_davinci_algo;
> adap->dev.parent = &pdev->dev;
> adap->timeout = DAVINCI_I2C_TIMEOUT;
> + adap->dev.of_node = pdev->dev.of_node;
>
> adap->nr = pdev->id;
> r = i2c_add_numbered_adapter(adap);
> @@ -718,6 +759,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
> dev_err(&pdev->dev, "failure adding adapter\n");
> goto err_free_irq;
> }
> + of_i2c_register_devices(adap);
>
> return 0;
>
> @@ -809,6 +851,7 @@ static struct platform_driver davinci_i2c_driver = {
> .name = "i2c_davinci",
> .owner = THIS_MODULE,
> .pm = davinci_i2c_pm_ops,
> + .of_match_table = davinci_i2c_of_match,
> },
> };
>
> --
> 1.7.7.5
>
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
2012-01-30 20:04 ` Grant Likely
@ 2012-01-31 7:14 ` Heiko Schocher
0 siblings, 0 replies; 37+ messages in thread
From: Heiko Schocher @ 2012-01-31 7:14 UTC (permalink / raw)
To: linux-arm-kernel
Hello Grant,
Grant Likely wrote:
> On Mon, Jan 23, 2012 at 09:56:05AM +0100, Heiko Schocher wrote:
>> add of support for the davinci i2c driver.
>>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree-discuss at lists.ozlabs.org
>> Cc: linux-i2c at vger.kernel.org
>> Cc: Ben Dooks <ben-linux@fluff.org>
>> Cc: Wolfram Sang <w.sang@pengutronix.de>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Cc: Wolfgang Denk <wd@denx.de>
>
> Hi Heiko,
>
> comments below.
Thanks!
>> ---
>> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++
>> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++
>> 2 files changed, 82 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
>> new file mode 100644
>> index 0000000..94ec670
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
>> @@ -0,0 +1,39 @@
>> +* Texas Instruments Davinci I2C
>> +
>> +This file provides information, what the device node for the
>> +davinci i2c interface contain.
>> +
>> +Required properties:
>> +- compatible: "ti,davinci-i2c";
>> +- reg : Offset and length of the register set for the device
>> +- id: id of the controller
>
> Don't use an 'id' property. i2c bus numbers should be dynamically
> assigned when using the device tree.
Yep, removed!
>> +
>> +Recommended properties :
>> +- interrupts : <a b> where a is the interrupt number and b is a
>> + field that represents an encoding of the sense and level
>> + information for the interrupt.
>
> This is inaccurate. It is entirely defined by the interrupt
> controller. All you need to say here is that this is a standard
> interrupts property.
fixed.
>> +- interrupt-parent : the phandle for the interrupt controller that
>> + services interrupts for this device.
>
> Don't even mention this one. It can often be inherited from a parent
> node.
deleted.
[...]
>> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
>> index a76d85f..6f59fae 100644
>> --- a/drivers/i2c/busses/i2c-davinci.c
>> +++ b/drivers/i2c/busses/i2c-davinci.c
>> @@ -38,9 +38,12 @@
>> #include <linux/slab.h>
>> #include <linux/cpufreq.h>
>> #include <linux/gpio.h>
>> +#include <linux/of_i2c.h>
>> +#include <linux/of_device.h>
>>
>> #include <mach/hardware.h>
>> #include <mach/i2c.h>
>> +#include <mach/mux.h>
>>
>> /* ----- global defines ----------------------------------------------- */
>>
>> @@ -635,6 +638,16 @@ static struct i2c_algorithm i2c_davinci_algo = {
>> .functionality = i2c_davinci_func,
>> };
>>
>> +#if defined(CONFIG_OF)
>> +static const struct of_device_id davinci_i2c_of_match[] = {
>> + {.compatible = "ti,davinci-i2c", },
>> + {},
>> +}
>> +MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
>> +#else
>> +#define davinci_i2c_of_match NULL
>> +#endif
>
> The #else clause can be dropped if you use the of_match_ptr() macro
> when referencing it.
removed.
>> +
>> static int davinci_i2c_probe(struct platform_device *pdev)
>> {
>> struct davinci_i2c_dev *dev;
>> @@ -676,7 +689,34 @@ static int davinci_i2c_probe(struct platform_device *pdev)
>> dev->irq = irq->start;
>> platform_set_drvdata(pdev, dev);
>>
>> + if ((dev->dev->platform_data == NULL) &&
>> + (pdev->dev.of_node)) {
>> + struct device_node *pinmux_np;
>> + struct davinci_i2c_platform_data *pdata;
>> + u32 prop;
>> +
>> + dev->dev->platform_data = &davinci_i2c_platform_data_default;
>
> Don't do this. What if a davinci part shows up with two i2c busses?
> Use devm_kzalloc() instead.
Fixed.
>> + pdata = &davinci_i2c_platform_data_default;
>> + if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
>> + &prop))
>> + pdata->bus_freq = prop / 1000;
>> + if (!of_property_read_u32(pdev->dev.of_node, "bus-delay",
>> + &prop))
>> + pdata->bus_delay = prop;
>> + if (!of_property_read_u32(pdev->dev.of_node, "id",
>> + &prop)) {
>> + pdev->id = prop;
>> + pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
>> + sprintf((char *)pdev->dev.init_name,
>> + "i2c_davinci.%d", pdev->id);
>
> Blech! Drop this. Leave the core code to set the device name.
completely removed.
>> dev->clk = clk_get(&pdev->dev, NULL);
>> +
>> if (IS_ERR(dev->clk)) {
>
> Nit: unrelated whitespace change
Ups, good catch, fixed.
[...]
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
2012-01-23 8:56 ` [RFC PATCH 5/7] ARM: davinci: i2c: " Heiko Schocher
2012-01-23 20:35 ` Sylwester Nawrocki
2012-01-30 20:04 ` Grant Likely
@ 2012-02-13 23:37 ` Ben Dooks
2012-02-14 7:16 ` Heiko Schocher
2 siblings, 1 reply; 37+ messages in thread
From: Ben Dooks @ 2012-02-13 23:37 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 23, 2012 at 09:56:05AM +0100, Heiko Schocher wrote:
> add of support for the davinci i2c driver.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-i2c at vger.kernel.org
> Cc: Ben Dooks <ben-linux@fluff.org>
> Cc: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Wolfgang Denk <wd@denx.de>
> ---
> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++
> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++
> 2 files changed, 82 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> new file mode 100644
> index 0000000..94ec670
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> @@ -0,0 +1,39 @@
> +* Texas Instruments Davinci I2C
> +
> +This file provides information, what the device node for the
> +davinci i2c interface contain.
> +
> +Required properties:
> +- compatible: "ti,davinci-i2c";
> +- reg : Offset and length of the register set for the device
> +- id: id of the controller
> +
> +Recommended properties :
> +- interrupts : <a b> where a is the interrupt number and b is a
> + field that represents an encoding of the sense and level
> + information for the interrupt.
> +- interrupt-parent : the phandle for the interrupt controller that
> + services interrupts for this device.
> +- clock-frequency : desired I2C bus clock frequency in Hz.
> +Optional properties:
> +- bus-delay: bus delay in usec
bus_delay sounds rather like frequency in a different name, what is it for?
+- pinmux-handle: Contains a handle to configure the pinmux settings.
> +
> +Example (enbw_cmc board):
> + i2c at 1c22000 {
> + compatible = "ti,davinci-i2c";
> + reg = <0x22000 0x1000>;
> + clock-frequency = <100000>;
> + interrupts = <15 2>;
> + interrupt-parent = <&intc>;
> + id = <1>;
> + pinmux-handle = <&i2c1_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dtt at 48 {
> + compatible = "national,lm75";
> + reg = <0x48>;
> + };
> + };
> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
> index a76d85f..6f59fae 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -38,9 +38,12 @@
> #include <linux/slab.h>
> #include <linux/cpufreq.h>
> #include <linux/gpio.h>
> +#include <linux/of_i2c.h>
> +#include <linux/of_device.h>
>
> #include <mach/hardware.h>
> #include <mach/i2c.h>
> +#include <mach/mux.h>
>
> /* ----- global defines ----------------------------------------------- */
>
> @@ -635,6 +638,16 @@ static struct i2c_algorithm i2c_davinci_algo = {
> .functionality = i2c_davinci_func,
> };
>
> +#if defined(CONFIG_OF)
> +static const struct of_device_id davinci_i2c_of_match[] = {
> + {.compatible = "ti,davinci-i2c", },
> + {},
> +}
> +MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
> +#else
> +#define davinci_i2c_of_match NULL
> +#endif
see of_match_ptr() and you won't need the #else.
> static int davinci_i2c_probe(struct platform_device *pdev)
> {
> struct davinci_i2c_dev *dev;
> @@ -676,7 +689,34 @@ static int davinci_i2c_probe(struct platform_device *pdev)
> dev->irq = irq->start;
> platform_set_drvdata(pdev, dev);
>
> + if ((dev->dev->platform_data == NULL) &&
> + (pdev->dev.of_node)) {
If there's platform_data an of_node, what happens then?
> + struct device_node *pinmux_np;
> + struct davinci_i2c_platform_data *pdata;
> + u32 prop;
> +
> + dev->dev->platform_data = &davinci_i2c_platform_data_default;
> + pdata = &davinci_i2c_platform_data_default;
> + if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
> + &prop))
> + pdata->bus_freq = prop / 1000;
> + if (!of_property_read_u32(pdev->dev.of_node, "bus-delay",
> + &prop))
> + pdata->bus_delay = prop;
> + if (!of_property_read_u32(pdev->dev.of_node, "id",
> + &prop)) {
> + pdev->id = prop;
> + pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
> + sprintf((char *)pdev->dev.init_name,
> + "i2c_davinci.%d", pdev->id);
> + }
Is this _really_ necessary, looks a bit of a hack to me.
> + pinmux_np = of_parse_phandle(pdev->dev.of_node,
> + "pinmux-handle", 0);
> + if (pinmux_np)
> + davinci_cfg_reg_of(pinmux_np);
> + }
> dev->clk = clk_get(&pdev->dev, NULL);
> +
> if (IS_ERR(dev->clk)) {
> r = -ENODEV;
> goto err_free_mem;
> @@ -711,6 +751,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
> adap->algo = &i2c_davinci_algo;
> adap->dev.parent = &pdev->dev;
> adap->timeout = DAVINCI_I2C_TIMEOUT;
> + adap->dev.of_node = pdev->dev.of_node;
>
> adap->nr = pdev->id;
> r = i2c_add_numbered_adapter(adap);
> @@ -718,6 +759,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
> dev_err(&pdev->dev, "failure adding adapter\n");
> goto err_free_irq;
> }
> + of_i2c_register_devices(adap);
>
> return 0;
>
> @@ -809,6 +851,7 @@ static struct platform_driver davinci_i2c_driver = {
> .name = "i2c_davinci",
> .owner = THIS_MODULE,
> .pm = davinci_i2c_pm_ops,
> + .of_match_table = davinci_i2c_of_match,
> },
> };
>
> --
> 1.7.7.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
2012-02-13 23:37 ` Ben Dooks
@ 2012-02-14 7:16 ` Heiko Schocher
0 siblings, 0 replies; 37+ messages in thread
From: Heiko Schocher @ 2012-02-14 7:16 UTC (permalink / raw)
To: linux-arm-kernel
Hello Ben,
Ben Dooks wrote:
> On Mon, Jan 23, 2012 at 09:56:05AM +0100, Heiko Schocher wrote:
>> add of support for the davinci i2c driver.
>>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree-discuss at lists.ozlabs.org
>> Cc: linux-i2c at vger.kernel.org
>> Cc: Ben Dooks <ben-linux@fluff.org>
>> Cc: Wolfram Sang <w.sang@pengutronix.de>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Cc: Wolfgang Denk <wd@denx.de>
>> ---
>> .../devicetree/bindings/arm/davinci/i2c.txt | 39 ++++++++++++++++++
>> drivers/i2c/busses/i2c-davinci.c | 43 ++++++++++++++++++++
>> 2 files changed, 82 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
>> new file mode 100644
>> index 0000000..94ec670
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
[...]
>> +Optional properties:
>> +- bus-delay: bus delay in usec
>
> bus_delay sounds rather like frequency in a different name, what is it for?
from drivers/i2c/busses/i2c-davinci.c i2c_davinci_xfer_msg():
/* Introduce a delay, required for some boards (e.g Davinci EVM) */
if (pdata->bus_delay)
udelay(pdata->bus_delay);
so I added this option to OF support too, but I do not know more about
this "feature" ...
[...]
>> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
>> index a76d85f..6f59fae 100644
>> --- a/drivers/i2c/busses/i2c-davinci.c
>> +++ b/drivers/i2c/busses/i2c-davinci.c
>> @@ -38,9 +38,12 @@
[...]
>> +MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
>> +#else
>> +#define davinci_i2c_of_match NULL
>> +#endif
>
> see of_match_ptr() and you won't need the #else.
Yep, already fixed, as Grant Likely commented.
>> static int davinci_i2c_probe(struct platform_device *pdev)
>> {
>> struct davinci_i2c_dev *dev;
>> @@ -676,7 +689,34 @@ static int davinci_i2c_probe(struct platform_device *pdev)
>> dev->irq = irq->start;
>> platform_set_drvdata(pdev, dev);
>>
>> + if ((dev->dev->platform_data == NULL) &&
>> + (pdev->dev.of_node)) {
>
> If there's platform_data an of_node, what happens then?
Then platform_data is used.
>> + struct device_node *pinmux_np;
>> + struct davinci_i2c_platform_data *pdata;
>> + u32 prop;
>> +
>> + dev->dev->platform_data = &davinci_i2c_platform_data_default;
>> + pdata = &davinci_i2c_platform_data_default;
>> + if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
>> + &prop))
>> + pdata->bus_freq = prop / 1000;
>> + if (!of_property_read_u32(pdev->dev.of_node, "bus-delay",
>> + &prop))
>> + pdata->bus_delay = prop;
>> + if (!of_property_read_u32(pdev->dev.of_node, "id",
>> + &prop)) {
>> + pdev->id = prop;
>> + pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
>> + sprintf((char *)pdev->dev.init_name,
>> + "i2c_davinci.%d", pdev->id);
>> + }
>
> Is this _really_ necessary, looks a bit of a hack to me.
Yep, "id" completely removed, as Grant Likely commented too.
[...]
Thanks for looking through this. Posting v2 soon.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller
2012-01-23 8:56 [RFC PATCH 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
` (4 preceding siblings ...)
2012-01-23 8:56 ` [RFC PATCH 5/7] ARM: davinci: i2c: " Heiko Schocher
@ 2012-01-23 8:56 ` Heiko Schocher
2012-01-23 23:59 ` Scott Wood
2012-01-23 8:56 ` [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
6 siblings, 1 reply; 37+ messages in thread
From: Heiko Schocher @ 2012-01-23 8:56 UTC (permalink / raw)
To: linux-arm-kernel
add OF support for the davinci nand controller.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-mtd at lists.infradead.org
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
---
.../devicetree/bindings/arm/davinci/nand.txt | 72 ++++++++++++++++++
drivers/mtd/nand/davinci_nand.c | 78 +++++++++++++++++++-
2 files changed, 148 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt
diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt
new file mode 100644
index 0000000..7e8d6db
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
@@ -0,0 +1,72 @@
+* Texas Instruments Davinci NAND
+
+This file provides information, what the device node for the
+davinci nand interface contain.
+
+Required properties:
+- compatible: "ti,davinci-nand";
+- reg : contain 2 offset/length values:
+ - offset and length for the access window
+ - offset and length for accessing the aemif control registers
+- id: id of the controller
+
+Recommended properties :
+- mask_ale: mask for ale
+- mask_cle: mask for cle
+- mask_chipsel: mask for chipselect
+- ecc_mode: ECC mode, see NAND_ECC_* defines
+- ecc_bits: used ECC bits
+- options: nand options, defined in
+ include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR
+- bbt_options: NAND_BBT_* defines
+
+Optional properties:
+- pinmux-handle: contains a handle to configure the pinmux settings.
+- timing-handle: contains a handle to setup aemif timing.
+
+Example (enbw_cmc board):
+aemif at 60000000 {
+ compatible = "ti,davinci-aemif";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x68000000 0x80000>;
+ ranges = <2 0 0x60000000 0x02000000
+ 3 0 0x62000000 0x02000000
+ 4 0 0x64000000 0x02000000
+ 5 0 0x66000000 0x02000000
+ 6 0 0x68000000 0x02000000>;
+ nand_cs: cs3 at 68000000 {
+ compatible = "ti,davinci-cs";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* all timings in nanoseconds */
+ cs = <3>;
+ asize = <0>;
+ ta = <0>;
+ rhold = <7>;
+ rstrobe = <42>;
+ rsetup = <7>;
+ whold = <7>;
+ wstrobe = <14>;
+ wsetup = <7>;
+ ew = <0>;
+ ss = <0>;
+ };
+ nandflash at 3,0 {
+ compatible = "ti,davinci-nand";
+ reg = <3 0x0 0x807ff
+ 6 0x0 0x8000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ id = <1>;
+ mask_ale = <0>;
+ mask_cle = <0>;
+ mask_chipsel = <0>;
+ ecc_mode = <2>;
+ ecc_bits = <4>;
+ options = <0>;
+ bbt_options = <0x20000>;
+ pinmux-handle = <&nand_pins>;
+ timing-handle = <&nand_cs>;
+ };
+};
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 6e56615..a1946c3 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -33,9 +33,12 @@
#include <linux/mtd/nand.h>
#include <linux/mtd/partitions.h>
#include <linux/slab.h>
+#include <linux/of_i2c.h>
+#include <linux/of_device.h>
#include <mach/nand.h>
#include <mach/aemif.h>
+#include <mach/mux.h>
/*
* This is a device driver for the NAND flash controller found on the
@@ -518,9 +521,76 @@ static struct nand_ecclayout hwecc4_2048 __initconst = {
},
};
+#if defined(CONFIG_OF)
+static const struct of_device_id davinci_nand_of_match[] = {
+ {.compatible = "ti,davinci-nand", },
+ {},
+}
+MODULE_DEVICE_TABLE(of, davinci_nand_of_match);
+
+static struct davinci_nand_pdata
+ *nand_davinci_get_pdata(struct platform_device *pdev)
+{
+ if ((pdev->dev.platform_data == NULL) &&
+ (pdev->dev.of_node)) {
+ struct device_node *tmp_np;
+ struct davinci_nand_pdata *pdata;
+ u32 prop;
+
+ pdata = kzalloc(sizeof(struct davinci_nand_pdata),
+ GFP_KERNEL);
+ pdev->dev.platform_data = pdata;
+ if (!pdata)
+ return NULL;
+ if (!of_property_read_u32(pdev->dev.of_node, "id",
+ &prop))
+ pdev->id = prop;
+ if (!of_property_read_u32(pdev->dev.of_node, "mask_ale",
+ &prop))
+ pdata->mask_ale = prop;
+ if (!of_property_read_u32(pdev->dev.of_node, "mask_cle",
+ &prop))
+ pdata->mask_cle = prop;
+ if (!of_property_read_u32(pdev->dev.of_node, "mask_chipsel",
+ &prop))
+ pdata->mask_chipsel = prop;
+ if (!of_property_read_u32(pdev->dev.of_node, "ecc_mode",
+ &prop))
+ pdata->ecc_mode = prop;
+ if (!of_property_read_u32(pdev->dev.of_node, "ecc_bits",
+ &prop))
+ pdata->ecc_bits = prop;
+ if (!of_property_read_u32(pdev->dev.of_node, "options",
+ &prop))
+ pdata->options = prop;
+ if (!of_property_read_u32(pdev->dev.of_node, "bbt_options",
+ &prop))
+ pdata->bbt_options = prop;
+ tmp_np = of_parse_phandle(pdev->dev.of_node,
+ "pinmux-handle", 0);
+ if (tmp_np)
+ davinci_cfg_reg_of(tmp_np);
+
+ tmp_np = of_parse_phandle(pdev->dev.of_node,
+ "timing-handle", 0);
+ if (tmp_np)
+ davinci_aemif_setup_timing_of(tmp_np);
+ }
+
+ return pdev->dev.platform_data;
+}
+#else
+#define davinci_nand_of_match NULL
+static struct davinci_nand_pdata
+ *nand_davinci_get_pdata(struct platform_device *pdev)
+{
+ return pdev->dev.platform_data;
+}
+#endif
+
static int __init nand_davinci_probe(struct platform_device *pdev)
{
- struct davinci_nand_pdata *pdata = pdev->dev.platform_data;
+ struct davinci_nand_pdata *pdata;
struct davinci_nand_info *info;
struct resource *res1;
struct resource *res2;
@@ -530,6 +600,7 @@ static int __init nand_davinci_probe(struct platform_device *pdev)
uint32_t val;
nand_ecc_modes_t ecc_mode;
+ pdata = nand_davinci_get_pdata(pdev);
/* insist on board-specific configuration */
if (!pdata)
return -ENODEV;
@@ -812,16 +883,19 @@ static int __exit nand_davinci_remove(struct platform_device *pdev)
}
static struct platform_driver nand_davinci_driver = {
+ .probe = nand_davinci_probe,
.remove = __exit_p(nand_davinci_remove),
.driver = {
.name = "davinci_nand",
+ .owner = THIS_MODULE,
+ .of_match_table = davinci_nand_of_match,
},
};
MODULE_ALIAS("platform:davinci_nand");
static int __init nand_davinci_init(void)
{
- return platform_driver_probe(&nand_davinci_driver, nand_davinci_probe);
+ return platform_driver_register(&nand_davinci_driver);
}
module_init(nand_davinci_init);
--
1.7.7.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller
2012-01-23 8:56 ` [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller Heiko Schocher
@ 2012-01-23 23:59 ` Scott Wood
2012-01-24 7:23 ` Heiko Schocher
0 siblings, 1 reply; 37+ messages in thread
From: Scott Wood @ 2012-01-23 23:59 UTC (permalink / raw)
To: linux-arm-kernel
On 01/23/2012 02:56 AM, Heiko Schocher wrote:
> diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt
> new file mode 100644
> index 0000000..7e8d6db
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
> @@ -0,0 +1,72 @@
> +* Texas Instruments Davinci NAND
> +
> +This file provides information, what the device node for the
> +davinci nand interface contain.
> +
> +Required properties:
> +- compatible: "ti,davinci-nand";
> +- reg : contain 2 offset/length values:
> + - offset and length for the access window
> + - offset and length for accessing the aemif control registers
> +- id: id of the controller
What does "id of the controller" mean, specfically? From this I can't
even tell if it's a number or a string, much less how to use it
semantically. If it's just a "match what's in the manual" thing,
perhaps an alias would be better here. Or, if it's a value with a
specific meaning (e.g. that you need to program into a register) use a
more specific name.
> +Recommended properties :
> +- mask_ale: mask for ale
> +- mask_cle: mask for cle
> +- mask_chipsel: mask for chipselect
> +- ecc_mode: ECC mode, see NAND_ECC_* defines
> +- ecc_bits: used ECC bits
> +- options: nand options, defined in
> + include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR
> +- bbt_options: NAND_BBT_* defines
Binding-specific properties should have a vendor prefix. Dashes are
preferred to underscores.
Don't specify Linux internals by reference -- they could change and
invalidate existing device trees and non-Linux code that accepts them
(e.g. U-Boot). If you want them to line up, copy the definition here,
and if Linux changes, write glue code to convert. It would probably be
better to define specific properties for anything that must be specified
here (neither deteted dynamically nor defined by compatible =
"ti,davinci-nand").
Do all of these properties really belong here? I can see providing some
information about ECC or BBT mode, if there are multiple conventions
already in use (or that are reasonably justifiable for different
situations), as that must agree with how the flash has already been
programmed. How much of the rest can vary from one "ti,davinci-nand" to
another? Maybe it's obvious to someone more familiar with davinci, but
what does "mask for ale/cle/chipselect" mean?
> + nandflash at 3,0 {
PowerPC's ePAPR document -- not directly relevant to ARM, but contains a
more recently updated list of generic names than the IEEE1275
recommended pratice -- specifies "flash@". If you don't want to do
that, "nand@" is used in many existing trees. Why introduce a new name?
-Scott
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller
2012-01-23 23:59 ` Scott Wood
@ 2012-01-24 7:23 ` Heiko Schocher
2012-01-24 19:45 ` Scott Wood
0 siblings, 1 reply; 37+ messages in thread
From: Heiko Schocher @ 2012-01-24 7:23 UTC (permalink / raw)
To: linux-arm-kernel
Hello Scott,
Scott Wood wrote:
> On 01/23/2012 02:56 AM, Heiko Schocher wrote:
>> diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt
>> new file mode 100644
>> index 0000000..7e8d6db
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
>> @@ -0,0 +1,72 @@
>> +* Texas Instruments Davinci NAND
>> +
>> +This file provides information, what the device node for the
>> +davinci nand interface contain.
>> +
>> +Required properties:
>> +- compatible: "ti,davinci-nand";
>> +- reg : contain 2 offset/length values:
>> + - offset and length for the access window
>> + - offset and length for accessing the aemif control registers
>> +- id: id of the controller
>
> What does "id of the controller" mean, specfically? From this I can't
> even tell if it's a number or a string, much less how to use it
> semantically. If it's just a "match what's in the manual" thing,
> perhaps an alias would be better here. Or, if it's a value with a
> specific meaning (e.g. that you need to program into a register) use a
> more specific name.
Ok, fix this. Id means here, which chipselect the controller uses.
Maybe it is better to rename it to "chipselect" ?
>> +Recommended properties :
>> +- mask_ale: mask for ale
>> +- mask_cle: mask for cle
>> +- mask_chipsel: mask for chipselect
>> +- ecc_mode: ECC mode, see NAND_ECC_* defines
>> +- ecc_bits: used ECC bits
>> +- options: nand options, defined in
>> + include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR
>> +- bbt_options: NAND_BBT_* defines
>
> Binding-specific properties should have a vendor prefix. Dashes are
> preferred to underscores.
You think something like that:
davinci-mask-ale
davinci-mask-cle
...
?
> Don't specify Linux internals by reference -- they could change and
> invalidate existing device trees and non-Linux code that accepts them
> (e.g. U-Boot). If you want them to line up, copy the definition here,
> and if Linux changes, write glue code to convert. It would probably be
> better to define specific properties for anything that must be specified
> here (neither deteted dynamically nor defined by compatible =
> "ti,davinci-nand").
Ok, I add the defines here, and add also a comment in the dts.
> Do all of these properties really belong here? I can see providing some
I think so, because this values come from existing platform code
(grep for struct davinci_nand_pdata)
> information about ECC or BBT mode, if there are multiple conventions
> already in use (or that are reasonably justifiable for different
> situations), as that must agree with how the flash has already been
> programmed. How much of the rest can vary from one "ti,davinci-nand" to
> another? Maybe it's obvious to someone more familiar with davinci, but
> what does "mask for ale/cle/chipselect" mean?
I mapped here just the existing platform code (=struct davinci_nand_pdata)
to OF, so existing boards can easy switch to OF.
Comment in arch/arm/mach-davinci/include/mach/nand.h says for
mask_ale and mask_cle:
/* NOTE: boards don't need to use these address bits
* for ALE/CLE unless they support booting from NAND.
* They're used unless platform data overrides them.
*/
It is used for addressing the ALE/CLE Signals through the address,
used on the arch/arm/mach-davinci/board-dm646x-evm.c and
arch/arm/mach-davinci/board-tnetv107x-evm.c board ... so I think,
this should be also be setupable through OF ...
>> + nandflash at 3,0 {
>
> PowerPC's ePAPR document -- not directly relevant to ARM, but contains a
> more recently updated list of generic names than the IEEE1275
> recommended pratice -- specifies "flash@". If you don't want to do
> that, "nand@" is used in many existing trees. Why introduce a new name?
There is no reason for that, change this to "nand@".
Thanks for the review.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller
2012-01-24 7:23 ` Heiko Schocher
@ 2012-01-24 19:45 ` Scott Wood
2012-01-25 7:09 ` Heiko Schocher
0 siblings, 1 reply; 37+ messages in thread
From: Scott Wood @ 2012-01-24 19:45 UTC (permalink / raw)
To: linux-arm-kernel
On 01/24/2012 01:23 AM, Heiko Schocher wrote:
> Hello Scott,
>
> Scott Wood wrote:
>> On 01/23/2012 02:56 AM, Heiko Schocher wrote:
>>> diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt
>>> new file mode 100644
>>> index 0000000..7e8d6db
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
>>> @@ -0,0 +1,72 @@
>>> +* Texas Instruments Davinci NAND
>>> +
>>> +This file provides information, what the device node for the
>>> +davinci nand interface contain.
>>> +
>>> +Required properties:
>>> +- compatible: "ti,davinci-nand";
>>> +- reg : contain 2 offset/length values:
>>> + - offset and length for the access window
>>> + - offset and length for accessing the aemif control registers
>>> +- id: id of the controller
>>
>> What does "id of the controller" mean, specfically? From this I can't
>> even tell if it's a number or a string, much less how to use it
>> semantically. If it's just a "match what's in the manual" thing,
>> perhaps an alias would be better here. Or, if it's a value with a
>> specific meaning (e.g. that you need to program into a register) use a
>> more specific name.
>
> Ok, fix this. Id means here, which chipselect the controller uses.
> Maybe it is better to rename it to "chipselect" ?
Yes, or better "ti,chipselect" or "ti,davinci-chipselect".
>>> +Recommended properties :
>>> +- mask_ale: mask for ale
>>> +- mask_cle: mask for cle
>>> +- mask_chipsel: mask for chipselect
>>> +- ecc_mode: ECC mode, see NAND_ECC_* defines
>>> +- ecc_bits: used ECC bits
>>> +- options: nand options, defined in
>>> + include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR
>>> +- bbt_options: NAND_BBT_* defines
>>
>> Binding-specific properties should have a vendor prefix. Dashes are
>> preferred to underscores.
>
> You think something like that:
>
> davinci-mask-ale
> davinci-mask-cle
> ...
"ti,davinci-mask-ale", etc.
>> Don't specify Linux internals by reference -- they could change and
>> invalidate existing device trees and non-Linux code that accepts them
>> (e.g. U-Boot). If you want them to line up, copy the definition here,
>> and if Linux changes, write glue code to convert. It would probably be
>> better to define specific properties for anything that must be specified
>> here (neither deteted dynamically nor defined by compatible =
>> "ti,davinci-nand").
>
> Ok, I add the defines here, and add also a comment in the dts.
Which options actually need to come from the device tree?
>> Do all of these properties really belong here? I can see providing some
>
> I think so, because this values come from existing platform code
> (grep for struct davinci_nand_pdata)
The standards are a bit stricter for the device tree, since it's a more
stable interface across components -- at least that's how we've used it
on a lot of powerpc targets. I'm not sure if that's the intent here,
but I have seen U-Boot patches for ARM hardware using them as well.
> Comment in arch/arm/mach-davinci/include/mach/nand.h says for
> mask_ale and mask_cle:
>
> /* NOTE: boards don't need to use these address bits
> * for ALE/CLE unless they support booting from NAND.
> * They're used unless platform data overrides them.
> */
>
> It is used for addressing the ALE/CLE Signals through the address,
> used on the arch/arm/mach-davinci/board-dm646x-evm.c and
> arch/arm/mach-davinci/board-tnetv107x-evm.c board ... so I think,
> this should be also be setupable through OF ...
OK, if it's board logic that does the decoding, and the compatible is
not board-specific, they belong here.
-Scott
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller
2012-01-24 19:45 ` Scott Wood
@ 2012-01-25 7:09 ` Heiko Schocher
2012-01-26 20:33 ` Scott Wood
0 siblings, 1 reply; 37+ messages in thread
From: Heiko Schocher @ 2012-01-25 7:09 UTC (permalink / raw)
To: linux-arm-kernel
Hello Scott,
Scott Wood wrote:
> On 01/24/2012 01:23 AM, Heiko Schocher wrote:
>> Hello Scott,
>>
>> Scott Wood wrote:
>>> On 01/23/2012 02:56 AM, Heiko Schocher wrote:
>>>> diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt
>>>> new file mode 100644
>>>> index 0000000..7e8d6db
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
>>>> @@ -0,0 +1,72 @@
>>>> +* Texas Instruments Davinci NAND
>>>> +
>>>> +This file provides information, what the device node for the
>>>> +davinci nand interface contain.
>>>> +
>>>> +Required properties:
>>>> +- compatible: "ti,davinci-nand";
>>>> +- reg : contain 2 offset/length values:
>>>> + - offset and length for the access window
>>>> + - offset and length for accessing the aemif control registers
>>>> +- id: id of the controller
>>> What does "id of the controller" mean, specfically? From this I can't
>>> even tell if it's a number or a string, much less how to use it
>>> semantically. If it's just a "match what's in the manual" thing,
>>> perhaps an alias would be better here. Or, if it's a value with a
>>> specific meaning (e.g. that you need to program into a register) use a
>>> more specific name.
>> Ok, fix this. Id means here, which chipselect the controller uses.
>> Maybe it is better to rename it to "chipselect" ?
>
> Yes, or better "ti,chipselect" or "ti,davinci-chipselect".
Ok. fixed this to "ti,davinci-chipselect"
>>>> +Recommended properties :
>>>> +- mask_ale: mask for ale
>>>> +- mask_cle: mask for cle
>>>> +- mask_chipsel: mask for chipselect
>>>> +- ecc_mode: ECC mode, see NAND_ECC_* defines
>>>> +- ecc_bits: used ECC bits
>>>> +- options: nand options, defined in
>>>> + include/linux/mtd/nand.h, grep for NAND_NO_AUTOINCR
>>>> +- bbt_options: NAND_BBT_* defines
>>> Binding-specific properties should have a vendor prefix. Dashes are
>>> preferred to underscores.
>> You think something like that:
>>
>> davinci-mask-ale
>> davinci-mask-cle
>> ...
>
> "ti,davinci-mask-ale", etc.
Ok, fixed.
>>> Don't specify Linux internals by reference -- they could change and
>>> invalidate existing device trees and non-Linux code that accepts them
>>> (e.g. U-Boot). If you want them to line up, copy the definition here,
>>> and if Linux changes, write glue code to convert. It would probably be
>>> better to define specific properties for anything that must be specified
>>> here (neither deteted dynamically nor defined by compatible =
>>> "ti,davinci-nand").
>> Ok, I add the defines here, and add also a comment in the dts.
>
> Which options actually need to come from the device tree?
I found the following used options:
ecc_mode:
NAND_ECC_NONE
NAND_ECC_SOFT
NAND_ECC_HW
NAND_ECC_HW_SYNDROME
bbt_options:
NAND_BBT_USE_FLASH
ecc_bits:
1
4
options:
NAND_BUSWIDTH_16
>>> Do all of these properties really belong here? I can see providing some
>> I think so, because this values come from existing platform code
>> (grep for struct davinci_nand_pdata)
>
> The standards are a bit stricter for the device tree, since it's a more
> stable interface across components -- at least that's how we've used it
> on a lot of powerpc targets. I'm not sure if that's the intent here,
> but I have seen U-Boot patches for ARM hardware using them as well.
Ok, so, should I introduce instead properties for the above
needed parameters? (As this are not davinci specific parameters,
are there somewhere such definitions for them?)
>> Comment in arch/arm/mach-davinci/include/mach/nand.h says for
>> mask_ale and mask_cle:
>>
>> /* NOTE: boards don't need to use these address bits
>> * for ALE/CLE unless they support booting from NAND.
>> * They're used unless platform data overrides them.
>> */
>>
>> It is used for addressing the ALE/CLE Signals through the address,
>> used on the arch/arm/mach-davinci/board-dm646x-evm.c and
>> arch/arm/mach-davinci/board-tnetv107x-evm.c board ... so I think,
>> this should be also be setupable through OF ...
>
> OK, if it's board logic that does the decoding, and the compatible is
> not board-specific, they belong here.
Ok.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller
2012-01-25 7:09 ` Heiko Schocher
@ 2012-01-26 20:33 ` Scott Wood
2012-01-27 6:40 ` Heiko Schocher
0 siblings, 1 reply; 37+ messages in thread
From: Scott Wood @ 2012-01-26 20:33 UTC (permalink / raw)
To: linux-arm-kernel
On 01/25/2012 01:09 AM, Heiko Schocher wrote:
> Scott Wood wrote:
> I found the following used options:
>
> ecc_mode:
> NAND_ECC_NONE
> NAND_ECC_SOFT
> NAND_ECC_HW
> NAND_ECC_HW_SYNDROME
>
> bbt_options:
> NAND_BBT_USE_FLASH
>
> ecc_bits:
> 1
> 4
>
> options:
> NAND_BUSWIDTH_16
>
>>>> Do all of these properties really belong here? I can see providing some
>>> I think so, because this values come from existing platform code
>>> (grep for struct davinci_nand_pdata)
>>
>> The standards are a bit stricter for the device tree, since it's a more
>> stable interface across components -- at least that's how we've used it
>> on a lot of powerpc targets. I'm not sure if that's the intent here,
>> but I have seen U-Boot patches for ARM hardware using them as well.
>
> Ok, so, should I introduce instead properties for the above
> needed parameters?
Yes.
> (As this are not davinci specific parameters, are there somewhere such definitions for them?)
It's controller-specific which options are changeable, and whether
there's a better source of information. Most controllers don't seem to
need this. I'd keep the definitions davinci specific for now. If
there's enough of a common need, a common definition could be considered.
-Scott
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller
2012-01-26 20:33 ` Scott Wood
@ 2012-01-27 6:40 ` Heiko Schocher
2012-01-27 17:02 ` Scott Wood
0 siblings, 1 reply; 37+ messages in thread
From: Heiko Schocher @ 2012-01-27 6:40 UTC (permalink / raw)
To: linux-arm-kernel
Hello Scott,
Scott Wood wrote:
> On 01/25/2012 01:09 AM, Heiko Schocher wrote:
>> Scott Wood wrote:
>> I found the following used options:
>>
>> ecc_mode:
>> NAND_ECC_NONE
>> NAND_ECC_SOFT
>> NAND_ECC_HW
>> NAND_ECC_HW_SYNDROME
>>
>> bbt_options:
>> NAND_BBT_USE_FLASH
>>
>> ecc_bits:
>> 1
>> 4
>>
>> options:
>> NAND_BUSWIDTH_16
>>
>>>>> Do all of these properties really belong here? I can see providing some
>>>> I think so, because this values come from existing platform code
>>>> (grep for struct davinci_nand_pdata)
>>> The standards are a bit stricter for the device tree, since it's a more
>>> stable interface across components -- at least that's how we've used it
>>> on a lot of powerpc targets. I'm not sure if that's the intent here,
>>> but I have seen U-Boot patches for ARM hardware using them as well.
>> Ok, so, should I introduce instead properties for the above
>> needed parameters?
>
> Yes.
Ok, I change this.
>> (As this are not davinci specific parameters, are there somewhere such definitions for them?)
>
> It's controller-specific which options are changeable, and whether
> there's a better source of information. Most controllers don't seem to
> need this. I'd keep the definitions davinci specific for now. If
> there's enough of a common need, a common definition could be considered.
Ok, a proposal for the properties names and values:
>> ecc_mode:
>> NAND_ECC_NONE
>> NAND_ECC_SOFT
>> NAND_ECC_HW
>> NAND_ECC_HW_SYNDROME
"ti,davinci-nand-ecc-mode" = "none", "soft", "hw" or "hw_syndrome"
>> bbt_options:
>> NAND_BBT_USE_FLASH
"ti,davinci-nand-bbt-options" = "use_flash"
>> ecc_bits:
>> 1
>> 4
"ti,davinci-nand-ecc-bits" = "1" or "4"
>> options:
>> NAND_BUSWIDTH_16
"ti,davinci-nand-options" = "buswidth-16"
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller
2012-01-27 6:40 ` Heiko Schocher
@ 2012-01-27 17:02 ` Scott Wood
0 siblings, 0 replies; 37+ messages in thread
From: Scott Wood @ 2012-01-27 17:02 UTC (permalink / raw)
To: linux-arm-kernel
On 01/27/2012 12:40 AM, Heiko Schocher wrote:
> Hello Scott,
>
> Scott Wood wrote:
>> On 01/25/2012 01:09 AM, Heiko Schocher wrote:
>>> ecc_mode:
>>> NAND_ECC_NONE
>>> NAND_ECC_SOFT
>>> NAND_ECC_HW
>>> NAND_ECC_HW_SYNDROME
>
> "ti,davinci-nand-ecc-mode" = "none", "soft", "hw" or "hw_syndrome"
OK.
>>> bbt_options:
>>> NAND_BBT_USE_FLASH
>
> "ti,davinci-nand-bbt-options" = "use_flash"
Just make it a boolean ti,davinci-nand-use-bbt
>>> ecc_bits:
>>> 1
>>> 4
>
> "ti,davinci-nand-ecc-bits" = "1" or "4"
<1> or <4>
>>> options:
>>> NAND_BUSWIDTH_16
>
> "ti,davinci-nand-options" = "buswidth-16"
ti,davinci-nand-buswidth = <16>;
-Scott
^ permalink raw reply [flat|nested] 37+ messages in thread
* [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
2012-01-23 8:56 [RFC PATCH 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
` (5 preceding siblings ...)
2012-01-23 8:56 ` [RFC PATCH 6/7] ARM: mtd: nand: davinci: add OF support for davinci nand controller Heiko Schocher
@ 2012-01-23 8:56 ` Heiko Schocher
2012-01-30 20:32 ` Grant Likely
6 siblings, 1 reply; 37+ messages in thread
From: Heiko Schocher @ 2012-01-23 8:56 UTC (permalink / raw)
To: linux-arm-kernel
- AM1808 based board
- 64 MiB DDR ram
- 2 MiB Nor flash
- 128 MiB NAND flash
- use internal RTC
- I2C support
- hwmon lm75 support
- UBI/UBIFS support
- MMC support
- USB OTG support
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-mtd at lists.infradead.org
Cc: linux-i2c at vger.kernel.org
Cc: netdev at vger.kernel.org
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
---
- post this board support with USB support, even though
USB is only working with the 10 ms "workaround", posted here:
http://comments.gmane.org/gmane.linux.usb.general/54505
I see this issue also on the AM1808 TMDXEXP1808L evalboard.
- MMC and USB are not using OF support yet, ideas how to port
this are welcome. I need for USB and MMC boards board
specific callbacks, how to solve this with OF support?
arch/arm/boot/dts/enbw_cmc.dts | 286 +++++++++++++++++
arch/arm/configs/enbw_cmc_defconfig | 125 ++++++++
arch/arm/mach-davinci/Kconfig | 8 +
arch/arm/mach-davinci/Makefile | 1 +
arch/arm/mach-davinci/board-enbw-cmc.c | 384 +++++++++++++++++++++++
arch/arm/mach-davinci/include/mach/uncompress.h | 1 +
6 files changed, 805 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
create mode 100644 arch/arm/configs/enbw_cmc_defconfig
create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c
diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts
new file mode 100644
index 0000000..e5995ce
--- /dev/null
+++ b/arch/arm/boot/dts/enbw_cmc.dts
@@ -0,0 +1,286 @@
+/*
+ * Device Tree for the EnBW CMC plattform
+ *
+ * Copyright 2011 DENX Software Engineering GmbH
+ * Heiko Schocher <hs@denx.de>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "EnBW CMC";
+ compatible = "enbw,cmc";
+
+ aliases {
+ ethernet0 = ð0;
+ };
+
+ arm {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0xfffee000 0x00020000>;
+ intc: interrupt-controller at 1 {
+ compatible = "ti,davinci-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ ti,intc-size = <101>;
+ reg = <0x0 0x2000>;
+ };
+ };
+ soc at 1c00000 {
+ compatible = "ti,da8xx";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x01c00000 0x400000>;
+
+ serial0: serial at 1c42000 {
+ cell-index = <2>;
+ compatible = "ns16550a";
+ reg = <0x42000 0x100>;
+ clock-frequency = <150000000>;
+ reg-shift = <2>;
+ interrupts = <25>;
+ interrupt-parent = <&intc>;
+ };
+ serial1: serial at 1d0c000 {
+ cell-index = <1>;
+ compatible = "ns16550a";
+ reg = <0x10c000 0x100>;
+ clock-frequency = <150000000>;
+ reg-shift = <2>;
+ interrupts = <53>;
+ interrupt-parent = <&intc>;
+ };
+ serial2: serial at 1d0d000 {
+ cell-index = <2>;
+ compatible = "ns16550a";
+ reg = <0x10d000 0x100>;
+ clock-frequency = <150000000>;
+ reg-shift = <2>;
+ interrupts = <61>;
+ interrupt-parent = <&intc>;
+ };
+
+ nor_pins: nor_pinmux at 1c14120 {
+ compatible = "ti,davinci-pinmux";
+ reg = <0x14120 0x1000>;
+ pins = < /* muxreg maskoff modemsk muxmode */
+ 5 24 15 1 /* EMA_BA_1 */
+ 6 0 15 1 /* EMA CLK */
+ 6 24 15 1 /* EMA_WAIT_1 */
+ 7 0 15 1 /* NEMA_CS_2 */
+ 7 16 15 1 /* NEMA_WE */
+ 7 20 15 1 /* NEMA_OE */
+ 9 28 15 1 /* EMA_D_0 */
+ 9 24 15 1 /* EMA_D_1 */
+ 9 20 15 1 /* EMA_D_2 */
+ 9 16 15 1 /* EMA_D_3 */
+ 9 12 15 1 /* EMA_D_4 */
+ 9 8 15 1 /* EMA_D_5 */
+ 9 4 15 1 /* EMA_D_6 */
+ 9 0 15 1 /* EMA_D_7 */
+ 8 28 15 1 /* EMA_D_8 */
+ 8 24 15 1 /* EMA_D_9 */
+ 8 20 15 1 /* EMA_D_10 */
+ 8 16 15 1 /* EMA_D_11 */
+ 8 12 15 1 /* EMA_D_12 */
+ 8 8 15 1 /* EMA_D_13 */
+ 8 4 15 1 /* EMA_D_14 */
+ 8 0 15 1 /* EMA_D_15 */
+ 12 28 15 1 /* EMA_A_0 */
+ 12 24 15 1 /* EMA_A_1 */
+ 12 20 15 1 /* EMA_A_2 */
+ 12 16 15 1 /* EMA_A_3 */
+ 12 12 15 1 /* EMA_A_4 */
+ 12 8 15 1 /* EMA_A_5 */
+ 12 4 15 1 /* EMA_A_6 */
+ 12 0 15 1 /* EMA_A_7 */
+ 11 28 15 1 /* EMA_A_8 */
+ 11 24 15 1 /* EMA_A_9 */
+ 11 20 15 1 /* EMA_A_10 */
+ 11 16 15 1 /* EMA_A_11 */
+ 11 12 15 1 /* EMA_A_12 */
+ 11 8 15 1 /* EMA_A_13 */
+ 11 4 15 1 /* EMA_A_14 */
+ 11 0 15 1 /* EMA_A_15 */
+ 10 28 15 1 /* EMA_A_16 */
+ 10 24 15 1 /* EMA_A_17 */
+ 10 20 15 1 /* EMA_A_18 */
+ 10 16 15 1 /* EMA_A_19 */
+ 10 12 15 1 /* EMA_A_20 */
+ 10 8 15 1 /* EMA_A_21 */
+ 10 4 15 1 /* EMA_A_22 */
+ 10 0 15 1 /* EMA_A_23 */
+ >;
+ };
+ nand_pins: nand_pinmux at 1c14120 {
+ compatible = "ti,davinci-pinmux";
+ reg = <0x14120 0x1000>;
+ pins = < /* muxreg maskoff modemsk muxmode */
+ 7 4 15 1 /* NEMA_CS_3 */
+ >;
+ };
+
+ emac_pins: pinmux at 1c14120 {
+ compatible = "ti,davinci-pinmux";
+ reg = <0x14120 0x1000>;
+ pins = < /* muxreg maskoff modemsk muxmode */
+ 2 4 15 8 /* MII TXEN */
+ 2 8 15 8 /* MII TXCLK */
+ 2 12 15 8 /* MII COL */
+ 2 16 15 8 /* MII TXD_3 */
+ 2 20 15 8 /* MII TXD_2 */
+ 2 24 15 8 /* MII TXD_1 */
+ 2 28 15 8 /* MII TXD_0 */
+ 3 8 15 8 /* MII RXER */
+ 3 12 15 8 /* MII CRS */
+ 3 0 15 8 /* MII RXCLK */
+ 3 4 15 8 /* MII RXDV */
+ 3 16 15 8 /* MII RXD_3 */
+ 3 20 15 8 /* MII RXD_2 */
+ 3 24 15 8 /* MII RXD_1 */
+ 3 28 15 8 /* MII RXD_0 */
+ 4 0 15 8 /* MDIO CLK */
+ 4 4 15 8 /* MDIO D */
+ >;
+ };
+
+ i2c1_pins: i2c_pinmux at 1c14120 {
+ compatible = "ti,davinci-pinmux";
+ reg = <0x14120 0x1000>;
+ pins = < /* muxreg maskoff modemsk muxmode */
+ 4 12 15 2 /* I2C0 SDA */
+ 4 8 15 2 /* I2C0 SCL */
+ >;
+ };
+
+ eth0: emac at 1e20000 {
+ compatible = "ti,davinci-emac";
+ reg = <0x220000 0x4000>;
+ ctrl_reg_offset = <0x3000>;
+ ctrl_mod_reg_offset = <0x2000>;
+ ctrl_ram_offset = <0>;
+ hw_ram_addr = <0>;
+ ctrl_ram_size = <0x2000>;
+ version = <1>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <33
+ 34
+ 35
+ 36
+ >;
+ interrupt-parent = <&intc>;
+ pinmux-handle = <&emac_pins>;
+ };
+
+ i2c at 1c22000 {
+ compatible = "ti,davinci-i2c";
+ reg = <0x22000 0x1000>;
+ clock-frequency = <100000>;
+ interrupts = <15>;
+ interrupt-parent = <&intc>;
+ id = <1>;
+ pinmux-handle = <&i2c1_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dtt at 48 {
+ compatible = "national,lm75";
+ reg = <0x48>;
+ };
+ };
+
+ wdt at 1c21000 {
+ compatible = "ti,davinci-wdt";
+ reg = <0x00021000 0x1000>;
+ period = <100>;
+ };
+ bootcount at 1c23000 {
+ compatible = "uboot,bootcount";
+ reg = <0x23060 0x20>;
+ };
+
+ };
+ onchipram at 8000000 {
+ compatible = "ti,davinci-onchipram";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x80000000 0x20000>;
+ };
+ aemif at 60000000 {
+ compatible = "ti,davinci-aemif";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x68000000 0x80000>;
+ ranges = <2 0 0x60000000 0x02000000
+ 3 0 0x62000000 0x02000000
+ 4 0 0x64000000 0x02000000
+ 5 0 0x66000000 0x02000000
+ 6 0 0x68000000 0x02000000>;
+ cs2 at 68000000 {
+ compatible = "ti,davinci-cs";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* all timings in nanoseconds */
+ cs = <2>;
+ asize = <1>;
+ ta = <0>;
+ rhold = <7>;
+ rstrobe = <42>;
+ rsetup = <14>;
+ whold = <7>;
+ wstrobe = <42>;
+ wsetup = <14>;
+ ew = <0>;
+ ss = <0>;
+ };
+ flash at 2,0 {
+ compatible = "cfi-flash";
+ reg = <2 0x0 0x400000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <2>;
+ device-width = <2>;
+ };
+ nand_cs: cs3 at 68000000 {
+ compatible = "ti,davinci-cs";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* all timings in nanoseconds */
+ cs = <3>;
+ asize = <0>;
+ ta = <0>;
+ rhold = <7>;
+ rstrobe = <42>;
+ rsetup = <7>;
+ whold = <7>;
+ wstrobe = <14>;
+ wsetup = <7>;
+ ew = <0>;
+ ss = <0>;
+ };
+ nandflash at 3,0 {
+ compatible = "ti,davinci-nand";
+ reg = <3 0x0 0x807ff
+ 6 0x0 0x8000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ id = <1>;
+ mask_ale = <0>;
+ mask_cle = <0>;
+ mask_chipsel = <0>;
+ ecc_mode = <2>;
+ ecc_bits = <4>;
+ options = <0>;
+ bbt_options = <0x20000>;
+ pinmux-handle = <&nand_pins>;
+ timing-handle = <&nand_cs>;
+ };
+
+ };
+};
diff --git a/arch/arm/configs/enbw_cmc_defconfig b/arch/arm/configs/enbw_cmc_defconfig
new file mode 100644
index 0000000..c794127
--- /dev/null
+++ b/arch/arm/configs/enbw_cmc_defconfig
@@ -0,0 +1,125 @@
+CONFIG_EXPERIMENTAL=y
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_EXPERT=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_DAVINCI=y
+CONFIG_ARCH_DAVINCI_DA850=y
+# CONFIG_MACH_DAVINCI_DA850_EVM is not set
+CONFIG_GPIO_PCA953X=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+CONFIG_USE_OF=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_LRO is not set
+CONFIG_IPV6=y
+CONFIG_NETFILTER=y
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+# CONFIG_FW_LOADER is not set
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_PHYSMAP=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_DAVINCI=y
+CONFIG_MTD_UBI=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=1
+CONFIG_BLK_DEV_RAM_SIZE=32768
+CONFIG_MISC_DEVICES=y
+CONFIG_UBOOT_BOOTCOUNT=y
+CONFIG_EEPROM_AT24=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_NETDEVICES=y
+CONFIG_MII=y
+CONFIG_TI_DAVINCI_EMAC=y
+# CONFIG_WLAN is not set
+CONFIG_INPUT_POLLDEV=y
+# CONFIG_INPUT_MOUSEDEV is not set
+CONFIG_INPUT_EVDEV=y
+CONFIG_INPUT_EVBUG=y
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=3
+CONFIG_SERIAL_8250_RUNTIME_UARTS=3
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_HW_RANDOM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_DAVINCI=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_PCF857X=y
+CONFIG_SENSORS_LM75=y
+CONFIG_WATCHDOG=y
+CONFIG_WD=y
+CONFIG_WD_DAVINCI=y
+# CONFIG_HID_SUPPORT is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_MUSB_HDRC=y
+CONFIG_USB_MUSB_DA8XX=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_UAS=y
+CONFIG_USB_LIBUSUAL=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_FUSB300=y
+CONFIG_USB_ETH=y
+CONFIG_MMC=y
+CONFIG_MMC_DAVINCI=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_OMAP=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+CONFIG_AUTOFS4_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_UBIFS_FS=y
+CONFIG_CRAMFS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+CONFIG_ROOT_NFS=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_DEBUG_FS=y
+CONFIG_TIMER_STATS=y
+CONFIG_DEBUG_RT_MUTEXES=y
+CONFIG_DEBUG_MUTEXES=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+# CONFIG_CRYPTO_HW is not set
+CONFIG_CRC_CCITT=m
+CONFIG_CRC_T10DIF=m
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 32d837d..66efe86 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -202,6 +202,14 @@ config DA850_WL12XX
Say Y if you want to use a wl1271 expansion card connected to the
AM18x EVM.
+config MACH_ENBW_CMC
+ bool "EnBW Communication Module Compact"
+ default ARCH_DAVINCI_DA850
+ depends on ARCH_DAVINCI_DA850
+ help
+ Say Y here to select the EnBW Communication Module Compact
+ board.
+
config GPIO_PCA953X
default MACH_DAVINCI_DA850_EVM
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 2db78bd..12f3166 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) += board-da850-evm.o
obj-$(CONFIG_MACH_TNETV107X) += board-tnetv107x-evm.o
obj-$(CONFIG_MACH_MITYOMAPL138) += board-mityomapl138.o
obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD) += board-omapl138-hawk.o
+obj-$(CONFIG_MACH_ENBW_CMC) += board-enbw-cmc.o
# Power Management
obj-$(CONFIG_CPU_FREQ) += cpufreq.o
diff --git a/arch/arm/mach-davinci/board-enbw-cmc.c b/arch/arm/mach-davinci/board-enbw-cmc.c
new file mode 100644
index 0000000..4473c4a
--- /dev/null
+++ b/arch/arm/mach-davinci/board-enbw-cmc.c
@@ -0,0 +1,384 @@
+/*
+ * EnBW Communication Module Compact board
+ * Copyright 2011 DENX Software Engineering GmbH
+ * Author: Heiko Schocher <hs@denx.de>
+ *
+ * based on:
+ * TI DA850/OMAP-L138 EVM board
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Derived from: arch/arm/mach-davinci/board-da850-evm.c
+ * Original Copyrights follow:
+ *
+ * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/console.h>
+#include <linux/gpio.h>
+#include <linux/gpio_keys.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/physmap.h>
+#include <linux/of.h>
+#include <linux/of_net.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/phy.h>
+#include <linux/phy_fixed.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <mach/aemif.h>
+#include <mach/cp_intc.h>
+#include <mach/da8xx.h>
+#include <mach/mux.h>
+#include <mach/nand.h>
+#include <mach/spi.h>
+
+#define ENBW_CMC_MMCSD_CD_PIN GPIO_TO_PIN(3, 13)
+
+/*
+ * USB1 VBUS is controlled by GPIO7[12], over-current is reported on GPIO7[8].
+ */
+#define DA850_USB_VBUS_PIN GPIO_TO_PIN(7, 12)
+#define ON_BD_USB_OVC GPIO_TO_PIN(7, 8)
+
+#if defined(CONFIG_USB_OHCI_HCD)
+static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id);
+static da8xx_ocic_handler_t enbw_cmc_usb_ocic_handler;
+
+static int enbw_cmc_usb_set_power(unsigned port, int on)
+{
+ gpio_set_value(DA850_USB_VBUS_PIN, on);
+ return 0;
+}
+
+static int enbw_cmc_usb_get_power(unsigned port)
+{
+ return gpio_get_value(DA850_USB_VBUS_PIN);
+}
+
+static int enbw_cmc_usb_get_oci(unsigned port)
+{
+ return !gpio_get_value(ON_BD_USB_OVC);
+}
+
+static irqreturn_t enbw_cmc_usb_ocic_irq(int, void *);
+
+static int enbw_cmc_usb_ocic_notify(da8xx_ocic_handler_t handler)
+{
+ int irq = gpio_to_irq(ON_BD_USB_OVC);
+ int error = 0;
+
+ if (handler != NULL) {
+ enbw_cmc_usb_ocic_handler = handler;
+
+ error = request_irq(irq, enbw_cmc_usb_ocic_irq,
+ IRQF_DISABLED | IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING,
+ "OHCI over-current indicator", NULL);
+ if (error)
+ pr_err("%s: could not request IRQ to watch "
+ "over-current indicator changes\n", __func__);
+ } else {
+ free_irq(irq, NULL);
+ }
+ return error;
+}
+
+static struct da8xx_ohci_root_hub enbw_cmc_usb11_pdata = {
+ .set_power = enbw_cmc_usb_set_power,
+ .get_power = enbw_cmc_usb_get_power,
+ .get_oci = enbw_cmc_usb_get_oci,
+ .ocic_notify = enbw_cmc_usb_ocic_notify,
+ .potpgt = (10 + 1) / 2, /* 10 ms max */
+};
+
+static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id)
+{
+ enbw_cmc_usb_ocic_handler(&enbw_cmc_usb11_pdata, 1);
+ return IRQ_HANDLED;
+}
+#endif
+
+#if defined(CONFIG_OF)
+static __init void enbw_cmc_usb_init(void)
+{
+ int ret;
+ u32 cfgchip2;
+
+ /* Set up USB clock/mode in the CFGCHIP2 register. */
+ cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ /* USB2.0 PHY reference clock is AUXCLK with 24MHz */
+ cfgchip2 &= ~CFGCHIP2_REFFREQ;
+ cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ;
+
+ /*
+ * Select internal reference clock for USB 2.0 PHY
+ * and use it as a clock source for USB 1.1 PHY
+ * (this is the default setting anyway).
+ */
+ cfgchip2 &= ~CFGCHIP2_USB1PHYCLKMUX;
+ cfgchip2 |= CFGCHIP2_USB2PHYCLKMUX;
+
+ cfgchip2 &= ~CFGCHIP2_OTGMODE;
+ cfgchip2 |= CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
+
+ __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ ret = davinci_cfg_reg(DA830_USB0_DRVVBUS);
+ if (ret)
+ pr_warning("%s: USB 2.0 PinMux setup failed: %d\n",
+ __func__, ret);
+ else {
+ /*
+ * SP2525A @ 5V supplies 500mA,
+ * with the power on to power good time of 10 ms.
+ */
+ ret = da8xx_register_usb20(500, 10);
+ if (ret)
+ pr_warning("%s: USB 2.0 registration failed: %d\n",
+ __func__, ret);
+ }
+
+ ret = gpio_request_one(DA850_USB_VBUS_PIN,
+ GPIOF_DIR_OUT, "USB 1.1 VBUS");
+ if (ret < 0) {
+ pr_err("%s: failed to request GPIO for USB 1.1 port "
+ "power control: %d\n", __func__, ret);
+ return;
+ }
+ gpio_direction_input(DA850_USB_VBUS_PIN);
+
+ ret = gpio_request(ON_BD_USB_OVC, "ON_BD_USB_OVC");
+ if (ret) {
+ printk(KERN_ERR "%s: failed to request GPIO for USB 1.1 port "
+ "over-current indicator: %d\n", __func__, ret);
+ gpio_free(DA850_USB_VBUS_PIN);
+ return;
+ }
+ gpio_direction_input(ON_BD_USB_OVC);
+
+#if defined(CONFIG_USB_OHCI_HCD)
+ ret = da8xx_register_usb11(&enbw_cmc_usb11_pdata);
+ if (ret) {
+ pr_warning("%s: USB 1.1 registration failed: %d\n",
+ __func__, ret);
+ gpio_free(ON_BD_USB_OVC);
+ gpio_free(DA850_USB_VBUS_PIN);
+ }
+#endif
+
+ return;
+}
+
+static int enbw_cmc_mmc_get_ro(int index)
+{
+ return 0;
+}
+
+static int enbw_cmc_mmc_get_cd(int index)
+{
+ return gpio_get_value(ENBW_CMC_MMCSD_CD_PIN) ? 1 : 0;
+}
+
+static struct davinci_mmc_config enbw_cmc_mmc_config = {
+ .get_ro = enbw_cmc_mmc_get_ro,
+ .get_cd = enbw_cmc_mmc_get_cd,
+ .wires = 4,
+ .max_freq = 50000000,
+ .caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
+ .version = MMC_CTLR_VERSION_2,
+};
+
+static int __init enbw_cmc_config_emac(void)
+{
+ void __iomem *cfg_chip3_base;
+ int ret;
+ u32 val;
+ struct davinci_soc_info *soc_info = &davinci_soc_info;
+
+ if (!machine_is_enbw_cmc())
+ return 0;
+
+ cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
+ val = __raw_readl(cfg_chip3_base);
+ val &= ~BIT(8);
+ pr_info("EMAC: MII PHY configured, RMII PHY will not be"
+ " functional\n");
+
+ /* configure the CFGCHIP3 register for MII */
+ __raw_writel(val, cfg_chip3_base);
+
+ /* use complete info from OF */
+ soc_info->emac_pdata = NULL;
+ ret = da8xx_register_emac();
+ if (ret)
+ pr_warning("enbw_cmc_init: emac registration failed: %d\n",
+ ret);
+
+ return 0;
+}
+device_initcall(enbw_cmc_config_emac);
+
+static const s16 da850_dma0_rsv_chans[][2] = {
+ /* (offset, number) */
+ {-1, -1}
+};
+
+static const s16 da850_dma0_rsv_slots[][2] = {
+ /* (offset, number) */
+ {-1, -1}
+};
+
+static const s16 da850_dma1_rsv_chans[][2] = {
+ /* (offset, number) */
+ {-1, -1}
+};
+
+static const s16 da850_dma1_rsv_slots[][2] = {
+ /* (offset, number) */
+ {-1, -1}
+};
+
+static struct edma_rsv_info da850_edma_cc0_rsv = {
+ .rsv_chans = da850_dma0_rsv_chans,
+ .rsv_slots = da850_dma0_rsv_slots,
+};
+
+static struct edma_rsv_info da850_edma_cc1_rsv = {
+ .rsv_chans = da850_dma1_rsv_chans,
+ .rsv_slots = da850_dma1_rsv_slots,
+};
+
+static struct edma_rsv_info *da850_edma_rsv[2] = {
+ &da850_edma_cc0_rsv,
+ &da850_edma_cc1_rsv,
+};
+
+#ifdef CONFIG_CPU_FREQ
+static __init int da850_evm_init_cpufreq(void)
+{
+ switch (system_rev & 0xF) {
+ case 3:
+ da850_max_speed = 456000;
+ break;
+ case 2:
+ da850_max_speed = 408000;
+ break;
+ case 1:
+ da850_max_speed = 372000;
+ break;
+ }
+
+ return da850_register_cpufreq("pll0_sysclk3");
+}
+#else
+static __init int da850_evm_init_cpufreq(void) { return 0; }
+#endif
+
+struct of_dev_auxdata enbw_cmc_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "ti,davinci-wdt", NULL),
+ {}
+};
+
+const struct of_device_id enbw_cmc_bus_match_table[] = {
+ { .compatible = "simple-bus", },
+ { .compatible = "ti,da8xx", },
+ { .compatible = "ti,davinci-onchipram", },
+ { .compatible = "ti,davinci-aemif", },
+ {} /* Empty terminated list */
+};
+
+static __init void enbw_cmc_init(void)
+{
+ int ret;
+
+ of_platform_populate(NULL, enbw_cmc_bus_match_table,
+ enbw_cmc_auxdata_lookup, NULL);
+
+ ret = da850_register_edma(da850_edma_rsv);
+ if (ret)
+ pr_warning("enbw_cmc_init: edma registration failed: %d\n",
+ ret);
+
+ /*
+ * shut down uart 0 this port is not used on the board
+ */
+ __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
+
+ ret = da8xx_register_rtc();
+ if (ret)
+ pr_warning("enbw_cmc_init: rtc setup failed: %d\n", ret);
+
+ ret = da850_evm_init_cpufreq();
+ if (ret)
+ pr_warning("enbw_cmc_init: cpufreq registration failed: %d\n",
+ ret);
+
+ ret = da8xx_register_cpuidle();
+ if (ret)
+ pr_warning("enbw_cmc_init: cpuidle registration failed: %d\n",
+ ret);
+
+ ret = gpio_request(ENBW_CMC_MMCSD_CD_PIN, "MMC CD\n");
+ if (ret)
+ pr_warning("enbw_cmc_init: can not open GPIO %d\n",
+ ENBW_CMC_MMCSD_CD_PIN);
+ gpio_direction_input(ENBW_CMC_MMCSD_CD_PIN);
+
+ ret = da850_register_mmcsd1(&enbw_cmc_mmc_config);
+ if (ret)
+ pr_warning("enbw_cmc_init: mmcsd1 registration failed:"
+ " %d\n", ret);
+
+ enbw_cmc_usb_init();
+}
+#else
+static __init void enbw_cmc_init(void)
+{
+ pr_err("enbw_cmc: please use OF.\n");
+ return;
+}
+#endif
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init enbw_cmc_console_init(void)
+{
+ if (!machine_is_enbw_cmc())
+ return 0;
+
+ return add_preferred_console("ttyS", 2, "115200");
+}
+console_initcall(enbw_cmc_console_init);
+#endif
+
+static void __init enbw_cmc_map_io(void)
+{
+ da850_init();
+}
+
+static const char *enbw_cmc_board_compat[] __initconst = {
+ "enbw,cmc",
+ NULL
+};
+
+MACHINE_START(ENBW_CMC, "EnBW CMC")
+ .map_io = enbw_cmc_map_io,
+ .init_irq = davinci_init_irq,
+ .timer = &davinci_timer,
+ .init_machine = enbw_cmc_init,
+ .dt_compat = enbw_cmc_board_compat,
+ .dma_zone_size = SZ_128M,
+ .restart = da8xx_restart,
+MACHINE_END
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 9dc7cf9..2f21384 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -96,6 +96,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
DEBUG_LL_DA8XX(davinci_da850_evm, 2);
DEBUG_LL_DA8XX(mityomapl138, 1);
DEBUG_LL_DA8XX(omapl138_hawkboard, 2);
+ DEBUG_LL_DA8XX(enbw_cmc, 2);
/* TNETV107x boards */
DEBUG_LL_TNETV107X(tnetv107x, 1);
--
1.7.7.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
2012-01-23 8:56 ` [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board Heiko Schocher
@ 2012-01-30 20:32 ` Grant Likely
2012-01-31 13:04 ` Heiko Schocher
0 siblings, 1 reply; 37+ messages in thread
From: Grant Likely @ 2012-01-30 20:32 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 23, 2012 at 09:56:07AM +0100, Heiko Schocher wrote:
> - AM1808 based board
> - 64 MiB DDR ram
> - 2 MiB Nor flash
> - 128 MiB NAND flash
> - use internal RTC
> - I2C support
> - hwmon lm75 support
> - UBI/UBIFS support
> - MMC support
> - USB OTG support
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Cc: linux-mtd at lists.infradead.org
> Cc: linux-i2c at vger.kernel.org
> Cc: netdev at vger.kernel.org
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Ben Dooks <ben-linux@fluff.org>
> Cc: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Wolfgang Denk <wd@denx.de>
>
> ---
> - post this board support with USB support, even though
> USB is only working with the 10 ms "workaround", posted here:
> http://comments.gmane.org/gmane.linux.usb.general/54505
> I see this issue also on the AM1808 TMDXEXP1808L evalboard.
> - MMC and USB are not using OF support yet, ideas how to port
> this are welcome. I need for USB and MMC boards board
> specific callbacks, how to solve this with OF support?
>
> arch/arm/boot/dts/enbw_cmc.dts | 286 +++++++++++++++++
> arch/arm/configs/enbw_cmc_defconfig | 125 ++++++++
> arch/arm/mach-davinci/Kconfig | 8 +
> arch/arm/mach-davinci/Makefile | 1 +
> arch/arm/mach-davinci/board-enbw-cmc.c | 384 +++++++++++++++++++++++
> arch/arm/mach-davinci/include/mach/uncompress.h | 1 +
> 6 files changed, 805 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
> create mode 100644 arch/arm/configs/enbw_cmc_defconfig
> create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c
>
> diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts
> new file mode 100644
> index 0000000..e5995ce
> --- /dev/null
> +++ b/arch/arm/boot/dts/enbw_cmc.dts
> @@ -0,0 +1,286 @@
> +/*
> + * Device Tree for the EnBW CMC plattform
> + *
> + * Copyright 2011 DENX Software Engineering GmbH
> + * Heiko Schocher <hs@denx.de>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +/dts-v1/;
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + model = "EnBW CMC";
> + compatible = "enbw,cmc";
> +
> + aliases {
> + ethernet0 = ð0;
> + };
> +
> + arm {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0xfffee000 0x00020000>;
> + intc: interrupt-controller at 1 {
> + compatible = "ti,davinci-intc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + ti,intc-size = <101>;
> + reg = <0x0 0x2000>;
> + };
> + };
> + soc at 1c00000 {
> + compatible = "ti,da8xx";
As previously mentioned, using wildcard ('x') characters in compatible
properties is bad practice. Always be specific and use the compatible
list to make sure the correct driver gets bound (assuming the device
is 100% register level compatible with the older one).
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x01c00000 0x400000>;
> +
> + serial0: serial at 1c42000 {
> + cell-index = <2>;
As previously mentioned, don't use cell index. If you *really* need
to assign a number to a device, then use a property in the /aliases
node and make sure pdev->id does *not* get modified.
> + compatible = "ns16550a";
Should include a string for the specific device. Something like:
compatible = "ti,da800", "ns16550a";
> diff --git a/arch/arm/mach-davinci/board-enbw-cmc.c b/arch/arm/mach-davinci/board-enbw-cmc.c
> new file mode 100644
> index 0000000..4473c4a
> --- /dev/null
> +++ b/arch/arm/mach-davinci/board-enbw-cmc.c
> @@ -0,0 +1,384 @@
> +/*
> + * EnBW Communication Module Compact board
> + * Copyright 2011 DENX Software Engineering GmbH
> + * Author: Heiko Schocher <hs@denx.de>
> + *
> + * based on:
> + * TI DA850/OMAP-L138 EVM board
> + *
> + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * Derived from: arch/arm/mach-davinci/board-da850-evm.c
> + * Original Copyrights follow:
> + *
> + * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +#include <linux/console.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio_keys.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/nand.h>
> +#include <linux/mtd/partitions.h>
> +#include <linux/mtd/physmap.h>
> +#include <linux/of.h>
> +#include <linux/of_net.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/phy.h>
> +#include <linux/phy_fixed.h>
> +#include <linux/platform_device.h>
> +#include <linux/spi/spi.h>
> +#include <linux/spi/flash.h>
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <mach/aemif.h>
> +#include <mach/cp_intc.h>
> +#include <mach/da8xx.h>
> +#include <mach/mux.h>
> +#include <mach/nand.h>
> +#include <mach/spi.h>
> +
> +#define ENBW_CMC_MMCSD_CD_PIN GPIO_TO_PIN(3, 13)
> +
> +/*
> + * USB1 VBUS is controlled by GPIO7[12], over-current is reported on GPIO7[8].
> + */
> +#define DA850_USB_VBUS_PIN GPIO_TO_PIN(7, 12)
> +#define ON_BD_USB_OVC GPIO_TO_PIN(7, 8)
> +
> +#if defined(CONFIG_USB_OHCI_HCD)
> +static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id);
> +static da8xx_ocic_handler_t enbw_cmc_usb_ocic_handler;
> +
> +static int enbw_cmc_usb_set_power(unsigned port, int on)
> +{
> + gpio_set_value(DA850_USB_VBUS_PIN, on);
> + return 0;
> +}
> +
> +static int enbw_cmc_usb_get_power(unsigned port)
> +{
> + return gpio_get_value(DA850_USB_VBUS_PIN);
> +}
> +
> +static int enbw_cmc_usb_get_oci(unsigned port)
> +{
> + return !gpio_get_value(ON_BD_USB_OVC);
> +}
> +
> +static irqreturn_t enbw_cmc_usb_ocic_irq(int, void *);
> +
> +static int enbw_cmc_usb_ocic_notify(da8xx_ocic_handler_t handler)
> +{
> + int irq = gpio_to_irq(ON_BD_USB_OVC);
> + int error = 0;
> +
> + if (handler != NULL) {
> + enbw_cmc_usb_ocic_handler = handler;
> +
> + error = request_irq(irq, enbw_cmc_usb_ocic_irq,
> + IRQF_DISABLED | IRQF_TRIGGER_RISING |
> + IRQF_TRIGGER_FALLING,
> + "OHCI over-current indicator", NULL);
> + if (error)
> + pr_err("%s: could not request IRQ to watch "
> + "over-current indicator changes\n", __func__);
> + } else {
> + free_irq(irq, NULL);
> + }
> + return error;
> +}
> +
> +static struct da8xx_ohci_root_hub enbw_cmc_usb11_pdata = {
> + .set_power = enbw_cmc_usb_set_power,
> + .get_power = enbw_cmc_usb_get_power,
> + .get_oci = enbw_cmc_usb_get_oci,
> + .ocic_notify = enbw_cmc_usb_ocic_notify,
> + .potpgt = (10 + 1) / 2, /* 10 ms max */
> +};
> +
> +static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id)
> +{
> + enbw_cmc_usb_ocic_handler(&enbw_cmc_usb11_pdata, 1);
> + return IRQ_HANDLED;
> +}
> +#endif
> +
> +#if defined(CONFIG_OF)
> +static __init void enbw_cmc_usb_init(void)
All the focus is on DT now. How about making CONFIG_OF required for
this board? Also, this is just another board file. The focus should
be on creating a generic board support file for DT platforms.
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
2012-01-30 20:32 ` Grant Likely
@ 2012-01-31 13:04 ` Heiko Schocher
2012-02-01 10:20 ` Sergei Shtylyov
0 siblings, 1 reply; 37+ messages in thread
From: Heiko Schocher @ 2012-01-31 13:04 UTC (permalink / raw)
To: linux-arm-kernel
Hello Grant,
Grant Likely wrote:
> On Mon, Jan 23, 2012 at 09:56:07AM +0100, Heiko Schocher wrote:
>> - AM1808 based board
>> - 64 MiB DDR ram
>> - 2 MiB Nor flash
>> - 128 MiB NAND flash
>> - use internal RTC
>> - I2C support
>> - hwmon lm75 support
>> - UBI/UBIFS support
>> - MMC support
>> - USB OTG support
>>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree-discuss at lists.ozlabs.org
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Cc: linux-mtd at lists.infradead.org
>> Cc: linux-i2c at vger.kernel.org
>> Cc: netdev at vger.kernel.org
>> Cc: David Woodhouse <dwmw2@infradead.org>
>> Cc: Ben Dooks <ben-linux@fluff.org>
>> Cc: Wolfram Sang <w.sang@pengutronix.de>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Cc: Kevin Hilman <khilman@ti.com>
>> Cc: Wolfgang Denk <wd@denx.de>
>>
>> ---
>> - post this board support with USB support, even though
>> USB is only working with the 10 ms "workaround", posted here:
>> http://comments.gmane.org/gmane.linux.usb.general/54505
>> I see this issue also on the AM1808 TMDXEXP1808L evalboard.
>> - MMC and USB are not using OF support yet, ideas how to port
>> this are welcome. I need for USB and MMC boards board
>> specific callbacks, how to solve this with OF support?
Can you give me a hint, how to add callbacks to OF support?
>> arch/arm/boot/dts/enbw_cmc.dts | 286 +++++++++++++++++
>> arch/arm/configs/enbw_cmc_defconfig | 125 ++++++++
>> arch/arm/mach-davinci/Kconfig | 8 +
>> arch/arm/mach-davinci/Makefile | 1 +
>> arch/arm/mach-davinci/board-enbw-cmc.c | 384 +++++++++++++++++++++++
>> arch/arm/mach-davinci/include/mach/uncompress.h | 1 +
>> 6 files changed, 805 insertions(+), 0 deletions(-)
>> create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
>> create mode 100644 arch/arm/configs/enbw_cmc_defconfig
>> create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c
>>
>> diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts
>> new file mode 100644
>> index 0000000..e5995ce
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/enbw_cmc.dts
>> @@ -0,0 +1,286 @@
>> +/*
>> + * Device Tree for the EnBW CMC plattform
>> + *
>> + * Copyright 2011 DENX Software Engineering GmbH
>> + * Heiko Schocher <hs@denx.de>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + */
>> +/dts-v1/;
>> +/include/ "skeleton.dtsi"
>> +
>> +/ {
>> + model = "EnBW CMC";
>> + compatible = "enbw,cmc";
>> +
>> + aliases {
>> + ethernet0 = ð0;
>> + };
>> +
>> + arm {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0 0xfffee000 0x00020000>;
>> + intc: interrupt-controller at 1 {
>> + compatible = "ti,davinci-intc";
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> + ti,intc-size = <101>;
>> + reg = <0x0 0x2000>;
>> + };
>> + };
>> + soc at 1c00000 {
>> + compatible = "ti,da8xx";
>
> As previously mentioned, using wildcard ('x') characters in compatible
> properties is bad practice. Always be specific and use the compatible
> list to make sure the correct driver gets bound (assuming the device
> is 100% register level compatible with the older one).
fixed.
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x01c00000 0x400000>;
>> +
>> + serial0: serial at 1c42000 {
>> + cell-index = <2>;
>
> As previously mentioned, don't use cell index. If you *really* need
> to assign a number to a device, then use a property in the /aliases
> node and make sure pdev->id does *not* get modified.
removed, as not needed.
>> + compatible = "ns16550a";
>
> Should include a string for the specific device. Something like:
>
> compatible = "ti,da800", "ns16550a";
added.
>> diff --git a/arch/arm/mach-davinci/board-enbw-cmc.c b/arch/arm/mach-davinci/board-enbw-cmc.c
>> new file mode 100644
>> index 0000000..4473c4a
>> --- /dev/null
>> +++ b/arch/arm/mach-davinci/board-enbw-cmc.c
>> @@ -0,0 +1,384 @@
[...]
>> +#if defined(CONFIG_OF)
>> +static __init void enbw_cmc_usb_init(void)
>
> All the focus is on DT now. How about making CONFIG_OF required for
> this board? Also, this is just another board file. The focus should
fixed.
> be on creating a generic board support file for DT platforms.
move the arch/arm/mach-davinci/board-enbw-cmc.c to
arch/arm/mach-davinci/board-da850_simple.c
and do it like
arch/powerpc/platforms/52xx/mpc5200_simple.c ?
and extract common nodes from arch/arm/boot/dts/enbw_cmc.dts
to arch/arm/boot/dts/da850.dtsi?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
2012-01-31 13:04 ` Heiko Schocher
@ 2012-02-01 10:20 ` Sergei Shtylyov
2012-02-02 0:17 ` Grant Likely
0 siblings, 1 reply; 37+ messages in thread
From: Sergei Shtylyov @ 2012-02-01 10:20 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 31-01-2012 17:04, Heiko Schocher wrote:
>> On Mon, Jan 23, 2012 at 09:56:07AM +0100, Heiko Schocher wrote:
>>> - AM1808 based board
>>> - 64 MiB DDR ram
>>> - 2 MiB Nor flash
>>> - 128 MiB NAND flash
>>> - use internal RTC
>>> - I2C support
>>> - hwmon lm75 support
>>> - UBI/UBIFS support
>>> - MMC support
>>> - USB OTG support
>>> Signed-off-by: Heiko Schocher<hs@denx.de>
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: devicetree-discuss at lists.ozlabs.org
>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>> Cc: linux-mtd at lists.infradead.org
>>> Cc: linux-i2c at vger.kernel.org
>>> Cc: netdev at vger.kernel.org
>>> Cc: David Woodhouse<dwmw2@infradead.org>
>>> Cc: Ben Dooks<ben-linux@fluff.org>
>>> Cc: Wolfram Sang<w.sang@pengutronix.de>
>>> Cc: Sekhar Nori<nsekhar@ti.com>
>>> Cc: Kevin Hilman<khilman@ti.com>
>>> Cc: Wolfgang Denk<wd@denx.de>
>>> ---
>>> - post this board support with USB support, even though
>>> USB is only working with the 10 ms "workaround", posted here:
>>> http://comments.gmane.org/gmane.linux.usb.general/54505
>>> I see this issue also on the AM1808 TMDXEXP1808L evalboard.
>>> - MMC and USB are not using OF support yet, ideas how to port
>>> this are welcome. I need for USB and MMC boards board
>>> specific callbacks, how to solve this with OF support?
[...]
>>> diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts
>>> new file mode 100644
>>> index 0000000..e5995ce
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/enbw_cmc.dts
[...]
>>> + compatible = "ns16550a";
>> Should include a string for the specific device. Something like:
>> compatible = "ti,da800", "ns16550a";
> added.
Note that there's no DA800 chip, only DA828, DA830, and DA850 AFAIK.
WBR, Sergei
^ permalink raw reply [flat|nested] 37+ messages in thread* [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
2012-02-01 10:20 ` Sergei Shtylyov
@ 2012-02-02 0:17 ` Grant Likely
0 siblings, 0 replies; 37+ messages in thread
From: Grant Likely @ 2012-02-02 0:17 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 01, 2012 at 02:20:13PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 31-01-2012 17:04, Heiko Schocher wrote:
>
> >>On Mon, Jan 23, 2012 at 09:56:07AM +0100, Heiko Schocher wrote:
> >>>- AM1808 based board
> >>>- 64 MiB DDR ram
> >>>- 2 MiB Nor flash
> >>>- 128 MiB NAND flash
> >>>- use internal RTC
> >>>- I2C support
> >>>- hwmon lm75 support
> >>>- UBI/UBIFS support
> >>>- MMC support
> >>>- USB OTG support
>
> >>>Signed-off-by: Heiko Schocher<hs@denx.de>
> >>>Cc: linux-arm-kernel at lists.infradead.org
> >>>Cc: devicetree-discuss at lists.ozlabs.org
> >>>Cc: davinci-linux-open-source at linux.davincidsp.com
> >>>Cc: linux-mtd at lists.infradead.org
> >>>Cc: linux-i2c at vger.kernel.org
> >>>Cc: netdev at vger.kernel.org
> >>>Cc: David Woodhouse<dwmw2@infradead.org>
> >>>Cc: Ben Dooks<ben-linux@fluff.org>
> >>>Cc: Wolfram Sang<w.sang@pengutronix.de>
> >>>Cc: Sekhar Nori<nsekhar@ti.com>
> >>>Cc: Kevin Hilman<khilman@ti.com>
> >>>Cc: Wolfgang Denk<wd@denx.de>
>
> >>>---
> >>>- post this board support with USB support, even though
> >>> USB is only working with the 10 ms "workaround", posted here:
> >>> http://comments.gmane.org/gmane.linux.usb.general/54505
> >>> I see this issue also on the AM1808 TMDXEXP1808L evalboard.
> >>>- MMC and USB are not using OF support yet, ideas how to port
> >>> this are welcome. I need for USB and MMC boards board
> >>> specific callbacks, how to solve this with OF support?
>
> [...]
>
> >>>diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts
> >>>new file mode 100644
> >>>index 0000000..e5995ce
> >>>--- /dev/null
> >>>+++ b/arch/arm/boot/dts/enbw_cmc.dts
> [...]
>
> >>>+ compatible = "ns16550a";
>
> >>Should include a string for the specific device. Something like:
>
> >> compatible = "ti,da800", "ns16550a";
>
> >added.
>
> Note that there's no DA800 chip, only DA828, DA830, and DA850 AFAIK.
Right, so the compatible string should reflect that.
g.
^ permalink raw reply [flat|nested] 37+ messages in thread