Re: [PATCHv10 2/9] of/pci: Provide support for parsing PCI DT ranges property
On Sun, May 19, 2013 at 10:31 PM, Jason Cooper ja...@lakedaemon.net wrote: patches 2, 3, and 4 applied to mvebu/of_pci to facilitate others (LinusW) basing their work off of it. Thanks, is this going to be pulled into ARM SoC soon-ish? I think Arnd may need this for some PCI work too. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] pinmux: Add TB10x pinmux driver
On Wed, May 15, 2013 at 11:41 AM, Christian Ruppert
christian.rupp...@abilis.com wrote:
On Tue, May 14, 2013 at 02:29:46PM +0200, Linus Walleij wrote:
Look at for example
drivers/pinctrl/pinctrl-abx500.c:
static u8 abx500_get_mode(struct pinctrl_dev *pctldev, struct gpio_chip
*chip,
unsigned gpio)
{
(...)
/* on ABx5xx, there is no GPIO0, so adjust the offset */
unsigned offset = gpio - 1;
As you can see, this driver, which does not use device tree,
is working around the same problem. Here the problem is that
the pins are numbered starting at 1 instead of 0, a very trivial
numberspace shuffleing.
Let me see if I understand this right:
In ABx5xx, the pin numbering is offset by 1 wrt. GPIO numbering?
No, sorry that the code is strange... The variable is named gpio
because that is the numbering used in the data sheet.
Think of gpio as the number in the data sheet.
Then offset is calculated to start from 0.
I'd be open to this approach if you:
- Make it generic for all pinctrl drivers, i.e. add the translation
to the core so it does not just apply to devices using device tree.
Do you mean what would be required here is a generic way to translate
pin numbers to GPIO numbers in the pin controller?
No that is already done by the GPIO ranges.
I thought this discussion was about shuffleing around/translating
the numberings of the pins themselves.
This translation is currently achieved by the gpio_range mechanism.
Yep.
Internals of gpio_range leak into the pinctrl drivers and are bypassed
in many cases. E.g. pinctrl-abx500.c uses an internal reimplementation
of gpio ranges and the offset by one instead of the information in the
pinctrl_gpio_range structure.
It has abx500_pinrange to associate some information with certain
ranges of pins. It has nothing to do with GPIO ranges if you look
closer at it.
The offset by one is achieved not by this range type, but by hard-coding
a subtraction with one at every entry point, as illustrated. This
is orthogonal to all range concepts.
Mapping pin numbers to GPIO numbers in the pin controller would have the
following advantages:
- It makes GPIO numbering well defined which is clearly an advantage
for the /sys/class/gpio interface: GPIO numbering is now controlled
by the pinctrl driver author and no longer needs to be kernel
internal.
- The device tree/acpi issue is solved since a GPIO controller could
now define its range in GPIO number space (which becomes public)
rather than kernel-internal pin number space. At least for our
products, GPIO numbering generally doesn't change between different
variants of the same chip and the /sys/class/gpio customer
documentation would apply to device also.
This is getting very confused so I can't follow it.
For the GPIO and pin control subsystems there exist three things:
- Local offsets on the GPIO controller, such as if there is a
GPIO controller for 32 lines represented by 32 bits, offset
0 .. 31.
- The global GPIO number space, which is a big array with
some roof, where the GPIO numbers are shoehorned in,
trying not to collide.
- Local offsets on the pin controller, which work the same way
as GPIO local offsets.
I think you are talking about something completely different
here, and that might be the numbering scheme used in the
data sheet, or device tree is this correct? Please call that
the data sheet or device tree numbering system in that
case, or it will be very confusing for me. To me all
GPIO numbers are pure kernel concepts.
If you mean that you try to map the global GPIO number space
1:1 on top of what your datasheet has, just *don't do that*.
Because we want to get rid of this global GPIO numberspace.
Alexandre is already working hard on this!
Can you please try to be very specific on what is
going on here?
- The custom logic inside many pinctrl drivers would be confined in one
translation function the driver provides instead of being spread out
all over the driver.
- Sparse GPIO ranges are easy to implement if required by the
platform/driver.
This looks good.
- Augment the pinctrl-abx500.c driver to show how this simplifies
that driver. (Does not need to be perfect, I'll help out finalizing it
for sure.)
The issue is that such a change is quite fundamental, all pinctrl
drivers would have to be upgraded (not just pinctrl-abx500.c) and struct
pinctrl_gpio_range would have to be removed from the gpio_request_enable
callback and friends in favour of some generic translation mechanism.
Doing large refactorings is a normal part of kernel life.
See: Documentation/stable_api_nonsense.txt
I am also afraid that the custom logic in many drivers could only be
rewritten with the help of the respective driver's author.
If you're patching their drivers they are obliged to help out
by reviewing and testing, that is how we work. If they don't
review and test patches
Re: [PATCH 1/2] pinmux: Add TB10x pinmux driver
On Thu, May 16, 2013 at 2:12 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/10/2013 02:25 AM, Christian Ruppert wrote:
(*1) TB100 GPIO ranges are defined as a phandle to the I/O function
which provides all pins of a given GPIO port. This function is not
necessarily requested from pinctrl and GPIO ports may overlap with
other functions. The pin controller knows about this and provides
whatever GPIO pin is available after mapping other requested
functions.
(*2) Here, the entire GPIOB port is explicitly requested by the GPIO
module, i.e. all pins of the port are made available as GPIOs.
So I think all you're looking for is a way in DT to represent GPIO
ranges? I don't think that should be by string name, but rather numbers:
(actually, doesn't pinctrl-simple already have this?)
Now I'm ever more confused ... we already have this :-)
It's not even pinctrl-simple-centric it is completely generic.
The code is in drivers/gpio/gpiolib-of.c.
It was written by Shiraz Hashin and Haojian Zhuang.
At the time I augmented the core code quite a bit to make
a good fit.
This is from:
Documentation/devicetree/bindings/gpio/gpio.txt
2.1) gpio-controller and pinctrl subsystem
--
gpio-controller on a SOC might be tightly coupled with the pinctrl
subsystem, in the sense that the pins can be used by other functions
together with optional gpio feature.
While the pin allocation is totally managed by the pin ctrl subsystem,
gpio (under gpiolib) is still maintained by gpio drivers. It may happen
that different pin ranges in a SoC is managed by different gpio drivers.
This makes it logical to let gpio drivers announce their pin ranges to
the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to
request the corresponding pin before any gpio usage.
For this, the gpio controller can use a pinctrl phandle and pins to
announce the pinrange to the pin ctrl subsystem. For example,
qe_pio_e: gpio-controller@1460 {
#gpio-cells = 2;
compatible = fsl,qe-pario-bank-e, fsl,qe-pario-bank;
reg = 0x1460 0x18;
gpio-controller;
gpio-ranges = pinctrl1 0 20 10, pinctrl2 10 50 20;
}
where,
pinctrl1 and pinctrl2 is the phandle to the pinctrl DT node.
Next values specify the base pin and number of pins for the range
handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
pin 29 under pinctrl1 with gpio offset 0 and pin 50 to pin 69 under
pinctrl2 with gpio offset 10 is handled by this gpio controller.
The pinctrl node must have #gpio-range-cells property to show number of
arguments to pass with phandle from gpio controllers node.
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/6] ARM: imx6q{dl}: add the WEIM driver
This patch set adds a new driver for WEIM in the imx6q{dl}-sabreauto boards.
The WEIM(Wireless External Interface Module) works like a bus.
You can attach many different devices on it, such as NOR, onenand.
In the case of i.MX6q-sabreauto, only the NOR is connected to WEIM.
Huang Shijie (6):
drivers: bus: add a new driver for WEIM
ARM: dts: imx6q{dl}: fix the pin conflict between SPI and WEIM
ARM: dts: imx6qdl: add more information for WEIM
ARM: dts: imx6q: add pinctrl for WEIM NOR
ARM: dts: imx6ql: add a pinctrl for WEIM NOR
ARM: dts: imx6qdl: enable the WEIM NOR
Documentation/devicetree/bindings/bus/imx-weim.txt | 69 +
arch/arm/boot/dts/imx6dl-sabreauto.dts |9 +-
arch/arm/boot/dts/imx6dl.dtsi | 57
arch/arm/boot/dts/imx6q-sabreauto.dts |9 +-
arch/arm/boot/dts/imx6q.dtsi | 58
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 23 +++-
arch/arm/boot/dts/imx6qdl.dtsi |4 +-
drivers/bus/Kconfig|9 ++
drivers/bus/Makefile |1 +
drivers/bus/imx-weim.c | 145
10 files changed, 380 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/imx-weim.txt
create mode 100644 drivers/bus/imx-weim.c
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/6] drivers: bus: add a new driver for WEIM
The WEIM(Wireless External Interface Module) works like a bus.
You can attach many different devices on it, such as NOR, onenand.
In the case of i.MX6q-sabreauto, the NOR is connected to WEIM.
This patch also adds the devicetree binding document.
The driver only works when the devicetree is enabled.
Signed-off-by: Huang Shijie b32...@freescale.com
---
Documentation/devicetree/bindings/bus/imx-weim.txt | 69 +
drivers/bus/Kconfig|9 ++
drivers/bus/Makefile |1 +
drivers/bus/imx-weim.c | 145
4 files changed, 224 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/imx-weim.txt
create mode 100644 drivers/bus/imx-weim.c
diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt
b/Documentation/devicetree/bindings/bus/imx-weim.txt
new file mode 100644
index 000..9913454
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/imx-weim.txt
@@ -0,0 +1,69 @@
+Device tree bindings for i.MX Wireless External Interface Module (WEIM)
+
+The term âwirelessâ does not imply that the WEIM is literally an interface
+without wires. It simply means that this module was originally designed for
+wireless and mobile applications that use low-power technology.
+
+The actual devices are instantiated from the child nodes of a WEIM node.
+But now we only have the NOR device.
+
+NOR flash connected to the WEIM (found on i.MX boards) are represented as
+child nodes with a name of nor.
+
+Required properties:
+
+ - compatible: Should be set to fsl, imx6q-weim
+ - reg:A resource specifier for the register space
+ (see the example below)
+ - interrupts: the interrupt number, see the example below.
+ - clocks: the clock, see the example below.
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells:Must be set to 1 to allow CS address passing
+ - ranges: Must be set up to reflect the memory layout with four
+ integer values for each chip-select line in use:
+
+ cs-number 0 physical address of mapping size
+
+Timing properties for child nodes. All are mandatory, not optional.
+
+ -weim-cs-index: The CS index which the device is attaching on.
+ -weim-cs-timing: The timing array, contains 6 timing values for the
+ weim-cs-index.
+
+Example for an i.MX6q-sabreauto board:
+ weim: weim@021b8000 {
+ compatible = fsl,imx6q-weim;
+ reg = 0x021b8000 0x4000;
+ interrupts = 0 14 0x04;
+ clocks = clks 196;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x0800;
+
+ nor@0,0 {
+ compatible = cfi-flash;
+ reg = 0 0 0x0200;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 2;
+
+ weim-cs-index = 0;
+ weim-cs-timing = 0x00620081 0x0001 0x1C022000
+ 0xC000 0x1404a38e 0x;
+ partition@0 {
+ label = U-Boot;
+ reg = 0x0 0x4;
+ };
+
+ partition@4 {
+ label = U-Boot-ENV;
+ reg = 0x4 0x1;
+ read-only;
+ };
+
+ partition@5 {
+ label = Kernel;
+ reg = 0x5 0x3b;
+ };
+ };
+ };
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index b05ecab..0f997af 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -4,6 +4,15 @@
menu Bus devices
+config IMX_WEIM
+ tristate Freescale EIM DRIVER
+ depends on ARCH_MXC MTD_PHYSMAP_OF
+ help
+ Driver for i.MX6 WEIM controller.
+ The WEIM(Wireless External Interface Module) works like a bus.
+ You can attach many different devices on it, such as NOR, onenand.
+ But now, we only support the Parallel NOR.
+
config MVEBU_MBUS
bool
depends on PLAT_ORION
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 3c7b53c..436bbcc 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -2,6 +2,7 @@
# Makefile for the bus drivers.
#
+obj-$(CONFIG_IMX_WEIM) += imx-weim.o
obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o
obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
new file mode 100644
index 000..8bd9362
--- /dev/null
+++ b/drivers/bus/imx-weim.c
@@
[PATCH 2/6] ARM: dts: imx6q{dl}: fix the pin conflict between SPI and WEIM
In the imx6q-sabreauto and imx6dl-sabreauto boards,
the pin MX6Q{DL}_PAD_EIM_D19 is used as a GPIO for SPI NOR, but
it is used as a data pin for the WEIM NOR.
In order to fix the conflict, this patch removes the pin from the hog,
and adds a new pinctrl item: pinctrl_ecspi1_2.
The SPI NOR selects this pinctrl_ecspi1_2 when it is enabled.
Signed-off-by: Huang Shijie b32...@freescale.com
---
arch/arm/boot/dts/imx6dl-sabreauto.dts |9 -
arch/arm/boot/dts/imx6q-sabreauto.dts|9 -
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi |2 +-
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-sabreauto.dts
b/arch/arm/boot/dts/imx6dl-sabreauto.dts
index 60f3038..7695f70 100644
--- a/arch/arm/boot/dts/imx6dl-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6dl-sabreauto.dts
@@ -25,7 +25,14 @@
fsl,pins =
MX6DL_PAD_NANDF_CS2__GPIO6_IO15 0x8000
MX6DL_PAD_SD2_DAT2__GPIO1_IO13 0x8000
- MX6DL_PAD_EIM_D19__GPIO3_IO19 0x8000
+ ;
+ };
+ };
+
+ ecspi1 {
+ pinctrl_ecspi1_2: ecspi1grp-2 {
+ fsl,pins =
+ MX6DL_PAD_EIM_D19__GPIO3_IO19 0x8000
;
};
};
diff --git a/arch/arm/boot/dts/imx6q-sabreauto.dts
b/arch/arm/boot/dts/imx6q-sabreauto.dts
index 9fb3e99..67a3a6b 100644
--- a/arch/arm/boot/dts/imx6q-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6q-sabreauto.dts
@@ -29,7 +29,14 @@
fsl,pins =
MX6Q_PAD_NANDF_CS2__GPIO6_IO15 0x8000
MX6Q_PAD_SD2_DAT2__GPIO1_IO13 0x8000
- MX6Q_PAD_EIM_D19__GPIO3_IO19 0x8000
+ ;
+ };
+ };
+
+ ecspi1 {
+ pinctrl_ecspi1_2: ecspi1grp-2 {
+ fsl,pins =
+ MX6Q_PAD_EIM_D19__GPIO3_IO19 0x8000
;
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index d6baa51..eb293f5 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -20,7 +20,7 @@
fsl,spi-num-chipselects = 1;
cs-gpios = gpio3 19 0;
pinctrl-names = default;
- pinctrl-0 = pinctrl_ecspi1_1;
+ pinctrl-0 = pinctrl_ecspi1_1 pinctrl_ecspi1_2;
status = disabled; /* pin conflict with WEIM NOR */
flash: m25p80@0 {
--
1.7.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/6] ARM: dts: imx6q: add pinctrl for WEIM NOR
Add a pinctrl for WEIM nor.
Signed-off-by: Huang Shijie b32...@freescale.com
---
arch/arm/boot/dts/imx6q.dtsi | 58 ++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index ed11bcf..e6174c7 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -323,6 +323,64 @@
;
};
};
+
+ weim {
+ pinctrl_weim_nor_1: weim_norgrp-1 {
+ fsl,pins =
+
MX6Q_PAD_EIM_OE__EIM_OE_B 0x10
+ MX6Q_PAD_EIM_RW__EIM_RW
0x10
+
MX6Q_PAD_EIM_CS0__EIM_CS0_B 0x10
+
MX6Q_PAD_EIM_LBA__EIM_LBA_B 0x10
+
MX6Q_PAD_EIM_WAIT__EIM_WAIT_B 0x8000
+
MX6Q_PAD_EIM_BCLK__EIM_BCLK 0x8000
+
+ /* data */
+
MX6Q_PAD_EIM_D16__EIM_DATA16 0x1b0b0
+
MX6Q_PAD_EIM_D17__EIM_DATA17 0x1b0b0
+
MX6Q_PAD_EIM_D18__EIM_DATA18 0x1b0b0
+
MX6Q_PAD_EIM_D19__EIM_DATA19 0x1b0b0
+
MX6Q_PAD_EIM_D20__EIM_DATA20 0x1b0b0
+
MX6Q_PAD_EIM_D21__EIM_DATA21 0x1b0b0
+
MX6Q_PAD_EIM_D22__EIM_DATA22 0x1b0b0
+
MX6Q_PAD_EIM_D23__EIM_DATA23 0x1b0b0
+
MX6Q_PAD_EIM_D24__EIM_DATA24 0x1b0b0
+
MX6Q_PAD_EIM_D25__EIM_DATA25 0x1b0b0
+
MX6Q_PAD_EIM_D26__EIM_DATA26 0x1b0b0
+
MX6Q_PAD_EIM_D27__EIM_DATA27 0x1b0b0
+
MX6Q_PAD_EIM_D28__EIM_DATA28 0x1b0b0
+
MX6Q_PAD_EIM_D29__EIM_DATA29 0x1b0b0
+
MX6Q_PAD_EIM_D30__EIM_DATA30 0x1b0b0
+
MX6Q_PAD_EIM_D31__EIM_DATA31 0x1b0b0
+
+ /* address */
+
MX6Q_PAD_EIM_A23__EIM_ADDR23 0xb0b1
+
MX6Q_PAD_EIM_A22__EIM_ADDR22 0xb0b1
+
MX6Q_PAD_EIM_A21__EIM_ADDR21 0xb0b1
+
MX6Q_PAD_EIM_A20__EIM_ADDR20 0xb0b1
+
MX6Q_PAD_EIM_A19__EIM_ADDR19 0xb0b1
+
MX6Q_PAD_EIM_A18__EIM_ADDR18 0xb0b1
+
MX6Q_PAD_EIM_A17__EIM_ADDR17 0xb0b1
+
MX6Q_PAD_EIM_A16__EIM_ADDR16 0xb0b1
+
MX6Q_PAD_EIM_DA15__EIM_AD15 0xb0b1
+
MX6Q_PAD_EIM_DA14__EIM_AD14 0xb0b1
+
MX6Q_PAD_EIM_DA13__EIM_AD13 0xb0b1
+
MX6Q_PAD_EIM_DA12__EIM_AD12 0xb0b1
+
MX6Q_PAD_EIM_DA11__EIM_AD11 0xb0b1
+
MX6Q_PAD_EIM_DA10__EIM_AD10 0xb0b1
+
MX6Q_PAD_EIM_DA9__EIM_AD09 0xb0b1
+
MX6Q_PAD_EIM_DA8__EIM_AD08 0xb0b1
+
MX6Q_PAD_EIM_DA7__EIM_AD07 0xb0b1
+
MX6Q_PAD_EIM_DA6__EIM_AD06 0xb0b1
+
MX6Q_PAD_EIM_DA5__EIM_AD05 0xb0b1
+
MX6Q_PAD_EIM_DA4__EIM_AD04 0xb0b1
+
MX6Q_PAD_EIM_DA3__EIM_AD03 0xb0b1
+
MX6Q_PAD_EIM_DA2__EIM_AD02 0xb0b1
+
[PATCH 3/6] ARM: dts: imx6qdl: add more information for WEIM
Add the clock and compatible information for the weim.
Also adds the weim label.
Signed-off-by: Huang Shijie b32...@freescale.com
---
arch/arm/boot/dts/imx6qdl.dtsi |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 42e461c..f21d259 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -744,9 +744,11 @@
reg = 0x021b4000 0x4000;
};
- weim@021b8000 {
+ weim: weim@021b8000 {
+ compatible = fsl,imx6q-weim;
reg = 0x021b8000 0x4000;
interrupts = 0 14 0x04;
+ clocks = clks 196;
};
ocotp@021bc000 {
--
1.7.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/6] ARM: dts: imx6ql: add a pinctrl for WEIM NOR
Add a new pinctrl for WEIN NOR.
Signed-off-by: Huang Shijie b32...@freescale.com
---
arch/arm/boot/dts/imx6dl.dtsi | 57 +
1 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 4b13454..e51c5b7 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -183,6 +183,63 @@
};
};
+ weim {
+ pinctrl_weim_nor_1: weim_norgrp-1 {
+ fsl,pins =
+
MX6DL_PAD_EIM_OE__EIM_OE_B 0x10
+
MX6DL_PAD_EIM_RW__EIM_RW 0x10
+
MX6DL_PAD_EIM_CS0__EIM_CS0_B 0x10
+
MX6DL_PAD_EIM_LBA__EIM_LBA_B 0x10
+
MX6DL_PAD_EIM_WAIT__EIM_WAIT_B 0x8000
+
MX6DL_PAD_EIM_BCLK__EIM_BCLK 0x8000
+
+ /* data */
+
MX6DL_PAD_EIM_D16__EIM_DATA16 0x1b0b0
+
MX6DL_PAD_EIM_D17__EIM_DATA17 0x1b0b0
+
MX6DL_PAD_EIM_D18__EIM_DATA18 0x1b0b0
+
MX6DL_PAD_EIM_D19__EIM_DATA19 0x1b0b0
+
MX6DL_PAD_EIM_D20__EIM_DATA20 0x1b0b0
+
MX6DL_PAD_EIM_D21__EIM_DATA21 0x1b0b0
+
MX6DL_PAD_EIM_D22__EIM_DATA22 0x1b0b0
+
MX6DL_PAD_EIM_D23__EIM_DATA23 0x1b0b0
+
MX6DL_PAD_EIM_D24__EIM_DATA24 0x1b0b0
+
MX6DL_PAD_EIM_D25__EIM_DATA25 0x1b0b0
+
MX6DL_PAD_EIM_D26__EIM_DATA26 0x1b0b0
+
MX6DL_PAD_EIM_D27__EIM_DATA27 0x1b0b0
+
MX6DL_PAD_EIM_D28__EIM_DATA28 0x1b0b0
+
MX6DL_PAD_EIM_D29__EIM_DATA29 0x1b0b0
+
MX6DL_PAD_EIM_D30__EIM_DATA30 0x1b0b0
+
MX6DL_PAD_EIM_D31__EIM_DATA31 0x1b0b0
+
+ /* address */
+
MX6DL_PAD_EIM_A23__EIM_ADDR23 0xb0b1
+
MX6DL_PAD_EIM_A22__EIM_ADDR22 0xb0b1
+
MX6DL_PAD_EIM_A21__EIM_ADDR21 0xb0b1
+
MX6DL_PAD_EIM_A20__EIM_ADDR20 0xb0b1
+
MX6DL_PAD_EIM_A19__EIM_ADDR19 0xb0b1
+
MX6DL_PAD_EIM_A18__EIM_ADDR18 0xb0b1
+
MX6DL_PAD_EIM_A17__EIM_ADDR17 0xb0b1
+
MX6DL_PAD_EIM_A16__EIM_ADDR16 0xb0b1
+
MX6DL_PAD_EIM_DA15__EIM_AD15 0xb0b1
+
MX6DL_PAD_EIM_DA14__EIM_AD14 0xb0b1
+
MX6DL_PAD_EIM_DA13__EIM_AD13 0xb0b1
+
MX6DL_PAD_EIM_DA12__EIM_AD12 0xb0b1
+
MX6DL_PAD_EIM_DA11__EIM_AD11 0xb0b1
+
MX6DL_PAD_EIM_DA10__EIM_AD10 0xb0b1
+
MX6DL_PAD_EIM_DA9__EIM_AD09 0xb0b1
+
MX6DL_PAD_EIM_DA8__EIM_AD08 0xb0b1
+
MX6DL_PAD_EIM_DA7__EIM_AD07 0xb0b1
+
MX6DL_PAD_EIM_DA6__EIM_AD06 0xb0b1
+
MX6DL_PAD_EIM_DA5__EIM_AD05 0xb0b1
+
MX6DL_PAD_EIM_DA4__EIM_AD04 0xb0b1
+
MX6DL_PAD_EIM_DA3__EIM_AD03 0xb0b1
+
MX6DL_PAD_EIM_DA2__EIM_AD02 0xb0b1
+
[PATCH 6/6] ARM: dts: imx6qdl: enable the WEIM NOR
Enable the WEIM NOR for imx6q{dl} boards.
For the pin conflict with SPI NOR, its status is set to disabled.
Signed-off-by: Huang Shijie b32...@freescale.com
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index eb293f5..9ce7c1d 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -58,3 +58,24 @@
wp-gpios = gpio1 13 0;
status = okay;
};
+
+weim {
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_weim_nor_1;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x0800;
+ status = disabled; /* pin conflict with SPI NOR */
+
+ nor@0,0 {
+ compatible = cfi-flash;
+ reg = 0 0 0x0200;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 2;
+
+ weim-cs-index = 0;
+ weim-cs-timing = 0x00620081 0x0001 0x1C022000
+ 0xC000 0x1404a38e 0x;
+ };
+};
--
1.7.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] documentation: iommu: add description of ARM System MMU binding
Hi Andreas,
On Fri, May 17, 2013 at 09:16:39PM +0100, Andreas Herrmann wrote:
On Mon, May 13, 2013 at 12:41:47PM +0200, Andreas Herrmann wrote:
On Mon, May 13, 2013 at 05:58:46AM -0400, Will Deacon wrote:
Again, you also need to tie in topology information if you go down this
route.
I still don't like the approach of having two independend lists that
must be in sync to associate a master with its stream-ids.
Why? Say you have 8 masters for an SMMU with 1 or 2 stream-ids each:
smmu {
...
mmu-masters = dma0, dma0, dma1, dma1,
dma2, dma2, dma4, dma4,
dma5, dma6, dma7, dma8;
stream-ids = 0, 1, 2, 3,
4, 5, 6, 7,
8, 9, 0xa, 0xb;
}
Couldn't we use of_phandle_args for this purpose? So your example
+smmu {
...
+mmu-masters = dma0,
+ dma0,
+ dma1;
+stream-ids = 0xd01d,
+ 0xd01e,
+ 0xd11c;
+};
would look like
dma0 {
...
#stream-id-cells = 2
...
}
dma1 {
...
#stream-id-cells = 1
...
}
smmu {
...
mmu-masters = dma0 0xd01d 0xd01e
dma1 0xd11c,
};
and my example would be converted to
smmu {
...
mmu-masters = dma0 0 1 dma1 2 3 dma2 4 5
dma4 6 7 dma5 8 dma6 9
dma7 0xa dma8 0xb
...
}
That also looks fine to me, although I'd like to write the parsing code in
my driver before I commit to anything!
Of course usage of of_phandle_args would restrict the number of
stream-ids per master to 8 (which is currently used as
MAX_PHANDLE_ARGS). But I don't think that this is a restriction in
practice or do you expect to have more than 8 stream-ids per master
(ie. per struct device in Linux)?
Actually, I think that could be a problem. It doesn't sound unlikely that
multi-channel DMA controllers could have:
- Separate instruction fetch streamid per channel
- Separate read/write streamids per channel
so 8 does sound a bit small to me. How difficult would it be to bump that
number in the future if we needed to?
Will
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] usb: add Atmel USBA UDC DT support
-static int __init usba_udc_probe(struct platform_device *pdev)
+#ifdef CONFIG_OF
+static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
+struct usba_udc *udc)
+{
+u32 val;
+const char *name;
+enum of_gpio_flags flags;
+struct device_node *np = pdev-dev.of_node;
+struct device_node *pp;
+int i, ret;
+struct usba_ep *eps, *ep;
+
+udc-num_ep = 0;
+
+udc-vbus_pin = of_get_named_gpio_flags(np, atmel,vbus-gpio, 0,
+flags);
+udc-vbus_pin_inverted = (flags OF_GPIO_ACTIVE_LOW) ? 1 : 0;
+
+pp = NULL;
+while ((pp = of_get_next_child(np, pp)))
+udc-num_ep++;
+
+eps = devm_kzalloc(pdev-dev, sizeof(struct usba_ep) * udc-num_ep,
+ GFP_KERNEL);
Using devm_kzalloc will cause issue when build as modules, and load
and unload this driver, the second time unload, it will come out
following segment fault, log as following. Using kzalloc will fix
it.
no devm_kzalloc is the right one to use
if there is a this not in the drivers and kzalloc is not the solution
we need to find the real reason as devm_xxx are used everywhere by now
Best Regards,
J.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 3/8] mfd:syscon: Introduce claim/read/write/release APIs
Hi Arnd, Thankyou for the comments. On 17/05/13 15:36, Arnd Bergmann wrote: On Thursday 09 May 2013, Srinivas KANDAGATLA wrote: On 08/05/13 20:48, Arnd Bergmann wrote: I agree, my initial approach was having a dedicated driver specific to ST syscon, however syscon seems to do things very much similar to what we want, so I have integrated those 3 functions in syscon. Am happy to go back with my first approach of adding ST specific syscon driver if no one is actually going to benefit with such a change to syscon driver. That would at least be less controversial. yes I agree. Total layout of the sysconf changes per SOC, and the bit arrangements aswell, however the core IP(pinctrl, etherenet ...) and logic to drive those bits remains exactly same. It sounds like you really need a driver with high-level interfaces for the bits that change by each core and are needed by otherwise identical drivers, like the Ethernet driver you mention. I would not go as far as you did describing the individual bits in the device node using these however. That driver can be layered on top of the existing syscon driver, but hardcode the bits for each SoC it knows of. Some of the drivers like Ethernet already provide higher level interfaces via callbacks. We did implement such a callbacks per each SOC in non-DT case, and ended up having code duplicated for each SOC. On the other hand using device trees to describe the HW configuration(sysconfs) made more sense and got rid of SOC specific callbacks. For drivers that are essentially just wrappers around sysconf, I would make them one driver per SoC and use a low-level interface but still hardcode the offsets in the driver instead of using DT to find the registers. The pinctrl and reset drivers are examples of this. In pinctrl bindings case, I think we could do better job by replacing the existing bindings of sysconfs for a group of banks with just two integer offsets. This would mean that, we can still use the a common driver across the SOCs. And w.r.t to reset, we are planning on using sysconf based reset-controller API sitting underneath the reset-controller subsystem. Passing the information from device trees would be much clear and flexible than adding new driver per/SOC. 2 The infrastructure should protect the claimed registers from over-writing by other drivers. We do this by claim-read/write-release style API. I don't understand this part. Is it about atomicity of accesses to 32-bit registers when you only want to change a bit? That is something the regmap interface handles already. I forget to mention a important point here, the protection is at bit level for the sysconfs. Some of sysconfs have bits shared across IPs, so protecting them while the IP is still using it is what we are trying to achieve with sysconf-claim/release apis. While it may be overkill, but In past it has found bugs and been helpful with a meaning full debug output. 3 The driver should be able to set a group of sysconf registers bits to a particular values before initialises the IP. I was thinking of doing this in a same way as pinctrl state. That does not fit well with the model we use for other subsystems. If possible, try to use the existing abstractions for clock, regulator, pinctrl, reset, etc. and call generic interfaces from the driver. When that does not work, create a high-level function call from your sysconf driver to do a particular thing (e.g. stih_sysconf_ethernet_set_phy_mode()) rather than set up random bits from the driver. I agree going for a higher level api in this case makes sense. Thanks, srini Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/6] drivers: bus: add a new driver for WEIM
On Mon, May 20, 2013 at 04:48:57PM +0800, Huang Shijie wrote:
The WEIM(Wireless External Interface Module) works like a bus.
You can attach many different devices on it, such as NOR, onenand.
In the case of i.MX6q-sabreauto, the NOR is connected to WEIM.
This patch also adds the devicetree binding document.
The driver only works when the devicetree is enabled.
Signed-off-by: Huang Shijie b32...@freescale.com
---
Documentation/devicetree/bindings/bus/imx-weim.txt | 69 +
drivers/bus/Kconfig|9 ++
drivers/bus/Makefile |1 +
drivers/bus/imx-weim.c | 145
4 files changed, 224 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/imx-weim.txt
create mode 100644 drivers/bus/imx-weim.c
diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt
b/Documentation/devicetree/bindings/bus/imx-weim.txt
new file mode 100644
index 000..9913454
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/imx-weim.txt
@@ -0,0 +1,69 @@
+Device tree bindings for i.MX Wireless External Interface Module (WEIM)
+
+The term ???wireless??? does not imply that the WEIM is literally an
interface
+without wires. It simply means that this module was originally designed for
+wireless and mobile applications that use low-power technology.
+
+The actual devices are instantiated from the child nodes of a WEIM node.
+But now we only have the NOR device.
+
+NOR flash connected to the WEIM (found on i.MX boards) are represented as
+child nodes with a name of nor.
+
+Required properties:
+
+ - compatible: Should be set to fsl, imx6q-weim
+ - reg: A resource specifier for the register space
+ (see the example below)
+ - interrupts: the interrupt number, see the example below.
+ - clocks: the clock, see the example below.
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells: Must be set to 1 to allow CS address passing
+ - ranges: Must be set up to reflect the memory layout with four
+ integer values for each chip-select line in use:
+
+cs-number 0 physical address of mapping size
+
+Timing properties for child nodes. All are mandatory, not optional.
+
+ -weim-cs-index: The CS index which the device is attaching on.
+ -weim-cs-timing:The timing array, contains 6 timing values for the
+ weim-cs-index.
+
+Example for an i.MX6q-sabreauto board:
+ weim: weim@021b8000 {
+ compatible = fsl,imx6q-weim;
+ reg = 0x021b8000 0x4000;
+ interrupts = 0 14 0x04;
+ clocks = clks 196;
+ #address-cells = 2;
Why is address cells 2 in this example?
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x0800;
+
+ nor@0,0 {
+ compatible = cfi-flash;
+ reg = 0 0 0x0200;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 2;
+
+ weim-cs-index = 0;
+ weim-cs-timing = 0x00620081 0x0001 0x1C022000
+ 0xC000 0x1404a38e 0x;
+ partition@0 {
+ label = U-Boot;
+ reg = 0x0 0x4;
+ };
+
+ partition@4 {
+ label = U-Boot-ENV;
+ reg = 0x4 0x1;
+ read-only;
+ };
+
+ partition@5 {
+ label = Kernel;
+ reg = 0x5 0x3b;
+ };
The partitions are unnecessary to understand the example. Please drop them.
+#define CS_TIMING_LEN 6
+#define CS_REG_RANGE 0x18
+/* Parse and set the timing for this device. */
+static int weim_timing(struct platform_device *pdev, struct device_node *np)
+{
+ struct imx_weim *weim = platform_get_drvdata(pdev);
+ u32 value[CS_TIMING_LEN];
+ u32 cs_idx;
+ int ret;
+ int i;
+
+ ret = of_property_read_u32(np, weim-cs-index, cs_idx);
+ if (ret)
+ goto weim_parse_err;
It would be nice to check for cs_idx being valid.
+
+ ret = of_property_read_u32_array(np, weim-cs-timing,
+ value, CS_TIMING_LEN);
+ if (ret)
+ goto weim_parse_err;
+
+ /* set the timing for WEIM */
+ for (i = 0; i CS_TIMING_LEN; i++)
+ writel(value[i], weim-base + cs_idx * CS_REG_RANGE + i * 4);
+ return 0;
+
+weim_parse_err:
+ return ret;
+}
+
[RFC 0/2] clk: samsung: add composite clocks
This patch adds support for composite clocks for samsung SoCs. Many drivers need access to a common clock which support gating and/or muxing and/or rate control operations. For example hdmi which needs to switch between parents and call enable/disable for sclk_hdmi. This patch set also adds composite clock for exyno5250 hdmi. Based on the review comment, I will extended this to other exynos SoCs clocks files. This patch series is based on for-next branch of tree: git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git Rahul Sharma (2): clk: samsung: add support for composite clocks clk: samsung: add exynos5250 composite clock for hdmi drivers/clk/samsung/clk-exynos5250.c | 20 - drivers/clk/samsung/clk.c| 149 ++ drivers/clk/samsung/clk.h| 49 +++ 3 files changed, 215 insertions(+), 3 deletions(-) -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC 1/2] clk: samsung: add support for composite clocks
Earlier to CCF, many drivers need access to a common clock which
support gating and/or muxing and/or rate control operations. For
example hdmi which needs to switch between parents and call
enable/disable for sclk_hdmi.
This patch add support for composite clocks which address above
driver requirements wrt clocks. By using composite clocks, drivers
also need not be modified for different S0Cs. This will handled
inside CCF.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/clk/samsung/clk.c | 149 +
drivers/clk/samsung/clk.h | 49 +++
2 files changed, 198 insertions(+)
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index cd3c40a..fa6ceb2 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -280,6 +280,155 @@ void __init samsung_clk_register_gate(struct
samsung_gate_clock *list,
}
}
+static void __samsung_clk_register_composite
+ (struct samsung_composite_clock *entry)
+{
+ struct clk *clk = NULL;
+ struct clk_mux *mux = NULL;
+ struct clk_gate *gate = NULL;
+ struct clk_divider *divider = NULL;
+ struct clk_fixed_rate *fixrate = NULL;
+ struct clk_fixed_factor *fixfactor = NULL;
+ struct clk_hw *mux_hw, *gate_hw, *rate_hw;
+ const struct clk_ops *mux_ops, *gate_ops, *rate_ops;
+ unsigned int cf, ret;
+
+ cf = entry-composition_flags;
+ mux_hw = NULL;
+ gate_hw = NULL;
+ rate_hw = NULL;
+ mux_ops = NULL;
+ gate_ops = NULL;
+ rate_ops = NULL;
+
+ /* register a mux clock, if specified */
+ if (cf SAMSUNG_CLK_TYPE_MUX) {
+ mux = kzalloc(sizeof(struct clk_mux), GFP_KERNEL);
+ if (!mux) {
+ pr_err(%s: fail to allocate mux clk %s\n,
+ __func__, entry-name);
+ goto fail_mux;
+ }
+ mux_hw = mux-hw;
+ mux_ops = clk_mux_ops;
+
+ mux-reg = reg_base + entry-mux_clk.offset;
+ mux-shift = entry-mux_clk.shift;
+ mux-mask = entry-mux_clk.width;
+ mux-flags = entry-mux_clk.mux_flags;
+ mux-lock = lock;
+ }
+
+ /* register a gate clock, if specified */
+ if (cf SAMSUNG_CLK_TYPE_GATE) {
+ gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
+ if (!gate) {
+ pr_err(%s: fail to allocate gate clk %s\n,
+ __func__, entry-name);
+ goto fail_gate;
+ }
+ gate_hw = gate-hw;
+ gate_ops = clk_gate_ops;
+
+ gate-reg = reg_base + entry-gate_clk.offset;
+ gate-bit_idx = entry-gate_clk.bit_idx;
+ gate-flags = entry-gate_clk.gate_flags;
+ gate-lock = lock;
+ }
+
+ /* register a rate clock, if specified */
+ if (cf SAMSUNG_CLK_TYPE_DIVIDER) {
+ divider = kzalloc(sizeof(struct clk_divider), GFP_KERNEL);
+ if (!divider) {
+ pr_err(%s: fail to allocate div clk %s\n,
+ __func__, entry-name);
+ goto fail_rate;
+ }
+ rate_hw = divider-hw;
+ rate_ops = clk_divider_ops;
+
+ divider-reg = reg_base + entry-div_clk.offset;
+ divider-shift = entry-div_clk.shift;
+ divider-width = entry-div_clk.width;
+ divider-flags = entry-div_clk.div_flags;
+
+ } else if (cf SAMSUNG_CLK_TYPE_FIXED_FACTOR) {
+ fixfactor = kzalloc(sizeof(struct clk_fixed_factor),
+ GFP_KERNEL);
+ if (!fixfactor) {
+ pr_err(%s: fail to allocate fixfactor clk %s\n,
+ __func__, entry-name);
+ goto fail_rate;
+ }
+ rate_hw = fixfactor-hw;
+ rate_ops = clk_fixed_factor_ops;
+
+ fixfactor-mult = entry-fixed_factor_clk.mult;
+ fixfactor-div = entry-fixed_factor_clk.div;
+
+ } else if (cf SAMSUNG_CLK_TYPE_FIXED_RATE) {
+ fixrate = kzalloc(sizeof(struct clk_fixed_rate),
+ GFP_KERNEL);
+ if (!fixrate) {
+ pr_err(%s: fail to allocate fixrate clk %s\n,
+ __func__, entry-name);
+ goto fail_rate;
+ }
+ rate_hw = fixrate-hw;
+ rate_ops = clk_fixed_rate_ops;
+
+ fixrate-fixed_rate = entry-fixed_rate_clk.fixed_rate;
+ }
+
+ clk = clk_register_composite(NULL, entry-name,
+ entry-parent_names, entry-num_parents,
+ mux_hw, mux_ops,
+ rate_hw,
[RFC 2/2] clk: samsung: add exynos5250 composite clock for hdmi
HDMI driver needs to change the parent of sclk_hdmi clock to
sclk_pixel or to sclk_hdmiphy, depends on the status of hdmiphy.
sclk_hdmi which is gate clock doesn't support the set_parent
operation.
This patch adds sclk_hdmi as a composite clock which is a
combination of mux clock and gate clock. Being a composite
clock, above clock supports both set_parent and enable/disable
functionality. Therefore hdmi driver need not be modified
different S0Cs. This will handled inside CCF.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/clk/samsung/clk-exynos5250.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index 5c97e75..0c9e37a 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -231,7 +231,6 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata =
{
MUX(none, mout_fimd1, mout_group1_p, SRC_DISP1_0, 0, 4),
MUX(none, mout_mipi1, mout_group1_p, SRC_DISP1_0, 12, 4),
MUX(none, mout_dp, mout_group1_p, SRC_DISP1_0, 16, 4),
- MUX(none, mout_hdmi, mout_hdmi_p, SRC_DISP1_0, 20, 1),
MUX(none, mout_audio0, mout_audio0_p, SRC_MAU, 0, 4),
MUX(none, mout_mmc0, mout_group1_p, SRC_FSYS, 0, 4),
MUX(none, mout_mmc1, mout_group1_p, SRC_FSYS, 4, 4),
@@ -416,8 +415,6 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata
= {
SRC_MASK_DISP1_0, 12, CLK_SET_RATE_PARENT, 0),
GATE(sclk_dp, sclk_dp, div_dp,
SRC_MASK_DISP1_0, 16, CLK_SET_RATE_PARENT, 0),
- GATE(sclk_hdmi, sclk_hdmi, mout_hdmi,
- SRC_MASK_DISP1_0, 20, 0, 0),
GATE(sclk_audio0, sclk_audio0, div_audio0,
SRC_MASK_MAU, 0, CLK_SET_RATE_PARENT, 0),
GATE(sclk_mmc0, sclk_mmc0, div_mmc_pre0,
@@ -464,6 +461,21 @@ struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = {
GATE(hdmi, hdmi, aclk200, GATE_IP_DISP1, 6, 0, 0),
};
+struct samsung_composite_clock exynos5250_composite_clks[] __initdata = {
+ {
+ .id = sclk_hdmi,
+ .name = sclk_hdmi,
+ .parent_names = mout_hdmi_p,
+ .num_parents = ARRAY_SIZE(mout_hdmi_p),
+ .mux_clk = MUX(none, NULL, mout_hdmi_p, SRC_DISP1_0, 20,
+ 1),
+ .gate_clk = GATE(none, NULL, NULL, SRC_MASK_DISP1_0, 20,
+ 0, 0),
+ .composition_flags = SAMSUNG_CLK_TYPE_GATE |
+ SAMSUNG_CLK_TYPE_MUX,
+ },
+};
+
static __initdata struct of_device_id ext_clk_match[] = {
{ .compatible = samsung,clock-xxti, .data = (void *)0, },
{ },
@@ -515,6 +527,8 @@ void __init exynos5250_clk_init(struct device_node *np)
ARRAY_SIZE(exynos5250_div_clks));
samsung_clk_register_gate(exynos5250_gate_clks,
ARRAY_SIZE(exynos5250_gate_clks));
+ samsung_clk_register_composite(exynos5250_composite_clks,
+ ARRAY_SIZE(exynos5250_composite_clks));
pr_info(Exynos5250: clock setup completed, armclk=%ld\n,
_get_rate(armclk));
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
help with eth0
Hello, I would like to know how to add eth0 to my DTS file. Data: Processor: ATMEL SAM9N12 Interface: EBI at @0x3000 Ethernet controller: MICREL - KSZ8851 MLL Please help. Thank you. Best regards, Raúl ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 0/2] clk: samsung: add composite clocks
Am Montag, 20. Mai 2013, 16:17:06 schrieb Rahul Sharma: This patch adds support for composite clocks for samsung SoCs. Many drivers need access to a common clock which support gating and/or muxing and/or rate control operations. For example hdmi which needs to switch between parents and call enable/disable for sclk_hdmi. This patch set also adds composite clock for exyno5250 hdmi. Based on the review comment, I will extended this to other exynos SoCs clocks files. I think I remember reading somewhere that the target of the common clock framework was to prevent every SoC from introducing their own special clock types and instead create these structures from separate clocks (mux clk + gate clk) and not to have every SoC create their own custom clock types. The Samsung clock drivers at the moment follow this paradigm of combining the existing simple clocks and only introduce new clock types for the pll clocks, that really need special handling. So it would probably good to keep it this way and define your clocks from their individual components, as all the other Samsung clocks currently do. Heiko ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2] video: implement a simple framebuffer driver
On 05/18/2013 04:29 AM, Alexandre Courbot wrote:
On Thu, Apr 4, 2013 at 11:39 AM, Stephen Warren swar...@wwwdotorg.org wrote:
+struct simplefb_format {
+ const char *name;
+ u32 bits_per_pixel;
+ struct fb_bitfield red;
+ struct fb_bitfield green;
+ struct fb_bitfield blue;
+ struct fb_bitfield transp;
+};
+
+struct simplefb_format simplefb_formats[] = {
+ { r5g6b5, 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
+};
I have been adding a few extra formats to this list, and I wonder if
this could not simply be turned into a function that would directly
convert the name string into the corresponding right format. The
mapping between name and format seems to be a 1:1 and this would
probably avoid errors in the future. I'm especially thinking about
color order here - I started adding a mode that reads
{ r8g8b8a8, 32, {0, 8}, {8, 8}, {16, 8}, {24, 8} },
while it should probably be called a8b8g8r8 as the order of colors
is not the same as your r5g6b5.
I can submit a patch if there is no issue with that idea.
I chose r5g6b5 rather than rgb565 specifically to make that format
trivially name machine-parsable. So, I'm not opposed to converting that
table to code. I'm not 100% sure if it's worth it or necessary by the
time we get to just 2 formats in the array, but I don't see any big
disadvantage, so why not. The DT binding documentation might want
enhancing with a more general description of how formats should be
represented if this is implemented.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] usb: add Atmel USBA UDC DT support
On 12:12 Mon 20 May , Jean-Christophe PLAGNIOL-VILLARD wrote:
-static int __init usba_udc_probe(struct platform_device *pdev)
+#ifdef CONFIG_OF
+static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
+ struct usba_udc *udc)
+{
+ u32 val;
+ const char *name;
+ enum of_gpio_flags flags;
+ struct device_node *np = pdev-dev.of_node;
+ struct device_node *pp;
+ int i, ret;
+ struct usba_ep *eps, *ep;
+
+ udc-num_ep = 0;
+
+ udc-vbus_pin = of_get_named_gpio_flags(np, atmel,vbus-gpio, 0,
+ flags);
+ udc-vbus_pin_inverted = (flags OF_GPIO_ACTIVE_LOW) ? 1 : 0;
+
+ pp = NULL;
+ while ((pp = of_get_next_child(np, pp)))
+ udc-num_ep++;
+
+ eps = devm_kzalloc(pdev-dev, sizeof(struct usba_ep) * udc-num_ep,
+ GFP_KERNEL);
Using devm_kzalloc will cause issue when build as modules, and load
and unload this driver, the second time unload, it will come out
following segment fault, log as following. Using kzalloc will fix
it.
no devm_kzalloc is the right one to use
if there is a this not in the drivers and kzalloc is not the solution
we need to find the real reason as devm_xxx are used everywhere by now
The issue come from that the current driver have some hack that forbiden
multi-instance
I'll drop that
so yes devm_kzalloc is the right alloc to use
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/7 v4] ARM: at91: dt: add USBA support
HI, v4: fix multi instance support v3: rebase againt 3.10-rc1 + dt macro cleanup This patch serie finish to add the usb device support to dt for at91 with the usba support present on the last at91 generation since sam9g45 The following changes since commit b3f442b0eedbc20b5ce3f4a96530588d14901199: ARM: at91: udpate defconfigs (2013-05-17 15:05:08 +0200) are available in the git repository at: git://github.com/at91linux/linux-at91.git j/for-3.11-usba for you to fetch changes up to 910026a08e2c2205953f2507cc11f4822998989b: ARM: at91: sam9m10g45ek add udc DT support (2013-05-20 23:52:17 +0800) Jean-Christophe PLAGNIOL-VILLARD (7): USB: gadget: atmel_usba: move global struct usba_ep usba_ep to struct usba_udc USB: gadget: atmel_usba: allow multi instance USB: gadget: atmel_usba: add DT support ARM: at91: sam9x5 add udc DT support ARM: at91: sam9x5ek add udc DT support ARM: at91: sam9g45 add udc DT support ARM: at91: sam9m10g45ek add udc DT support Documentation/devicetree/bindings/usb/atmel-usb.txt | 82 ++ arch/arm/boot/dts/at91sam9g45.dtsi | 62 +++ arch/arm/boot/dts/at91sam9m10g45ek.dts |5 ++ arch/arm/boot/dts/at91sam9x5.dtsi | 62 +++ arch/arm/boot/dts/at91sam9x5ek.dtsi |5 ++ arch/arm/mach-at91/at91sam9g45.c|2 + arch/arm/mach-at91/at91sam9x5.c |2 + drivers/usb/gadget/Kconfig |2 +- drivers/usb/gadget/atmel_usba_udc.c | 264 ++- drivers/usb/gadget/atmel_usba_udc.h |2 + 10 files changed, 407 insertions(+), 81 deletions(-) Best Regards, J. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/7] USB: gadget: atmel_usba: add DT support
Allow to compile the driver all the time if AT91 enabled.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: linux-...@vger.kernel.org
---
.../devicetree/bindings/usb/atmel-usb.txt | 82
drivers/usb/gadget/Kconfig |2 +-
drivers/usb/gadget/atmel_usba_udc.c| 220 ++--
drivers/usb/gadget/atmel_usba_udc.h|1 +
4 files changed, 245 insertions(+), 60 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt
b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index 60bd215..55f51af 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -47,3 +47,85 @@ usb1: gadget@fffa4000 {
interrupts = 10 4;
atmel,vbus-gpio = pioC 5 0;
};
+
+Atmel High-Speed USB device controller
+
+Required properties:
+ - compatible: Should be atmel,at91sam9rl-udc
+ - reg: Address and length of the register set for the device
+ - interrupts: Should contain usba interrupt
+ - ep childnode: To specify the number of endpoints and their properties.
+
+Optional properties:
+ - atmel,vbus-gpio: If present, specifies a gpio that needs to be
+ activated for the bus to be powered.
+
+Required child node properties:
+ - name: Name of the endpoint.
+ - reg: Num of the endpoint.
+ - atmel,fifo-size: Size of the fifo.
+ - atmel,nb-banks: Number of banks.
+ - atmel,can-dma: Boolean to specify if the endpoint support DMA.
+ - atmel,can-isoc: Boolean to specify if the endpoint support ISOC.
+
+usb2: gadget@fff78000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = atmel,at91sam9rl-udc;
+ reg = 0x0060 0x8
+ 0xfff78000 0x400;
+ interrupts = 27 4 0;
+ atmel,vbus-gpio = pioB 19 0;
+
+ ep0 {
+ reg = 0;
+ atmel,fifo-size = 64;
+ atmel,nb-banks = 1;
+ };
+
+ ep1 {
+ reg = 1;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 2;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep2 {
+ reg = 2;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 2;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep3 {
+ reg = 3;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ };
+
+ ep4 {
+ reg = 4;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ };
+
+ ep5 {
+ reg = 5;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep6 {
+ reg = 6;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+};
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 83300d9..5e47d50 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -156,7 +156,7 @@ config USB_LPC32XX
config USB_ATMEL_USBA
tristate Atmel USBA
- depends on AVR32 || ARCH_AT91SAM9RL || ARCH_AT91SAM9G45
+ depends on AVR32 || ARCH_AT91
help
USBA is the integrated high-speed USB Device controller on
the AT32AP700x, some AT91SAM9 and AT91CAP9 processors from Atmel.
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index eea57a3..f89ce5e 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -22,6 +22,8 @@
#include linux/usb/atmel_usba_udc.h
#include linux/delay.h
#include linux/platform_data/atmel.h
+#include linux/of.h
+#include linux/of_gpio.h
#include asm/gpio.h
@@ -1828,13 +1830,146 @@ static int atmel_usba_stop(struct usb_gadget *gadget,
return 0;
}
-static int __init usba_udc_probe(struct platform_device *pdev)
+#ifdef CONFIG_OF
+static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
+ struct usba_udc *udc)
+{
+ u32 val;
+ const char *name;
+ enum of_gpio_flags flags;
+ struct device_node *np = pdev-dev.of_node;
+ struct device_node *pp;
+ int i, ret;
+ struct usba_ep *eps, *ep;
+
+ udc-num_ep = 0;
+
+ udc-vbus_pin = of_get_named_gpio_flags(np, atmel,vbus-gpio, 0,
+ flags);
+ udc-vbus_pin_inverted = (flags OF_GPIO_ACTIVE_LOW) ? 1 : 0;
+
+ pp = NULL;
+ while ((pp = of_get_next_child(np, pp)))
+ udc-num_ep++;
+
+ eps = devm_kzalloc(pdev-dev, sizeof(struct usba_ep) * udc-num_ep,
+
[PATCH 6/7] ARM: at91: sam9g45 add udc DT support
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/arm/boot/dts/at91sam9g45.dtsi | 62
arch/arm/mach-at91/at91sam9g45.c |2 ++
2 files changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
b/arch/arm/boot/dts/at91sam9g45.dtsi
index f0091af..fccc488 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -582,6 +582,68 @@
pinctrl-0 = pinctrl_spi1;
status = disabled;
};
+
+ usb2: gadget@fff78000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = atmel,at91sam9rl-udc;
+ reg = 0x0060 0x8
+ 0xfff78000 0x400;
+ interrupts = 27 IRQ_TYPE_LEVEL_HIGH 0;
+ status = disabled;
+
+ ep0 {
+ reg = 0;
+ atmel,fifo-size = 64;
+ atmel,nb-banks = 1;
+ };
+
+ ep1 {
+ reg = 1;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 2;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep2 {
+ reg = 2;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 2;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep3 {
+ reg = 3;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ };
+
+ ep4 {
+ reg = 4;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ };
+
+ ep5 {
+ reg = 5;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep6 {
+ reg = 6;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+ };
};
nand0: nand@4000 {
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index 8b7fce0..95a418a 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -266,6 +266,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID(NULL, fff88000.i2c, twi1_clk),
CLKDEV_CON_DEV_ID(spi_clk, fffa4000.spi, spi0_clk),
CLKDEV_CON_DEV_ID(spi_clk, fffa8000.spi, spi1_clk),
+ CLKDEV_CON_DEV_ID(hclk, 60.gadget, utmi_clk),
+ CLKDEV_CON_DEV_ID(pclk, 60.gadget, udphs_clk),
/* fake hclk clock */
CLKDEV_CON_DEV_ID(hclk, at91_ohci, uhphs_clk),
CLKDEV_CON_DEV_ID(NULL, f200.gpio, pioA_clk),
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 7/7] ARM: at91: sam9m10g45ek add udc DT support
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/arm/boot/dts/at91sam9m10g45ek.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts
b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index 89c50d1..17665ef 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -112,6 +112,11 @@
reg = 0;
};
};
+
+ usb2: gadget@fff78000 {
+ atmel,vbus-gpio = pioB 19 GPIO_ACTIVE_HIGH;
+ status = okay;
+ };
};
nand0: nand@4000 {
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/7] USB: gadget: atmel_usba: move global struct usba_ep usba_ep to struct usba_udc
so we can have multiple usb gadget instance
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: linux-...@vger.kernel.org
---
drivers/usb/gadget/atmel_usba_udc.c | 20 +++-
drivers/usb/gadget/atmel_usba_udc.h |1 +
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index f2a970f..d2ffd04 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -29,7 +29,6 @@
static struct usba_udc the_udc;
-static struct usba_ep *usba_ep;
#ifdef CONFIG_USB_GADGET_DEBUG_FS
#include linux/debugfs.h
@@ -1147,7 +1146,7 @@ static int do_test_mode(struct usba_udc *udc)
* Test_SE0_NAK: Force high-speed mode and set up ep0
* for Bulk IN transfers
*/
- ep = usba_ep[0];
+ ep = udc-usba_ep[0];
usba_writel(udc, TST,
USBA_BF(SPEED_CFG, USBA_SPEED_CFG_FORCE_HIGH));
usba_ep_writel(ep, CFG,
@@ -1165,7 +1164,7 @@ static int do_test_mode(struct usba_udc *udc)
break;
case 0x0400:
/* Test_Packet */
- ep = usba_ep[0];
+ ep = udc-usba_ep[0];
usba_ep_writel(ep, CFG,
USBA_BF(EPT_SIZE, USBA_EPT_SIZE_64)
| USBA_EPT_DIR_IN
@@ -1668,7 +1667,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
for (i = 1; i USBA_NR_ENDPOINTS; i++)
if (dma_status (1 i))
- usba_dma_irq(udc, usba_ep[i]);
+ usba_dma_irq(udc, udc-usba_ep[i]);
}
ep_status = USBA_BFEXT(EPT_INT, status);
@@ -1677,10 +1676,10 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
for (i = 0; i USBA_NR_ENDPOINTS; i++)
if (ep_status (1 i)) {
- if (ep_is_control(usba_ep[i]))
- usba_control_irq(udc, usba_ep[i]);
+ if (ep_is_control(udc-usba_ep[i]))
+ usba_control_irq(udc, udc-usba_ep[i]);
else
- usba_ep_irq(udc, usba_ep[i]);
+ usba_ep_irq(udc, udc-usba_ep[i]);
}
}
@@ -1705,7 +1704,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
DBG(DBG_BUS, %s bus reset detected\n,
usb_speed_string(udc-gadget.speed));
- ep0 = usba_ep[0];
+ ep0 = udc-usba_ep[0];
ep0-ep.desc = usba_ep0_desc;
ep0-state = WAIT_FOR_SETUP;
usba_ep_writel(ep0, CFG,
@@ -1841,6 +1840,7 @@ static int __init usba_udc_probe(struct platform_device
*pdev)
struct resource *regs, *fifo;
struct clk *pclk, *hclk;
struct usba_udc *udc = the_udc;
+ static struct usba_ep *usba_ep;
int irq, ret, i;
regs = platform_get_resource(pdev, IORESOURCE_MEM, CTRL_IOMEM_ID);
@@ -1896,6 +1896,8 @@ static int __init usba_udc_probe(struct platform_device
*pdev)
if (!usba_ep)
goto err_alloc_ep;
+ udc-usba_ep = usba_ep;
+
the_udc.gadget.ep0 = usba_ep[0].ep;
INIT_LIST_HEAD(usba_ep[0].ep.ep_list);
@@ -2008,7 +2010,7 @@ static int __exit usba_udc_remove(struct platform_device
*pdev)
usb_del_gadget_udc(udc-gadget);
for (i = 1; i pdata-num_ep; i++)
- usba_ep_cleanup_debugfs(usba_ep[i]);
+ usba_ep_cleanup_debugfs(udc-usba_ep[i]);
usba_cleanup_debugfs(udc);
if (gpio_is_valid(udc-vbus_pin)) {
diff --git a/drivers/usb/gadget/atmel_usba_udc.h
b/drivers/usb/gadget/atmel_usba_udc.h
index d65a618..0841986 100644
--- a/drivers/usb/gadget/atmel_usba_udc.h
+++ b/drivers/usb/gadget/atmel_usba_udc.h
@@ -319,6 +319,7 @@ struct usba_udc {
int vbus_pin_inverted;
struct clk *pclk;
struct clk *hclk;
+ struct usba_ep *usba_ep;
u16 devstatus;
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/7] ARM: at91: sam9x5 add udc DT support
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/arm/boot/dts/at91sam9x5.dtsi | 62 +
arch/arm/mach-at91/at91sam9x5.c |2 ++
2 files changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
b/arch/arm/boot/dts/at91sam9x5.dtsi
index af91599..01a815d 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -645,6 +645,68 @@
status = disabled;
};
+ usb2: gadget@f803c000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = atmel,at91sam9rl-udc;
+ reg = 0x0050 0x8
+ 0xf803c000 0x400;
+ interrupts = 23 IRQ_TYPE_LEVEL_HIGH 0;
+ status = disabled;
+
+ ep0 {
+ reg = 0;
+ atmel,fifo-size = 64;
+ atmel,nb-banks = 1;
+ };
+
+ ep1 {
+ reg = 1;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 2;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep2 {
+ reg = 2;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 2;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep3 {
+ reg = 3;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ };
+
+ ep4 {
+ reg = 4;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ };
+
+ ep5 {
+ reg = 5;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep6 {
+ reg = 6;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+ };
+
rtc@feb0 {
compatible = atmel,at91rm9200-rtc;
reg = 0xfeb0 0x40;
diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
index e631fec..2abee66 100644
--- a/arch/arm/mach-at91/at91sam9x5.c
+++ b/arch/arm/mach-at91/at91sam9x5.c
@@ -249,6 +249,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID(hclk, 60.ohci, uhphs_clk),
CLKDEV_CON_DEV_ID(ohci_clk, 60.ohci, uhphs_clk),
CLKDEV_CON_DEV_ID(ehci_clk, 70.ehci, uhphs_clk),
+ CLKDEV_CON_DEV_ID(hclk, 50.gadget, utmi_clk),
+ CLKDEV_CON_DEV_ID(pclk, 50.gadget, udphs_clk),
};
/*
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/7] ARM: at91: sam9x5ek add udc DT support
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/arm/boot/dts/at91sam9x5ek.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi
b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index 19c8ebb..5e10027 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -52,6 +52,11 @@
status = okay;
};
+ usb2: gadget@f803c000 {
+ atmel,vbus-gpio = pioB 16 GPIO_ACTIVE_HIGH;
+ status = okay;
+ };
+
i2c0: i2c@f801 {
status = okay;
};
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/7] USB: gadget: atmel_usba: move global struct usba_ep usba_ep to struct usba_udc
so we can have multiple usb gadget instance
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: linux-...@vger.kernel.org
---
drivers/usb/gadget/atmel_usba_udc.c | 20 +++-
drivers/usb/gadget/atmel_usba_udc.h |1 +
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index f2a970f..d2ffd04 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -29,7 +29,6 @@
static struct usba_udc the_udc;
-static struct usba_ep *usba_ep;
#ifdef CONFIG_USB_GADGET_DEBUG_FS
#include linux/debugfs.h
@@ -1147,7 +1146,7 @@ static int do_test_mode(struct usba_udc *udc)
* Test_SE0_NAK: Force high-speed mode and set up ep0
* for Bulk IN transfers
*/
- ep = usba_ep[0];
+ ep = udc-usba_ep[0];
usba_writel(udc, TST,
USBA_BF(SPEED_CFG, USBA_SPEED_CFG_FORCE_HIGH));
usba_ep_writel(ep, CFG,
@@ -1165,7 +1164,7 @@ static int do_test_mode(struct usba_udc *udc)
break;
case 0x0400:
/* Test_Packet */
- ep = usba_ep[0];
+ ep = udc-usba_ep[0];
usba_ep_writel(ep, CFG,
USBA_BF(EPT_SIZE, USBA_EPT_SIZE_64)
| USBA_EPT_DIR_IN
@@ -1668,7 +1667,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
for (i = 1; i USBA_NR_ENDPOINTS; i++)
if (dma_status (1 i))
- usba_dma_irq(udc, usba_ep[i]);
+ usba_dma_irq(udc, udc-usba_ep[i]);
}
ep_status = USBA_BFEXT(EPT_INT, status);
@@ -1677,10 +1676,10 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
for (i = 0; i USBA_NR_ENDPOINTS; i++)
if (ep_status (1 i)) {
- if (ep_is_control(usba_ep[i]))
- usba_control_irq(udc, usba_ep[i]);
+ if (ep_is_control(udc-usba_ep[i]))
+ usba_control_irq(udc, udc-usba_ep[i]);
else
- usba_ep_irq(udc, usba_ep[i]);
+ usba_ep_irq(udc, udc-usba_ep[i]);
}
}
@@ -1705,7 +1704,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
DBG(DBG_BUS, %s bus reset detected\n,
usb_speed_string(udc-gadget.speed));
- ep0 = usba_ep[0];
+ ep0 = udc-usba_ep[0];
ep0-ep.desc = usba_ep0_desc;
ep0-state = WAIT_FOR_SETUP;
usba_ep_writel(ep0, CFG,
@@ -1841,6 +1840,7 @@ static int __init usba_udc_probe(struct platform_device
*pdev)
struct resource *regs, *fifo;
struct clk *pclk, *hclk;
struct usba_udc *udc = the_udc;
+ static struct usba_ep *usba_ep;
int irq, ret, i;
regs = platform_get_resource(pdev, IORESOURCE_MEM, CTRL_IOMEM_ID);
@@ -1896,6 +1896,8 @@ static int __init usba_udc_probe(struct platform_device
*pdev)
if (!usba_ep)
goto err_alloc_ep;
+ udc-usba_ep = usba_ep;
+
the_udc.gadget.ep0 = usba_ep[0].ep;
INIT_LIST_HEAD(usba_ep[0].ep.ep_list);
@@ -2008,7 +2010,7 @@ static int __exit usba_udc_remove(struct platform_device
*pdev)
usb_del_gadget_udc(udc-gadget);
for (i = 1; i pdata-num_ep; i++)
- usba_ep_cleanup_debugfs(usba_ep[i]);
+ usba_ep_cleanup_debugfs(udc-usba_ep[i]);
usba_cleanup_debugfs(udc);
if (gpio_is_valid(udc-vbus_pin)) {
diff --git a/drivers/usb/gadget/atmel_usba_udc.h
b/drivers/usb/gadget/atmel_usba_udc.h
index d65a618..0841986 100644
--- a/drivers/usb/gadget/atmel_usba_udc.h
+++ b/drivers/usb/gadget/atmel_usba_udc.h
@@ -319,6 +319,7 @@ struct usba_udc {
int vbus_pin_inverted;
struct clk *pclk;
struct clk *hclk;
+ struct usba_ep *usba_ep;
u16 devstatus;
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/7] USB: gadget: atmel_usba: allow multi instance
drop static struct usba_udc the_udc
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: linux-...@vger.kernel.org
---
drivers/usb/gadget/atmel_usba_udc.c | 36 +--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index d2ffd04..eea57a3 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -27,9 +27,6 @@
#include atmel_usba_udc.h
-
-static struct usba_udc the_udc;
-
#ifdef CONFIG_USB_GADGET_DEBUG_FS
#include linux/debugfs.h
#include linux/uaccess.h
@@ -1013,16 +1010,13 @@ static void nop_release(struct device *dev)
}
-static struct usba_udc the_udc = {
- .gadget = {
- .ops= usba_udc_ops,
- .ep_list= LIST_HEAD_INIT(the_udc.gadget.ep_list),
- .max_speed = USB_SPEED_HIGH,
- .name = atmel_usba_udc,
- .dev= {
- .init_name = gadget,
- .release= nop_release,
- },
+struct usb_gadget usba_gadget_template = {
+ .ops= usba_udc_ops,
+ .max_speed = USB_SPEED_HIGH,
+ .name = atmel_usba_udc,
+ .dev= {
+ .init_name = gadget,
+ .release= nop_release,
},
};
@@ -1839,10 +1833,17 @@ static int __init usba_udc_probe(struct platform_device
*pdev)
struct usba_platform_data *pdata = pdev-dev.platform_data;
struct resource *regs, *fifo;
struct clk *pclk, *hclk;
- struct usba_udc *udc = the_udc;
+ struct usba_udc *udc;
static struct usba_ep *usba_ep;
int irq, ret, i;
+ udc = devm_kzalloc(pdev-dev, sizeof(*udc), GFP_KERNEL);
+ if (!udc)
+ return -ENOMEM;
+
+ udc-gadget = usba_gadget_template;
+ INIT_LIST_HEAD(udc-gadget.ep_list);
+
regs = platform_get_resource(pdev, IORESOURCE_MEM, CTRL_IOMEM_ID);
fifo = platform_get_resource(pdev, IORESOURCE_MEM, FIFO_IOMEM_ID);
if (!regs || !fifo || !pdata)
@@ -1897,8 +1898,7 @@ static int __init usba_udc_probe(struct platform_device
*pdev)
goto err_alloc_ep;
udc-usba_ep = usba_ep;
-
- the_udc.gadget.ep0 = usba_ep[0].ep;
+ udc-gadget.ep0 = usba_ep[0].ep;
INIT_LIST_HEAD(usba_ep[0].ep.ep_list);
usba_ep[0].ep_regs = udc-regs + USBA_EPT_BASE(0);
@@ -1907,7 +1907,7 @@ static int __init usba_udc_probe(struct platform_device
*pdev)
usba_ep[0].ep.ops = usba_ep_ops;
usba_ep[0].ep.name = pdata-ep[0].name;
usba_ep[0].ep.maxpacket = pdata-ep[0].fifo_size;
- usba_ep[0].udc = the_udc;
+ usba_ep[0].udc = udc;
INIT_LIST_HEAD(usba_ep[0].queue);
usba_ep[0].fifo_size = pdata-ep[0].fifo_size;
usba_ep[0].nr_banks = pdata-ep[0].nr_banks;
@@ -1924,7 +1924,7 @@ static int __init usba_udc_probe(struct platform_device
*pdev)
ep-ep.ops = usba_ep_ops;
ep-ep.name = pdata-ep[i].name;
ep-ep.maxpacket = pdata-ep[i].fifo_size;
- ep-udc = the_udc;
+ ep-udc = udc;
INIT_LIST_HEAD(ep-queue);
ep-fifo_size = pdata-ep[i].fifo_size;
ep-nr_banks = pdata-ep[i].nr_banks;
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/7] USB: gadget: atmel_usba: add DT support
Allow to compile the driver all the time if AT91 enabled.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: linux-...@vger.kernel.org
---
.../devicetree/bindings/usb/atmel-usb.txt | 82
drivers/usb/gadget/Kconfig |2 +-
drivers/usb/gadget/atmel_usba_udc.c| 220 ++--
drivers/usb/gadget/atmel_usba_udc.h|1 +
4 files changed, 245 insertions(+), 60 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt
b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index 60bd215..55f51af 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -47,3 +47,85 @@ usb1: gadget@fffa4000 {
interrupts = 10 4;
atmel,vbus-gpio = pioC 5 0;
};
+
+Atmel High-Speed USB device controller
+
+Required properties:
+ - compatible: Should be atmel,at91sam9rl-udc
+ - reg: Address and length of the register set for the device
+ - interrupts: Should contain usba interrupt
+ - ep childnode: To specify the number of endpoints and their properties.
+
+Optional properties:
+ - atmel,vbus-gpio: If present, specifies a gpio that needs to be
+ activated for the bus to be powered.
+
+Required child node properties:
+ - name: Name of the endpoint.
+ - reg: Num of the endpoint.
+ - atmel,fifo-size: Size of the fifo.
+ - atmel,nb-banks: Number of banks.
+ - atmel,can-dma: Boolean to specify if the endpoint support DMA.
+ - atmel,can-isoc: Boolean to specify if the endpoint support ISOC.
+
+usb2: gadget@fff78000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = atmel,at91sam9rl-udc;
+ reg = 0x0060 0x8
+ 0xfff78000 0x400;
+ interrupts = 27 4 0;
+ atmel,vbus-gpio = pioB 19 0;
+
+ ep0 {
+ reg = 0;
+ atmel,fifo-size = 64;
+ atmel,nb-banks = 1;
+ };
+
+ ep1 {
+ reg = 1;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 2;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep2 {
+ reg = 2;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 2;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep3 {
+ reg = 3;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ };
+
+ ep4 {
+ reg = 4;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ };
+
+ ep5 {
+ reg = 5;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep6 {
+ reg = 6;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+};
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 83300d9..5e47d50 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -156,7 +156,7 @@ config USB_LPC32XX
config USB_ATMEL_USBA
tristate Atmel USBA
- depends on AVR32 || ARCH_AT91SAM9RL || ARCH_AT91SAM9G45
+ depends on AVR32 || ARCH_AT91
help
USBA is the integrated high-speed USB Device controller on
the AT32AP700x, some AT91SAM9 and AT91CAP9 processors from Atmel.
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index eea57a3..f89ce5e 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -22,6 +22,8 @@
#include linux/usb/atmel_usba_udc.h
#include linux/delay.h
#include linux/platform_data/atmel.h
+#include linux/of.h
+#include linux/of_gpio.h
#include asm/gpio.h
@@ -1828,13 +1830,146 @@ static int atmel_usba_stop(struct usb_gadget *gadget,
return 0;
}
-static int __init usba_udc_probe(struct platform_device *pdev)
+#ifdef CONFIG_OF
+static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
+ struct usba_udc *udc)
+{
+ u32 val;
+ const char *name;
+ enum of_gpio_flags flags;
+ struct device_node *np = pdev-dev.of_node;
+ struct device_node *pp;
+ int i, ret;
+ struct usba_ep *eps, *ep;
+
+ udc-num_ep = 0;
+
+ udc-vbus_pin = of_get_named_gpio_flags(np, atmel,vbus-gpio, 0,
+ flags);
+ udc-vbus_pin_inverted = (flags OF_GPIO_ACTIVE_LOW) ? 1 : 0;
+
+ pp = NULL;
+ while ((pp = of_get_next_child(np, pp)))
+ udc-num_ep++;
+
+ eps = devm_kzalloc(pdev-dev, sizeof(struct usba_ep) * udc-num_ep,
+
[PATCH 4/7] ARM: at91: sam9x5 add udc DT support
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/arm/boot/dts/at91sam9x5.dtsi | 62 +
arch/arm/mach-at91/at91sam9x5.c |2 ++
2 files changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
b/arch/arm/boot/dts/at91sam9x5.dtsi
index af91599..01a815d 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -645,6 +645,68 @@
status = disabled;
};
+ usb2: gadget@f803c000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = atmel,at91sam9rl-udc;
+ reg = 0x0050 0x8
+ 0xf803c000 0x400;
+ interrupts = 23 IRQ_TYPE_LEVEL_HIGH 0;
+ status = disabled;
+
+ ep0 {
+ reg = 0;
+ atmel,fifo-size = 64;
+ atmel,nb-banks = 1;
+ };
+
+ ep1 {
+ reg = 1;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 2;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep2 {
+ reg = 2;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 2;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep3 {
+ reg = 3;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ };
+
+ ep4 {
+ reg = 4;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ };
+
+ ep5 {
+ reg = 5;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep6 {
+ reg = 6;
+ atmel,fifo-size = 1024;
+ atmel,nb-banks = 3;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+ };
+
rtc@feb0 {
compatible = atmel,at91rm9200-rtc;
reg = 0xfeb0 0x40;
diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
index e631fec..2abee66 100644
--- a/arch/arm/mach-at91/at91sam9x5.c
+++ b/arch/arm/mach-at91/at91sam9x5.c
@@ -249,6 +249,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID(hclk, 60.ohci, uhphs_clk),
CLKDEV_CON_DEV_ID(ohci_clk, 60.ohci, uhphs_clk),
CLKDEV_CON_DEV_ID(ehci_clk, 70.ehci, uhphs_clk),
+ CLKDEV_CON_DEV_ID(hclk, 50.gadget, utmi_clk),
+ CLKDEV_CON_DEV_ID(pclk, 50.gadget, udphs_clk),
};
/*
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] ARM: dts: Remove combiner IRQ node from exynos4x12.dtsi
Ping...
On Tuesday, 23 April 2013, Sachin Kamat sachin.ka...@linaro.org wrote:
These nodes have separately been added to 4212 and 4412 dtsi
files by commit 30269ddff1 (ARM: exynos: add missing properties
for combiner IRQs). The existing node also contained a few
incorrect entries.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Patch based on linux-next tree (20130423)
---
arch/arm/boot/dts/exynos4x12.dtsi |8
1 file changed, 8 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index ede3f9b..675c221 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -28,14 +28,6 @@
pinctrl3 = pinctrl_3;
};
- combiner:interrupt-controller@1044 {
- interrupts = 0 0 0, 0 1 0, 0 2 0, 0 3 0,
-0 4 0, 0 5 0, 0 6 0, 0 7 0,
-0 8 0, 0 9 0, 0 10 0, 0 11 0,
-0 12 0, 0 13 0, 0 14 0, 0 15 0,
-0 16 0, 0 17 0, 0 18 0, 0 19 0;
- };
-
clock: clock-controller@0x1003 {
compatible = samsung,exynos4412-clock;
reg = 0x1003 0x2;
--
1.7.9.5
--
With warm regards,
Sachin
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv10 2/9] of/pci: Provide support for parsing PCI DT ranges property
On Mon, May 20, 2013 at 09:03:00AM +0200, Linus Walleij wrote: On Sun, May 19, 2013 at 10:31 PM, Jason Cooper ja...@lakedaemon.net wrote: patches 2, 3, and 4 applied to mvebu/of_pci to facilitate others (LinusW) basing their work off of it. Thanks, is this going to be pulled into ARM SoC soon-ish? I think Arnd may need this for some PCI work too. I was half expecting -rc2 to drop yesterday. Since it didn't, I'll go ahead and send another round of PRs, including this one. Probably today or tomorrow. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/7] USB: gadget: atmel_usba: allow multi instance
drop static struct usba_udc the_udc
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: linux-...@vger.kernel.org
---
drivers/usb/gadget/atmel_usba_udc.c | 36 +--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index d2ffd04..eea57a3 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -27,9 +27,6 @@
#include atmel_usba_udc.h
-
-static struct usba_udc the_udc;
-
#ifdef CONFIG_USB_GADGET_DEBUG_FS
#include linux/debugfs.h
#include linux/uaccess.h
@@ -1013,16 +1010,13 @@ static void nop_release(struct device *dev)
}
-static struct usba_udc the_udc = {
- .gadget = {
- .ops= usba_udc_ops,
- .ep_list= LIST_HEAD_INIT(the_udc.gadget.ep_list),
- .max_speed = USB_SPEED_HIGH,
- .name = atmel_usba_udc,
- .dev= {
- .init_name = gadget,
- .release= nop_release,
- },
+struct usb_gadget usba_gadget_template = {
+ .ops= usba_udc_ops,
+ .max_speed = USB_SPEED_HIGH,
+ .name = atmel_usba_udc,
+ .dev= {
+ .init_name = gadget,
+ .release= nop_release,
},
};
@@ -1839,10 +1833,17 @@ static int __init usba_udc_probe(struct platform_device
*pdev)
struct usba_platform_data *pdata = pdev-dev.platform_data;
struct resource *regs, *fifo;
struct clk *pclk, *hclk;
- struct usba_udc *udc = the_udc;
+ struct usba_udc *udc;
static struct usba_ep *usba_ep;
int irq, ret, i;
+ udc = devm_kzalloc(pdev-dev, sizeof(*udc), GFP_KERNEL);
+ if (!udc)
+ return -ENOMEM;
+
+ udc-gadget = usba_gadget_template;
+ INIT_LIST_HEAD(udc-gadget.ep_list);
+
regs = platform_get_resource(pdev, IORESOURCE_MEM, CTRL_IOMEM_ID);
fifo = platform_get_resource(pdev, IORESOURCE_MEM, FIFO_IOMEM_ID);
if (!regs || !fifo || !pdata)
@@ -1897,8 +1898,7 @@ static int __init usba_udc_probe(struct platform_device
*pdev)
goto err_alloc_ep;
udc-usba_ep = usba_ep;
-
- the_udc.gadget.ep0 = usba_ep[0].ep;
+ udc-gadget.ep0 = usba_ep[0].ep;
INIT_LIST_HEAD(usba_ep[0].ep.ep_list);
usba_ep[0].ep_regs = udc-regs + USBA_EPT_BASE(0);
@@ -1907,7 +1907,7 @@ static int __init usba_udc_probe(struct platform_device
*pdev)
usba_ep[0].ep.ops = usba_ep_ops;
usba_ep[0].ep.name = pdata-ep[0].name;
usba_ep[0].ep.maxpacket = pdata-ep[0].fifo_size;
- usba_ep[0].udc = the_udc;
+ usba_ep[0].udc = udc;
INIT_LIST_HEAD(usba_ep[0].queue);
usba_ep[0].fifo_size = pdata-ep[0].fifo_size;
usba_ep[0].nr_banks = pdata-ep[0].nr_banks;
@@ -1924,7 +1924,7 @@ static int __init usba_udc_probe(struct platform_device
*pdev)
ep-ep.ops = usba_ep_ops;
ep-ep.name = pdata-ep[i].name;
ep-ep.maxpacket = pdata-ep[i].fifo_size;
- ep-udc = the_udc;
+ ep-udc = udc;
INIT_LIST_HEAD(ep-queue);
ep-fifo_size = pdata-ep[i].fifo_size;
ep-nr_banks = pdata-ep[i].nr_banks;
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/4] ARM: tegra: use #include for all device trees
On 05/13/2013 01:24 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Replace /include/ (dtc) with #include (C pre-processor) for all Tegra DT files, so that gcc -E handles the entire include tree, and hence any of those files can #include some other file e.g. for constant definitions. This allows future use of #defines and header files in order to define names for various constants, such as the IDs and flags in GPIO specifiers. Use of those features will increase the readability of the device tree files. I have applied this series, with patch 3/4 replaced with V3 of that patch. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] drivers/gpio: Altera soft IP GPIO driver
On Wed, May 8, 2013 at 4:39 AM, Tien Hock Loh th...@altera.com wrote:
Add driver support for Altera GPIO soft IP, including interrupts and I/O.
Tested on Altera CV SoC board.
Signed-off-by: Tien Hock Loh th...@altera.com
(...)
Note: I have come to realize that there is apparently almost zero
review on the devicetree-discuss list, is there anyone in the world
reviewing new device tree bindings for generality, or is it all up to
Linux subsystem maintainers like myself to take care of this?
+++ b/Documentation/devicetree/bindings/gpio/gpio-altera.txt
@@ -0,0 +1,40 @@
+Altera GPIO controller bindings
+
+Required properties:
+- compatible:
+ - altr,pio-1.0
This vendor prefix does not exist in
Documentation/devicetree/bindings/vendor-prefixes.txt
so atleast add it.
I don't see the point in abbreviating altera to altr to
save two letters, use the full name of the company!
+- reg: Physical base address and length of the controller's registers.
+- #gpio-cells : Should be two.
+ - first cell is the gpio offset number
+ - second cell is used to specify optional parameters (unused)
So why do you add it? Because all other GPIO controllers
use it? Or because you will use it for something later?
+- gpio-controller : Marks the device node as a GPIO controller.
+- #interrupt-cells : Should be 1.
+- interrupts: Specify the interrupt.
+- interrupt-controller: Mark the device node as an interrupt controller
+ The first cell is the GPIO number.
+Altera GPIO specific properties:
+- width: Width of the GPIO bank, range from 1-32
+- level_trigger: Specifies whether the GPIO interrupt is level trigger.
+ This field is required if the Altera GPIO controller used has IRQ enabled.
Is this how other GPIO controllers do it?
+ Note: This field is does not specify whether Altera GPIO controller is
+ level or edge trigger. It is used to detect internally how the trigger is
+ handled.
I don't get it, but I guess reading the code will. I suspect this
needs editing since DT bindings shall be *reusable* without
having to read the code to understand them.
Explain exactly what you mean when you say it is used to
detect internally how the trigger is handled. Used how?
Handled how? Internally to what?
+Note: If the Altera GPIO is set to be built as a module, peripherals that
uses
+Altera GPIO as interrupt-parent should be a module so that the peripheral
+doesn't get initialized before Altera GPIO is initialized.
Delete this. We do not put Linux-specific information into the
device tree bindings.
(...)
+++ b/drivers/gpio/gpio-altera.c
(...)
+#include linux/platform_device.h
Suggest
#include linux/basic_mmio_gpio.h
+#define ALTERA_GPIO_DATA 0x0
+#define ALTERA_GPIO_DIR0x4
+#define ALTERA_GPIO_IRQ_MASK 0x8
+#define ALTERA_GPIO_EDGE_CAP 0xc
+#define ALTERA_GPIO_OUTSET 0x10
+#define ALTERA_GPIO_OUTCLEAR 0x14
Looking at this is is pretty apparent that you shall use
the generic basic MMIO GPIO helper library.
In Kconfig:
select GPIO_GENERIC
Include #include linux/basic_mmio_gpio.h
See other GPIO drivers to figure out how to reuse the
generic MMIO GPIO helpers. For example the new
GRGPIO driver, drivers/gpio/gpio-grgpio.c.
+struct altera_gpio_chip {
+ struct of_mm_gpio_chip mmchip;
+ struct irq_domain *irq; /* GPIO controller IRQ number */
+ spinlock_t gpio_lock; /* Lock used for synchronization */
+ bool level_trigger;
+ int hwirq;
+};
Convert inline documentation to kerneldoc.
Document the rest of the members as well because
I don't understand them, and the documentation for the
irqdomain is plain wrong, the other comment is
just stating the obvious: tell us *what* is it locking
and *why*.
(...)
+static int altera_gpio_irq_set_type(struct irq_data *d,
+ unsigned int type)
+{
+ /* There is no way to know the soft IP configuration,
+ so we accept any interrupt types that are supported by the soft
+ IP. Nothing to do here since it is hardware defined. Just return
+ OK status to the caller. */
Eh what? Why don't you say pass in the capabilities from
the device tree then, if the hardware cannot say what it is
capable of, something else has to.
/*
* Please use this multiline comment
* style, it is easier to read.
*/
+ if (type == IRQ_TYPE_EDGE_RISING ||
+ type == IRQ_TYPE_EDGE_FALLING ||
+ type == IRQ_TYPE_EDGE_BOTH ||
+ type == IRQ_TYPE_NONE) {
+ return 0;
+ }
This is not OK if it is unclear whether this is all supported.
Get that info from somewhere.
Apparently this is exactly what the level trigger field in
the device tree defines.
Especially handling both edges is quite tricky, have you
actually tested this?
(...)
+static int altera_gpio_get(struct gpio_chip *gc, unsigned offset)
+static void
Re: [PATCHv10 5/9] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
On Sun, May 19, 2013 at 04:47:03PM -0400, Jason Cooper wrote: On Thu, May 16, 2013 at 05:55:20PM +0200, Thomas Petazzoni wrote: The Armada 370 has two gatable clocks for each PCIe interface, and we want both of them to be enabled. We therefore make one of the two clocks a child of the other, as we did for the sataX and sataXlnk clocks on Armada XP. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Mike Turquette mturque...@linaro.org --- drivers/clk/mvebu/clk-gating-ctrl.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Patches 5 - 8 applied to mvebu/pcie, with a dep on Sebastian's clock rework and mvebu/of_pci. Thanks for the head's up on the clk conflict. My resolution should match yours. Please let me know if it doesn't. As stated in the clk thread, I'm going to re-order this so pcie doesn't depend on the clk series. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC/PATCH 1/2] gpio-rcar: Make the platform data gpio_base field signed
On Fri, May 10, 2013 at 4:48 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: The gpio_base field is used to specify the desired GPIO base for the GPIO controller. The GPIO core can automatically allocate a GPIO number range when the base is set to -1. To make this possible, make the field signed. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 0/2] clk: samsung: add composite clocks
On Mon, May 20, 2013 at 7:44 PM, Heiko Stübner he...@sntech.de wrote: Am Montag, 20. Mai 2013, 16:17:06 schrieb Rahul Sharma: This patch adds support for composite clocks for samsung SoCs. Many drivers need access to a common clock which support gating and/or muxing and/or rate control operations. For example hdmi which needs to switch between parents and call enable/disable for sclk_hdmi. This patch set also adds composite clock for exyno5250 hdmi. Based on the review comment, I will extended this to other exynos SoCs clocks files. I think I remember reading somewhere that the target of the common clock framework was to prevent every SoC from introducing their own special clock types and instead create these structures from separate clocks (mux clk + gate clk) and not to have every SoC create their own custom clock types. The Samsung clock drivers at the moment follow this paradigm of combining the existing simple clocks and only introduce new clock types for the pll clocks, that really need special handling. So it would probably good to keep it this way and define your clocks from their individual components, as all the other Samsung clocks currently do. Thanks Heiko, I agree, but I am not trying to introduce a new type here, instead using the existing generic support for composite clocks for exynos as well. These have not been added for Samsung SoCs so far but I do not see any harm in using them also. With them, drivers do not need to get and configure each clock component separately. This ensures less and more reasonable changes in the drivers during migration to CCF. Please help me understand about the loss when using composite clocks. regards, Rahul Sharma Heiko ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 0/2] clk: samsung: add composite clocks
Am Montag, 20. Mai 2013, 20:19:29 schrieb Rahul Sharma: On Mon, May 20, 2013 at 7:44 PM, Heiko Stübner he...@sntech.de wrote: Am Montag, 20. Mai 2013, 16:17:06 schrieb Rahul Sharma: This patch adds support for composite clocks for samsung SoCs. Many drivers need access to a common clock which support gating and/or muxing and/or rate control operations. For example hdmi which needs to switch between parents and call enable/disable for sclk_hdmi. This patch set also adds composite clock for exyno5250 hdmi. Based on the review comment, I will extended this to other exynos SoCs clocks files. I think I remember reading somewhere that the target of the common clock framework was to prevent every SoC from introducing their own special clock types and instead create these structures from separate clocks (mux clk + gate clk) and not to have every SoC create their own custom clock types. The Samsung clock drivers at the moment follow this paradigm of combining the existing simple clocks and only introduce new clock types for the pll clocks, that really need special handling. So it would probably good to keep it this way and define your clocks from their individual components, as all the other Samsung clocks currently do. Thanks Heiko, I agree, but I am not trying to introduce a new type here, instead using the existing generic support for composite clocks for exynos as well. These have not been added for Samsung SoCs so far but I do not see any harm in using them also. With them, drivers do not need to get and configure each clock component separately. This ensures less and more reasonable changes in the drivers during migration to CCF. Please help me understand about the loss when using composite clocks. hehe ... it seems I remembered something outdated ... The last time (before march 12th) I looked at the ccf, it was use simple clocktypes. But it seems in the meantime the separate composite-clock you use was introduced. And I didn't read your patch careful enough to see that you're using the (now) existing composite clock. So, sorry for the noise :-) Heiko ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 2/2] clk: samsung: add exynos5250 composite clock for hdmi
Hi Rahul,
On Monday 20 of May 2013 19:47:08 Rahul Sharma wrote:
HDMI driver needs to change the parent of sclk_hdmi clock to
sclk_pixel or to sclk_hdmiphy, depends on the status of hdmiphy.
sclk_hdmi which is gate clock doesn't support the set_parent
operation.
Wouldn't it be better to simply allow calling clk_set_parent() on gate
clocks and propagate parent change to nearest mux, just like it is done
with clk_set_rate()?
It wouldn't require any SoC-specific composite clocks and keep the nice
property of the clock tree, which is built from basic, generic clock
blocks that nicely correspond to blocks shown in the documentation.
We had discussed this already at SRPOL and got to the conclusion that it's
a step backwards, making the clock driver more complex, because each
composite block would have to be described using a structure with many
fields. In addition there are many special cases, for which the composite
scheme wouldn't work anyway and they would end up with simple clocks
attached after the composite block, defeating the purpose of your patch.
Best regards,
Tomasz
This patch adds sclk_hdmi as a composite clock which is a
combination of mux clock and gate clock. Being a composite
clock, above clock supports both set_parent and enable/disable
functionality. Therefore hdmi driver need not be modified
different S0Cs. This will handled inside CCF.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/clk/samsung/clk-exynos5250.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c index 5c97e75..0c9e37a 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -231,7 +231,6 @@ struct samsung_mux_clock exynos5250_mux_clks[]
__initdata = { MUX(none, mout_fimd1, mout_group1_p, SRC_DISP1_0, 0,
4),
MUX(none, mout_mipi1, mout_group1_p, SRC_DISP1_0, 12, 4),
MUX(none, mout_dp, mout_group1_p, SRC_DISP1_0, 16, 4),
- MUX(none, mout_hdmi, mout_hdmi_p, SRC_DISP1_0, 20, 1),
MUX(none, mout_audio0, mout_audio0_p, SRC_MAU, 0, 4),
MUX(none, mout_mmc0, mout_group1_p, SRC_FSYS, 0, 4),
MUX(none, mout_mmc1, mout_group1_p, SRC_FSYS, 4, 4),
@@ -416,8 +415,6 @@ struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = { SRC_MASK_DISP1_0, 12, CLK_SET_RATE_PARENT, 0),
GATE(sclk_dp, sclk_dp, div_dp,
SRC_MASK_DISP1_0, 16, CLK_SET_RATE_PARENT, 0),
- GATE(sclk_hdmi, sclk_hdmi, mout_hdmi,
- SRC_MASK_DISP1_0, 20, 0, 0),
GATE(sclk_audio0, sclk_audio0, div_audio0,
SRC_MASK_MAU, 0, CLK_SET_RATE_PARENT, 0),
GATE(sclk_mmc0, sclk_mmc0, div_mmc_pre0,
@@ -464,6 +461,21 @@ struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = { GATE(hdmi, hdmi, aclk200, GATE_IP_DISP1, 6, 0, 0),
};
+struct samsung_composite_clock exynos5250_composite_clks[] __initdata =
{ + {
+ .id = sclk_hdmi,
+ .name = sclk_hdmi,
+ .parent_names = mout_hdmi_p,
+ .num_parents = ARRAY_SIZE(mout_hdmi_p),
+ .mux_clk = MUX(none, NULL, mout_hdmi_p, SRC_DISP1_0, 20,
+ 1),
+ .gate_clk = GATE(none, NULL, NULL, SRC_MASK_DISP1_0, 20,
+ 0, 0),
+ .composition_flags = SAMSUNG_CLK_TYPE_GATE |
+ SAMSUNG_CLK_TYPE_MUX,
+ },
+};
+
static __initdata struct of_device_id ext_clk_match[] = {
{ .compatible = samsung,clock-xxti, .data = (void *)0, },
{ },
@@ -515,6 +527,8 @@ void __init exynos5250_clk_init(struct device_node
*np) ARRAY_SIZE(exynos5250_div_clks));
samsung_clk_register_gate(exynos5250_gate_clks,
ARRAY_SIZE(exynos5250_gate_clks));
+ samsung_clk_register_composite(exynos5250_composite_clks,
+ ARRAY_SIZE(exynos5250_composite_clks));
pr_info(Exynos5250: clock setup completed, armclk=%ld\n,
_get_rate(armclk));
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3] net: dm9000: Allow instantiation using device tree
This patch adds Device Tree support to dm9000 driver.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
Changes since v2:
- corrected a typo in bindings documentation
- removed redundant error message about failed memory allocation
Changes since v1:
- dropped davicom,simple-phy property as it seems to be of no use
- used of_get_mac_address() to get MAC address from device tree
- replaced #ifdef CONFIG_OF around dm9000_parse_dt() with IS_ENABLED
.../devicetree/bindings/net/davicom-dm9000.txt | 26 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
drivers/net/ethernet/davicom/dm9000.c | 42 ++
3 files changed, 69 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/davicom-dm9000.txt
diff --git a/Documentation/devicetree/bindings/net/davicom-dm9000.txt
b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
new file mode 100644
index 000..2d39c99
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
@@ -0,0 +1,26 @@
+Davicom DM9000 Fast Ethernet controller
+
+Required properties:
+- compatible = davicom,dm9000;
+- reg : physical addresses and sizes of registers, must contain 2 entries:
+first entry : address register,
+second entry : data register.
+- interrupt-parent : interrupt controller to which the device is connected
+- interrupts : interrupt specifier specific to interrupt controller
+
+Optional properties:
+- local-mac-address : A bytestring of 6 bytes specifying Ethernet MAC address
+to use (from firmware or bootloader)
+- davicom,no-eeprom : Configuration EEPROM is not available
+- davicom,ext-phy : Use external PHY
+
+Example:
+
+ ethernet@1800 {
+ compatible = davicom,dm9000;
+ reg = 0x1800 0x2 0x1804 0x2;
+ interrupt-parent = gpn;
+ interrupts = 7 4;
+ local-mac-address = [00 00 de ad be ef];
+ davicom,no-eeprom;
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 6931c43..2fe74e6 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -18,6 +18,7 @@ chrp Common Hardware Reference Platform
cirrus Cirrus Logic, Inc.
cortinaCortina Systems, Inc.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
+davicomDAVICOM Semiconductor, Inc.
denx Denx Software Engineering
emmicroEM Microelectronic
epson Seiko Epson Corp.
diff --git a/drivers/net/ethernet/davicom/dm9000.c
b/drivers/net/ethernet/davicom/dm9000.c
index 9105465..7af6126 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -29,6 +29,8 @@
#include linux/spinlock.h
#include linux/crc32.h
#include linux/mii.h
+#include linux/of.h
+#include linux/of_net.h
#include linux/ethtool.h
#include linux/dm9000.h
#include linux/delay.h
@@ -1358,6 +1360,31 @@ static const struct net_device_ops dm9000_netdev_ops = {
#endif
};
+static struct dm9000_plat_data *dm9000_parse_dt(struct device *dev)
+{
+ struct dm9000_plat_data *pdata;
+ struct device_node *np = dev-of_node;
+ const void *mac_addr;
+
+ if (!IS_ENABLED(CONFIG_OF) || !np)
+ return NULL;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ if (of_find_property(np, davicom,ext-phy, NULL))
+ pdata-flags |= DM9000_PLATF_EXT_PHY;
+ if (of_find_property(np, davicom,no-eeprom, NULL))
+ pdata-flags |= DM9000_PLATF_NO_EEPROM;
+
+ mac_addr = of_get_mac_address(np);
+ if (mac_addr)
+ memcpy(pdata-dev_addr, mac_addr, sizeof(pdata-dev_addr));
+
+ return pdata;
+}
+
/*
* Search DM9000 board, allocate space and register it
*/
@@ -1373,6 +1400,12 @@ dm9000_probe(struct platform_device *pdev)
int i;
u32 id_val;
+ if (!pdata) {
+ pdata = dm9000_parse_dt(pdev-dev);
+ if (IS_ERR(pdata))
+ return PTR_ERR(pdata);
+ }
+
/* Init network device */
ndev = alloc_etherdev(sizeof(struct board_info));
if (!ndev)
@@ -1683,11 +1716,20 @@ dm9000_drv_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id dm9000_of_matches[] = {
+ { .compatible = davicom,dm9000, },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, dm9000_of_matches);
+#endif
+
static struct platform_driver dm9000_driver = {
.driver = {
.name= dm9000,
.owner = THIS_MODULE,
.pm = dm9000_drv_pm_ops,
+ .of_match_table = of_match_ptr(dm9000_of_matches),
},
.probe = dm9000_probe,
.remove = dm9000_drv_remove,
--
Re: [RFC 2/2] clk: samsung: add exynos5250 composite clock for hdmi
On 05/20/2013 11:57 AM, Tomasz Figa wrote: Hi Rahul, On Monday 20 of May 2013 19:47:08 Rahul Sharma wrote: HDMI driver needs to change the parent of sclk_hdmi clock to sclk_pixel or to sclk_hdmiphy, depends on the status of hdmiphy. sclk_hdmi which is gate clock doesn't support the set_parent operation. Wouldn't it be better to simply allow calling clk_set_parent() on gate clocks and propagate parent change to nearest mux, just like it is done with clk_set_rate()? It wouldn't require any SoC-specific composite clocks and keep the nice property of the clock tree, which is built from basic, generic clock blocks that nicely correspond to blocks shown in the documentation. We had discussed this already at SRPOL and got to the conclusion that it's a step backwards, making the clock driver more complex, because each composite block would have to be described using a structure with many fields. In addition there are many special cases, for which the composite scheme wouldn't work anyway and they would end up with simple clocks attached after the composite block, defeating the purpose of your patch. +1 to all these comments. -Saravana -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] net: dm9000: Allow instantiation using device tree
On 05/20/2013 09:16 PM, Tomasz Figa wrote: This patch adds Device Tree support to dm9000 driver. Signed-off-by: Tomasz Figatomasz.f...@gmail.com Looks good. I'm going to test also this version at the end of this week on Mini2440. Reviewed-by: Sylwester Nawrocki sylvester.nawro...@gmail.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] net: dm9000: Allow instantiation using device tree
On Mon, May 20, 2013 at 09:16:58PM +0200, Tomasz Figa wrote: This patch adds Device Tree support to dm9000 driver. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com Looks good for me aswell, thanks. Reviewed-by: Sascha Hauer s.ha...@pengutronix.de Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.
* Andreas Fenkart andreas.fenk...@streamunlimited.com [130515 01:51]:
Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
the system. This patch reconfigures dat1 line as a gpio while the fclk is
off. When the fclk is present it uses the standard SDIO IRQ detection of
the module.
The gpio irq is managed via the 'disable_depth' ref counter of the irq
subsystem, this driver simply calls enable_irq/disable_irq when needed.
sdio irqsdio irq
unmasked masked
-
runtime default |1 | 2
runtime suspend |0 | 1
irq disable depth
only when sdio irq is enabled AND the module is idle, the reference
count drops to zero and the gpio irq is effectively armed.
Patch was tested on AM335x/Stream800. Test setup was two modules
with sdio wifi cards. Modules where connected to a dual-band AP, each
module using a different band. One of module was running iperf as server
the other as client connecting to the server in a while true loop. Test
was running for 4+ weeks. There were about 60 Mio. suspend/resume
transitions. Test was shut down regularly.
Looks like this somehow breaks detecting of eMMC on mmc2 for me at least
with the non-dt legacyboot. For a removable mmc1 still keeps working.
For mmc2 I have .nonremovable = true and no gpio_cd or gpio_wp.
Also few comments below.
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
+ host-pinctrl = devm_pinctrl_get(pdev-dev);
+ if (IS_ERR(host-pinctrl)) {
+ ret = PTR_ERR(host-pinctrl);
+ goto err_pinctrl;
+ }
+
+ host-active = pinctrl_lookup_state(host-pinctrl,
+ PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(host-active)) {
+ dev_warn(mmc_dev(host-mmc), Unable to lookup active
pinmux\n);
+ ret = PTR_ERR(host-active);
+ goto err_pinctrl_state;
+ }
This should be checked, we have systems with all muxing done statically
in the bootloader. And we also have systems that provide the default
pinctrl state only as they don't need remuxing. So at most a warning should
be printed.
static int omap_hsmmc_runtime_resume(struct device *dev)
{
struct omap_hsmmc_host *host;
+ unsigned long flags;
+ int ret = 0;
host = platform_get_drvdata(to_platform_device(dev));
omap_hsmmc_context_restore(host);
dev_dbg(dev, enabled\n);
- return 0;
+ if (mmc_slot(host).sdio_irq host-pinctrl) {
+ disable_irq(mmc_slot(host).sdio_irq);
+
+ ret = pinctrl_select_state(host-pinctrl, host-active);
+ if (ret 0) {
+ dev_warn(mmc_dev(host-mmc), Unable to select active
pinmux\n);
+ return ret;
+ }
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ host-active_pinmux = true;
+
+ if (host-sdio_irq_en) {
+ OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ OMAP_HSMMC_WRITE(host-base, ISE, CIRQ_EN);
+ OMAP_HSMMC_WRITE(host-base, IE, CIRQ_EN);
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
+ }
+ return ret;
}
The check for sdio_irq host-pinctrl looks broken too as we may
have not dynamic muxing via pinctrl needed for let's say omap3 based
systems.
Other than that, looks good to me.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] net: dm9000: Allow instantiation using device tree
From: Tomasz Figa tomasz.f...@gmail.com Date: Mon, 20 May 2013 21:16:58 +0200 This patch adds Device Tree support to dm9000 driver. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com APplied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/7] net: mv643xx_eth: add Device Tree bindings
Hi Sebastian,
On Mon, May 06, 2013 at 05:33:34PM +0200, Sebastian Hesselbarth wrote:
From: Florian Fainelli flor...@openwrt.org
This patch adds Device Tree bindings following the already defined
bindings at Documentation/devicetree/bindings/marvell.txt. The binding
documentation is also enhanced with new optionnal properties required
for supporting certain devices (RX/TX queue and SRAM). Since we now have
proper support for the orion MDIO bus driver, there is no need to fiddle
around with device tree phandles. PHY-less (MAC connected to switch)
configurations are supported by not specifying any phy phandle for an
ethernet node.
Signed-off-by: Florian Fainelli flor...@openwrt.org
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changelog:
v2-v3:
- rebase on top of mv643xx_eth clean-ups
- do not reparse existing platform_data
- use managed devm_kzalloc for parsed platform_data
- use of_property_read_u32 where applicable
- add phy_node to platform_data
- use of_connect_phy if DT phy node was found
v1-v2:
- properly ifdef of_platform_bus_probe with CONFIG_OF
- handle of_platform_bus_probe errors and cleanup accordingly
- use of_property_read_u32 where applicable
- parse duplex and speed property in PHY-less configuration
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: David Miller da...@davemloft.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: Arnaud Patard arnaud.pat...@rtp-net.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Jean-Francois Moine moin...@free.fr
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Simon Guinot simon.gui...@sequanux.org
Cc: Jamie Lentin j...@lentin.co.uk
Cc: Michael Walle mich...@walle.cc
Cc: Eric Hutter hutter.e...@gmail.com
Cc: Joshua Coombs josh.coo...@gmail.com
Cc: Willy Tarreau w...@1wt.eu
Cc: Simon Baatz gmbno...@gmail.com
Cc: Alan M Butler alanbutt...@gmail.com
Cc: Nigel Roberts ni...@nobiscuit.com
Cc: Valentin Longchamp valentin.longch...@keymile.com
Cc: Stefan Peter s.pe...@mpl.ch
Cc: Arnaud Ebalard a...@natisbad.org
Cc: Nobuhiro Iwamatsu iwama...@nigauri.org
Cc: net...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
Documentation/devicetree/bindings/marvell.txt | 22 +-
drivers/net/ethernet/marvell/mv643xx_eth.c| 108
-
include/linux/mv643xx_eth.h |3 +
3 files changed, 128 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/marvell.txt
b/Documentation/devicetree/bindings/marvell.txt
index f7a0da6..73ea12f 100644
--- a/Documentation/devicetree/bindings/marvell.txt
+++ b/Documentation/devicetree/bindings/marvell.txt
@@ -112,11 +112,13 @@ prefixed with the string marvell,, for Marvell
Technology Group Ltd.
Required properties:
- #address-cells : 1
- #size-cells : 0
- - compatible : marvell,mv64360-eth-block
+ - compatible : marvell,mv64360-eth-block, marvell,mv643xx-eth-block
- reg : Offset and length of the register set for this block
Optional properties:
- clocks : Phandle to the clock control device and gate bit
+ - tx-csum-limit : Hardware limit above which transmit checksumming
+ is disabled.
Example Discovery Ethernet block node:
ethernet-block@2000 {
@@ -133,7 +135,7 @@ prefixed with the string marvell,, for Marvell
Technology Group Ltd.
Required properties:
- device_type : Should be network.
- - compatible : Should be marvell,mv64360-eth.
+ - compatible : Should be marvell,mv64360-eth, marvell,mv643xx-eth
- reg : Should be 0, 1, or 2, according to which registers
within the silicon block the device uses.
- interrupts : a where a is the interrupt number for the port.
@@ -143,6 +145,22 @@ prefixed with the string marvell,, for Marvell
Technology Group Ltd.
controller.
- local-mac-address : 6 bytes, MAC address
+ Optional properties:
+ - clocks : Phandle to the clock control device and gate bit
+ - clock-names : String describing the clock gate bit
+ - speed : Speed to force the link (10, 100, 1000), used when no
+ phy property is defined
+ - duplex : Duplex to force the link (0: half, 1: full), used when no
+ phy property is defined
+ - rx-queue-count : number of RX queues to use
+ - tx-queue-count : number of TX queues to use
+ - rx-queue-size : size of the RX queue (in bytes)
+ - tx-queue-size : size of the TX queue (in bytes)
+ - rx-sram-addr : address of the SRAM for RX path (non 0 means used)
+ - rx-sram-size : size of the
Re: [PATCH v3 6/7] ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes
Hi Sebastian,
On Mon, May 06, 2013 at 05:33:39PM +0200, Sebastian Hesselbarth wrote:
This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Kirkwood boards. Phy nodes are also added with reg property set on a
per-board basis.
...
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index fada7e6..c01a273 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -202,5 +202,57 @@
clocks = gate_clk 4;
status = disabled;
};
+
+ mdio: mdio-bus@72004 {
+ compatible = marvell,orion-mdio;
+ reg = 0x72004 0x84;
+ interrupts = 11;
Shouldn't this be 46?
- Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/7] net: mv643xx_eth: add Device Tree bindings
On 05/20/2013 11:19 PM, Simon Baatz wrote:
On Mon, May 06, 2013 at 05:33:34PM +0200, Sebastian Hesselbarth wrote:
From: Florian Fainelliflor...@openwrt.org
...
@@ -2485,13 +2499,21 @@ static int mv643xx_eth_shared_probe(struct
platform_device *pdev)
if (dram)
mv643xx_eth_conf_mbus_windows(msp, dram);
- msp-tx_csum_limit = (pd != NULL pd-tx_csum_limit) ?
- pd-tx_csum_limit : 9 * 1024;
+ if (np)
+ of_property_read_u32(np, tx-csum-limit,tx_csum_limit);
+ else
+ tx_csum_limit = pd-tx_csum_limit;
+
+ msp-tx_csum_limit = tx_csum_limit ? tx_csum_limit : 9 * 1024;
infer_hw_params(msp);
platform_set_drvdata(pdev, msp);
+#ifdef CONFIG_OF
+ return of_platform_bus_probe(np, mv643xx_eth_match,pdev-dev);
I have tested this on Kirkwood (Sheevaplug eSATA). When using
mv643xx_eth as a module with a built-in mvmdio the GbE port works.
However, when unloading the mv643xx_eth module and loading it again,
the second call to of_platform_bus_probe() results in a warning:
[ 190.542992] WARNING: at fs/sysfs/dir.c:530 sysfs_add_one+0x7c/0xa4()
[ 190.549372] sysfs: cannot create duplicate filename '/devices/ocp.0/f1072000.
ethernet-controller/0.ethernet-port'
(Looks more like a problem of of_platform_bus_probe() than a problem
in the driver?)
Hi Simon,
thanks for the review. I am right now working on a v4 of the DT support
patches for mv643xx_eth and the above will not be there anymore. I will
test v4 for rmmod/modprobe issues before posting.
@@ -2677,6 +2769,10 @@ static int mv643xx_eth_probe(struct platform_device
*pdev)
struct resource *res;
int err;
+ err = mv643xx_eth_of_probe(pdev);
+ if (err)
+ return err;
+
pd = pdev-dev.platform_data;
if (pd == NULL) {
dev_err(pdev-dev, no mv643xx_eth_platform_data\n);
If the clock isn't already enabled (mvmdio and mv643xx_eth both built
as modules), a delay seems to be necessary in mv643xx_eth_probe()
after enabling the clock on my hardware. Otherwise the device hangs.
Andrew found the same in the past (see [1]). udelay(50) seems to be
sufficient in my case.
Hmm, I am wondering if that delay shouldn't be in the clock provider
then. I test it on Dove also and look for a way to insert the delay
if neccessary. Maybe Andrew can also comment on this.
@@ -2717,7 +2813,12 @@ static int mv643xx_eth_probe(struct platform_device
*pdev)
netif_set_real_num_rx_queues(dev, mp-rxq_count);
if (pd-phy_addr != MV643XX_ETH_PHY_NONE) {
- mp-phy = phy_scan(mp, pd-phy_addr);
+ if (pd-phy_node)
+ mp-phy = of_phy_connect(mp-dev, pd-phy_node,
+ mv643xx_eth_adjust_link, 0,
+ PHY_INTERFACE_MODE_GMII);
of_phy_connect() returns NULL in case of an error and no ERR_PTR.
True, will take care of that.
Sebastian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 6/7] ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes
On 05/20/2013 11:27 PM, Simon Baatz wrote:
Hi Sebastian,
On Mon, May 06, 2013 at 05:33:39PM +0200, Sebastian Hesselbarth wrote:
This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Kirkwood boards. Phy nodes are also added with reg property set on a
per-board basis.
...
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index fada7e6..c01a273 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -202,5 +202,57 @@
clocks =gate_clk 4;
status = disabled;
};
+
+ mdio: mdio-bus@72004 {
+ compatible = marvell,orion-mdio;
+ reg =0x72004 0x84;
+ interrupts =11;
Shouldn't this be 46?
Yes, mdio is using GbE0Err interrupt and that is 14 on IRQ HIGH CAUSE.
I was misled by 11 on IRQ LOW CAUSE.
Sebastian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 01/10] mmc: return mmc_of_parse() errors to caller
In addition to just logging errors encountered during DT parsing or
allocating GPIO slots for CD/WP, mmc_of_parse() now returns with an error.
In particular, this is needed if the GPIO allocation may return
EPROBE_DEFER.
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
changes in V3:
- Handle EPROBE_DEFER case
drivers/mmc/core/host.c | 30 +-
include/linux/mmc/host.h |2 +-
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 2a3593d..89f5849 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -306,7 +306,7 @@ static inline void mmc_host_clk_sysfs_init(struct mmc_host
*host)
* parse the properties and set respective generic mmc-host flags and
* parameters.
*/
-void mmc_of_parse(struct mmc_host *host)
+int mmc_of_parse(struct mmc_host *host)
{
struct device_node *np;
u32 bus_width;
@@ -315,7 +315,7 @@ void mmc_of_parse(struct mmc_host *host)
int len, ret, gpio;
if (!host-parent || !host-parent-of_node)
- return;
+ return 0;
np = host-parent-of_node;
@@ -338,6 +338,7 @@ void mmc_of_parse(struct mmc_host *host)
default:
dev_err(host-parent,
Invalid \bus-width\ value %ud!\n, bus_width);
+ return -EINVAL;
}
/* f_max is obtained from the optional max-frequency property */
@@ -367,18 +368,22 @@ void mmc_of_parse(struct mmc_host *host)
host-caps |= MMC_CAP_NEEDS_POLL;
gpio = of_get_named_gpio_flags(np, cd-gpios, 0, flags);
+ if (gpio == -EPROBE_DEFER)
+ return gpio;
if (gpio_is_valid(gpio)) {
if (!(flags OF_GPIO_ACTIVE_LOW))
gpio_inv_cd = true;
ret = mmc_gpio_request_cd(host, gpio);
- if (ret 0)
+ if (ret 0) {
dev_err(host-parent,
Failed to request CD GPIO #%d: %d!\n,
gpio, ret);
- else
+ return ret;
+ } else {
dev_info(host-parent, Got CD GPIO #%d.\n,
gpio);
+ }
}
if (explicit_inv_cd ^ gpio_inv_cd)
@@ -389,14 +394,23 @@ void mmc_of_parse(struct mmc_host *host)
explicit_inv_wp = of_property_read_bool(np, wp-inverted);
gpio = of_get_named_gpio_flags(np, wp-gpios, 0, flags);
+ if (gpio == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto out;
+ }
if (gpio_is_valid(gpio)) {
if (!(flags OF_GPIO_ACTIVE_LOW))
gpio_inv_wp = true;
ret = mmc_gpio_request_ro(host, gpio);
- if (ret 0)
+ if (ret 0) {
dev_err(host-parent,
Failed to request WP GPIO: %d!\n, ret);
+ goto out;
+ } else {
+ dev_info(host-parent, Got WP GPIO #%d.\n,
+gpio);
+ }
}
if (explicit_inv_wp ^ gpio_inv_wp)
host-caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
@@ -413,6 +427,12 @@ void mmc_of_parse(struct mmc_host *host)
host-pm_caps |= MMC_PM_KEEP_POWER;
if (of_find_property(np, enable-sdio-wakeup, len))
host-pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
+
+ return 0;
+
+out:
+ mmc_gpio_free_cd(host);
+ return ret;
}
EXPORT_SYMBOL(mmc_of_parse);
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index e326ae2..c8c4fbc 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -369,7 +369,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *);
int mmc_add_host(struct mmc_host *);
void mmc_remove_host(struct mmc_host *);
void mmc_free_host(struct mmc_host *);
-void mmc_of_parse(struct mmc_host *host);
+int mmc_of_parse(struct mmc_host *host);
static inline void *mmc_priv(struct mmc_host *host)
{
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 00/10] mmc_of_parse() adaptations, DT support for Sheevaplugs
Hi, V3 changes: - Patch 01/10: Added EPROBE_DEFER case to mmc_of_parse() - Added Acked-By to (unmodified) patches 02 and 03. V2 changes: - Converted mvsdio to use mmc_of_parse() - Adapted DTS files using mvsdio accordingly - Changed mmc_of_parse() to return errors to the caller While adding DT support for the Sheevaplugs by Globalscale Technologies (Kirkwood), it turned out that the DT binding of mvsdio lacked features to properly support the hardware (active high/low of CD and WP pins could not be described in DT). This is standard functionality provided by the mmc_of_parse() helper function. However, mmc_of_parse() may allocate GPIO lines. If the allocation fails, it outputs an error, but does not return an error to its caller. Therefore, a proposal to handle errors in mmc_of_parse() is made. The patch set is structured as follows: 1 Adapt mmc_of_parse() to return errors 2-6 Handle errors in current drivers using mmc_of_parse() (compile tested only) 7-8 Convert mvsdio and respective dts files to mmc_of_parse() (tested on kirkwood) 9 Add dts files for (eSATA) Sheevaplug 10 Add DT support for (eSATA) Sheevaplug I could only test on an eSATA Sheevaplug. I found patches with different LEDs for the Sheevaplug. Thus, I would highly appreciate if someone with the hardware could give this a spin on a non-eSATA version. Some additional testing of the change detect and write protect behaviour for mvsdio can't hurt either. I hope that there aren't board revisions with different CD/WP pins out there. Simon Baatz (10): mmc: return mmc_of_parse() errors to caller mmc: sh_mmcif: handle mmc_of_parse() errors during probe mmc: tmio-mmc: handle mmc_of_parse() errors during probe mmc: mxcmmc: handle mmc_of_parse() errors during probe mmc: sdhci-pxav3: handle mmc_of_parse() errors during probe mmc: tegra: handle mmc_of_parse() errors during probe ARM: mvebu: Use standard MMC binding for all users of mvsdio mmc: mvsdio: use standard MMC device-tree binding parser mmc_of_parse() ARM: Kirkwood: Add dts files for Sheevaplug and eSATA Sheevaplug ARM: Kirkwood: add DT support for Sheevaplug and Sheevaplug eSATA arch/arm/boot/dts/Makefile |2 + arch/arm/boot/dts/armada-370-db.dts|1 + arch/arm/boot/dts/armada-370-mirabox.dts |1 + arch/arm/boot/dts/armada-370-rd.dts|1 + arch/arm/boot/dts/armada-370-xp.dtsi |4 + arch/arm/boot/dts/armada-xp-db.dts |1 + arch/arm/boot/dts/kirkwood-dreamplug.dts |1 + .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |2 + arch/arm/boot/dts/kirkwood-mplcec4.dts |2 +- arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi | 97 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts| 40 arch/arm/boot/dts/kirkwood-sheevaplug.dts | 45 + arch/arm/boot/dts/kirkwood-topkick.dts |1 + arch/arm/boot/dts/kirkwood.dtsi|4 + arch/arm/mach-kirkwood/Kconfig |7 ++ arch/arm/mach-kirkwood/Makefile|1 + arch/arm/mach-kirkwood/board-dt.c |4 + arch/arm/mach-kirkwood/board-sheevaplug.c | 27 ++ arch/arm/mach-kirkwood/common.h|5 + drivers/mmc/core/host.c| 30 +- drivers/mmc/host/mvsdio.c | 73 --- drivers/mmc/host/mxcmmc.c |4 +- drivers/mmc/host/sdhci-pxav3.c |7 +- drivers/mmc/host/sdhci-tegra.c |9 +- drivers/mmc/host/sh_mmcif.c|7 +- drivers/mmc/host/tmio_mmc_pio.c|4 +- include/linux/mmc/host.h |2 +- 27 files changed, 334 insertions(+), 48 deletions(-) create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug.dts create mode 100644 arch/arm/mach-kirkwood/board-sheevaplug.c -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 02/10] mmc: sh_mmcif: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz gmbno...@gmail.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- drivers/mmc/host/sh_mmcif.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c index ba76a53..6ded7fb 100644 --- a/drivers/mmc/host/sh_mmcif.c +++ b/drivers/mmc/host/sh_mmcif.c @@ -1369,7 +1369,11 @@ static int sh_mmcif_probe(struct platform_device *pdev) ret = -ENOMEM; goto ealloch; } - mmc_of_parse(mmc); + + ret = mmc_of_parse(mmc); + if (ret 0) + goto eofparse; + host= mmc_priv(mmc); host-mmc = mmc; host-addr = reg; @@ -1464,6 +1468,7 @@ eclkupdate: clk_put(host-hclk); eclkget: pm_runtime_disable(pdev-dev); +eofparse: mmc_free_host(mmc); ealloch: iounmap(reg); -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 03/10] mmc: tmio-mmc: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz gmbno...@gmail.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- drivers/mmc/host/tmio_mmc_pio.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c index f508ecb..f1a9d4a 100644 --- a/drivers/mmc/host/tmio_mmc_pio.c +++ b/drivers/mmc/host/tmio_mmc_pio.c @@ -988,7 +988,9 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host, if (!mmc) return -ENOMEM; - mmc_of_parse(mmc); + ret = mmc_of_parse(mmc); + if (ret 0) + goto host_free; pdata-dev = pdev-dev; _host = mmc_priv(mmc); -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 04/10] mmc: mxcmmc: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz gmbno...@gmail.com --- drivers/mmc/host/mxcmmc.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c index d503635..f47546f 100644 --- a/drivers/mmc/host/mxcmmc.c +++ b/drivers/mmc/host/mxcmmc.c @@ -1067,7 +1067,9 @@ static int mxcmci_probe(struct platform_device *pdev) goto out_release_mem; } - mmc_of_parse(mmc); + ret = mmc_of_parse(mmc); + if (ret) + goto out_free; mmc-ops = mxcmci_ops; /* For devicetree parsing, the bus width is read from devicetree */ -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 05/10] mmc: sdhci-pxav3: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
drivers/mmc/host/sdhci-pxav3.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 1ae358e..67ea388 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -252,7 +252,9 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
match = of_match_device(of_match_ptr(sdhci_pxav3_of_match), pdev-dev);
if (match) {
- mmc_of_parse(host-mmc);
+ ret = mmc_of_parse(host-mmc);
+ if (ret)
+ goto err_of_parse;
sdhci_get_of_property(pdev);
pdata = pxav3_get_mmc_pdata(dev);
} else if (pdata) {
@@ -313,10 +315,11 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
return 0;
+err_of_parse:
+err_cd_req:
err_add_host:
clk_disable_unprepare(clk);
clk_put(clk);
-err_cd_req:
err_clk_get:
sdhci_pltfm_free(pdev);
kfree(pxa);
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 06/10] mmc: tegra: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
drivers/mmc/host/sdhci-tegra.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index e0dba74..7eb62f8 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -205,7 +205,7 @@ static const struct of_device_id sdhci_tegra_dt_match[] = {
};
MODULE_DEVICE_TABLE(of, sdhci_tegra_dt_match);
-static void sdhci_tegra_parse_dt(struct device *dev)
+static int sdhci_tegra_parse_dt(struct device *dev)
{
struct device_node *np = dev-of_node;
struct sdhci_host *host = dev_get_drvdata(dev);
@@ -213,7 +213,7 @@ static void sdhci_tegra_parse_dt(struct device *dev)
struct sdhci_tegra *tegra_host = pltfm_host-priv;
tegra_host-power_gpio = of_get_named_gpio(np, power-gpios, 0);
- mmc_of_parse(host-mmc);
+ return mmc_of_parse(host-mmc);
}
static int sdhci_tegra_probe(struct platform_device *pdev)
@@ -245,7 +245,9 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
tegra_host-soc_data = soc_data;
pltfm_host-priv = tegra_host;
- sdhci_tegra_parse_dt(pdev-dev);
+ rc = sdhci_tegra_parse_dt(pdev-dev);
+ if (rc)
+ goto err_parse_dt;
if (gpio_is_valid(tegra_host-power_gpio)) {
rc = gpio_request(tegra_host-power_gpio, sdhci_power);
@@ -278,6 +280,7 @@ err_add_host:
err_clk_get:
if (gpio_is_valid(tegra_host-power_gpio))
gpio_free(tegra_host-power_gpio);
+err_parse_dt:
err_power_req:
err_alloc_tegra_host:
sdhci_pltfm_free(pdev);
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 07/10] ARM: mvebu: Use standard MMC binding for all users of mvsdio
In order to prepare the switch to the standard MMC device tree parser
for mvsdio, adapt all current uses of mvsdio in the dts files to the
standard format.
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
arch/arm/boot/dts/armada-370-db.dts|1 +
arch/arm/boot/dts/armada-370-mirabox.dts |1 +
arch/arm/boot/dts/armada-370-rd.dts|1 +
arch/arm/boot/dts/armada-370-xp.dtsi |4
arch/arm/boot/dts/armada-xp-db.dts |1 +
arch/arm/boot/dts/kirkwood-dreamplug.dts |1 +
.../arm/boot/dts/kirkwood-guruplug-server-plus.dts |2 ++
arch/arm/boot/dts/kirkwood-mplcec4.dts |2 +-
arch/arm/boot/dts/kirkwood-topkick.dts |1 +
arch/arm/boot/dts/kirkwood.dtsi|4
10 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 2353b1f..beee169 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -74,6 +74,7 @@
*/
status = disabled;
/* No CD or WP GPIOs */
+ broken-cd;
};
usb@5 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 14e36e1..45b1077 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -99,6 +99,7 @@
* No CD or WP GPIOs: SDIO interface used for
* Wifi/Bluetooth chip
*/
+broken-cd;
};
usb@5 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 130f839..89c2110 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -64,6 +64,7 @@
pinctrl-names = default;
status = okay;
/* No CD or WP GPIOs */
+ broken-cd;
};
usb@5 {
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 272bbc6..031894e 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -142,6 +142,10 @@
reg = 0xd4000 0x200;
interrupts = 54;
clocks = gateclk 17;
+ bus-width = 4;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
status = disabled;
};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index d6cc8bf..7c22a20 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -97,6 +97,7 @@
pinctrl-names = default;
status = okay;
/* No CD or WP GPIOs */
+ broken-cd;
};
usb@5 {
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts
b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 289e51d..be16a84 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -79,6 +79,7 @@
pinctrl-names = default;
status = okay;
/* No CD or WP GPIOs */
+ broken-cd;
};
};
diff --git a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
index 44fd97d..484a2a6 100644
--- a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
+++ b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
@@ -72,6 +72,8 @@
mvsdio@9 {
status = okay;
+ /* No CD or WP GPIOs */
+ broken-cd;
};
};
diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts
b/arch/arm/boot/dts/kirkwood-mplcec4.dts
index 7588241..bf3a58c 100644
--- a/arch/arm/boot/dts/kirkwood-mplcec4.dts
+++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts
@@ -136,7 +136,7 @@
pinctrl-0 = pmx_sdio pmx_sdio_cd;
pinctrl-names = default;
status = okay;
- cd-gpios = gpio1 15 0;
+ cd-gpios = gpio1 15 1;
/* No WP GPIO */
};
};
diff --git
[PATCH V3 08/10] mmc: mvsdio: use standard MMC device-tree binding parser mmc_of_parse()
Instead of parsing the DT binding on our own, use the standard parser
mmc_of_parse(), introduced by commit 6c56e7a.
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
drivers/mmc/host/mvsdio.c | 73 +
1 file changed, 40 insertions(+), 33 deletions(-)
diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
index 8960fc8..edfc481 100644
--- a/drivers/mmc/host/mvsdio.c
+++ b/drivers/mmc/host/mvsdio.c
@@ -35,7 +35,7 @@
#define DRIVER_NAMEmvsdio
-static int maxfreq = MVSD_CLOCKRATE_MAX;
+static int maxfreq;
static int nodma;
struct mvsd_host {
@@ -685,7 +685,6 @@ static int __init mvsd_probe(struct platform_device *pdev)
const struct mbus_dram_target_info *dram;
struct resource *r;
int ret, irq;
- int gpio_card_detect, gpio_write_protect;
struct pinctrl *pinctrl;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -718,6 +717,20 @@ static int __init mvsd_probe(struct platform_device *pdev)
if (!IS_ERR(host-clk))
clk_prepare_enable(host-clk);
+ mmc-ops = mvsd_ops;
+
+ mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
+
+ mmc-f_min = DIV_ROUND_UP(host-base_clock, MVSD_BASE_DIV_MAX);
+ mmc-f_max = MVSD_CLOCKRATE_MAX;
+
+ mmc-max_blk_size = 2048;
+ mmc-max_blk_count = 65535;
+
+ mmc-max_segs = 1;
+ mmc-max_seg_size = mmc-max_blk_size * mmc-max_blk_count;
+ mmc-max_req_size = mmc-max_blk_size * mmc-max_blk_count;
+
if (np) {
if (IS_ERR(host-clk)) {
dev_err(pdev-dev, DT platforms must have a clock
associated\n);
@@ -726,35 +739,38 @@ static int __init mvsd_probe(struct platform_device *pdev)
}
host-base_clock = clk_get_rate(host-clk) / 2;
- gpio_card_detect = of_get_named_gpio(np, cd-gpios, 0);
- gpio_write_protect = of_get_named_gpio(np, wp-gpios, 0);
+ ret = mmc_of_parse(mmc);
+ if (ret 0)
+ goto out;
} else {
const struct mvsdio_platform_data *mvsd_data;
+
mvsd_data = pdev-dev.platform_data;
if (!mvsd_data) {
ret = -ENXIO;
goto out;
}
+ mmc-caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ |
+ MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
host-base_clock = mvsd_data-clock / 2;
- gpio_card_detect = mvsd_data-gpio_card_detect ? : -EINVAL;
- gpio_write_protect = mvsd_data-gpio_write_protect ? : -EINVAL;
- }
-
- mmc-ops = mvsd_ops;
-
- mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
- mmc-caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ |
- MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
-
- mmc-f_min = DIV_ROUND_UP(host-base_clock, MVSD_BASE_DIV_MAX);
- mmc-f_max = maxfreq;
+ /* GPIO 0 regarded as invalid for backward compatibility */
+ if (mvsd_data-gpio_card_detect
+ gpio_is_valid(mvsd_data-gpio_card_detect)) {
+ ret = mmc_gpio_request_cd(mmc,
+ mvsd_data-gpio_card_detect);
+ if (ret)
+ goto out;
+ } else {
+ mmc-caps |= MMC_CAP_NEEDS_POLL;
+ }
- mmc-max_blk_size = 2048;
- mmc-max_blk_count = 65535;
+ if (mvsd_data-gpio_write_protect
+ gpio_is_valid(mvsd_data-gpio_write_protect))
+ mmc_gpio_request_ro(mmc, mvsd_data-gpio_write_protect);
+ }
- mmc-max_segs = 1;
- mmc-max_seg_size = mmc-max_blk_size * mmc-max_blk_count;
- mmc-max_req_size = mmc-max_blk_size * mmc-max_blk_count;
+ if (maxfreq)
+ mmc-f_max = maxfreq;
spin_lock_init(host-lock);
@@ -777,15 +793,6 @@ static int __init mvsd_probe(struct platform_device *pdev)
goto out;
}
- if (gpio_is_valid(gpio_card_detect)) {
- ret = mmc_gpio_request_cd(mmc, gpio_card_detect);
- if (ret)
- goto out;
- } else
- mmc-caps |= MMC_CAP_NEEDS_POLL;
-
- mmc_gpio_request_ro(mmc, gpio_write_protect);
-
setup_timer(host-timer, mvsd_timeout_timer, (unsigned long)host);
platform_set_drvdata(pdev, mmc);
ret = mmc_add_host(mmc);
@@ -793,10 +800,10 @@ static int __init mvsd_probe(struct platform_device *pdev)
goto out;
if (!(mmc-caps MMC_CAP_NEEDS_POLL))
- dev_notice(pdev-dev, using GPIO %d for card detection\n,
- gpio_card_detect);
+ dev_notice(pdev-dev, using GPIO for card detection\n);
else
- dev_notice(pdev-dev,
[PATCH V3 09/10] ARM: Kirkwood: Add dts files for Sheevaplug and eSATA Sheevaplug
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
arch/arm/boot/dts/Makefile|2 +
arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi | 97 +
arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts | 40 +
arch/arm/boot/dts/kirkwood-sheevaplug.dts | 45 ++
4 files changed, 184 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9f7121..e81a387 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -84,6 +84,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
kirkwood-ns2max.dtb \
kirkwood-ns2mini.dtb \
kirkwood-nsa310.dtb \
+ kirkwood-sheevaplug.dtb \
+ kirkwood-sheevaplug-esata.dtb \
kirkwood-topkick.dtb \
kirkwood-ts219-6281.dtb \
kirkwood-ts219-6282.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
new file mode 100644
index 000..9d59475
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
@@ -0,0 +1,97 @@
+/*
+ * kirkwood-sheevaplug-common.dts - Common parts for Sheevaplugs
+ *
+ * Copyright (C) 2013 Simon Baatz gmbno...@gmail.com
+ *
+ * Licensed under GPLv2
+ */
+
+/include/ kirkwood.dtsi
+/include/ kirkwood-6281.dtsi
+
+/ {
+ memory {
+ device_type = memory;
+ reg = 0x 0x2000;
+ };
+
+ chosen {
+ bootargs = console=ttyS0,115200n8 earlyprintk;
+ };
+
+ ocp@f100 {
+ pinctrl: pinctrl@1 {
+
+ pmx_usb_power_enable: pmx-usb-power-enable {
+ marvell,pins = mpp29;
+ marvell,function = gpio;
+ };
+ pmx_led_red: pmx-led-red {
+ marvell,pins = mpp46;
+ marvell,function = gpio;
+ };
+ pmx_led_blue: pmx-led-blue {
+ marvell,pins = mpp49;
+ marvell,function = gpio;
+ };
+ pmx_sdio_cd: pmx-sdio-cd {
+ marvell,pins = mpp44;
+ marvell,function = gpio;
+ };
+ pmx_sdio_wp: pmx-sdio-wp {
+ marvell,pins = mpp47;
+ marvell,function = gpio;
+ };
+ };
+ serial@12000 {
+ status = okay;
+ };
+
+ nand@300 {
+ status = okay;
+
+ partition@0 {
+ label = u-boot;
+ reg = 0x000 0x10;
+ };
+
+ partition@10 {
+ label = uImage;
+ reg = 0x010 0x40;
+ };
+
+ partition@50 {
+ label = root;
+ reg = 0x050 0x1fb0;
+ };
+ };
+ };
+
+ regulators {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ usb_power: regulator@1 {
+ compatible = regulator-fixed;
+ reg = 1;
+ regulator-name = USB Power;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ enable-active-high;
+ regulator-always-on;
+ regulator-boot-on;
+ gpio = gpio0 29 0;
+ };
+ };
+
+ gpio-leds {
+ compatible = gpio-leds;
+
+ health {
+ label = sheevaplug:blue:health;
+ gpios = gpio1 17 1;
+ linux,default-trigger = default-on;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
b/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
new file mode 100644
index 000..1c6946a
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
@@ -0,0 +1,40 @@
+/*
+ * kirkwood-sheevaplug-esata.dts - Device tree file for eSATA Sheevaplug
+ *
+ * Copyright (C) 2013 Simon Baatz gmbno...@gmail.com
+ *
+ * Licensed under GPLv2
+ */
+
+/dts-v1/;
+
+/include/ kirkwood-sheevaplug-common.dtsi
+
+/ {
+ model = Globalscale Technologies eSATA SheevaPlug;
+ compatible =
[PATCH V3 10/10] ARM: Kirkwood: add DT support for Sheevaplug and Sheevaplug eSATA
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
arch/arm/mach-kirkwood/Kconfig|7 +++
arch/arm/mach-kirkwood/Makefile |1 +
arch/arm/mach-kirkwood/board-dt.c |4
arch/arm/mach-kirkwood/board-sheevaplug.c | 27 +++
arch/arm/mach-kirkwood/common.h |5 +
5 files changed, 44 insertions(+)
create mode 100644 arch/arm/mach-kirkwood/board-sheevaplug.c
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 7509a89..58518a2 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -296,6 +296,13 @@ config MACH_READYNAS_DT
Say 'Y' here if you want your kernel to support the
NETGEAR ReadyNAS Duo v2 using Fattened Device Tree.
+config MACH_SHEEVAPLUG_DT
+ bool Marvell (eSATA) SheevaPlug (Flattened Device Tree)
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the
+ Marvell (eSATA) SheevaPlug (Flattened Device Tree).
+
config MACH_TOPKICK_DT
bool USI Topkick (Flattened Device Tree)
select ARCH_KIRKWOOD_DT
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index e1f3735..8846abf 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -40,5 +40,6 @@ obj-$(CONFIG_MACH_NETSPACE_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NSA310_DT) += board-nsa310.o
obj-$(CONFIG_MACH_OPENBLOCKS_A6_DT)+= board-openblocks_a6.o
obj-$(CONFIG_MACH_READYNAS_DT) += board-readynas.o
+obj-$(CONFIG_MACH_SHEEVAPLUG_DT) += board-sheevaplug.o
obj-$(CONFIG_MACH_TOPKICK_DT) += board-usi_topkick.o
obj-$(CONFIG_MACH_TS219_DT)+= board-ts219.o tsx1x-common.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c
b/arch/arm/mach-kirkwood/board-dt.c
index e9647b8..a09dbac 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -112,6 +112,9 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible(globalscale,guruplug))
guruplug_dt_init();
+ if (of_machine_is_compatible(globalscale,sheevaplug))
+ sheevaplug_dt_init();
+
if (of_machine_is_compatible(dlink,dns-kirkwood))
dnskw_init();
@@ -165,6 +168,7 @@ static void __init kirkwood_dt_init(void)
static const char * const kirkwood_dt_board_compat[] = {
globalscale,dreamplug,
globalscale,guruplug,
+ globalscale,sheevaplug,
dlink,dns-320,
dlink,dns-325,
iom,iconnect,
diff --git a/arch/arm/mach-kirkwood/board-sheevaplug.c
b/arch/arm/mach-kirkwood/board-sheevaplug.c
new file mode 100644
index 000..fa38937
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-sheevaplug.c
@@ -0,0 +1,27 @@
+/*
+ * arch/arm/mach-kirkwood/board-sheevaplug.c
+ *
+ * Marvell Sheevaplug Reference Board Init for drivers not converted to
+ * flattened device tree yet.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/mv643xx_eth.h
+#include common.h
+
+static struct mv643xx_eth_platform_data sheevaplug_ge00_data = {
+ .phy_addr = MV643XX_ETH_PHY_ADDR(0),
+};
+
+void __init sheevaplug_dt_init(void)
+{
+ /*
+* Basic setup. Needs to be called early.
+*/
+ kirkwood_ge00_init(sheevaplug_ge00_data);
+}
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 21da3b1..974442e 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -65,6 +65,11 @@ void guruplug_dt_init(void);
#else
static inline void guruplug_dt_init(void) {};
#endif
+#ifdef CONFIG_MACH_SHEEVAPLUG_DT
+void sheevaplug_dt_init(void);
+#else
+static inline void sheevaplug_dt_init(void) {};
+#endif
#ifdef CONFIG_MACH_TS219_DT
void qnap_dt_ts219_init(void);
#else
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.
* Tony Lindgren t...@atomide.com [130520 14:03]:
* Andreas Fenkart andreas.fenk...@streamunlimited.com [130515 01:51]:
Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
the system. This patch reconfigures dat1 line as a gpio while the fclk is
off. When the fclk is present it uses the standard SDIO IRQ detection of
the module.
The gpio irq is managed via the 'disable_depth' ref counter of the irq
subsystem, this driver simply calls enable_irq/disable_irq when needed.
sdio irqsdio irq
unmasked masked
-
runtime default |1 | 2
runtime suspend |0 | 1
irq disable depth
only when sdio irq is enabled AND the module is idle, the reference
count drops to zero and the gpio irq is effectively armed.
Patch was tested on AM335x/Stream800. Test setup was two modules
with sdio wifi cards. Modules where connected to a dual-band AP, each
module using a different band. One of module was running iperf as server
the other as client connecting to the server in a while true loop. Test
was running for 4+ weeks. There were about 60 Mio. suspend/resume
transitions. Test was shut down regularly.
Looks like this somehow breaks detecting of eMMC on mmc2 for me at least
with the non-dt legacyboot. For a removable mmc1 still keeps working.
For mmc2 I have .nonremovable = true and no gpio_cd or gpio_wp.
Looks like that's because gpio0 is considered valid. But for these pins
gpio0 is not valid, so let's cut the dependency to updating the pdata
and ignore gpio0.
We should also have three pinmux states: default, active and idle to
avoid remuxing all the pins unnecessarily. The default pins should
contain the fixed pins, active mmc_dat1, and idle the gpio pin.
I've attempted to fix up these issues, did not add the wake-up events
from Steve Sakoman's patch for the non-muxed case:
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
Based on the patch above, sounds like the wake-up events won't work
for deeper idle states though. But we should probably still support
those as most people run without the deeper idle states anyways.
Can you check if the following changes on top of your patch still
work for you? Note that you need to update your .dts file for the
new pinctrl states.
Regards,
Tony
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -186,7 +186,7 @@ struct omap_hsmmc_host {
struct omap_hsmmc_next next_data;
boolsdio_irq_en;
struct pinctrl *pinctrl;
- struct pinctrl_state*active, *idle;
+ struct pinctrl_state*fixed, *active, *idle;
boolactive_pinmux;
struct omap_mmc_platform_data *pdata;
@@ -434,7 +434,8 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
} else
pdata-slots[0].gpio_wp = -EINVAL;
- if (gpio_is_valid(pdata-slots[0].gpio_cirq)) {
+ if (pdata-slots[0].gpio_cirq 0
+ gpio_is_valid(pdata-slots[0].gpio_cirq)) {
pdata-slots[0].sdio_irq =
gpio_to_irq(pdata-slots[0].gpio_cirq);
@@ -1635,7 +1636,7 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc,
struct mmc_card *card)
static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
{
struct omap_hsmmc_host *host = mmc_priv(mmc);
- u32 irq_mask;
+ u32 irq_mask, con;
unsigned long flags;
spin_lock_irqsave(host-irq_lock, flags);
@@ -2116,35 +2117,43 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
omap_hsmmc_disable_irq(host);
+ mmc-caps |= MMC_CAP_SDIO_IRQ;
+
host-pinctrl = devm_pinctrl_get(pdev-dev);
- if (IS_ERR(host-pinctrl)) {
- ret = PTR_ERR(host-pinctrl);
- goto err_pinctrl;
- }
-
- host-active = pinctrl_lookup_state(host-pinctrl,
- PINCTRL_STATE_DEFAULT);
- if (IS_ERR(host-active)) {
- dev_warn(mmc_dev(host-mmc), Unable to lookup active
pinmux\n);
- ret = PTR_ERR(host-active);
- goto err_pinctrl_state;
- }
-
- if (mmc_slot(host).sdio_irq) {
- host-idle = pinctrl_lookup_state(host-pinctrl,
- PINCTRL_STATE_IDLE);
- if (IS_ERR(host-idle)) {
- dev_warn(mmc_dev(host-mmc), Unable to lookup idle
pinmux\n);
- ret = PTR_ERR(host-idle);
- goto err_pinctrl_state;
+ if (!IS_ERR(host-pinctrl)) {
+ host-fixed = pinctrl_lookup_state(host-pinctrl,
+ PINCTRL_STATE_DEFAULT);
+
Re: [RFC 2/2] clk: samsung: add exynos5250 composite clock for hdmi
On Tue, May 21, 2013 at 12:27 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Rahul,
On Monday 20 of May 2013 19:47:08 Rahul Sharma wrote:
HDMI driver needs to change the parent of sclk_hdmi clock to
sclk_pixel or to sclk_hdmiphy, depends on the status of hdmiphy.
sclk_hdmi which is gate clock doesn't support the set_parent
operation.
Wouldn't it be better to simply allow calling clk_set_parent() on gate
clocks and propagate parent change to nearest mux, just like it is done
with clk_set_rate()?
Sorry, I din't get you completly here. Allowing clk_set_parent() on gate
clocks is like changing the inherent property of the gate clock. I dont see
it possible without overiding the default gate_ops (clk_gate_ops). Please
cite me the code/patch doing the same for clk_set_rate.
What I did here is rather simple and utilising the exisiting composite clock
framework for exynos (as well). I register comp. clock with default
gate/mux/rate operations. No customised clk type /ops in this patch.
It wouldn't require any SoC-specific composite clocks and keep the nice
property of the clock tree, which is built from basic, generic clock
blocks that nicely correspond to blocks shown in the documentation.
We had discussed this already at SRPOL and got to the conclusion that it's
a step backwards, making the clock driver more complex, because each
composite block would have to be described using a structure with many
I respectfully disagree with above. If we adhere to generic composite
clocks (in drivers/clk/clk-composite.c) we donot need to add different
struct for different blocks. I have further restricted the ops overriding in
drivers/clk/samsung/clk.c. Please refer the previous patch.
fields. In addition there are many special cases, for which the composite
scheme wouldn't work anyway and they would end up with simple clocks
attached after the composite block, defeating the purpose of your patch.
Purpose of the patch is to avoid spilling complextiy of clk path/block to
all over the drivers. Just for instance hdmi/fimd needs 2 extra mux clocks
and 1 divider clock for set_parent and set_rate operations (other than
gating operation) which was not required before CCF and still avoidable.
I am sure, there will be many more similar cases. This list of exposed
clock IDs will keep explanding when all drivers migrate to CCF.
We have to take a call on this.
regards,
Rahul Sharma.
Best regards,
Tomasz
This patch adds sclk_hdmi as a composite clock which is a
combination of mux clock and gate clock. Being a composite
clock, above clock supports both set_parent and enable/disable
functionality. Therefore hdmi driver need not be modified
different S0Cs. This will handled inside CCF.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/clk/samsung/clk-exynos5250.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c index 5c97e75..0c9e37a 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -231,7 +231,6 @@ struct samsung_mux_clock exynos5250_mux_clks[]
__initdata = { MUX(none, mout_fimd1, mout_group1_p, SRC_DISP1_0, 0,
4),
MUX(none, mout_mipi1, mout_group1_p, SRC_DISP1_0, 12, 4),
MUX(none, mout_dp, mout_group1_p, SRC_DISP1_0, 16, 4),
- MUX(none, mout_hdmi, mout_hdmi_p, SRC_DISP1_0, 20, 1),
MUX(none, mout_audio0, mout_audio0_p, SRC_MAU, 0, 4),
MUX(none, mout_mmc0, mout_group1_p, SRC_FSYS, 0, 4),
MUX(none, mout_mmc1, mout_group1_p, SRC_FSYS, 4, 4),
@@ -416,8 +415,6 @@ struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = { SRC_MASK_DISP1_0, 12, CLK_SET_RATE_PARENT, 0),
GATE(sclk_dp, sclk_dp, div_dp,
SRC_MASK_DISP1_0, 16, CLK_SET_RATE_PARENT, 0),
- GATE(sclk_hdmi, sclk_hdmi, mout_hdmi,
- SRC_MASK_DISP1_0, 20, 0, 0),
GATE(sclk_audio0, sclk_audio0, div_audio0,
SRC_MASK_MAU, 0, CLK_SET_RATE_PARENT, 0),
GATE(sclk_mmc0, sclk_mmc0, div_mmc_pre0,
@@ -464,6 +461,21 @@ struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = { GATE(hdmi, hdmi, aclk200, GATE_IP_DISP1, 6, 0, 0),
};
+struct samsung_composite_clock exynos5250_composite_clks[] __initdata =
{ + {
+ .id = sclk_hdmi,
+ .name = sclk_hdmi,
+ .parent_names = mout_hdmi_p,
+ .num_parents = ARRAY_SIZE(mout_hdmi_p),
+ .mux_clk = MUX(none, NULL, mout_hdmi_p, SRC_DISP1_0, 20,
+ 1),
+ .gate_clk = GATE(none, NULL, NULL, SRC_MASK_DISP1_0, 20,
+ 0, 0),
+ .composition_flags = SAMSUNG_CLK_TYPE_GATE |
+ SAMSUNG_CLK_TYPE_MUX,
+ },
+};
+
static __initdata struct of_device_id ext_clk_match[] = {
{ .compatible = samsung,clock-xxti, .data = (void *)0, },
Re: [PATCH v6 0/9] Generic PHY Framework
Hi, On Monday 29 April 2013 03:33 PM, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on linux-next tree. Any comments on this patch series? Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 09/10] ARM: Kirkwood: Add dts files for Sheevaplug and eSATA Sheevaplug
On Tue, May 21, 2013 at 01:01:50AM +0200, Simon Baatz wrote:
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
arch/arm/boot/dts/Makefile|2 +
arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi | 97
+
arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts | 40 +
arch/arm/boot/dts/kirkwood-sheevaplug.dts | 45 ++
4 files changed, 184 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9f7121..e81a387 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -84,6 +84,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
kirkwood-ns2max.dtb \
kirkwood-ns2mini.dtb \
kirkwood-nsa310.dtb \
+ kirkwood-sheevaplug.dtb \
+ kirkwood-sheevaplug-esata.dtb \
kirkwood-topkick.dtb \
kirkwood-ts219-6281.dtb \
kirkwood-ts219-6282.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
new file mode 100644
index 000..9d59475
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
@@ -0,0 +1,97 @@
+/*
+ * kirkwood-sheevaplug-common.dts - Common parts for Sheevaplugs
+ *
+ * Copyright (C) 2013 Simon Baatz gmbno...@gmail.com
+ *
+ * Licensed under GPLv2
+ */
+
+/include/ kirkwood.dtsi
+/include/ kirkwood-6281.dtsi
+
+/ {
+ memory {
+ device_type = memory;
+ reg = 0x 0x2000;
+ };
+
+ chosen {
+ bootargs = console=ttyS0,115200n8 earlyprintk;
+ };
+
+ ocp@f100 {
+ pinctrl: pinctrl@1 {
+
+ pmx_usb_power_enable: pmx-usb-power-enable {
+ marvell,pins = mpp29;
+ marvell,function = gpio;
+ };
+ pmx_led_red: pmx-led-red {
+ marvell,pins = mpp46;
+ marvell,function = gpio;
+ };
+ pmx_led_blue: pmx-led-blue {
+ marvell,pins = mpp49;
+ marvell,function = gpio;
+ };
+ pmx_sdio_cd: pmx-sdio-cd {
+ marvell,pins = mpp44;
+ marvell,function = gpio;
+ };
+ pmx_sdio_wp: pmx-sdio-wp {
+ marvell,pins = mpp47;
+ marvell,function = gpio;
+ };
+ };
+ serial@12000 {
+ status = okay;
+ };
+
+ nand@300 {
+ status = okay;
+
+ partition@0 {
+ label = u-boot;
+ reg = 0x000 0x10;
+ };
+
+ partition@10 {
+ label = uImage;
+ reg = 0x010 0x40;
+ };
+
+ partition@50 {
+ label = root;
+ reg = 0x050 0x1fb0;
+ };
+ };
+ };
+
+ regulators {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ usb_power: regulator@1 {
+ compatible = regulator-fixed;
+ reg = 1;
+ regulator-name = USB Power;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ enable-active-high;
+ regulator-always-on;
+ regulator-boot-on;
+ gpio = gpio0 29 0;
+ };
+ };
+
+ gpio-leds {
+ compatible = gpio-leds;
+
+ health {
+ label = sheevaplug:blue:health;
+ gpios = gpio1 17 1;
+ linux,default-trigger = default-on;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
b/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
new file mode 100644
index 000..1c6946a
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
@@ -0,0 +1,40 @@
+/*
+ * kirkwood-sheevaplug-esata.dts - Device tree file for eSATA Sheevaplug
+ *
+ * Copyright (C) 2013 Simon Baatz gmbno...@gmail.com
+ *
+ * Licensed under GPLv2
+ */
+
+/dts-v1/;
+
+/include/ kirkwood-sheevaplug-common.dtsi
+
+/ {
+ model = Globalscale
Re: [PATCH V3 10/10] ARM: Kirkwood: add DT support for Sheevaplug and Sheevaplug eSATA
On Tue, May 21, 2013 at 01:01:51AM +0200, Simon Baatz wrote:
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
arch/arm/mach-kirkwood/Kconfig|7 +++
arch/arm/mach-kirkwood/Makefile |1 +
arch/arm/mach-kirkwood/board-dt.c |4
arch/arm/mach-kirkwood/board-sheevaplug.c | 27 +++
arch/arm/mach-kirkwood/common.h |5 +
5 files changed, 44 insertions(+)
create mode 100644 arch/arm/mach-kirkwood/board-sheevaplug.c
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 7509a89..58518a2 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -296,6 +296,13 @@ config MACH_READYNAS_DT
Say 'Y' here if you want your kernel to support the
NETGEAR ReadyNAS Duo v2 using Fattened Device Tree.
+config MACH_SHEEVAPLUG_DT
+ bool Marvell (eSATA) SheevaPlug (Flattened Device Tree)
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the
+ Marvell (eSATA) SheevaPlug (Flattened Device Tree).
+
config MACH_TOPKICK_DT
bool USI Topkick (Flattened Device Tree)
select ARCH_KIRKWOOD_DT
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index e1f3735..8846abf 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -40,5 +40,6 @@ obj-$(CONFIG_MACH_NETSPACE_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NSA310_DT) += board-nsa310.o
obj-$(CONFIG_MACH_OPENBLOCKS_A6_DT) += board-openblocks_a6.o
obj-$(CONFIG_MACH_READYNAS_DT) += board-readynas.o
+obj-$(CONFIG_MACH_SHEEVAPLUG_DT) += board-sheevaplug.o
obj-$(CONFIG_MACH_TOPKICK_DT)+= board-usi_topkick.o
obj-$(CONFIG_MACH_TS219_DT) += board-ts219.o tsx1x-common.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c
b/arch/arm/mach-kirkwood/board-dt.c
index e9647b8..a09dbac 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -112,6 +112,9 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible(globalscale,guruplug))
guruplug_dt_init();
+ if (of_machine_is_compatible(globalscale,sheevaplug))
+ sheevaplug_dt_init();
+
if (of_machine_is_compatible(dlink,dns-kirkwood))
dnskw_init();
@@ -165,6 +168,7 @@ static void __init kirkwood_dt_init(void)
static const char * const kirkwood_dt_board_compat[] = {
globalscale,dreamplug,
globalscale,guruplug,
+ globalscale,sheevaplug,
dlink,dns-320,
dlink,dns-325,
iom,iconnect,
diff --git a/arch/arm/mach-kirkwood/board-sheevaplug.c
b/arch/arm/mach-kirkwood/board-sheevaplug.c
new file mode 100644
index 000..fa38937
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-sheevaplug.c
@@ -0,0 +1,27 @@
+/*
+ * arch/arm/mach-kirkwood/board-sheevaplug.c
+ *
+ * Marvell Sheevaplug Reference Board Init for drivers not converted to
+ * flattened device tree yet.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/mv643xx_eth.h
+#include common.h
+
+static struct mv643xx_eth_platform_data sheevaplug_ge00_data = {
+ .phy_addr = MV643XX_ETH_PHY_ADDR(0),
+};
+
+void __init sheevaplug_dt_init(void)
+{
+ /*
+ * Basic setup. Needs to be called early.
+ */
+ kirkwood_ge00_init(sheevaplug_ge00_data);
+}
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 21da3b1..974442e 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -65,6 +65,11 @@ void guruplug_dt_init(void);
#else
static inline void guruplug_dt_init(void) {};
#endif
+#ifdef CONFIG_MACH_SHEEVAPLUG_DT
+void sheevaplug_dt_init(void);
+#else
+static inline void sheevaplug_dt_init(void) {};
+#endif
#ifdef CONFIG_MACH_TS219_DT
void qnap_dt_ts219_init(void);
#else
--
1.7.9.5
Acked-by: Andrew Lunn and...@lunn.ch
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/6] drivers: bus: add a new driver for WEIM
On Mon, May 20, 2013 at 04:48:57PM +0800, Huang Shijie wrote:
The WEIM(Wireless External Interface Module) works like a bus.
You can attach many different devices on it, such as NOR, onenand.
In the case of i.MX6q-sabreauto, the NOR is connected to WEIM.
This patch also adds the devicetree binding document.
The driver only works when the devicetree is enabled.
Signed-off-by: Huang Shijie b32...@freescale.com
---
Documentation/devicetree/bindings/bus/imx-weim.txt | 69 +
drivers/bus/Kconfig|9 ++
drivers/bus/Makefile |1 +
drivers/bus/imx-weim.c | 145
4 files changed, 224 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/imx-weim.txt
create mode 100644 drivers/bus/imx-weim.c
diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt
b/Documentation/devicetree/bindings/bus/imx-weim.txt
new file mode 100644
index 000..9913454
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/imx-weim.txt
@@ -0,0 +1,69 @@
+Device tree bindings for i.MX Wireless External Interface Module (WEIM)
+
+The term ???wireless??? does not imply that the WEIM is literally an
interface
wireless
+without wires. It simply means that this module was originally designed for
+wireless and mobile applications that use low-power technology.
+
+The actual devices are instantiated from the child nodes of a WEIM node.
+But now we only have the NOR device.
+
+NOR flash connected to the WEIM (found on i.MX boards) are represented as
+child nodes with a name of nor.
I doubt that WEIM should care the particular device type connected on
it.
+
+Required properties:
+
+ - compatible: Should be set to fsl, imx6q-weim
Drop the space in middle of compatible string.
+ - reg: A resource specifier for the register space
+ (see the example below)
+ - interrupts: the interrupt number, see the example below.
+ - clocks: the clock, see the example below.
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells: Must be set to 1 to allow CS address passing
+ - ranges: Must be set up to reflect the memory layout with four
+ integer values for each chip-select line in use:
+
+cs-number 0 physical address of mapping size
+
+Timing properties for child nodes. All are mandatory, not optional.
+
+ -weim-cs-index: The CS index which the device is attaching on.
It seems we can find it out from reg property, so that we can save
this property?
+ -weim-cs-timing:The timing array, contains 6 timing values for the
+ weim-cs-index.
This is a vendor specific property, and should have a vendor (fsl)
perfix. Also please put a space after the first - which acts as
a bullet symbol here.
+
+Example for an i.MX6q-sabreauto board:
You can write it as i.MX6Q SABRE Auto or imx6q-sabreauto.
+ weim: weim@021b8000 {
+ compatible = fsl,imx6q-weim;
+ reg = 0x021b8000 0x4000;
+ interrupts = 0 14 0x04;
+ clocks = clks 196;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x0800;
+
+ nor@0,0 {
+ compatible = cfi-flash;
+ reg = 0 0 0x0200;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 2;
+
+ weim-cs-index = 0;
+ weim-cs-timing = 0x00620081 0x0001 0x1C022000
+ 0xC000 0x1404a38e 0x;
+ partition@0 {
+ label = U-Boot;
+ reg = 0x0 0x4;
+ };
+
+ partition@4 {
+ label = U-Boot-ENV;
+ reg = 0x4 0x1;
+ read-only;
+ };
+
+ partition@5 {
+ label = Kernel;
+ reg = 0x5 0x3b;
+ };
+ };
+ };
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index b05ecab..0f997af 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -4,6 +4,15 @@
menu Bus devices
+config IMX_WEIM
+ tristate Freescale EIM DRIVER
+ depends on ARCH_MXC MTD_PHYSMAP_OF
I do not see how this driver depends on MTD_PHYSMAP_OF.
+ help
+ Driver for i.MX6 WEIM controller.
+ The WEIM(Wireless External Interface Module) works like a bus.
+ You can attach many different devices on it, such as NOR, onenand.
+
Re: [PATCH 2/6] ARM: dts: imx6q{dl}: fix the pin conflict between SPI and WEIM
On Mon, May 20, 2013 at 04:48:58PM +0800, Huang Shijie wrote:
In the imx6q-sabreauto and imx6dl-sabreauto boards,
the pin MX6Q{DL}_PAD_EIM_D19 is used as a GPIO for SPI NOR, but
it is used as a data pin for the WEIM NOR.
In order to fix the conflict, this patch removes the pin from the hog,
and adds a new pinctrl item: pinctrl_ecspi1_2.
The SPI NOR selects this pinctrl_ecspi1_2 when it is enabled.
Signed-off-by: Huang Shijie b32...@freescale.com
---
arch/arm/boot/dts/imx6dl-sabreauto.dts |9 -
arch/arm/boot/dts/imx6q-sabreauto.dts|9 -
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi |2 +-
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-sabreauto.dts
b/arch/arm/boot/dts/imx6dl-sabreauto.dts
index 60f3038..7695f70 100644
--- a/arch/arm/boot/dts/imx6dl-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6dl-sabreauto.dts
@@ -25,7 +25,14 @@
fsl,pins =
MX6DL_PAD_NANDF_CS2__GPIO6_IO15 0x8000
MX6DL_PAD_SD2_DAT2__GPIO1_IO13 0x8000
- MX6DL_PAD_EIM_D19__GPIO3_IO19 0x8000
+ ;
+ };
+ };
+
+ ecspi1 {
+ pinctrl_ecspi1_2: ecspi1grp-2 {
The naming sounds like another ecspi1 pin groups beside
pinctrl_ecspi1_1, both of which should be ecspi1 pin groups defined by
SoC. Please encode the board name in there to suggest this is a board
specific pin setup for ecspi1, something like pinctrl_ecspi1_sabreauto.
Shawn
+ fsl,pins =
+ MX6DL_PAD_EIM_D19__GPIO3_IO19 0x8000
;
};
};
diff --git a/arch/arm/boot/dts/imx6q-sabreauto.dts
b/arch/arm/boot/dts/imx6q-sabreauto.dts
index 9fb3e99..67a3a6b 100644
--- a/arch/arm/boot/dts/imx6q-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6q-sabreauto.dts
@@ -29,7 +29,14 @@
fsl,pins =
MX6Q_PAD_NANDF_CS2__GPIO6_IO15 0x8000
MX6Q_PAD_SD2_DAT2__GPIO1_IO13 0x8000
- MX6Q_PAD_EIM_D19__GPIO3_IO19 0x8000
+ ;
+ };
+ };
+
+ ecspi1 {
+ pinctrl_ecspi1_2: ecspi1grp-2 {
+ fsl,pins =
+ MX6Q_PAD_EIM_D19__GPIO3_IO19 0x8000
;
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index d6baa51..eb293f5 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -20,7 +20,7 @@
fsl,spi-num-chipselects = 1;
cs-gpios = gpio3 19 0;
pinctrl-names = default;
- pinctrl-0 = pinctrl_ecspi1_1;
+ pinctrl-0 = pinctrl_ecspi1_1 pinctrl_ecspi1_2;
status = disabled; /* pin conflict with WEIM NOR */
flash: m25p80@0 {
--
1.7.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/6] ARM: dts: imx6q{dl}: fix the pin conflict between SPI and WEIM
于 2013年05月21日 13:49, Shawn Guo 写道: specific pin setup for ecspi1, something like pinctrl_ecspi1_sabreauto. ok. thanks Huang Shijie ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
