Re: [PATCH 1/6] ARM: sunxi: Add pinctrl driver for Allwinner SoCs
Hi Linus,
Le 11/12/2012 01:28, Linus Walleij a écrit :
> On Mon, Dec 10, 2012 at 11:08 PM, Maxime Ripard
> wrote:
>
>> This IP has 8 banks of 32 bits, with a number of pins actually useful
>> for each of these banks varying from one to another, and depending on
>> the SoC used on the board.
>>
>> This driver only implements the pinctrl part, the gpio part will come
>> eventually.
>
> It's looking pretty nice already :-)
>
> Of course I have some comments...
>
> OK will it be a combined driver so the same file implement both pinctrl
> and gpio?
It's not fixed yet, for now I've done a very draft that is a separate
gpio driver, but relies on the pinctrl_*gpio functions.
But since it's still at an early stage, if you have a better solution,
I'd be happy to follow it.
>> +- allwinner,pin-ids: An integer array. Each integer in the array
>> + specify a pin with given mux function, with bank, pin and mux packed
>> + as below.
>> +
>> +[15..12] : bank number
>> +[11..4] : pin number
>> +[3..0] : mux selection
>
> Why are you using this scheme instead of just open-coding the three
> things? Well maybe I'm not getting it... Device Trees are usually for reading,
> not for bitstuffing, that's why I ask.
I'm used to the mxs syntax, so I based my work on it. But after a quick
look, it looks like the more recent pinctrl drivers like for bcm2835 or
mvebu use strings to give a much more readable dt.
I'll change that.
> You should pass all this DT stuff to the devicetree-discuss list because
> I'm not any good at this (paging Stephen Warren.)
Ok, I will :)
>> +- allwinner,pull: Integer.
>> +0: No resistor
>> +1: Pull-up resistor
>> +2: Pull-down resistor
>
> This seems legit.
>
>> +config PINCTRL_SUNXI
>> + bool
>> + select PINMUX
>> + select PINCONF
>
> If your SoC is only simple pinconfig like pull-up/pull-down, why are
> you not using PINCONF_GENERIC and ?
It's not only pull-up/pull-down but also "drive levels". Since we don't
have any useful datasheet for these SoCs, we're not quite sure about
what this is really about except than it is related to the current of
the pin though (thus the "to be documented" in the documentation).
I didn't saw the pinconf-generic infrastructure, I'll switch to it.
> (...)
>> + ret = of_property_read_u32(node, "allwinner,drive", &val);
>> + if (!ret)
>> + config |= val << DLEVEL_SHIFT | DLEVEL_PRESENT;
>> +
>> + ret = of_property_read_u32(node, "allwinner,pull", &val);
>> + if (!ret)
>> + config |= val << PULL_SHIFT | PULL_PRESENT;
>
> So looks nice... but can you use generic pinconfig?
Yes
>
>> +static void sunxi_pmx_set_config(struct pinctrl_dev *pctldev,
>> +unsigned pin,
>> +u8 config)
>> +{
>> + struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
>> +
>> + u32 val = readl(pctl->membase + CFG_REG(pin));
>> + u32 mask = ((1 << CFG_PINS_BITS) - 1) << CFG_OFFSET(pin);
>> + writel((val & ~mask) | config << CFG_OFFSET(pin),
>> + pctl->membase + CFG_REG(pin));
>> +}
>
> There is something a bit confusing with the naming here, this is
> configuring the multiplexing (mux) but named config and CFG,
> which makes for great misunderstandings... can it be changed
> to eg just pmx_set() and MUX_OFFSET and MUX_REG() for
> example?
You're right, will do.
>> +static struct of_device_id sunxi_pinctrl_match[] __devinitconst = {
>> + {}
>> +};
>> +MODULE_DEVICE_TABLE(of, sunxi_pinctrl_match);
>
> This table will not match very much :-/
>
> You should put one example in atleast? Something must have
> been used to test this...
Aaah, sorry, I forgot to Cc you in the second patch that adds precisely
this part of the driver...
Sorry again.
>> +static int __devinit sunxi_pinctrl_parse_group(struct platform_device *pdev,
>> + struct device_node *node,
>> + int idx,
>> + const char **out_name)
>> +{
>> + struct sunxi_pinctrl *pctl = platform_get_drvdata(pdev);
>> + struct sunxi_pinctrl_group *group = pctl->groups + idx;
>> + struct property *prop;
>> + char *group_name;
>> + int i;
>> + u32 val,
[PATCH 2/6] ARM: pinctrl: sunxi: Add the pinctrl pin set for sun5i
Since the Allwinner SoCs variants don't have the same set of pins to
handle, we need to declare the pin ranges available.
Signed-off-by: Maxime Ripard
Cc: Linus Walleij
Cc: Grant Likely
Cc: Rob Herring
Cc: devicetree-discuss@lists.ozlabs.org
---
drivers/pinctrl/pinctrl-sunxi.c | 254 +++
1 file changed, 254 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index 83d67d8..b031ed0 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -26,6 +26,259 @@
#include "core.h"
#include "pinctrl-sunxi.h"
+static const struct sunxi_desc_pin sun5i_a13_pins[] = {
+ /* Hole */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PB0,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PB1,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PB2,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PB3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PB4,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ /* Hole */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PB10,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ /* Hole */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PB15,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PB16,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PB17,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PB18,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ /* Hole */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC0,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC1,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC2,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC4,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC5,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC6,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC7,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC8,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC9,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC10,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC11,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC12,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC13,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC14,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC15,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ /* Hole */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PC19,
+
[PATCH 1/6] ARM: sunxi: Add pinctrl driver for Allwinner SoCs
The Allwinner SoCs have an IP module that handle both the muxing and the
GPIOs.
This IP has 8 banks of 32 bits, with a number of pins actually useful
for each of these banks varying from one to another, and depending on
the SoC used on the board.
This driver only implements the pinctrl part, the gpio part will come
eventually.
Signed-off-by: Maxime Ripard
Cc: Linus Walleij
Cc: Grant Likely
Cc: Rob Herring
Cc: devicetree-discuss@lists.ozlabs.org
---
.../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 60 +++
arch/arm/mach-sunxi/Kconfig|1 +
drivers/pinctrl/Kconfig|5 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-sunxi.c| 538
drivers/pinctrl/pinctrl-sunxi.h| 384 ++
include/linux/pinctrl/pinconf-generic.h|1 +
7 files changed, 990 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
create mode 100644 drivers/pinctrl/pinctrl-sunxi.c
create mode 100644 drivers/pinctrl/pinctrl-sunxi.h
diff --git
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
new file mode 100644
index 000..f8b6d82
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -0,0 +1,60 @@
+* Allwinner A1X Pin Controller
+
+The pins controlled by sunXi pin controller are organized in banks,
+each bank has 32 pins. Each pin has 7 multiplexing functions, with
+the first two functions being GPIO in and out. The configuration on
+the pins includes drive strength and pull-up.
+
+Required properties:
+- compatible: "allwinner,-pinctrl". Supported SoCs for now are:
+ sun5i-a13.
+- reg: Should contain the register physical address and length for the
+ pin controller.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+A pinctrl node should contain at least one subnodes representing the
+pinctrl groups available on the machine. Each subnode will list the
+pins it needs, and how they should be configured, with regard to muxer
+configuration, drive strength and pullups. If one of these options is
+not set, its actual value will be unspecified.
+
+Required subnode-properties:
+
+- allwinner,pins: List of strings containing the pin name.
+- allwinner,function: Function to mux the pins listed above to.
+
+Optional subnode-properties:
+- allwinner,drive: Integer. Represents the current sent to the pin
+0: To be documented
+1: To be documented
+2: To be documented
+3: To be documented
+- allwinner,pull: Integer.
+0: No resistor
+1: Pull-up resistor
+2: Pull-down resistor
+
+Examples:
+
+pinctrl@01c20800 {
+ compatible = "allwinner,sun5i-a13-pinctrl";
+ reg = <0x01c20800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ uart1_pins_a: uart1@0 {
+ allwinner,pins = "PE10", "PE11";
+ allwinner,function = "uart1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ uart1_pins_b: uart1@1 {
+ allwinner,pins = "PG3", "PG4";
+ allwinner,function = "uart1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+};
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 3fdd008..8709a39 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -7,3 +7,4 @@ config ARCH_SUNXI
select PINCTRL
select SPARSE_IRQ
select SUNXI_TIMER
+ select PINCTRL_SUNXI
\ No newline at end of file
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index d96caef..1d9a7dc 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -147,6 +147,11 @@ config PINCTRL_SIRF
depends on ARCH_PRIMA2
select PINMUX
+config PINCTRL_SUNXI
+ bool
+ select PINMUX
+ select GENERIC_PINCONF
+
config PINCTRL_TEGRA
bool
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f395ba5..8f3ddea 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_PINCTRL_PXA168) += pinctrl-pxa168.o
obj-$(CONFIG_PINCTRL_PXA910) += pinctrl-pxa910.o
obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
obj-$(CONFIG_PINCTRL_SIRF) += pinctrl-sirf.o
+obj-$(CONFIG_PINCTRL_SUNXI)+= pinctrl-sunxi.o
obj-$(CONFIG_PINCTRL_TEGRA)+= pinctrl-tegra.o
obj-$(CONFIG_PINCTRL_TEGRA20) += pinctrl-tegra20.o
obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
new file mode 100644
i
[PATCH 1/2] ARM: sunxi: gpio: Add Allwinner SoCs GPIO drivers
The IP responsible for the muxing on the Allwinner SoCs are also
handling the GPIOs on the system. This patch adds the needed driver that
relies on the pinctrl driver for most of its operations.
The number of pins available for GPIOs operations are already declared
in the pinctrl driver, we only need to probe a generic driver to handle
the banks available for each SoC.
This driver has been tested on a A13-Olinuxino.
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/gpio/gpio-sunxi.txt| 77 ++
drivers/gpio/Kconfig |6 +
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-sunxi.c | 150
drivers/pinctrl/pinctrl-sunxi.c| 106 ++
drivers/pinctrl/pinctrl-sunxi.h|6 +-
6 files changed, 345 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-sunxi.txt
create mode 100644 drivers/gpio/gpio-sunxi.c
diff --git a/Documentation/devicetree/bindings/gpio/gpio-sunxi.txt
b/Documentation/devicetree/bindings/gpio/gpio-sunxi.txt
new file mode 100644
index 000..cecdca0
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-sunxi.txt
@@ -0,0 +1,77 @@
+* Allwinner sunXi GPIO controller
+
+The Allwinner GPIO controller is part of the same IP than the PIN
+controller. The GPIOs are organized in port/bank. Each port consists
+of 32 GPIOs.
+
+As there is some interaction between the pinctrl driver and the gpio
+driver, you will need both enabled in your system for this driver to
+work.
+
+Required properties for GPIO node:
+- compatible : Should be "allwinner,sunxi-gpio".
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be one. The cell is the pin number.
+
+Note: Each GPIO port should have an alias correctly numbered in "aliases"
+node.
+
+Examples:
+aliases {
+ gpio1 = &pb;
+ gpio2 = &pc;
+ gpio3 = &pd;
+ gpio4 = &pe;
+ gpio5 = &pf;
+ gpio6 = &pg;
+};
+
+
+pinctrl@01c20800 {
+ compatible = "allwinner,sun5i-a13-pinctrl";
+ reg = <0x01c20800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
+
+pb: gpio@01c20824 {
+ compatible = "allwinner,sunxi-gpio";
+ reg = <0x01c20824 0x24>;
+ gpio-controller;
+ #gpio-cells = <1>;
+};
+
+pc: gpio@01c20848 {
+ compatible = "allwinner,sunxi-gpio";
+ reg = <0x01c20848 0x24>;
+ gpio-controller;
+ #gpio-cells = <1>;
+};
+
+pd: gpio@01c2086c {
+ compatible = "allwinner,sunxi-gpio";
+ reg = <0x01c2086c 0x24>;
+ gpio-controller;
+ #gpio-cells = <1>;
+};
+
+pe: gpio@01c20890 {
+ compatible = "allwinner,sunxi-gpio";
+ reg = <0x01c20890 0x24>;
+ gpio-controller;
+ #gpio-cells = <1>;
+};
+
+pf: gpio@01c208b4 {
+ compatible = "allwinner,sunxi-gpio";
+ reg = <0x01c208b4 0x24>;
+ gpio-controller;
+ #gpio-cells = <1>;
+};
+
+pg: gpio@01c208d8 {
+ compatible = "allwinner,sunxi-gpio";
+ reg = <0x01c208d8 0x24>;
+ gpio-controller;
+ #gpio-cells = <1>;
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 682de75..6f4199f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -224,6 +224,12 @@ config GPIO_TS5500
blocks of the TS-5500: DIO1, DIO2 and the LCD port, and the TS-5600
LCD port.
+config GPIO_SUNXI
+ def_bool y
+ depends on ARCH_SUNXI
+ select GPIO_GENERIC
+ select GENERIC_IRQ_CHIP
+
config GPIO_VT8500
bool "VIA/Wondermedia SoC GPIO Support"
depends on ARCH_VT8500
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index c5aebd0..c5a9306 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_GPIO_SPEAR_SPICS)+= gpio-spear-spics.o
obj-$(CONFIG_GPIO_STA2X11) += gpio-sta2x11.o
obj-$(CONFIG_GPIO_STMPE) += gpio-stmpe.o
obj-$(CONFIG_GPIO_STP_XWAY)+= gpio-stp-xway.o
+obj-$(CONFIG_GPIO_SUNXI) += gpio-sunxi.o
obj-$(CONFIG_GPIO_SX150X) += gpio-sx150x.o
obj-$(CONFIG_GPIO_TC3589X) += gpio-tc3589x.o
obj-$(CONFIG_ARCH_TEGRA) += gpio-tegra.o
diff --git a/drivers/gpio/gpio-sunxi.c b/drivers/gpio/gpio-sunxi.c
new file mode 100644
index 000..017ace4
--- /dev/null
+++ b/drivers/gpio/gpio-sunxi.c
@@ -0,0 +1,150 @@
+/*
+ * Allwinner A1X SoCs GPIO driver.
+ *
+ * Copyright (C) 2012 Maxime Ripard
+ *
+ * Maxime Ripard
+ *
+ * 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.
+ */
+
+#includ
Re: [PATCH 1/6] ARM: sunxi: Add pinctrl driver for Allwinner SoCs
Hi Linus,
Le 07/01/2013 00:46, Linus Walleij a écrit :
> On Wed, Dec 19, 2012 at 9:18 PM, Maxime Ripard
> wrote:
>
>> The Allwinner SoCs have an IP module that handle both the muxing and the
>> GPIOs.
>
> Sorry for very slow review :-( :-(
That's fine, at that time of the year, I wasn't expecting a fast review
anyway :)
>> include/linux/pinctrl/pinconf-generic.h|1 +
>
> Can you break this into a separate patch and rebase it?
>
> It does not apply anymore after v3.8...
Ah, yes, of course... Will do.
>> diff --git a/include/linux/pinctrl/pinconf-generic.h
>> b/include/linux/pinctrl/pinconf-generic.h
>> index 4f0abb9..5f5968d 100644
>> --- a/include/linux/pinctrl/pinconf-generic.h
>> +++ b/include/linux/pinctrl/pinconf-generic.h
>> @@ -74,6 +74,7 @@ enum pin_config_param {
>> PIN_CONFIG_DRIVE_PUSH_PULL,
>> PIN_CONFIG_DRIVE_OPEN_DRAIN,
>> PIN_CONFIG_DRIVE_OPEN_SOURCE,
>> + PIN_CONFIG_DRIVE_CURRENT,
>> PIN_CONFIG_INPUT_SCHMITT,
>> PIN_CONFIG_INPUT_DEBOUNCE,
>> PIN_CONFIG_POWER_SOURCE,
>
> Above the definitions there is some kerneldoc and that is where this has to be
> defined.
>
> You also have to defines what the argument to this parameter is.
>
> I think it should be renamed PIN_CONFIG_DRIVE_STRENGTH and the
> argument should be the number of drivers stages.
>
> These things are constructed with totem-pole-like outputs and the number
> of totempoles define the drive strength, usually it will be something like
>
> 1 = 2mA
> 2 = 4mA
> 3 = 6mA
> 4 = 8mA
>
> or similar, as you see 2 mA for each added driver stage. The driver can
> convert to any internal representation...
Ok, I will do it.
Do you have other comments on the driver that I should wait for before
sending a v3?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/7] ARM: sunxi: Add pinctrl driver for Allwinner SoCs
The Allwinner SoCs have an IP module that handle both the muxing and the
GPIOs.
This IP has 8 banks of 32 bits, with a number of pins actually useful
for each of these banks varying from one to another, and depending on
the SoC used on the board.
This driver only implements the pinctrl part, the gpio part will come
eventually.
Signed-off-by: Maxime Ripard
---
.../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 60 +++
arch/arm/mach-sunxi/Kconfig|1 +
drivers/pinctrl/Kconfig|5 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-sunxi.c| 549
drivers/pinctrl/pinctrl-sunxi.h| 384 ++
6 files changed, 1000 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
create mode 100644 drivers/pinctrl/pinctrl-sunxi.c
create mode 100644 drivers/pinctrl/pinctrl-sunxi.h
diff --git
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
new file mode 100644
index 000..dff0e5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -0,0 +1,60 @@
+* Allwinner A1X Pin Controller
+
+The pins controlled by sunXi pin controller are organized in banks,
+each bank has 32 pins. Each pin has 7 multiplexing functions, with
+the first two functions being GPIO in and out. The configuration on
+the pins includes drive strength and pull-up.
+
+Required properties:
+- compatible: "allwinner,-pinctrl". Supported SoCs for now are:
+ sun5i-a13.
+- reg: Should contain the register physical address and length for the
+ pin controller.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+A pinctrl node should contain at least one subnodes representing the
+pinctrl groups available on the machine. Each subnode will list the
+pins it needs, and how they should be configured, with regard to muxer
+configuration, drive strength and pullups. If one of these options is
+not set, its actual value will be unspecified.
+
+Required subnode-properties:
+
+- allwinner,pins: List of strings containing the pin name.
+- allwinner,function: Function to mux the pins listed above to.
+
+Optional subnode-properties:
+- allwinner,drive: Integer. Represents the current sent to the pin
+0: 10 mA
+1: 20 mA
+2: 30 mA
+3: 40 mA
+- allwinner,pull: Integer.
+0: No resistor
+1: Pull-up resistor
+2: Pull-down resistor
+
+Examples:
+
+pinctrl@01c20800 {
+ compatible = "allwinner,sun5i-a13-pinctrl";
+ reg = <0x01c20800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ uart1_pins_a: uart1@0 {
+ allwinner,pins = "PE10", "PE11";
+ allwinner,function = "uart1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ uart1_pins_b: uart1@1 {
+ allwinner,pins = "PG3", "PG4";
+ allwinner,function = "uart1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+};
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 3fdd008..8709a39 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -7,3 +7,4 @@ config ARCH_SUNXI
select PINCTRL
select SPARSE_IRQ
select SUNXI_TIMER
+ select PINCTRL_SUNXI
\ No newline at end of file
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index c31aeb0..88840a4 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -151,6 +151,11 @@ config PINCTRL_SIRF
depends on ARCH_SIRF
select PINMUX
+config PINCTRL_SUNXI
+ bool
+ select PINMUX
+ select GENERIC_PINCONF
+
config PINCTRL_TEGRA
bool
select PINMUX
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index fc4606f..a2427da 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_PINCTRL_PXA168) += pinctrl-pxa168.o
obj-$(CONFIG_PINCTRL_PXA910) += pinctrl-pxa910.o
obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
obj-$(CONFIG_PINCTRL_SIRF) += pinctrl-sirf.o
+obj-$(CONFIG_PINCTRL_SUNXI)+= pinctrl-sunxi.o
obj-$(CONFIG_PINCTRL_TEGRA)+= pinctrl-tegra.o
obj-$(CONFIG_PINCTRL_TEGRA20) += pinctrl-tegra20.o
obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
new file mode 100644
index 000..1b85a81
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -0,0 +1,549 @@
+/*
+ * Allwinner A1X SoCs pinctrl driver.
+ *
+ * Copyright (C) 2012 Maxime Ripard
+
Re: [PATCH 1/2] ARM: sunxi: gpio: Add Allwinner SoCs GPIO drivers
Hi Linus,
On 10/01/2013 12:06, Linus Walleij wrote:
> On Fri, Jan 4, 2013 at 5:45 PM, Maxime Ripard
> wrote:
>> +static int __devinit
>> +sunxi_pinctrl_register_gpio_ranges(struct sunxi_pinctrl *pctl)
>> +{
>> + int id = 0, base = 0, npins = 1, i, prev_pin = -1;
>> + struct pinctrl_gpio_range *range;
>> +
>> + for (i = 0; i < pctl->desc->npins; i++) {
>> + const struct sunxi_desc_pin *pin = pctl->desc->pins + i;
>> + unsigned pin_num = pin->pin.number;
>> +
>> + if (prev_pin < 0) {
>> + prev_pin = pin_num;
>> + base = pin_num;
>> + } else if (prev_pin + 1 != pin_num) {
>> + range = devm_kzalloc(pctl->dev,
>> + sizeof(*range),
>> + GFP_KERNEL);
>> + if (!range)
>> + return -ENOMEM;
>> +
>> + range->name = "sunxi";
>> + range->id = id;
>> + range->base = base;
>> + range->pin_base = base;
>> + range->npins = npins;
>> +
>> + pinctrl_add_gpio_range(pctl->pctl_dev, range);
>> +
>> + id++;
>> + npins = 1;
>> + prev_pin = pin_num;
>> + base = prev_pin;
>> + } else {
>> + prev_pin++;
>> + npins++;
>> + }
>> + }
>> +
>> + range = devm_kzalloc(pctl->dev, sizeof(*range),
>> + GFP_KERNEL);
>> + if (!range)
>> + return -ENOMEM;
>> +
>> + range->name = "sunxi";
>> + range->id = id;
>> + range->base = base;
>> + range->pin_base = base;
>> + range->npins = npins;
>> +
>> + pinctrl_add_gpio_range(pctl->pctl_dev, range);
>> +
>> + return 0;
>> +}
>
> Really hairy way to add ranges right?
Yes... I didn't find any best way to do so. It was either that or
duplicate the already existing informations we had about the pins ranges
into a ranges array, which is pretty error-prone.
I guess I could add some comments though.
> Registering ranges from the pinctrl side is deprecated and discouraged.
>
> Instead register the ranges from the GPIO driver.
>
> Use gpiochip_add_pin_range() from the GPIO driver.
>
> An example is provided in
> drivers/pinctrl/pinctrl-coh901.c
Ok, will do. But we need to find a way to share the pins arrays between
the pinctrl and gpio drivers then.
Maybe add a pinctrl-sunxi-pins.h file? or merge the pinctrl and gpio
drivers?
I'm kind of reluctant to merging the drivers into one single messy file,
but if that's the way to go, fine.
>
> After you have done this, you can probably get rid of this as well:
>
> +static int __init sunxi_gpio_init(void)
> +{
> + return platform_driver_register(&sunxi_gpio_driver);
> +}
> +postcore_initcall(sunxi_gpio_init);
>
> This will become a simple module_init() if you are handling
> deferred probe correctly.
Ok. Thanks for your review!
Maxime
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/7] ARM: sunxi: Add pinctrl driver for Allwinner SoCs
The Allwinner SoCs have an IP module that handle both the muxing and the
GPIOs.
This IP has 8 banks of 32 bits, with a number of pins actually useful
for each of these banks varying from one to another, and depending on
the SoC used on the board.
This driver only implements the pinctrl part, the gpio part will come
eventually.
Signed-off-by: Maxime Ripard
---
.../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 60 +++
arch/arm/mach-sunxi/Kconfig|1 +
drivers/pinctrl/Kconfig|5 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-sunxi.c| 548
drivers/pinctrl/pinctrl-sunxi.h| 387 ++
6 files changed, 1002 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
create mode 100644 drivers/pinctrl/pinctrl-sunxi.c
create mode 100644 drivers/pinctrl/pinctrl-sunxi.h
diff --git
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
new file mode 100644
index 000..dff0e5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -0,0 +1,60 @@
+* Allwinner A1X Pin Controller
+
+The pins controlled by sunXi pin controller are organized in banks,
+each bank has 32 pins. Each pin has 7 multiplexing functions, with
+the first two functions being GPIO in and out. The configuration on
+the pins includes drive strength and pull-up.
+
+Required properties:
+- compatible: "allwinner,-pinctrl". Supported SoCs for now are:
+ sun5i-a13.
+- reg: Should contain the register physical address and length for the
+ pin controller.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+A pinctrl node should contain at least one subnodes representing the
+pinctrl groups available on the machine. Each subnode will list the
+pins it needs, and how they should be configured, with regard to muxer
+configuration, drive strength and pullups. If one of these options is
+not set, its actual value will be unspecified.
+
+Required subnode-properties:
+
+- allwinner,pins: List of strings containing the pin name.
+- allwinner,function: Function to mux the pins listed above to.
+
+Optional subnode-properties:
+- allwinner,drive: Integer. Represents the current sent to the pin
+0: 10 mA
+1: 20 mA
+2: 30 mA
+3: 40 mA
+- allwinner,pull: Integer.
+0: No resistor
+1: Pull-up resistor
+2: Pull-down resistor
+
+Examples:
+
+pinctrl@01c20800 {
+ compatible = "allwinner,sun5i-a13-pinctrl";
+ reg = <0x01c20800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ uart1_pins_a: uart1@0 {
+ allwinner,pins = "PE10", "PE11";
+ allwinner,function = "uart1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ uart1_pins_b: uart1@1 {
+ allwinner,pins = "PG3", "PG4";
+ allwinner,function = "uart1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+};
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 3fdd008..8709a39 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -7,3 +7,4 @@ config ARCH_SUNXI
select PINCTRL
select SPARSE_IRQ
select SUNXI_TIMER
+ select PINCTRL_SUNXI
\ No newline at end of file
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index c31aeb0..88840a4 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -151,6 +151,11 @@ config PINCTRL_SIRF
depends on ARCH_SIRF
select PINMUX
+config PINCTRL_SUNXI
+ bool
+ select PINMUX
+ select GENERIC_PINCONF
+
config PINCTRL_TEGRA
bool
select PINMUX
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index fc4606f..a2427da 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_PINCTRL_PXA168) += pinctrl-pxa168.o
obj-$(CONFIG_PINCTRL_PXA910) += pinctrl-pxa910.o
obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
obj-$(CONFIG_PINCTRL_SIRF) += pinctrl-sirf.o
+obj-$(CONFIG_PINCTRL_SUNXI)+= pinctrl-sunxi.o
obj-$(CONFIG_PINCTRL_TEGRA)+= pinctrl-tegra.o
obj-$(CONFIG_PINCTRL_TEGRA20) += pinctrl-tegra20.o
obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
new file mode 100644
index 000..1a81613
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -0,0 +1,548 @@
+/*
+ * Allwinner A1X SoCs pinctrl driver.
+ *
+ * Copyright (C) 2012 Maxime Ripard
+
[PATCH 1/3] fb: backlight: Add the Himax HX-8357B LCD controller
Signed-off-by: Maxime Ripard
---
drivers/video/backlight/Kconfig |7 +
drivers/video/backlight/Makefile |1 +
drivers/video/backlight/hx8357.c | 482 ++
3 files changed, 490 insertions(+)
create mode 100644 drivers/video/backlight/hx8357.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 765a945..c39bed0 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -126,6 +126,13 @@ config LCD_AMS369FG06
If you have an AMS369FG06 AMOLED Panel, say Y to enable its
LCD control driver.
+config LCD_HX8357
+ tristate "Himax HX-8357 LCD Driver"
+ depends on SPI
+ help
+ If you have a HX-8357 LCD panel, say Y to enable its LCD control
+ driver.
+
endif # LCD_CLASS_DEVICE
#
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index e7ce729..b69d391 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_LCD_TOSA) += tosa_lcd.o
obj-$(CONFIG_LCD_S6E63M0) += s6e63m0.o
obj-$(CONFIG_LCD_LD9040) += ld9040.o
obj-$(CONFIG_LCD_AMS369FG06) += ams369fg06.o
+obj-$(CONFIG_LCD_HX8357) += hx8357.o
obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o
obj-$(CONFIG_BACKLIGHT_ATMEL_PWM)+= atmel-pwm-bl.o
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
new file mode 100644
index 000..ee4d607
--- /dev/null
+++ b/drivers/video/backlight/hx8357.c
@@ -0,0 +1,482 @@
+/*
+ * Driver for the Himax HX-8357 LCD Controller
+ *
+ * Copyright 2012 Free Electrons
+ *
+ * Licensed under the GPLv2 or later.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HX8357_NUM_IM_PINS 3
+
+#define HX8357_SWRESET 0x01
+#define HX8357_GET_RED_CHANNEL 0x06
+#define HX8357_GET_GREEN_CHANNEL 0x07
+#define HX8357_GET_BLUE_CHANNEL0x08
+#define HX8357_GET_POWER_MODE 0x0a
+#define HX8357_GET_MADCTL 0x0b
+#define HX8357_GET_PIXEL_FORMAT0x0c
+#define HX8357_GET_DISPLAY_MODE0x0d
+#define HX8357_GET_SIGNAL_MODE 0x0e
+#define HX8357_GET_DIAGNOSTIC_RESULT 0x0f
+#define HX8357_ENTER_SLEEP_MODE0x10
+#define HX8357_EXIT_SLEEP_MODE 0x11
+#define HX8357_ENTER_PARTIAL_MODE 0x12
+#define HX8357_ENTER_NORMAL_MODE 0x13
+#define HX8357_EXIT_INVERSION_MODE 0x20
+#define HX8357_ENTER_INVERSION_MODE0x21
+#define HX8357_SET_DISPLAY_OFF 0x28
+#define HX8357_SET_DISPLAY_ON 0x29
+#define HX8357_SET_COLUMN_ADDRESS 0x2a
+#define HX8357_SET_PAGE_ADDRESS0x2b
+#define HX8357_WRITE_MEMORY_START 0x2c
+#define HX8357_READ_MEMORY_START 0x2e
+#define HX8357_SET_PARTIAL_AREA0x30
+#define HX8357_SET_SCROLL_AREA 0x33
+#define HX8357_SET_TEAR_OFF0x34
+#define HX8357_SET_TEAR_ON 0x35
+#define HX8357_SET_ADDRESS_MODE0x36
+#define HX8357_SET_SCROLL_START0x37
+#define HX8357_EXIT_IDLE_MODE 0x38
+#define HX8357_ENTER_IDLE_MOD 0x39
+#define HX8357_SET_PIXEL_FORMAT0x3a
+#define HX8357_SET_PIXEL_FORMAT_DBI_3BIT (0x1)
+#define HX8357_SET_PIXEL_FORMAT_DBI_16BIT (0x5)
+#define HX8357_SET_PIXEL_FORMAT_DBI_18BIT (0x6)
+#define HX8357_SET_PIXEL_FORMAT_DPI_3BIT (0x1 << 4)
+#define HX8357_SET_PIXEL_FORMAT_DPI_16BIT (0x5 << 4)
+#define HX8357_SET_PIXEL_FORMAT_DPI_18BIT (0x6 << 4)
+#define HX8357_WRITE_MEMORY_CONTINUE 0x3c
+#define HX8357_READ_MEMORY_CONTINUE0x3e
+#define HX8357_SET_TEAR_SCAN_LINES 0x44
+#define HX8357_GET_SCAN_LINES 0x45
+#define HX8357_READ_DDB_START 0xa1
+#define HX8357_SET_DISPLAY_MODE0xb4
+#define HX8357_SET_DISPLAY_MODE_RGB_THROUGH(0x3)
+#define HX8357_SET_DISPLAY_MODE_RGB_INTERFACE (1 << 4)
+#define HX8357_SET_PANEL_DRIVING 0xc0
+#define HX8357_SET_DISPLAY_FRAME 0xc5
+#define HX8357_SET_RGB 0xc6
+#define HX8357_SET_RGB_ENABLE_HIGH (1 << 1)
+#define HX8357_SET_GAMMA 0xc8
+#define HX8357_SET_POWER 0xd0
+#define HX8357_SET_VCOM0xd1
+#define HX8357_SET_POWER_NORMAL0xd2
+#define HX8357_SET_PANEL_RELATED 0xe9
+
+struct hx8357_data {
+ unsignedim_pins[HX8357_NUM_IM_PINS];
+ unsignedreset;
+ struct spi_device *spi;
+ int state;
+};
+
+static int hx8357_spi_write_then_read(struct lcd_device *lcdev,
+ void *txbuf, u16 txlen,
+ void *rxbuf, u16 rxlen)
+{
+ struct hx8357_data *lcd = lcd_get_data(lcdev);
+ struct spi_message
[PATCH 1/3] fb: backlight: Add the Himax HX-8357B LCD controller
Signed-off-by: Maxime Ripard
Cc: Andrew Morton
---
drivers/video/backlight/Kconfig |7 +
drivers/video/backlight/Makefile |1 +
drivers/video/backlight/hx8357.c | 482 ++
3 files changed, 490 insertions(+)
create mode 100644 drivers/video/backlight/hx8357.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 765a945..c39bed0 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -126,6 +126,13 @@ config LCD_AMS369FG06
If you have an AMS369FG06 AMOLED Panel, say Y to enable its
LCD control driver.
+config LCD_HX8357
+ tristate "Himax HX-8357 LCD Driver"
+ depends on SPI
+ help
+ If you have a HX-8357 LCD panel, say Y to enable its LCD control
+ driver.
+
endif # LCD_CLASS_DEVICE
#
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index e7ce729..b69d391 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_LCD_TOSA) += tosa_lcd.o
obj-$(CONFIG_LCD_S6E63M0) += s6e63m0.o
obj-$(CONFIG_LCD_LD9040) += ld9040.o
obj-$(CONFIG_LCD_AMS369FG06) += ams369fg06.o
+obj-$(CONFIG_LCD_HX8357) += hx8357.o
obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o
obj-$(CONFIG_BACKLIGHT_ATMEL_PWM)+= atmel-pwm-bl.o
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
new file mode 100644
index 000..00925c0
--- /dev/null
+++ b/drivers/video/backlight/hx8357.c
@@ -0,0 +1,482 @@
+/*
+ * Driver for the Himax HX-8357 LCD Controller
+ *
+ * Copyright 2012 Free Electrons
+ *
+ * Licensed under the GPLv2 or later.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HX8357_NUM_IM_PINS 3
+
+#define HX8357_SWRESET 0x01
+#define HX8357_GET_RED_CHANNEL 0x06
+#define HX8357_GET_GREEN_CHANNEL 0x07
+#define HX8357_GET_BLUE_CHANNEL0x08
+#define HX8357_GET_POWER_MODE 0x0a
+#define HX8357_GET_MADCTL 0x0b
+#define HX8357_GET_PIXEL_FORMAT0x0c
+#define HX8357_GET_DISPLAY_MODE0x0d
+#define HX8357_GET_SIGNAL_MODE 0x0e
+#define HX8357_GET_DIAGNOSTIC_RESULT 0x0f
+#define HX8357_ENTER_SLEEP_MODE0x10
+#define HX8357_EXIT_SLEEP_MODE 0x11
+#define HX8357_ENTER_PARTIAL_MODE 0x12
+#define HX8357_ENTER_NORMAL_MODE 0x13
+#define HX8357_EXIT_INVERSION_MODE 0x20
+#define HX8357_ENTER_INVERSION_MODE0x21
+#define HX8357_SET_DISPLAY_OFF 0x28
+#define HX8357_SET_DISPLAY_ON 0x29
+#define HX8357_SET_COLUMN_ADDRESS 0x2a
+#define HX8357_SET_PAGE_ADDRESS0x2b
+#define HX8357_WRITE_MEMORY_START 0x2c
+#define HX8357_READ_MEMORY_START 0x2e
+#define HX8357_SET_PARTIAL_AREA0x30
+#define HX8357_SET_SCROLL_AREA 0x33
+#define HX8357_SET_TEAR_OFF0x34
+#define HX8357_SET_TEAR_ON 0x35
+#define HX8357_SET_ADDRESS_MODE0x36
+#define HX8357_SET_SCROLL_START0x37
+#define HX8357_EXIT_IDLE_MODE 0x38
+#define HX8357_ENTER_IDLE_MODE 0x39
+#define HX8357_SET_PIXEL_FORMAT0x3a
+#define HX8357_SET_PIXEL_FORMAT_DBI_3BIT (0x1)
+#define HX8357_SET_PIXEL_FORMAT_DBI_16BIT (0x5)
+#define HX8357_SET_PIXEL_FORMAT_DBI_18BIT (0x6)
+#define HX8357_SET_PIXEL_FORMAT_DPI_3BIT (0x1 << 4)
+#define HX8357_SET_PIXEL_FORMAT_DPI_16BIT (0x5 << 4)
+#define HX8357_SET_PIXEL_FORMAT_DPI_18BIT (0x6 << 4)
+#define HX8357_WRITE_MEMORY_CONTINUE 0x3c
+#define HX8357_READ_MEMORY_CONTINUE0x3e
+#define HX8357_SET_TEAR_SCAN_LINES 0x44
+#define HX8357_GET_SCAN_LINES 0x45
+#define HX8357_READ_DDB_START 0xa1
+#define HX8357_SET_DISPLAY_MODE0xb4
+#define HX8357_SET_DISPLAY_MODE_RGB_THROUGH(0x3)
+#define HX8357_SET_DISPLAY_MODE_RGB_INTERFACE (1 << 4)
+#define HX8357_SET_PANEL_DRIVING 0xc0
+#define HX8357_SET_DISPLAY_FRAME 0xc5
+#define HX8357_SET_RGB 0xc6
+#define HX8357_SET_RGB_ENABLE_HIGH (1 << 1)
+#define HX8357_SET_GAMMA 0xc8
+#define HX8357_SET_POWER 0xd0
+#define HX8357_SET_VCOM0xd1
+#define HX8357_SET_POWER_NORMAL0xd2
+#define HX8357_SET_PANEL_RELATED 0xe9
+
+struct hx8357_data {
+ unsignedim_pins[HX8357_NUM_IM_PINS];
+ unsignedreset;
+ struct spi_device *spi;
+ int state;
+};
+
+static int hx8357_spi_write_then_read(struct lcd_device *lcdev,
+ void *txbuf, u16 txlen,
+ void *rxbuf, u16 rxlen)
+{
+ struct hx8357_data *lcd = lcd_get_data(lcdev);
+ struct spi_
[PATCH 1/2] video: ssd1307fb: Add support for SSD1306 OLED controller
The Solomon SSD1306 OLED controller is very similar to the SSD1307,
except for the fact that the power is given through an external PWM for
the 1307, and while the 1306 can generate its own power without any PWM.
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/video/ssd1307fb.txt| 10 +-
drivers/video/ssd1307fb.c | 267 ++--
2 files changed, 203 insertions(+), 74 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt
b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index 3d0060c..7a12542 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -1,13 +1,17 @@
* Solomon SSD1307 Framebuffer Driver
Required properties:
- - compatible: Should be "solomon,ssd1307fb-". The only supported bus for
-now is i2c.
+ - compatible: Should be "solomon,fb-". The only supported bus for
+now is i2c, and the supported chips are ssd1306 and ssd1307.
- reg: Should contain address of the controller on the I2C bus. Most likely
0x3c or 0x3d
- pwm: Should contain the pwm to use according to the OF device tree PWM
- specification [0]
+ specification [0]. Only required for the ssd1307.
- reset-gpios: Should contain the GPIO used to reset the OLED display
+ - solomon,height: Height in pixel of the screen driven by the controller
+ - solomon,width: Width in pixel of the screen driven by the controller
+ - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is
+mapped to.
Optional properties:
- reset-active-low: Is the reset gpio is active on physical low?
diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
index 395cb6a..95f76e2 100644
--- a/drivers/video/ssd1307fb.c
+++ b/drivers/video/ssd1307fb.c
@@ -16,24 +16,39 @@
#include
#include
-#define SSD1307FB_WIDTH96
-#define SSD1307FB_HEIGHT 16
-
#define SSD1307FB_DATA 0x40
#define SSD1307FB_COMMAND 0x80
#define SSD1307FB_CONTRAST 0x81
+#defineSSD1307FB_CHARGE_PUMP 0x8d
#define SSD1307FB_SEG_REMAP_ON 0xa1
#define SSD1307FB_DISPLAY_OFF 0xae
+#define SSD1307FB_SET_MULTIPLEX_RATIO 0xa8
#define SSD1307FB_DISPLAY_ON 0xaf
#define SSD1307FB_START_PAGE_ADDRESS 0xb0
+#define SSD1307FB_SET_DISPLAY_OFFSET 0xd3
+#defineSSD1307FB_SET_CLOCK_FREQ0xd5
+#defineSSD1307FB_SET_PRECHARGE_PERIOD 0xd9
+#defineSSD1307FB_SET_COM_PINS_CONFIG 0xda
+#defineSSD1307FB_SET_VCOMH 0xdb
+
+struct ssd1307fb_par;
+
+struct ssd1307fb_ops {
+ int (*init)(struct ssd1307fb_par *);
+ int (*remove)(struct ssd1307fb_par *);
+};
struct ssd1307fb_par {
struct i2c_client *client;
+ u32 height;
struct fb_info *info;
+ struct ssd1307fb_ops *ops;
+ u32 page_offset;
struct pwm_device *pwm;
u32 pwm_period;
int reset;
+ u32 width;
};
static struct fb_fix_screeninfo ssd1307fb_fix = {
@@ -43,15 +58,10 @@ static struct fb_fix_screeninfo ssd1307fb_fix = {
.xpanstep = 0,
.ypanstep = 0,
.ywrapstep = 0,
- .line_length= SSD1307FB_WIDTH / 8,
.accel = FB_ACCEL_NONE,
};
static struct fb_var_screeninfo ssd1307fb_var = {
- .xres = SSD1307FB_WIDTH,
- .yres = SSD1307FB_HEIGHT,
- .xres_virtual = SSD1307FB_WIDTH,
- .yres_virtual = SSD1307FB_HEIGHT,
.bits_per_pixel = 1,
};
@@ -134,16 +144,16 @@ static void ssd1307fb_update_display(struct ssd1307fb_par
*par)
* (5) A4 B4 C4 D4 E4 F4 G4 H4
*/
- for (i = 0; i < (SSD1307FB_HEIGHT / 8); i++) {
- ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS +
(i + 1));
+ for (i = 0; i < (par->height / 8); i++) {
+ ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS +
i + par->page_offset);
ssd1307fb_write_cmd(par->client, 0x00);
ssd1307fb_write_cmd(par->client, 0x10);
- for (j = 0; j < SSD1307FB_WIDTH; j++) {
+ for (j = 0; j < par->width; j++) {
u8 buf = 0;
for (k = 0; k < 8; k++) {
- u32 page_length = SSD1307FB_WIDTH * i;
- u32 index = page_length + (SSD1307FB_WIDTH * k
+ j) / 8;
+ u32 page_length = par->width * i;
+ u32 index = page_length + (par->width * k + j)
/ 8;
u8 byte = *(vmem + index);
u8 bit = byte & (1 << (j % 8));
bit = bit >> (j % 8);
@@ -227,16 +23
Re: doubt about where to put pin-mux in MX28 based platform DT
Hi Hector,
Le 06/03/2013 18:02, Hector Palacios a écrit :
> I'm creating the DT for a custom platform based on Freescale MX28 CPU
> and I have some doubts about where to add some pin mux configurations:
> whether in imx28.dtsi or in my platform dts.
>
> A pair of examples folow:
>
> Example #1. My platform is using a valid IOMUX for DUART TX/RX lines
> which is not covered in imx28.dtsi, namely the I2C0 pins. Since this is
> a valid IOMUX that can be used by other platforms, I'd say I should
> included it in imx28.dtsi:
>
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 3fa6d19..8928b7b 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -186,6 +186,17 @@
> fsl,pull-up = <0>;
> };
>
> + duart_pins_c: duart@2 {
> + reg = <2>;
> + fsl,pinmux-ids = <
> + 0x3182 /*
> MX28_PAD_I2C0_SCL__DUART_RX */
> + 0x3192 /*
> MX28_PAD_I2C0_SDA__DUART_TX */
> + >;
> + fsl,drive-strength = <0>;
> + fsl,voltage = <1>;
> + fsl,pull-up = <0>;
> + };
> +
> duart_4pins_a: duart-4pins@0 {
> reg = <0>;
> fsl,pinmux-ids = <
That's right.
> Example #2. My platform assembles a NAND chip which is powered at 1.8V.
> The imx28.dtsi has a configuration 'gpmi_pins_a: gpmi-nand@0' that
> configures the pins at 3.3V.
> Should I create another entry here 'gpmi_pins_b: gpmi-nand@1' with
> fsl,voltage = <0>; or should I create a specific entry in my platform's
> DT instead?
> What is the convention?
Since it's the same pinset, I'd rather go for using gpmi_pins_a in your
NAND chip node, but also overload the fsl,voltage property of
gpmi_pins_a in your board device tree.
That would give something like
pinctrl@80018000 {
gpmi_pins_a: gpmi-nand@0 {
fsl,voltage = <0>;
};
};
nand@deadbeef {
pinctrl-names = "default";
pinctrl-0 = <&gpmi_pins_a>;
}
But maybe Sascha will have a different view on this.
Maxime
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/5] net: Add davicom wemac ethernet driver found on Allwinner A10 SoC's
From: Stefan Roese
The Allwinner A10 has an ethernet controller that is advertised as
coming from Davicom.
The exact feature set of this controller is unknown, since there is no
public documentation for this IP, and this driver is mostly the one
published by Allwinner that has been heavily cleaned up.
Signed-off-by: Stefan Roese
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/net/davicom-wemac.txt | 20 +
drivers/net/ethernet/Makefile |2 +-
drivers/net/ethernet/davicom/Kconfig | 31 +
drivers/net/ethernet/davicom/Makefile |1 +
drivers/net/ethernet/davicom/wemac.c | 1033
drivers/net/ethernet/davicom/wemac.h | 130 +++
6 files changed, 1216 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/davicom-wemac.txt
create mode 100644 drivers/net/ethernet/davicom/wemac.c
create mode 100644 drivers/net/ethernet/davicom/wemac.h
diff --git a/Documentation/devicetree/bindings/net/davicom-wemac.txt
b/Documentation/devicetree/bindings/net/davicom-wemac.txt
new file mode 100644
index 000..516cf31
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/davicom-wemac.txt
@@ -0,0 +1,20 @@
+* Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
+
+Required properties:
+- compatible: should be "marvell,armada-370-neta".
+- reg: address and length of the register set for the device.
+- interrupts: interrupt for the device
+
+Optional properties:
+- allwinner,power-gpios: gpio pointer if the phy needs to be
+ enabled through a GPIO.
+- (local-)mac-address: mac address to be used by this driver
+
+Example:
+
+wemac: ethernet@01c0b000 {
+ compatible = "davicom,wemac";
+ reg = <0x01c0b000 0x1000>;
+ interrupts = <55>;
+ allwinner,power-gpios = <&pio 7 19 0>;
+};
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 8268d85..5871143 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_NET_CALXEDA_XGMAC) += calxeda/
obj-$(CONFIG_NET_VENDOR_CHELSIO) += chelsio/
obj-$(CONFIG_NET_VENDOR_CIRRUS) += cirrus/
obj-$(CONFIG_NET_VENDOR_CISCO) += cisco/
-obj-$(CONFIG_DM9000) += davicom/
+obj-$(CONFIG_NET_VENDOR_DAVICOM) += davicom/
obj-$(CONFIG_DNET) += dnet.o
obj-$(CONFIG_NET_VENDOR_DEC) += dec/
obj-$(CONFIG_NET_VENDOR_DLINK) += dlink/
diff --git a/drivers/net/ethernet/davicom/Kconfig
b/drivers/net/ethernet/davicom/Kconfig
index 9745fe5..0185e62 100644
--- a/drivers/net/ethernet/davicom/Kconfig
+++ b/drivers/net/ethernet/davicom/Kconfig
@@ -2,6 +2,23 @@
# Davicom device configuration
#
+config NET_VENDOR_DAVICOM
+ bool "Davicom devices"
+ default y
+ depends on ARM || BLACKFIN || MIPS || COLDFIRE
+ ---help---
+ If you have a network (Ethernet) card belonging to this
+ class, say Y and read the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>.
+
+ Note that the answer to this question doesn't directly
+ affect the kernel: saying N will just cause the configurator
+ to skip all the questions about Davicom cards. If you say Y,
+ you will be asked for your specific card in the following
+ questions.
+
+if NET_VENDOR_DAVICOM
+
config DM9000
tristate "DM9000 support"
depends on ARM || BLACKFIN || MIPS || COLDFIRE
@@ -22,3 +39,17 @@ config DM9000_FORCE_SIMPLE_PHY_POLL
bit to determine if the link is up or down instead of the more
costly MII PHY reads. Note, this will not work if the chip is
operating with an external PHY.
+
+config WEMAC
+tristate "WEMAC support"
+ depends on OF
+ select CRC32
+ select NET_CORE
+ select MII
+---help---
+ Support for Davicom WEMAC ethernet driver.
+
+ To compile this driver as a module, choose M here. The module
+ will be called wemac.
+
+endif # NET_VENDOR_DAVICOM
diff --git a/drivers/net/ethernet/davicom/Makefile
b/drivers/net/ethernet/davicom/Makefile
index 74b31f0..803297e 100644
--- a/drivers/net/ethernet/davicom/Makefile
+++ b/drivers/net/ethernet/davicom/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_DM9000) += dm9000.o
+obj-$(CONFIG_WEMAC) += wemac.o
diff --git a/drivers/net/ethernet/davicom/wemac.c
b/drivers/net/ethernet/davicom/wemac.c
new file mode 100644
index 000..8468baf
--- /dev/null
+++ b/drivers/net/ethernet/davicom/wemac.c
@@ -0,0 +1,1033 @@
+/*
+ * Allwinner WEMAC Fast Ethernet driver for Linux.
+ *
+ * Copyright 2012 Stefan Roese
+ * Copyright 2013 Maxime Ripard
+ *
+ * Based on the Linux driver provided by Allwinner:
+ * Copyright (C) 1997 Sten Wang
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is"
Re: [PATCH 1/5] net: Add davicom wemac ethernet driver found on Allwinner A10 SoC's
Le 15/03/2013 21:50, Maxime Ripard a écrit : > From: Stefan Roese > > The Allwinner A10 has an ethernet controller that is advertised as > coming from Davicom. > > The exact feature set of this controller is unknown, since there is no > public documentation for this IP, and this driver is mostly the one > published by Allwinner that has been heavily cleaned up. > > Signed-off-by: Stefan Roese > Signed-off-by: Maxime Ripard > --- > .../devicetree/bindings/net/davicom-wemac.txt | 20 + > drivers/net/ethernet/Makefile |2 +- > drivers/net/ethernet/davicom/Kconfig | 31 + > drivers/net/ethernet/davicom/Makefile |1 + > drivers/net/ethernet/davicom/wemac.c | 1033 > > drivers/net/ethernet/davicom/wemac.h | 130 +++ > 6 files changed, 1216 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/net/davicom-wemac.txt > create mode 100644 drivers/net/ethernet/davicom/wemac.c > create mode 100644 drivers/net/ethernet/davicom/wemac.h > > diff --git a/Documentation/devicetree/bindings/net/davicom-wemac.txt > b/Documentation/devicetree/bindings/net/davicom-wemac.txt > new file mode 100644 > index 000..516cf31 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/davicom-wemac.txt > @@ -0,0 +1,20 @@ > +* Marvell Armada 370 / Armada XP Ethernet Controller (NETA) > + > +Required properties: > +- compatible: should be "marvell,armada-370-neta". It looks like I've been a bit too quick to send this one... I'll change in v2, obviously. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] net: Add davicom wemac ethernet driver found on Allwinner A10 SoC's
msg_tx_done(db))
>> +dev_dbg(db->dev, "tx done, NSR %02x\n", tx_status);
>> +
>> +netif_wake_queue(dev);
>
> Why is that also required? According to your start_xmit function you should
> do
> this only when you have transmitted 2 packets no?
I don't know, maybe the code here is more about always having a buffer
of one packet at any point in time. With the current code, when you have
to send packets, it will:
- send the packet 1
- stop the queue
- wait for the packet 1 to be sent
- once packet 1 is sent, restart the queue, so that it can load a
packet 3
- start transmitting packet 2 if there's one, and loop, or just wait
for it
Which would make sense, and for this, it looks to me that you should
always restart the queue, no matter what the number of packets to send was.
>> +
>> +reg_val = readl(db->membase + EMAC_RX_IO_DATA_REG);
>> +if (netif_msg_rx_status(db))
>> +dev_dbg(db->dev, "receive header: %x\n", reg_val);
>> +if (reg_val != 0x0143414d) {
>
> Where is that magic value coming from?
The original code.
Maybe I should define it to something like "UNDOCUMENTED_VOODOO_MAGIC1",
or something like that, but I have no idea what it relates to in the
hardware :S
Thanks for your review,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: doubt about where to put pin-mux in MX28 based platform DT
Hi Hector,
Le 21/03/2013 17:57, Hector Palacios a écrit :
> On 03/07/2013 02:06 PM, Maxime Ripard wrote:
>> Hi Hector,
>>
>> Le 06/03/2013 18:02, Hector Palacios a écrit :
>>> I'm creating the DT for a custom platform based on Freescale MX28 CPU
>>> and I have some doubts about where to add some pin mux configurations:
>>> whether in imx28.dtsi or in my platform dts.
>>>
>>> A pair of examples folow:
>>>
>>> Example #1. My platform is using a valid IOMUX for DUART TX/RX lines
>>> which is not covered in imx28.dtsi, namely the I2C0 pins. Since this is
>>> a valid IOMUX that can be used by other platforms, I'd say I should
>>> included it in imx28.dtsi:
>>>
>>> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
>>> index 3fa6d19..8928b7b 100644
>>> --- a/arch/arm/boot/dts/imx28.dtsi
>>> +++ b/arch/arm/boot/dts/imx28.dtsi
>>> @@ -186,6 +186,17 @@
>>> fsl,pull-up = <0>;
>>> };
>>>
>>> + duart_pins_c: duart@2 {
>>> + reg = <2>;
>>> + fsl,pinmux-ids = <
>>> + 0x3182 /*
>>> MX28_PAD_I2C0_SCL__DUART_RX */
>>> + 0x3192 /*
>>> MX28_PAD_I2C0_SDA__DUART_TX */
>>> + >;
>>> + fsl,drive-strength = <0>;
>>> + fsl,voltage = <1>;
>>> + fsl,pull-up = <0>;
>>> + };
>>> +
>>> duart_4pins_a: duart-4pins@0 {
>>> reg = <0>;
>>> fsl,pinmux-ids = <
>>
>> That's right.
>
> I'm getting into more cases like this: valid IOMUX configurations that
> my platform uses but are not included into imx28.dtsi.
> So before adding new entries I was wondering whether it is a good idea
> to have IOMUX configurations in this include file at all. There are
> multiple valid combinations so why not adding these to the specific
> platform DTS files instead?
>
> Existing IOMUX configurations in imx28.dtsi that later are not used by
> platform *.dts files are 'polluting' the final DTB with unused nodes.
> Do other architectures follow the same approach?
> Maybe there is a good reason that I simply don't see.
My view on this is: as long as a pinmux combination is defined in the
datasheet, we should add it to the DTSI to avoid duplication and errors
in boards DTS. And all the muxing that is board specific (like which pin
should I mux to the GPIO function to use the LED on my board) should be
in the board DTS.
You have a point about the final DTB size, but I don't think we care
that much...
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/5] net: Add EMAC ethernet driver found on Allwinner A10 SoC's
From: Stefan Roese
The Allwinner A10 has an ethernet controller that seem to be developped
internally by them.
The exact feature set of this controller is unknown, since there is no
public documentation for this IP, and this driver is mostly the one
published by Allwinner that has been heavily cleaned up.
Signed-off-by: Stefan Roese
Signed-off-by: Maxime Ripard
---
.../bindings/net/allwinner,sun4i-emac.txt | 19 +
drivers/net/ethernet/Kconfig |1 +
drivers/net/ethernet/Makefile |1 +
drivers/net/ethernet/allwinner/Kconfig | 36 +
drivers/net/ethernet/allwinner/Makefile|5 +
drivers/net/ethernet/allwinner/sun4i-emac.c| 1033
drivers/net/ethernet/allwinner/sun4i-emac.h| 114 +++
7 files changed, 1209 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
create mode 100644 drivers/net/ethernet/allwinner/Kconfig
create mode 100644 drivers/net/ethernet/allwinner/Makefile
create mode 100644 drivers/net/ethernet/allwinner/sun4i-emac.c
create mode 100644 drivers/net/ethernet/allwinner/sun4i-emac.h
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
new file mode 100644
index 000..aaf5013
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
@@ -0,0 +1,19 @@
+* Allwinner EMAC ethernet controller
+
+Required properties:
+- compatible: should be "allwinner,sun4i-emac".
+- reg: address and length of the register set for the device.
+- interrupts: interrupt for the device
+
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+- (local-)mac-address: mac address to be used by this driver
+
+Example:
+
+emac: ethernet@01c0b000 {
+ compatible = "allwinner,sun4i-emac";
+ reg = <0x01c0b000 0x1000>;
+ phy-supply = <®_emac_3v3>;
+ interrupts = <55>;
+};
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index ed956e0..18fd6fb 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -20,6 +20,7 @@ config SUNGEM_PHY
source "drivers/net/ethernet/3com/Kconfig"
source "drivers/net/ethernet/adaptec/Kconfig"
source "drivers/net/ethernet/aeroflex/Kconfig"
+source "drivers/net/ethernet/allwinner/Kconfig"
source "drivers/net/ethernet/alteon/Kconfig"
source "drivers/net/ethernet/amd/Kconfig"
source "drivers/net/ethernet/apple/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 8268d85..009da27 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_NET_VENDOR_3COM) += 3com/
obj-$(CONFIG_NET_VENDOR_8390) += 8390/
obj-$(CONFIG_NET_VENDOR_ADAPTEC) += adaptec/
obj-$(CONFIG_GRETH) += aeroflex/
+obj-$(CONFIG_NET_VENDOR_ALLWINNER) += allwinner/
obj-$(CONFIG_NET_VENDOR_ALTEON) += alteon/
obj-$(CONFIG_NET_VENDOR_AMD) += amd/
obj-$(CONFIG_NET_VENDOR_APPLE) += apple/
diff --git a/drivers/net/ethernet/allwinner/Kconfig
b/drivers/net/ethernet/allwinner/Kconfig
new file mode 100644
index 000..5d20fb0
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/Kconfig
@@ -0,0 +1,36 @@
+#
+# Allwinner device configuration
+#
+
+config NET_VENDOR_ALLWINNER
+ bool "Allwinner devices"
+ default y
+ depends on ARCH_SUNXI
+ ---help---
+ If you have a network (Ethernet) card belonging to this
+class, say Y and read the Ethernet-HOWTO, available from
+<http://www.tldp.org/docs.html#howto>.
+
+Note that the answer to this question doesn't directly
+affect the kernel: saying N will just cause the configurator
+to skip all the questions about Davicom cards. If you say Y,
+you will be asked for your specific card in the following
+questions.
+
+if NET_VENDOR_ALLWINNER
+
+config SUN4I_EMAC
+tristate "Allwinner A10 EMAC support"
+ depends on ARCH_SUNXI
+ depends on OF
+ select CRC32
+ select NET_CORE
+ select MII
+ select REGULATOR_FIXED_VOLTAGE
+---help---
+ Support for Allwinner A10 EMAC ethernet driver.
+
+ To compile this driver as a module, choose M here. The module
+ will be called sun4i-emac.
+
+endif # NET_VENDOR_ALLWINNER
diff --git a/drivers/net/ethernet/allwinner/Makefile
b/drivers/net/ethernet/allwinner/Makefile
new file mode 100644
index 000..03129f7
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the Allwinner device drivers.
+#
+
+obj-$(CONFIG_SUN4I_EMAC) += sun4i-emac.o
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c
b/drivers/net/ethernet/allwinner/sun4i-emac.c
new file mode 100644
ind
[PATCH 04/10] clocksource: sunxi: Rename sunxi to sun4i
During the introduction of the Allwinner SoC platforms, sunxi was
initially meant as a generic name for all the variants of the Allwinner
SoC.
It was ok at the time of the support of only the A10 and A13 that
looks pretty much the same, but it's beginning to be troublesome with
the future addition of the Allwinner A31 (sun6i) that is quite
different, and would introduce some weird logic, where sunxi would
actually mean in some case sun4i and sun5i but without sun6i...
Moreover, it makes the compatible strings naming scheme not consistent
with other architectures, where usually for this kind of compability, we
just use the oldest SoC name that has this IP, so let's do just this.
Signed-off-by: Maxime Ripard
---
...r,sunxi-timer.txt => allwinner,sun4i-timer.txt} |4 +--
arch/arm/mach-sunxi/Kconfig|4 +--
drivers/clocksource/Kconfig|2 +-
drivers/clocksource/Makefile |2 +-
.../clocksource/{sunxi_timer.c => sun4i_timer.c} | 34 ++--
5 files changed, 23 insertions(+), 23 deletions(-)
rename Documentation/devicetree/bindings/timer/{allwinner,sunxi-timer.txt =>
allwinner,sun4i-timer.txt} (78%)
rename drivers/clocksource/{sunxi_timer.c => sun4i_timer.c} (80%)
diff --git a/Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt
b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
similarity index 78%
rename from Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt
rename to Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
index 0c7b64e..48aeb78 100644
--- a/Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt
+++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
@@ -2,7 +2,7 @@ Allwinner A1X SoCs Timer Controller
Required properties:
-- compatible : should be "allwinner,sunxi-timer"
+- compatible : should be "allwinner,sun4i-timer"
- reg : Specifies base physical address and size of the registers.
- interrupts : The interrupt of the first timer
- clocks: phandle to the source clock (usually a 24 MHz fixed clock)
@@ -10,7 +10,7 @@ Required properties:
Example:
timer {
- compatible = "allwinner,sunxi-timer";
+ compatible = "allwinner,sun4i-timer";
reg = <0x01c20c00 0x400>;
interrupts = <22>;
clocks = <&osc>;
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 06c2894..d259c78 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -7,5 +7,5 @@ config ARCH_SUNXI
select GENERIC_IRQ_CHIP
select PINCTRL
select SPARSE_IRQ
- select SUNXI_TIMER
- select PINCTRL_SUNXI
\ No newline at end of file
+ select SUN4I_TIMER
+ select PINCTRL_SUNXI
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index e507ab7..9002185 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -25,7 +25,7 @@ config DW_APB_TIMER_OF
config ARMADA_370_XP_TIMER
bool
-config SUNXI_TIMER
+config SUN4I_TIMER
bool
config VT8500_TIMER
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 4d8283a..7d5d23a 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -16,7 +16,7 @@ obj-$(CONFIG_CLKSRC_NOMADIK_MTU) += nomadik-mtu.o
obj-$(CONFIG_CLKSRC_DBX500_PRCMU) += clksrc-dbx500-prcmu.o
obj-$(CONFIG_ARMADA_370_XP_TIMER) += time-armada-370-xp.o
obj-$(CONFIG_ARCH_BCM2835) += bcm2835_timer.o
-obj-$(CONFIG_SUNXI_TIMER) += sunxi_timer.o
+obj-$(CONFIG_SUN4I_TIMER) += sun4i_timer.o
obj-$(CONFIG_ARCH_TEGRA) += tegra20_timer.o
obj-$(CONFIG_VT8500_TIMER) += vt8500_timer.o
diff --git a/drivers/clocksource/sunxi_timer.c
b/drivers/clocksource/sun4i_timer.c
similarity index 80%
rename from drivers/clocksource/sunxi_timer.c
rename to drivers/clocksource/sun4i_timer.c
index 308bbe3..d4674e7 100644
--- a/drivers/clocksource/sunxi_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -37,7 +37,7 @@
static void __iomem *timer_base;
-static void sunxi_clkevt_mode(enum clock_event_mode mode,
+static void sun4i_clkevt_mode(enum clock_event_mode mode,
struct clock_event_device *clk)
{
u32 u = readl(timer_base + TIMER_CTL_REG(0));
@@ -59,7 +59,7 @@ static void sunxi_clkevt_mode(enum clock_event_mode mode,
}
}
-static int sunxi_clkevt_next_event(unsigned long evt,
+static int sun4i_clkevt_next_event(unsigned long evt,
struct clock_event_device *unused)
{
u32 u = readl(timer_base + TIMER_CTL_REG(0));
@@ -70,16 +70,16 @@ static int sunxi_clkevt_next_event(unsigned long evt,
return 0;
}
-static struct clock_event_device sunxi_clockevent = {
- .name = "sunxi_tick",
+static stru
[PATCH 07/10] irqchip: sunxi: Rename sunxi to sun4i
During the introduction of the Allwinner SoC platforms, sunxi was
initially meant as a generic name for all the variants of the Allwinner
SoC.
It was ok at the time of the support of only the A10 and A13 that
looks pretty much the same, but it's beginning to be troublesome with
the future addition of the Allwinner A31 (sun6i) that is quite
different, and would introduce some weird logic, where sunxi would
actually mean in some case sun4i and sun5i but without sun6i...
Moreover, it makes the compatible strings naming scheme not consistent
with other architectures, where usually for this kind of compability, we
just use the oldest SoC name that has this IP, so let's do just this.
Signed-off-by: Maxime Ripard
---
...lwinner,sunxi-ic.txt => allwinner,sun4i-ic.txt} |4 +-
drivers/irqchip/Makefile |2 +-
drivers/irqchip/{irq-sunxi.c => irq-sun4i.c} | 102 ++--
3 files changed, 54 insertions(+), 54 deletions(-)
rename
Documentation/devicetree/bindings/interrupt-controller/{allwinner,sunxi-ic.txt
=> allwinner,sun4i-ic.txt} (94%)
rename drivers/irqchip/{irq-sunxi.c => irq-sun4i.c} (41%)
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt
b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
similarity index 94%
rename from
Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt
rename to
Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
index 7f9fb85..e7f4dc1 100644
---
a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt
+++
b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
@@ -2,7 +2,7 @@ Allwinner Sunxi Interrupt Controller
Required properties:
-- compatible : should be "allwinner,sunxi-ic"
+- compatible : should be "allwinner,sun4i-ic"
- reg : Specifies base physical address and size of the registers.
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
@@ -97,7 +97,7 @@ The interrupt sources are as follows:
Example:
intc: interrupt-controller {
- compatible = "allwinner,sunxi-ic";
+ compatible = "allwinner,sun4i-ic";
reg = <0x01c20400 0x400>;
interrupt-controller;
#interrupt-cells = <2>;
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 98e3b87..5416965 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -4,7 +4,7 @@ obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
obj-$(CONFIG_ARCH_EXYNOS) += exynos-combiner.o
obj-$(CONFIG_METAG)+= irq-metag-ext.o
obj-$(CONFIG_METAG_PERFCOUNTER_IRQS) += irq-metag.o
-obj-$(CONFIG_ARCH_SUNXI) += irq-sunxi.o
+obj-$(CONFIG_ARCH_SUNXI) += irq-sun4i.o
obj-$(CONFIG_ARCH_SPEAR3XX)+= spear-shirq.o
obj-$(CONFIG_ARM_GIC) += irq-gic.o
obj-$(CONFIG_ARM_VIC) += irq-vic.o
diff --git a/drivers/irqchip/irq-sunxi.c b/drivers/irqchip/irq-sun4i.c
similarity index 41%
rename from drivers/irqchip/irq-sunxi.c
rename to drivers/irqchip/irq-sun4i.c
index 0fc49c5..b66d4ae 100644
--- a/drivers/irqchip/irq-sunxi.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -25,125 +25,125 @@
#include "irqchip.h"
-#define SUNXI_IRQ_VECTOR_REG 0x00
-#define SUNXI_IRQ_PROTECTION_REG 0x08
-#define SUNXI_IRQ_NMI_CTRL_REG 0x0c
-#define SUNXI_IRQ_PENDING_REG(x) (0x10 + 0x4 * x)
-#define SUNXI_IRQ_FIQ_PENDING_REG(x) (0x20 + 0x4 * x)
-#define SUNXI_IRQ_ENABLE_REG(x)(0x40 + 0x4 * x)
-#define SUNXI_IRQ_MASK_REG(x) (0x50 + 0x4 * x)
+#define SUN4I_IRQ_VECTOR_REG 0x00
+#define SUN4I_IRQ_PROTECTION_REG 0x08
+#define SUN4I_IRQ_NMI_CTRL_REG 0x0c
+#define SUN4I_IRQ_PENDING_REG(x) (0x10 + 0x4 * x)
+#define SUN4I_IRQ_FIQ_PENDING_REG(x) (0x20 + 0x4 * x)
+#define SUN4I_IRQ_ENABLE_REG(x)(0x40 + 0x4 * x)
+#define SUN4I_IRQ_MASK_REG(x) (0x50 + 0x4 * x)
-static void __iomem *sunxi_irq_base;
-static struct irq_domain *sunxi_irq_domain;
+static void __iomem *sun4i_irq_base;
+static struct irq_domain *sun4i_irq_domain;
-static asmlinkage void __exception_irq_entry sunxi_handle_irq(struct pt_regs
*regs);
+static asmlinkage void __exception_irq_entry sun4i_handle_irq(struct pt_regs
*regs);
-void sunxi_irq_ack(struct irq_data *irqd)
+void sun4i_irq_ack(struct irq_data *irqd)
{
unsigned int irq = irqd_to_hwirq(irqd);
unsigned int irq_off = irq % 32;
int reg = irq / 32;
u32 val;
- val = readl(sunxi_irq_base + SUNXI_IRQ_PENDING_REG(reg));
+ val = readl(sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
writel(val | (1 << irq_off),
- sunxi_irq_bas
[PATCH 09/10] ARM: sunxi: Rework the restart code
The Allwinner sun6i (A31) has a slightly different watchdog, that
doesn't allow to use the already existing restart code.
Rework a bit the restart code to allow to plug in more easily different
restart handlers depending on the device tree.
In the past, we were also meaning sunxi as a generic name covering all
Allwinner SoCs. This won't be true anymore with the A31 (sun6i) that
differs pretty much from sun4i and sun5i, and we will end up having
sunxi, for sun4i and sun5i, and sun6i, which is neither consistent nor
convenient. So, while we're at it, also change sunxi to sun4i.
Signed-off-by: Maxime Ripard
---
.../watchdog/{sunxi-wdt.txt => sun4i-wdt.txt} |6 +-
arch/arm/mach-sunxi/sunxi.c| 58
2 files changed, 38 insertions(+), 26 deletions(-)
rename Documentation/devicetree/bindings/watchdog/{sunxi-wdt.txt =>
sun4i-wdt.txt} (57%)
diff --git a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
b/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
similarity index 57%
rename from Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
rename to Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
index 0b27177..ecd650a 100644
--- a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
@@ -1,13 +1,13 @@
-Allwinner sunXi Watchdog timer
+Allwinner sun4i Watchdog timer
Required properties:
-- compatible : should be "allwinner,sunxi-wdt"
+- compatible : should be "allwinner,sun4i-wdt"
- reg : Specifies base physical address and size of the registers.
Example:
wdt: watchdog@01c20c90 {
- compatible = "allwinner,sunxi-wdt";
+ compatible = "allwinner,sun4i-wdt";
reg = <0x01c20c90 0x10>;
};
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index c99ab1b..706ce35 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -24,50 +24,63 @@
#include
#include
+#include
#include "sunxi.h"
-#define WATCHDOG_CTRL_REG 0x00
-#define WATCHDOG_CTRL_RESTART (1 << 0)
-#define WATCHDOG_MODE_REG 0x04
-#define WATCHDOG_MODE_ENABLE (1 << 0)
-#define WATCHDOG_MODE_RESET_ENABLE (1 << 1)
+#define SUN4I_WATCHDOG_CTRL_REG0x00
+#define SUN4I_WATCHDOG_CTRL_RESTART(1 << 0)
+#define SUN4I_WATCHDOG_MODE_REG0x04
+#define SUN4I_WATCHDOG_MODE_ENABLE (1 << 0)
+#define SUN4I_WATCHDOG_MODE_RESET_ENABLE (1 << 1)
static void __iomem *wdt_base;
-static void sunxi_setup_restart(void)
-{
- struct device_node *np = of_find_compatible_node(NULL, NULL,
- "allwinner,sunxi-wdt");
- if (WARN(!np, "unable to setup watchdog restart"))
- return;
-
- wdt_base = of_iomap(np, 0);
- WARN(!wdt_base, "failed to map watchdog base address");
-}
-
-static void sunxi_restart(char mode, const char *cmd)
+static void sun4i_restart(char mode, const char *cmd)
{
if (!wdt_base)
return;
/* Enable timer and set reset bit in the watchdog */
- writel(WATCHDOG_MODE_ENABLE | WATCHDOG_MODE_RESET_ENABLE,
- wdt_base + WATCHDOG_MODE_REG);
+ writel(SUN4I_WATCHDOG_MODE_ENABLE | SUN4I_WATCHDOG_MODE_RESET_ENABLE,
+ wdt_base + SUN4I_WATCHDOG_MODE_REG);
/*
* Restart the watchdog. The default (and lowest) interval
* value for the watchdog is 0.5s.
*/
- writel(WATCHDOG_CTRL_RESTART, wdt_base + WATCHDOG_CTRL_REG);
+ writel(SUN4I_WATCHDOG_CTRL_RESTART, wdt_base + SUN4I_WATCHDOG_CTRL_REG);
while (1) {
mdelay(5);
- writel(WATCHDOG_MODE_ENABLE | WATCHDOG_MODE_RESET_ENABLE,
- wdt_base + WATCHDOG_MODE_REG);
+ writel(SUN4I_WATCHDOG_MODE_ENABLE |
SUN4I_WATCHDOG_MODE_RESET_ENABLE,
+ wdt_base + SUN4I_WATCHDOG_MODE_REG);
}
}
+static struct of_device_id sunxi_restart_ids[] = {
+ { .compatible = "allwinner,sun4i-wdt", .data = sun4i_restart },
+ { /*sentinel*/ }
+};
+
+static void sunxi_setup_restart(void)
+{
+ const struct of_device_id *of_id;
+ struct device_node *np;
+
+ np = of_find_matching_node(NULL, sunxi_restart_ids);
+ if (WARN(!np, "unable to setup watchdog restart"))
+ return;
+
+ wdt_base = of_iomap(np, 0);
+ WARN(!wdt_base, "failed to map watchdog base address");
+
+ of_id = of_match_node(sunxi_restart_ids, np);
+ WARN(!of_id, "restart function not available");
+
+ arm_pm_restart = of_id->data;
+}
+
static struct map_desc sunxi_io_desc[] __initdata = {
{
.vir
Re: [PATCH 1/2] video: ssd1307fb: Add support for SSD1306 OLED controller
Hi Jean Christophe,
Le 29/03/2013 19:38, Jean-Christophe PLAGNIOL-VILLARD a écrit :
> On 17:44 Wed 06 Mar , Maxime Ripard wrote:
[snip]
>> static int ssd1307fb_probe(struct i2c_client *client,
>> const struct i2c_device_id *id)
>> {
>> struct fb_info *info;
>> -u32 vmem_size = SSD1307FB_WIDTH * SSD1307FB_HEIGHT / 8;
>> +struct device_node *node = client->dev.of_node;
>> +u32 vmem_size;
>> struct ssd1307fb_par *par;
>> u8 *vmem;
>> int ret;
>>
>> -if (!client->dev.of_node) {
>> +if (!node) {
> why this will be DT only?
>
> a platform or ARN that does not support DT can not use this driver
>
> this looks not right
Because the platform I was developing that for was DT-only, and I guess
if someone wants to use this driver on a non-DT platform, that
hypothetical someone can always send a patch to enable the "old-style"
probing in this driver.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote: > On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote: > > The low resolution ADC of the mxs is able to read an internal temperature > > sensor, expose that using hwmon. > > > > Signed-off-by: Alexandre Belloni > > --- > > Wouldn't it make more sense to use iio-hwmon and improve it if necessary ? Actually, I wonder if we should not just put the hwmon driver capabilities directly into the mxs-lradc driver, just like it's already been done in this driver for the touchscreen support. The probing of this hwmon driver doesn't really belong to the DT, it's not really realistic to probe it from the machine definition, and it really is the IP that is wired that way. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] ARM: sunxi: Convert DTSI to new CPU bindings
Hi Lorenzo, On Fri, Jul 05, 2013 at 11:19:46AM +0100, Lorenzo Pieralisi wrote: > On Sun, Jun 30, 2013 at 10:48:46AM +0100, Lorenzo Pieralisi wrote: > > On Sat, Jun 29, 2013 at 08:38:19PM +0100, Russell King - ARM Linux wrote: > > > On Fri, Jun 28, 2013 at 01:05:42PM -0700, Olof Johansson wrote: > > > > On Fri, Jun 28, 2013 at 1:03 PM, Maxime Ripard > > > > wrote: > > > > > On Fri, Jun 28, 2013 at 06:15:32PM +0100, Lorenzo Pieralisi wrote: > > > > >> The patch above should already be queued in next/dt right ? > > > > > > > > > > Indeed. > > > > > > > > > > Then why the latest patch of your patchset got in 3.10, while the > > > > > patches actually fixing the DT it would have impacted were delayed to > > > > > 3.11? > > > > > > > > > > (And why was it merged so late in the development cycle?) > > > > > > > > This. So now we have to scramble because some device trees will > > > > produce warnings at boot. > > > > > > > > Russell, the alternative is to revert Lorenzo's patch for 3.10 (and > > > > re-introduce it for 3.11). Do you have a preference? > > > > > > Sorry but I really don't understand what all the fuss in this thread > > > is about. > > > > > > This thread seems to be saying that two development patches were > > > merged, which were 7762/1 and 7763/1, and that 7764/1 is a fix? > > > Are you sure about that, because that's not how they're described, > > > and not how they look either. > > > > As Olof's warning downgrade is being merged (thanks for that and apologies > > for > > failing to explain patches dependencies properly and stable related issues), > > 7764/1 won't apply cleanly anymore. Can you please drop it from the patch > > system, I will update it and test it first thing tomorrow and send a > > final version to the patch system. > > Patch 7779/1, replacing 7764/1 is in the patch system now, and is ready > to get merged. > > Unfortunately cpu/cpus bindings documentation updates, following: > > https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036735.html > https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-May/033779.html > > were not pulled in the kernel. This is an issue since this means that > we still have no reference in the kernel or wherever it has to be, to > the final cpus/cpu bindings for ARM and ARM64 provided in the pull > request link above (that has been reviewed to death and acknowledged). > > It is a significant overhaul of cpu/cpus bindings standard for ARM/ARM64, > covering all CPUs harking back to arm926 and beyond, and should be final. > > dts updates following that standard have already been pulled into 3.11 > through arm-soc. > > IMHO the bindings contained in pull request above must be merged in the > kernel asap, I would like to ask you please what should I do to get them in > please. If we want to move bindings documentation elsewhere let's do it, > as long as there is a published standard I am happy and will stop annoying > you with this stuff. Just to be clear, I had no problems with the patches themselves, but just the way it was merged. That being said, I think every DTS patch you did should be merged by now, only the second patch of this serie for the A10S hasn't. Arnd, Olof, could you just apply the patch 2 for a 3.11-rc*? It's the only rc patch for the sunxi platform for now, so I don't think a pull request would be worth it, but I can send one anyway if you prefer. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] iio: lps331ap: Add support for DT
Hi Jacek, I find myself needing these bindings as well, so I'm definitely interested by your patches. On Tue, Jul 02, 2013 at 02:15:38PM +0200, Lukasz Czerwinski wrote: > From: Jacek Anaszewski > > This patch adds DT support for the lps331ap barometer > sensor. > > Signed-off-by: Jacek Anaszewski > Signed-off-by: Kyungmin Park > --- > .../bindings/iio/pressure/st_pressure.txt | 41 > > drivers/iio/pressure/st_pressure_i2c.c |9 + > drivers/iio/pressure/st_pressure_spi.c |9 + > 3 files changed, 59 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/iio/pressure/st_pressure.txt > > diff --git a/Documentation/devicetree/bindings/iio/pressure/st_pressure.txt > b/Documentation/devicetree/bindings/iio/pressure/st_pressure.txt > new file mode 100644 > index 000..73a4b7d > --- /dev/null > +++ b/Documentation/devicetree/bindings/iio/pressure/st_pressure.txt > @@ -0,0 +1,41 @@ > +* STMicroelectronics LPS331AP barometer sensor > + > +Required properties: > + > + - compatible : should be "lps331ap" > + - reg : the I2C address of the barometer > + > +Optional properties: > + > + - drdy-int-pin : redirect DRDY on pin INT1 (1) or pin INT2 (2) (u8) > + - interrupt-parent : phandle to the interrupt map subnode > + - interrupts : interrupt mapping for LPS331AP interrupt sources: > + 2 sources: 0 - INT1, 1 - INT2 Maybe you could use interrupts-names here, instead of requiring to hardcode the interrupt index. Plus, I guess that it's assuming that you can only use INT2 when you already use INT1? > + - irq-map : irq sub-node defining interrupt map > + (all properties listed below are required): > + - #interrupt-cells : should be 1 > + - #address-cells : should be 0 > + - #size-cells : should be 0 > + - interrupt-map : table of entries consisting of three child elements: > + - unit_interrupt_specifier - 0 : INT1, 1 : INT2 > + - interrupt parent phandle > + - parent unit interrupt specifier consisiting of two elements: > + - index of the interrupt within the controller > + - flags : should be 0 I don't really get why it's needed. Isn't that redundant with the interrupt parent and the interrupt number already defined by interrupt-parent and interrupts in the top node? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] video: ssd1307fb: Add support for SSD1306 OLED controller
The Solomon SSD1306 OLED controller is very similar to the SSD1307,
except for the fact that the power is given through an external PWM for
the 1307, and while the 1306 can generate its own power without any PWM.
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/video/ssd1307fb.txt| 10 +-
drivers/video/ssd1307fb.c | 267 ++--
2 files changed, 203 insertions(+), 74 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt
b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index 3d0060c..7a12542 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -1,13 +1,17 @@
* Solomon SSD1307 Framebuffer Driver
Required properties:
- - compatible: Should be "solomon,ssd1307fb-". The only supported bus for
-now is i2c.
+ - compatible: Should be "solomon,fb-". The only supported bus for
+now is i2c, and the supported chips are ssd1306 and ssd1307.
- reg: Should contain address of the controller on the I2C bus. Most likely
0x3c or 0x3d
- pwm: Should contain the pwm to use according to the OF device tree PWM
- specification [0]
+ specification [0]. Only required for the ssd1307.
- reset-gpios: Should contain the GPIO used to reset the OLED display
+ - solomon,height: Height in pixel of the screen driven by the controller
+ - solomon,width: Width in pixel of the screen driven by the controller
+ - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is
+mapped to.
Optional properties:
- reset-active-low: Is the reset gpio is active on physical low?
diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
index 395cb6a..95f76e2 100644
--- a/drivers/video/ssd1307fb.c
+++ b/drivers/video/ssd1307fb.c
@@ -16,24 +16,39 @@
#include
#include
-#define SSD1307FB_WIDTH96
-#define SSD1307FB_HEIGHT 16
-
#define SSD1307FB_DATA 0x40
#define SSD1307FB_COMMAND 0x80
#define SSD1307FB_CONTRAST 0x81
+#defineSSD1307FB_CHARGE_PUMP 0x8d
#define SSD1307FB_SEG_REMAP_ON 0xa1
#define SSD1307FB_DISPLAY_OFF 0xae
+#define SSD1307FB_SET_MULTIPLEX_RATIO 0xa8
#define SSD1307FB_DISPLAY_ON 0xaf
#define SSD1307FB_START_PAGE_ADDRESS 0xb0
+#define SSD1307FB_SET_DISPLAY_OFFSET 0xd3
+#defineSSD1307FB_SET_CLOCK_FREQ0xd5
+#defineSSD1307FB_SET_PRECHARGE_PERIOD 0xd9
+#defineSSD1307FB_SET_COM_PINS_CONFIG 0xda
+#defineSSD1307FB_SET_VCOMH 0xdb
+
+struct ssd1307fb_par;
+
+struct ssd1307fb_ops {
+ int (*init)(struct ssd1307fb_par *);
+ int (*remove)(struct ssd1307fb_par *);
+};
struct ssd1307fb_par {
struct i2c_client *client;
+ u32 height;
struct fb_info *info;
+ struct ssd1307fb_ops *ops;
+ u32 page_offset;
struct pwm_device *pwm;
u32 pwm_period;
int reset;
+ u32 width;
};
static struct fb_fix_screeninfo ssd1307fb_fix = {
@@ -43,15 +58,10 @@ static struct fb_fix_screeninfo ssd1307fb_fix = {
.xpanstep = 0,
.ypanstep = 0,
.ywrapstep = 0,
- .line_length= SSD1307FB_WIDTH / 8,
.accel = FB_ACCEL_NONE,
};
static struct fb_var_screeninfo ssd1307fb_var = {
- .xres = SSD1307FB_WIDTH,
- .yres = SSD1307FB_HEIGHT,
- .xres_virtual = SSD1307FB_WIDTH,
- .yres_virtual = SSD1307FB_HEIGHT,
.bits_per_pixel = 1,
};
@@ -134,16 +144,16 @@ static void ssd1307fb_update_display(struct ssd1307fb_par
*par)
* (5) A4 B4 C4 D4 E4 F4 G4 H4
*/
- for (i = 0; i < (SSD1307FB_HEIGHT / 8); i++) {
- ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS +
(i + 1));
+ for (i = 0; i < (par->height / 8); i++) {
+ ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS +
i + par->page_offset);
ssd1307fb_write_cmd(par->client, 0x00);
ssd1307fb_write_cmd(par->client, 0x10);
- for (j = 0; j < SSD1307FB_WIDTH; j++) {
+ for (j = 0; j < par->width; j++) {
u8 buf = 0;
for (k = 0; k < 8; k++) {
- u32 page_length = SSD1307FB_WIDTH * i;
- u32 index = page_length + (SSD1307FB_WIDTH * k
+ j) / 8;
+ u32 page_length = par->width * i;
+ u32 index = page_length + (par->width * k + j)
/ 8;
u8 byte = *(vmem + index);
u8 bit = byte & (1 << (j % 8));
bit = bit >> (j % 8);
@@ -227,16 +23
Re: [PATCH 1/3] iio: Add Nuvoton NAU7802 ADC driver
Hi Alexandre, Jonathan, Le 20/04/2013 17:38, Alexandre Belloni a écrit : > On 20/04/2013 11:52, Jonathan Cameron wrote: >>> + &iio_dev_attr_gain.dev_attr.attr, >>> + &iio_const_attr_gain_available.dev_attr.attr, >>> + &iio_dev_attr_min_conversions.dev_attr.attr, >> What governs this? Looks to me more like it should be hidden away >> in the device tree than be here. > > I guess it will depend on what you connect to your adc. Do we want to > fix that in the DT or to be able to change it at runtime ? I don't think so. Unless I misunderstood it, this attribute is the number of conversions that must occur when switching from one channel to another to get a good-enough precision for the ADC, right? So I don't really see 1) why it could be changed by the user through sysfs in the first place 2) this is not hardware configuration at all, more some black magic within the driver, so it shouldn't be at all in the device tree anyway. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] iio: Add Nuvoton NAU7802 ADC driver
Hi Alexandre,
Le 18/04/2013 17:38, Alexandre Belloni a écrit :
> + nau7802_i2c_write(st, NAU7802_REG_PUCTRL, data);
> + nau7802_i2c_write(st, NAU7802_REG_ADC_CTRL, 0x30);
> +
> + if (tmp >= 2400) {
> + data = NAU7802_CTRL1_VLDO((4500 - tmp) / 300);
> + nau7802_i2c_write(st, NAU7802_REG_CTRL1, data);
> + }
You should probably make a macro or inline function (with a comment) out
of that computation explaining why you are doing this.
> +
> + st->min_conversions = 6;
I'd prefer to see this as a define.
> +
> + /*
> + * The ADC fires continuously and we can't do anything about
> + * it. So we need to have the IRQ disabled by default, and we
> + * will enable them back when we will need them..
> + */
> + if (client->irq) {
> + irq_set_status_flags(client->irq, IRQ_NOAUTOEN);
> + ret = request_threaded_irq(client->irq,
> + NULL,
> + nau7802_eoc_trigger,
> + IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> + client->dev.driver->name,
> + idev);
> + if (ret) {
> + /*
> + * What may happen here is that our IRQ controller is
> + * not able to get level interrupt but this is required
> + * by this ADC as when going over 40 sample per second,
> + * the interrupt line may stay high between conversions.
> + * So, we continue no matter what but we switch to
> + * polling mode.
> + */
> + dev_info(&client->dev,
> + "Failed to allocate IRQ, using polling mode\n");
> + client->irq = 0;
> + /*
> + * We are polling, use the fastest sample rate by
> + * default
> + */
> + st->sample_rate = 0x7;
Ditto.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] video: ssd1307fb: Add support for SSD1306 OLED controller
The Solomon SSD1306 OLED controller is very similar to the SSD1307,
except for the fact that the power is given through an external PWM for
the 1307, and while the 1306 can generate its own power without any PWM.
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/video/ssd1307fb.txt| 10 +-
drivers/video/ssd1307fb.c | 273 +++-
2 files changed, 209 insertions(+), 74 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt
b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index 3d0060c..7a12542 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -1,13 +1,17 @@
* Solomon SSD1307 Framebuffer Driver
Required properties:
- - compatible: Should be "solomon,ssd1307fb-". The only supported bus for
-now is i2c.
+ - compatible: Should be "solomon,fb-". The only supported bus for
+now is i2c, and the supported chips are ssd1306 and ssd1307.
- reg: Should contain address of the controller on the I2C bus. Most likely
0x3c or 0x3d
- pwm: Should contain the pwm to use according to the OF device tree PWM
- specification [0]
+ specification [0]. Only required for the ssd1307.
- reset-gpios: Should contain the GPIO used to reset the OLED display
+ - solomon,height: Height in pixel of the screen driven by the controller
+ - solomon,width: Width in pixel of the screen driven by the controller
+ - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is
+mapped to.
Optional properties:
- reset-active-low: Is the reset gpio is active on physical low?
diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
index 395cb6a..5ab5281 100644
--- a/drivers/video/ssd1307fb.c
+++ b/drivers/video/ssd1307fb.c
@@ -16,24 +16,39 @@
#include
#include
-#define SSD1307FB_WIDTH96
-#define SSD1307FB_HEIGHT 16
-
#define SSD1307FB_DATA 0x40
#define SSD1307FB_COMMAND 0x80
#define SSD1307FB_CONTRAST 0x81
+#defineSSD1307FB_CHARGE_PUMP 0x8d
#define SSD1307FB_SEG_REMAP_ON 0xa1
#define SSD1307FB_DISPLAY_OFF 0xae
+#define SSD1307FB_SET_MULTIPLEX_RATIO 0xa8
#define SSD1307FB_DISPLAY_ON 0xaf
#define SSD1307FB_START_PAGE_ADDRESS 0xb0
+#define SSD1307FB_SET_DISPLAY_OFFSET 0xd3
+#defineSSD1307FB_SET_CLOCK_FREQ0xd5
+#defineSSD1307FB_SET_PRECHARGE_PERIOD 0xd9
+#defineSSD1307FB_SET_COM_PINS_CONFIG 0xda
+#defineSSD1307FB_SET_VCOMH 0xdb
+
+struct ssd1307fb_par;
+
+struct ssd1307fb_ops {
+ int (*init)(struct ssd1307fb_par *);
+ int (*remove)(struct ssd1307fb_par *);
+};
struct ssd1307fb_par {
struct i2c_client *client;
+ u32 height;
struct fb_info *info;
+ struct ssd1307fb_ops *ops;
+ u32 page_offset;
struct pwm_device *pwm;
u32 pwm_period;
int reset;
+ u32 width;
};
static struct fb_fix_screeninfo ssd1307fb_fix = {
@@ -43,15 +58,10 @@ static struct fb_fix_screeninfo ssd1307fb_fix = {
.xpanstep = 0,
.ypanstep = 0,
.ywrapstep = 0,
- .line_length= SSD1307FB_WIDTH / 8,
.accel = FB_ACCEL_NONE,
};
static struct fb_var_screeninfo ssd1307fb_var = {
- .xres = SSD1307FB_WIDTH,
- .yres = SSD1307FB_HEIGHT,
- .xres_virtual = SSD1307FB_WIDTH,
- .yres_virtual = SSD1307FB_HEIGHT,
.bits_per_pixel = 1,
};
@@ -134,16 +144,17 @@ static void ssd1307fb_update_display(struct ssd1307fb_par
*par)
* (5) A4 B4 C4 D4 E4 F4 G4 H4
*/
- for (i = 0; i < (SSD1307FB_HEIGHT / 8); i++) {
- ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS +
(i + 1));
+ for (i = 0; i < (par->height / 8); i++) {
+ ssd1307fb_write_cmd(par->client,
+ SSD1307FB_START_PAGE_ADDRESS + i +
par->page_offset);
ssd1307fb_write_cmd(par->client, 0x00);
ssd1307fb_write_cmd(par->client, 0x10);
- for (j = 0; j < SSD1307FB_WIDTH; j++) {
+ for (j = 0; j < par->width; j++) {
u8 buf = 0;
for (k = 0; k < 8; k++) {
- u32 page_length = SSD1307FB_WIDTH * i;
- u32 index = page_length + (SSD1307FB_WIDTH * k
+ j) / 8;
+ u32 page_length = par->width * i;
+ u32 index = page_length + (par->width * k + j)
/ 8;
u8 byte = *(vmem + index);
u8 bit = byte & (1 << (j % 8));
bit = bit >>
Re: [RFC PATCH v2 11/13] ARM: mach-sunxi: cpus/cpu nodes dts updates
Hi Lorenzo, Le 22/04/2013 17:27, Lorenzo Pieralisi a écrit : > This patch updates the in-kernel dts files according to the latest cpus > and cpu bindings updates for ARM. > > Signed-off-by: Lorenzo Pieralisi > --- > arch/arm/boot/dts/sunxi.dtsi | 4 > 1 file changed, 4 insertions(+) Just to let you know, this file won't exist anymore in 3.10, and has been split out in sun4i-a10.dtsi and sun5i-a13.dtsi. You'll obviously need to change both when rebasing. Other than that, Acked-By: Maxime Ripard Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/6] net: Add MDIO bus driver for the Allwinner EMAC
This patch adds a separate driver for the MDIO interface of the
Allwinner ethernet controllers.
Signed-off-by: Maxime Ripard
---
.../bindings/net/allwinner,sun4i-mdio.txt | 26 +++
drivers/net/ethernet/allwinner/Kconfig | 8 +
drivers/net/ethernet/allwinner/Makefile| 1 +
drivers/net/ethernet/allwinner/sun4i-mdio.c| 191 +
4 files changed, 226 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
create mode 100644 drivers/net/ethernet/allwinner/sun4i-mdio.c
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
new file mode 100644
index 000..00b9f9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
@@ -0,0 +1,26 @@
+* Allwinner A10 MDIO Ethernet Controller interface
+
+Required properties:
+- compatible: should be "allwinner,sun4i-mdio".
+- reg: address and length of the register set for the device.
+
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+
+Example at the SoC level:
+mdio@01c0b080 {
+ compatible = "allwinner,sun4i-mdio";
+ reg = <0x01c0b080 0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
+
+And at the board level:
+
+mdio@01c0b080 {
+ phy-supply = <®_emac_3v3>;
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
diff --git a/drivers/net/ethernet/allwinner/Kconfig
b/drivers/net/ethernet/allwinner/Kconfig
index 5d20fb0..7bbd500 100644
--- a/drivers/net/ethernet/allwinner/Kconfig
+++ b/drivers/net/ethernet/allwinner/Kconfig
@@ -27,10 +27,18 @@ config SUN4I_EMAC
select NET_CORE
select MII
select REGULATOR_FIXED_VOLTAGE
+ select PHYLIB
---help---
Support for Allwinner A10 EMAC ethernet driver.
To compile this driver as a module, choose M here. The module
will be called sun4i-emac.
+config SUN4I_MDIO
+ tristate "Allwinner sun4i MDIO interface support"
+ ---help---
+ This driver supports the MDIO interface found in the network
+ interface units of the Allwinner SoC that have an EMAC (A10,
+ A12, A10s, etc.)
+
endif # NET_VENDOR_ALLWINNER
diff --git a/drivers/net/ethernet/allwinner/Makefile
b/drivers/net/ethernet/allwinner/Makefile
index 03129f7..95eaa31 100644
--- a/drivers/net/ethernet/allwinner/Makefile
+++ b/drivers/net/ethernet/allwinner/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_SUN4I_EMAC) += sun4i-emac.o
+obj-$(CONFIG_SUN4I_MDIO) += sun4i-mdio.o
\ No newline at end of file
diff --git a/drivers/net/ethernet/allwinner/sun4i-mdio.c
b/drivers/net/ethernet/allwinner/sun4i-mdio.c
new file mode 100644
index 000..00e432c
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/sun4i-mdio.c
@@ -0,0 +1,191 @@
+/*
+ * Allwinner EMAC MDIO interface driver
+ *
+ * Copyright 2012-2013 Stefan Roese
+ * Copyright 2013 Maxime Ripard
+ *
+ * Based on the Linux driver provided by Allwinner:
+ * Copyright (C) 1997 Sten Wang
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EMAC_MAC_MCMD_REG (0x00)
+#define EMAC_MAC_MADR_REG (0x04)
+#define EMAC_MAC_MWTD_REG (0x08)
+#define EMAC_MAC_MRDD_REG (0x0c)
+#define EMAC_MAC_MIND_REG (0x10)
+#define EMAC_MAC_SSRR_REG (0x14)
+
+#define MDIO_TIMEOUT (msecs_to_jiffies(100))
+
+struct sun4i_mdio_data {
+ void __iomem*membase;
+ struct regulator*regulator;
+};
+
+static int sun4i_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
+{
+ struct sun4i_mdio_data *data = bus->priv;
+ unsigned long start_jiffies;
+ int value;
+
+ /* issue the phy address and reg */
+ writel((mii_id << 8) | regnum, data->membase + EMAC_MAC_MADR_REG);
+ /* pull up the phy io line */
+ writel(0x1, data->membase + EMAC_MAC_MCMD_REG);
+
+ /* Wait read complete */
+ start_jiffies = jiffies;
+ while (readl(data->membase + EMAC_MAC_MIND_REG) & 0x1) {
+ if (time_after(start_jiffies,
+ start_jiffies + MDIO_TIMEOUT))
+ return -ETIMEDOUT;
+ msleep(1);
+ }
+
+ /* push down the phy io line */
+ writel(0x0, data->membase + EMAC_MAC_MCMD_REG);
+ /* and read data */
+ value = readl(data->membase + EMAC_MAC_MRDD_REG);
+
+ return value;
+}
+
+static int sun4i_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
+ u16 value)
+{
+ str
[PATCH 1/6] net: Add EMAC ethernet driver found on Allwinner A10 SoC's
From: Stefan Roese
The Allwinner A10 has an ethernet controller that seem to be developped
internally by them.
The exact feature set of this controller is unknown, since there is no
public documentation for this IP, and this driver is mostly the one
published by Allwinner that has been heavily cleaned up.
Signed-off-by: Stefan Roese
Signed-off-by: Maxime Ripard
---
.../bindings/net/allwinner,sun4i-emac.txt | 22 +
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/ethernet/allwinner/Kconfig | 36 +
drivers/net/ethernet/allwinner/Makefile| 5 +
drivers/net/ethernet/allwinner/sun4i-emac.c| 960 +
drivers/net/ethernet/allwinner/sun4i-emac.h| 108 +++
7 files changed, 1133 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
create mode 100644 drivers/net/ethernet/allwinner/Kconfig
create mode 100644 drivers/net/ethernet/allwinner/Makefile
create mode 100644 drivers/net/ethernet/allwinner/sun4i-emac.c
create mode 100644 drivers/net/ethernet/allwinner/sun4i-emac.h
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
new file mode 100644
index 000..b90bfcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
@@ -0,0 +1,22 @@
+* Allwinner EMAC ethernet controller
+
+Required properties:
+- compatible: should be "allwinner,sun4i-emac".
+- reg: address and length of the register set for the device.
+- interrupts: interrupt for the device
+- phy: A phandle to a phy node defining the PHY address (as the reg
+ property, a single integer).
+- clocks: A phandle to the reference clock for this device
+
+Optional properties:
+- (local-)mac-address: mac address to be used by this driver
+
+Example:
+
+emac: ethernet@01c0b000 {
+ compatible = "allwinner,sun4i-emac";
+ reg = <0x01c0b000 0x1000>;
+ interrupts = <55>;
+ clocks = <&ahb_gates 17>;
+ phy = <&phy0>;
+};
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index ed956e0..18fd6fb 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -20,6 +20,7 @@ config SUNGEM_PHY
source "drivers/net/ethernet/3com/Kconfig"
source "drivers/net/ethernet/adaptec/Kconfig"
source "drivers/net/ethernet/aeroflex/Kconfig"
+source "drivers/net/ethernet/allwinner/Kconfig"
source "drivers/net/ethernet/alteon/Kconfig"
source "drivers/net/ethernet/amd/Kconfig"
source "drivers/net/ethernet/apple/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 8268d85..009da27 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_NET_VENDOR_3COM) += 3com/
obj-$(CONFIG_NET_VENDOR_8390) += 8390/
obj-$(CONFIG_NET_VENDOR_ADAPTEC) += adaptec/
obj-$(CONFIG_GRETH) += aeroflex/
+obj-$(CONFIG_NET_VENDOR_ALLWINNER) += allwinner/
obj-$(CONFIG_NET_VENDOR_ALTEON) += alteon/
obj-$(CONFIG_NET_VENDOR_AMD) += amd/
obj-$(CONFIG_NET_VENDOR_APPLE) += apple/
diff --git a/drivers/net/ethernet/allwinner/Kconfig
b/drivers/net/ethernet/allwinner/Kconfig
new file mode 100644
index 000..5d20fb0
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/Kconfig
@@ -0,0 +1,36 @@
+#
+# Allwinner device configuration
+#
+
+config NET_VENDOR_ALLWINNER
+ bool "Allwinner devices"
+ default y
+ depends on ARCH_SUNXI
+ ---help---
+ If you have a network (Ethernet) card belonging to this
+class, say Y and read the Ethernet-HOWTO, available from
+<http://www.tldp.org/docs.html#howto>.
+
+Note that the answer to this question doesn't directly
+affect the kernel: saying N will just cause the configurator
+to skip all the questions about Davicom cards. If you say Y,
+you will be asked for your specific card in the following
+questions.
+
+if NET_VENDOR_ALLWINNER
+
+config SUN4I_EMAC
+tristate "Allwinner A10 EMAC support"
+ depends on ARCH_SUNXI
+ depends on OF
+ select CRC32
+ select NET_CORE
+ select MII
+ select REGULATOR_FIXED_VOLTAGE
+---help---
+ Support for Allwinner A10 EMAC ethernet driver.
+
+ To compile this driver as a module, choose M here. The module
+ will be called sun4i-emac.
+
+endif # NET_VENDOR_ALLWINNER
diff --git a/drivers/net/ethernet/allwinner/Makefile
b/drivers/net/ethernet/allwinner/Makefile
new file mode 100644
index 000..03129f7
--- /dev/null
+++ b/drivers/net/ethernet/allwinner/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the Allwinner device drivers.
+#
+
+obj-$(CONFIG_SUN4I_EMAC) += sun4i-e
[PATCH 1/2] clk: sun5i: Add compatibles for Allwinner A13
The A13 has a lot less clocks than the one found in the Allwinner A10.
Add these stripped down clocks to the clock driver and in the
documentation.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/clock/sunxi.txt | 117 +++--
.../bindings/clock/sunxi/sun4i-a10-gates.txt | 93
.../bindings/clock/sunxi/sun5i-a13-gates.txt | 58 ++
drivers/clk/sunxi/clk-sunxi.c | 31 --
4 files changed, 187 insertions(+), 112 deletions(-)
create mode 100644
Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
create mode 100644
Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 729f524..d495521 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -12,22 +12,30 @@ Required properties:
"allwinner,sun4i-axi-clk" - for the AXI clock
"allwinner,sun4i-axi-gates-clk" - for the AXI gates
"allwinner,sun4i-ahb-clk" - for the AHB clock
- "allwinner,sun4i-ahb-gates-clk" - for the AHB gates
+ "allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10
+ "allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
"allwinner,sun4i-apb0-clk" - for the APB0 clock
- "allwinner,sun4i-apb0-gates-clk" - for the APB0 gates
+ "allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10
+ "allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
"allwinner,sun4i-apb1-clk" - for the APB1 clock
"allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
- "allwinner,sun4i-apb1-gates-clk" - for the APB1 gates
+ "allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10
+ "allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
Required properties for all clocks:
- reg : shall be the control register address for the clock.
- clocks : shall be the input parent clock(s) phandle for the clock
- #clock-cells : from common clock binding; shall be set to 0 except for
- "allwinner,sun4i-*-gates-clk" where it shall be set to 1
+ "allwinner,*-gates-clk" where it shall be set to 1
-Additionally, "allwinner,sun4i-*-gates-clk" clocks require:
+Additionally, "allwinner,*-gates-clk" clocks require:
- clock-output-names : the corresponding gate names that the clock controls
+Clock consumers should specify the desired clocks they use with a
+"clocks" phandle cell. Consumers that are using a gated clock should
+provide an additional ID in their clock property. The values of this
+ID are documented in sunxi/-gates.txt.
+
For example:
osc24M: osc24M@01c20050 {
@@ -50,102 +58,3 @@ cpu: cpu@01c20054 {
reg = <0x01c20054 0x4>;
clocks = <&osc32k>, <&osc24M>, <&pll1>;
};
-
-
-
-Gate clock outputs
-
-The "allwinner,sun4i-*-gates-clk" clocks provide several gatable outputs;
-their corresponding offsets as present on sun4i are listed below. Note that
-some of these gates are not present on sun5i.
-
- * AXI gates ("allwinner,sun4i-axi-gates-clk")
-
-DRAM0
-
- * AHB gates ("allwinner,sun4i-ahb-gates-clk")
-
-USB00
-EHCI0 1
-OHCI0 2*
-EHCI1 3
-OHCI1 4*
-SS 5
-DMA 6
-BIST7
-MMC08
-MMC19
-MMC210
-MMC311
-MS 12**
-NAND13
-SDRAM 14
-
-ACE 16
-EMAC17
-TS
[PATCH 1/5] i2c: sunxi: Add Allwinner A1X i2c driver
This patch implements a basic driver for the I2C host driver found on
the Allwinner A10, A13 and A31 SoCs.
Notable missing feature is 10-bit addressing.
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/i2c/i2c-sunxi.txt | 19 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-sunxi.c | 441 +
4 files changed, 471 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sunxi.txt
create mode 100644 drivers/i2c/busses/i2c-sunxi.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-sunxi.txt
b/Documentation/devicetree/bindings/i2c/i2c-sunxi.txt
new file mode 100644
index 000..40c16d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-sunxi.txt
@@ -0,0 +1,19 @@
+Allwinner SoC I2C controller
+
+Required properties:
+- compatible : Should be "allwinner,sun4i-i2c".
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks : The parent clock feeding the I2C controller.
+
+Recommended properties:
+- clock-frequency : desired I2C bus clock frequency in Hz.
+
+Example:
+i2c0: i2c@01c2ac00 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = <7>;
+ clocks = <&apb1_gates 0>;
+ clock-frequency = <10>;
+};
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index adfee98..327a49b 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -706,6 +706,16 @@ config I2C_STU300
This driver can also be built as a module. If so, the module
will be called i2c-stu300.
+config I2C_SUNXI
+ tristate "Allwinner A1X I2C controller"
+ depends on ARCH_SUNXI
+ help
+ If you say yes to this option, support will be included for the
+ I2C controller embedded in Allwinner A1X SoCs.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-sunxi.
+
config I2C_TEGRA
tristate "NVIDIA Tegra internal I2C controller"
depends on ARCH_TEGRA
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 8f4fc23..7225818 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_I2C_SH_MOBILE) += i2c-sh_mobile.o
obj-$(CONFIG_I2C_SIMTEC) += i2c-simtec.o
obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o
obj-$(CONFIG_I2C_STU300) += i2c-stu300.o
+obj-$(CONFIG_I2C_SUNXI)+= i2c-sunxi.o
obj-$(CONFIG_I2C_TEGRA)+= i2c-tegra.o
obj-$(CONFIG_I2C_VERSATILE)+= i2c-versatile.o
obj-$(CONFIG_I2C_OCTEON) += i2c-octeon.o
diff --git a/drivers/i2c/busses/i2c-sunxi.c b/drivers/i2c/busses/i2c-sunxi.c
new file mode 100644
index 000..f9f8bd4
--- /dev/null
+++ b/drivers/i2c/busses/i2c-sunxi.c
@@ -0,0 +1,441 @@
+/*
+ * Allwinner A1X SoCs i2c controller driver.
+ *
+ * Copyright (C) 2013 Maxime Ripard
+ *
+ * Maxime Ripard
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SUNXI_I2C_ADDR_REG (0x00)
+#define SUNXI_I2C_ADDR_ADDR(v) ((v & 0x7f) << 1)
+#define SUNXI_I2C_XADDR_REG(0x04)
+#define SUNXI_I2C_DATA_REG (0x08)
+#define SUNXI_I2C_CNTR_REG (0x0c)
+#define SUNXI_I2C_CNTR_ASSERT_ACK BIT(2)
+#define SUNXI_I2C_CNTR_INT_FLAGBIT(3)
+#define SUNXI_I2C_CNTR_MASTER_STOP BIT(4)
+#define SUNXI_I2C_CNTR_MASTER_STARTBIT(5)
+#define SUNXI_I2C_CNTR_BUS_ENABLE BIT(6)
+#define SUNXI_I2C_CNTR_INT_ENABLE BIT(7)
+#define SUNXI_I2C_STA_REG (0x10)
+#define SUNXI_I2C_STA_BUS_ERROR(0x00)
+#define SUNXI_I2C_STA_START(0x08)
+#define SUNXI_I2C_STA_START_REPEAT (0x10)
+#define SUNXI_I2C_STA_MASTER_WADDR_ACK (0x18)
+#define SUNXI_I2C_STA_MASTER_WADDR_NAK (0x20)
+#define SUNXI_I2C_STA_MASTER_DATA_SENT_ACK (0x28)
+#define SUNXI_I2C_STA_MASTER_DATA_SENT_NAK (0x30)
+#define SUNXI_I2C_STA_MASTER_RADDR_ACK (0x40)
+#define SUNXI_I2C_STA_MASTER_RADDR_NAK (0x48)
+#define SUNXI_I2C_STA_MASTER_DATA_RECV_ACK (0x50)
+#define SUNXI_I2C_STA_MASTER_DATA_RECV_NAK (0x58)
+#define SUNXI_I2C_CCR_REG (0x14)
+#define SUNXI_I2C_CCR_DIV_N(val) (val & 0x3)
+#define SUNXI_I2C_CCR_DIV_M(val) ((val & 0xf) << 3)
+#define SUNXI_I2C_SRST_REG (0x18)
+#define SUNXI_I2C_SRST_RE
[PATCH 1/5] i2c: sunxi: Add Allwinner A1X i2c driver
This patch implements a basic driver for the I2C host driver found on
the Allwinner A10, A13 and A31 SoCs.
Notable missing feature is 10-bit addressing.
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/i2c/i2c-sunxi.txt | 19 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-sunxi.c | 441 +
4 files changed, 471 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sunxi.txt
create mode 100644 drivers/i2c/busses/i2c-sunxi.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-sunxi.txt
b/Documentation/devicetree/bindings/i2c/i2c-sunxi.txt
new file mode 100644
index 000..40c16d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-sunxi.txt
@@ -0,0 +1,19 @@
+Allwinner SoC I2C controller
+
+Required properties:
+- compatible : Should be "allwinner,sun4i-i2c".
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks : The parent clock feeding the I2C controller.
+
+Recommended properties:
+- clock-frequency : desired I2C bus clock frequency in Hz.
+
+Example:
+i2c0: i2c@01c2ac00 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = <7>;
+ clocks = <&apb1_gates 0>;
+ clock-frequency = <10>;
+};
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index adfee98..327a49b 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -706,6 +706,16 @@ config I2C_STU300
This driver can also be built as a module. If so, the module
will be called i2c-stu300.
+config I2C_SUNXI
+ tristate "Allwinner A1X I2C controller"
+ depends on ARCH_SUNXI
+ help
+ If you say yes to this option, support will be included for the
+ I2C controller embedded in Allwinner A1X SoCs.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-sunxi.
+
config I2C_TEGRA
tristate "NVIDIA Tegra internal I2C controller"
depends on ARCH_TEGRA
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 8f4fc23..7225818 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_I2C_SH_MOBILE) += i2c-sh_mobile.o
obj-$(CONFIG_I2C_SIMTEC) += i2c-simtec.o
obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o
obj-$(CONFIG_I2C_STU300) += i2c-stu300.o
+obj-$(CONFIG_I2C_SUNXI)+= i2c-sunxi.o
obj-$(CONFIG_I2C_TEGRA)+= i2c-tegra.o
obj-$(CONFIG_I2C_VERSATILE)+= i2c-versatile.o
obj-$(CONFIG_I2C_OCTEON) += i2c-octeon.o
diff --git a/drivers/i2c/busses/i2c-sunxi.c b/drivers/i2c/busses/i2c-sunxi.c
new file mode 100644
index 000..f9f8bd4
--- /dev/null
+++ b/drivers/i2c/busses/i2c-sunxi.c
@@ -0,0 +1,441 @@
+/*
+ * Allwinner A1X SoCs i2c controller driver.
+ *
+ * Copyright (C) 2013 Maxime Ripard
+ *
+ * Maxime Ripard
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SUNXI_I2C_ADDR_REG (0x00)
+#define SUNXI_I2C_ADDR_ADDR(v) ((v & 0x7f) << 1)
+#define SUNXI_I2C_XADDR_REG(0x04)
+#define SUNXI_I2C_DATA_REG (0x08)
+#define SUNXI_I2C_CNTR_REG (0x0c)
+#define SUNXI_I2C_CNTR_ASSERT_ACK BIT(2)
+#define SUNXI_I2C_CNTR_INT_FLAGBIT(3)
+#define SUNXI_I2C_CNTR_MASTER_STOP BIT(4)
+#define SUNXI_I2C_CNTR_MASTER_STARTBIT(5)
+#define SUNXI_I2C_CNTR_BUS_ENABLE BIT(6)
+#define SUNXI_I2C_CNTR_INT_ENABLE BIT(7)
+#define SUNXI_I2C_STA_REG (0x10)
+#define SUNXI_I2C_STA_BUS_ERROR(0x00)
+#define SUNXI_I2C_STA_START(0x08)
+#define SUNXI_I2C_STA_START_REPEAT (0x10)
+#define SUNXI_I2C_STA_MASTER_WADDR_ACK (0x18)
+#define SUNXI_I2C_STA_MASTER_WADDR_NAK (0x20)
+#define SUNXI_I2C_STA_MASTER_DATA_SENT_ACK (0x28)
+#define SUNXI_I2C_STA_MASTER_DATA_SENT_NAK (0x30)
+#define SUNXI_I2C_STA_MASTER_RADDR_ACK (0x40)
+#define SUNXI_I2C_STA_MASTER_RADDR_NAK (0x48)
+#define SUNXI_I2C_STA_MASTER_DATA_RECV_ACK (0x50)
+#define SUNXI_I2C_STA_MASTER_DATA_RECV_NAK (0x58)
+#define SUNXI_I2C_CCR_REG (0x14)
+#define SUNXI_I2C_CCR_DIV_N(val) (val & 0x3)
+#define SUNXI_I2C_CCR_DIV_M(val) ((val & 0xf) << 3)
+#define SUNXI_I2C_SRST_REG (0x18)
+#define SUNXI_I2C_SRST_RE
[PATCH] irq-sun4i: Fix trivial build errors
Signed-off-by: Maxime Ripard Cc: Thomas Gleixner Cc: Russell King - ARM Linux Cc: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: Arnd Bergmann Cc: Jason Cooper Cc: Andrew Lunn Cc: Jason Gunthorpe Cc: Thomas Petazzoni Cc: Gregory Clement Cc: Ezequiel Garcia Cc: Maxime Ripard Cc: Jean-Francois Moine Cc: Gerlando Falauto Cc: Uwe Kleine-Koenig Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org --- drivers/irqchip/irq-sun4i.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c index 0191f2c..cab36b1 100644 --- a/drivers/irqchip/irq-sun4i.c +++ b/drivers/irqchip/irq-sun4i.c @@ -46,7 +46,8 @@ static int __init sun4i_init_domain_chips(void) struct irq_chip_generic *gc; int i, ret, base = 0; - ret = irq_alloc_domain_generic_chips(d, SUN4I_IRQS_PER_CHIP, 1, + ret = irq_alloc_domain_generic_chips(sun4i_irq_domain, +SUN4I_IRQS_PER_CHIP, 1, "sun4i_irq", handle_level_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE); if (ret) @@ -57,9 +58,9 @@ static int __init sun4i_init_domain_chips(void) gc->reg_base = sun4i_irq_base; gc->chip_types[0].regs.mask = SUN4I_IRQ_ENABLE_REG(i); gc->chip_types[0].regs.ack = SUN4I_IRQ_PENDING_REG(i); - gc->chip_types[0].chip.mask = irq_gc_mask_clr_bit; - gc->chip_types[0].chip.ack = irq_gc_ack_set_bit; - gc->chip_types[0].chip.unmask = irq_gc_mask_set_bit; + gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit; + gc->chip_types[0].chip.irq_ack = irq_gc_ack_set_bit; + gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit; /* Disable, mask and clear all pending interrupts */ writel(0, sun4i_irq_base + SUN4I_IRQ_ENABLE_REG(i)); -- 1.8.1.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [patch 8/8] irqchip: sun4i: Convert to generic irq chip
Hi Thomas, Le 06/05/2013 16:30, Thomas Gleixner a écrit : > Proof of concept patch to demonstrate the new irqdomain support for > the generic irq chip. Untested !! > > Signed-off-by: Thomas Gleixner > Cc: Maxime Ripard I just tested it, and with the minor patch I sent, it's working fine. You can add my Acked-by: Maxime Ripard Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [patch 8/8] irqchip: sun4i: Convert to generic irq chip
Le 12/05/2013 16:08, Maxime Ripard a écrit : > Hi Thomas, > > Le 06/05/2013 16:30, Thomas Gleixner a écrit : >> Proof of concept patch to demonstrate the new irqdomain support for >> the generic irq chip. Untested !! >> >> Signed-off-by: Thomas Gleixner >> Cc: Maxime Ripard > > I just tested it, and with the minor patch I sent, it's working fine. > > You can add my > Acked-by: Maxime Ripard After addressing the comments RobH already made that is. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] pinctrl: sunxi: fix error return code in sunxi_pinctrl_probe()
Hi Linus, On Fri, May 24, 2013 at 11:23:04AM +0200, Linus Walleij wrote: > On Thu, May 23, 2013 at 11:32 AM, Wei Yongjun wrote: > > > From: Wei Yongjun > > > > Fix to return a negative error code from the devm_clk_get() error > > handling case instead of 0, as done elsewhere in this function. > > > > Introduced by commit 950707c0eb5c7aeaa2c446a04c824f4be686d2f6 > > (pinctrl: sunxi: add clock support) > > > > Signed-off-by: Wei Yongjun > > Patch applied for fixes, thanks! > > Maxime: OK? Yes, everything's fine for me. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] i2c: sunxi: Add Allwinner A1X i2c driver
Hi Tomasz, On Sat, May 25, 2013 at 02:06:51PM +0200, Tomasz Figa wrote: > Hi Maxime, > > Overall the driver looks good, just some minor nitpicks inline. Thanks for the review! I'll fix the comments you had and send a new version. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] net: sun4i-emac: fix a typo in emac_probe()
Hi,
On Mon, Jun 03, 2013 at 09:36:52PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Just fixed a typo in emac_probe().
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/net/ethernet/allwinner/sun4i-emac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c
> b/drivers/net/ethernet/allwinner/sun4i-emac.c
> index b411344..26083cd 100644
> --- a/drivers/net/ethernet/allwinner/sun4i-emac.c
> +++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
> @@ -821,7 +821,7 @@ static int emac_probe(struct platform_device *pdev)
> db->membase = of_iomap(np, 0);
> if (!db->membase) {
> dev_err(&pdev->dev, "failed to remap registers\n");
> - return -ENOMEM;
> + ret = -ENOMEM;
> goto out;
> }
>
>
Ouch, nice catch.
Thanks!
Acked-by: Maxime Ripard
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 10/10] arm: add basic support for Rockchip RK3066a boards
Hi Thomas, On Wed, Jun 05, 2013 at 09:11:19AM +0200, Thomas Petazzoni wrote: > Dear Heiko Stübner, > > On Mon, 3 Jun 2013 01:02:20 +0200, Heiko Stübner wrote: > > index 000..a2d8c70 > > --- /dev/null > > +++ b/arch/arm/mach-rockchip/Makefile.boot > > @@ -0,0 +1,3 @@ > > +zreladdr-$(CONFIG_ARCH_ROCKCHIP) := 0x60408000 > > +params_phys-$(CONFIG_ARCH_ROCKCHIP):= 0x60088000 > > +initrd_phys-$(CONFIG_ARCH_ROCKCHIP):= 0x6080 > > Thanks to the AUTO_ZRELADDR thing that you're using as part of the > MULTIPLATFORM support, this Makefile.boot file is no longer useful. See > mach-socfpga, mach-mvebu, mach-bcm2835, mach-bcm, mach-highbank, etc. > > Cc'ing Maxime Ripard, since I see that mach-sunxi does have a > Makefile.boot, even though I believe it is not needed. Yes, it is a left-over and should be removed obviously. Thanks for reminding it to me :) Maxime ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Hi everyone, On Thu, Jun 06, 2013 at 09:00:00AM -0700, Olof Johansson wrote: > On Thu, Jun 6, 2013 at 8:13 AM, jonsm...@gmail.com wrote: > > On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton > > wrote: > >> augh. ok. solutions. what are the solutions here? > > > > Luke if you really want to fix this a good solution is to have > > Allwinner join Linaro and provide an engineer to the Linaro effort. > > That engineer will get educated on the right way to do kernel > > development and he can pass that knowledge back to Allwinner each day > > as he learns it. > > There's no need for anybody to join Linaro to contribute upstream. > That's a crazy notion. > > Listen, Allwinner isn't working in a vacuum, believe it or not. I've > talked to them, so has Arnd and other people working on ARM, including > Maxime Ripard, who's been reimplementing upstream support for their > platform. Everybody is interested in the right things happening, it's > just a matter of figuring out how to do it. The right people are > already talking. I should also add that Allwinner not only talked to us already, but also expressed interest in doing actual modern kernel development (like using "recently" introduced kernel frameworks, like the clk framework). I've received patches from them already for private reviews, they began to show up on the kernel mailing lists, they asked to be CCed on the patches I send upstream, they're even the one that reached out to me when the early support for their chips was released. So, like Olof said, they aren't in a vacuum, they are very aware of the mainline kernel and speak a decent english. So yes, Allwinner has an evil vendor tree (c), with a solution similar yet inferior (because not generic enough) to the device tree, but they show interest on going down the mainline road. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 07, 2013 at 07:26:49PM +0100, luke.leighton wrote: > maxime: we need to talk :) > > please tell me in 4 or 5 sentences what you've managed to do so far, > expanding a little on what thomas says below, more specifically what > it achieves and/or allows rather than technically what it does > (suitable for managers and directors in other words), and what plans > you'd like to see happen. You mean something like http://linux-sunxi.org/Linux_mainlining_effort ? You should really do a bit of research before starting a thread like this one. This webpage has been around for like 9 monthes now on the wiki of a community you pretend to represent (even though I fail to get how you can pretend such thing, but that's another topic). > > is the maintainer of the mainline Allwinner sunxi > > effort. It already supports a number of boards, has a pinctrl driver, a > > GPIO driver, serial port is working, network is working, I2C is > > working. > > > > All in mainline, completely Device Tree based. > > great. which version did it first hit, i.e. what will the first > signs of this be when allwinner begin doing "git pulls"? 3.8, as shown in the wiki page > and which boards. bear in mind that one of those "boards" should > really be "the total range of products available across hundreds of > chinese tablet clone manufacturers". > > specific question: is one of the "boards" the one that tom cubie > submitted, which covers virtually every android tablet product > manufactured in the millions by chinese tablet clone manufacturers? Again, wiki. > > So isn't this entire discussion completely moot? > > no because it's totally in isolation from allwinner. i need to give > them a heads-up, and get them involved, giving them specific > incentives [which nobody's yet given!!] for following a particular > path [or paths] yet to be recommended. > > > The mainline support > > for sunxi has already started since 6 months or so, and has been Device > > Tree based from day one. > > to clarify: the *community-driven* mainline support for sunxi. ok - > which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i > (Dual-Core Cortex A7)? which ones are in? A10, A13 for the moment. I just received hardware with A10s, A20 and A31 that I need to work on, but support should come quite soon. I already have some patches pending to be tested on an A31 board, but didn't have as much time as I wanted lately to actually set a proper environment to test them. Maxime ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
