Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems
On Wed, Mar 13, 2013 at 04:21:02PM -0600, Jason Gunthorpe wrote: On Wed, Mar 13, 2013 at 11:02:35PM +0100, Thierry Reding wrote: Does that look about correct? By my reading of the spec the entries in ranges should not have the b,d,f bits set.. Although it is not a big stretch to include them.. Now the code will actually match the first entry and assume that it represents the non-prefetchable 32-bit memory space and program the controller to forward accesses to the 0x8000-0x8fff region as PCI memory write transactions. Yah, it makes a mess of determining the host bridge aperture. Require the aperture to be first/last? Make use of the 2nd dword? Go back to the idea of the top level reg? It turns out that this works with the Tegra driver because it uses the new of_pci_process_ranges() function and simply overwrites earlier matches by subsequent ones. ranges = 0x8200 0 0 0x8000 0 0x1000 /* port 0 registers */ 0x8200 0 0 0x80001000 0 0x1000 /* port 1 registers */ 0x8100 0 0 0x8200 0 0x0001 /* downstream I/O */ 0x8200 0 0 0xa000 0 0x1000 /* non-prefetchable memory */ 0xc200 0 0 0xb000 0 0x1000; /* prefetchable memory */ So the second entry would overwrite the non-prefetchable memory region as established by the first entry. Finally that will also be overwritten by the fourth entry. So the above will actually work along with the corresponding root-port assigned-addresses properties. I still don't like it much because I don't think it accurately reflects the hardware. Furthermore it has the same kludgy, non-spec conformant smack that my original proposal had because it uses assigned-addresses for something it wasn't intended to. Also the mapping is actually not correct, because the first two entries don't refer to 32-bit memory space. They really map configuration space and therefore the ss field is wrong IMO (it should be 00, but that won't work with the OF core). One of the very early versions of my Tegra PCIe patch series actually introduced an IORESOURCE_CS type to account for this but it didn't go anywhere and became obsolete when I switched to the new binding which side-steps this issue by not using the PCI bus' translation mechanism. Thierry pgpIPC8wnlsyU.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V7 1/2] ARM: bcm281xx: Add timer driver (driver portion)
On Wed, 13 Mar 2013, John Stultz wrote:
On 03/13/2013 02:27 PM, Christian Daudt wrote:
This adds support for the Broadcom timer, used in the following SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
[snip]
Signed-off-by: Christian Daudt c...@broadcom.com
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: John Stultz john.stu...@linaro.org
Reviewed-by: Stephen Warren swar...@nvidia.com
Hey Olof,
So Christian mentioned you were hoping I'd pull these in through my tree,
but I'd really rather these go via the arch-soc tree, since that is more
likely where they will be tested and more intelligently reviewed.
I've mentioned before my distaste for the drivers/clocksource directory
becoming a dumping ground for arch specific (for the most part arm)
clocksource, and more recently clockevent, drivers. I initially wanted the
OTOH, if they are all in one place we have a better chance to analyze
them in bulk, find similarities and patterns for consolidation. And
it's simpler for the developer of a new SoC support to find the
matching driver for his IP block instead of copying stuff from one
mach directory to the next. We've been there :)
But I'd really rather the patch flow for arch specific clocksource and
clockevent drivers go through the arch tree, since there's a better chance
folks will be building and testing against other arch specific changes that
might cause problems. There's just no way for me to be able to intelligently
review these sorts of changes.
I agree with the build and test part, but you can still review the
code in general - correctness of the particular hw details aside. I
just opened a random one there and found:
static cycle_t vt8500_timer_read(struct clocksource *cs)
{
int loops = msecs_to_loops(10);
writel(3, regbase + TIMER_CTRL_VAL);
while ((readl((regbase + TIMER_AS_VAL)) TIMER_COUNT_R_ACTIVE)
--loops)
cpu_relax();
return readl(regbase + TIMER_COUNT_VAL);
You don't need particular hw knowledge to see that this looks more
than fishy at least without comments describing the hardware designers
brainfart.
Now, if there are changes to the clocksource core code, then I definitely want
to be in the path there. Additionally meta-drivers like mmio, I should
probably be more involved with, so they can be more properly integrated into
the clocksource core. Also for drivers that are actually arch shared (ie:
things like hpet/acpi_pm where ia64 and x86 share them).
But if its arch specific for hardware I don't have, I'd really prefer the arch
maintainer be the upstream path.
Thomas: Am I being too obstinate here? If not, should we drop F:
drivers/clocksource from the MAINTAINERS entry?
Maybe we should move the ARM specific ones into
drivers/clocksource/arm/ ?
Thanks,
tglx
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/5] spi/davinci: add DT binding documentation
On 3/12/2013 1:40 PM, Manjunathappa, Prakash wrote:
From: Murali Karicheri m-kariche...@ti.com
Get back missed out binding documentation submitted along
with below patch:
spi/davinci: add OF support for the spi controller
This is not really the correct description of this patch. Years later
its mostly irrelevant that binding documentation did not get applied
along with the actual usage.
[prakash...@ti.com: Follow DT naming convention for compatible property]
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Manjunathappa, Prakash prakash...@ti.com
---
.../devicetree/bindings/spi/spi-davinci.txt| 51
1 files changed, 51 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/spi-davinci.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt
b/Documentation/devicetree/bindings/spi/spi-davinci.txt
new file mode 100644
index 000..75ad9ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt
@@ -0,0 +1,51 @@
+Davinci SPI controller device bindings
+
+Required properties:
+- #address-cells: number of cells required to define a chip select
+ address on the SPI bus. Should be set to 1.
+- #size-cells: should be zero.
+- compatible:
+ - ti,dm6441-spi for SPI used similar to that on DM644x SoC family
+ - ti,da830-spi for SPI used similar to that on DA8xx SoC family
+- reg: Offset and length of SPI controller register space
+- num-cs: Number of chip selects
+- ti,davinci-spi-intr-line: interrupt line used to connect the SPI
+ IP to the interrupt controller withn the SoC. Possible values
+ are 0 and 1. Manual says one of the two possible interrupt
+ lines can be tied to the interrupt controller. Set this
+ based on a specifc SoC configuration.
+- interrupts: interrupt number mapped to CPU.
+- clocks: spi clk phandle
+
+Example of a NOR flash slave device (n25q032) connected to DaVinci
+SPI controller device over the SPI bus.
+
+spi0:spi@20BF {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = ti,dm6446-spi;
+ reg = 0x20BF 0x1000;
+ num-cs = 4;
+ ti,davinci-spi-intr-line= 0;
+ interrupts = 338;
+ clocks = clkspi;
+
+ flash: n25q032@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = st,m25p32;
+ spi-max-frequency = 2500;
+ reg = 0;
+
+ partition@0 {
+ label = u-boot-spl;
+ reg = 0x0 0x8;
+ read-only;
+ };
+
+ partition@1 {
+ label = test;
+ reg = 0x8 0x38;
+ };
+ };
Looks like the tabs were messed up when you took Murali's patch.
Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
GPIO polarity in bindings for Freescale MXS
Hello, Maybe I'm missing something but the MXS processors (at least i.MX23 and i.MX28) cannot set the polarity of the GPIOs, so shouldn't the #gpio-cells be 1? (From Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt): - #gpio-cells : Should be two. The first cell is the pin number and the second cell is used to specify the gpio polarity: 0 = active high 1 = active low Regards, -- Héctor Palacios ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v3 2/5] spi/davinci: add DT binding documentation
Hi Sekhar,
On Thu, Mar 14, 2013 at 14:46:54, Nori, Sekhar wrote:
On 3/12/2013 1:40 PM, Manjunathappa, Prakash wrote:
From: Murali Karicheri m-kariche...@ti.com
Get back missed out binding documentation submitted along
with below patch:
spi/davinci: add OF support for the spi controller
This is not really the correct description of this patch. Years later
its mostly irrelevant that binding documentation did not get applied
along with the actual usage.
Agreed, I will change the commit message. This could have been below
scissors lines
[prakash...@ti.com: Follow DT naming convention for compatible property]
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Manjunathappa, Prakash prakash...@ti.com
---
.../devicetree/bindings/spi/spi-davinci.txt| 51
1 files changed, 51 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/spi-davinci.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt
b/Documentation/devicetree/bindings/spi/spi-davinci.txt
new file mode 100644
index 000..75ad9ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt
@@ -0,0 +1,51 @@
+Davinci SPI controller device bindings
+
+Required properties:
+- #address-cells: number of cells required to define a chip select
+ address on the SPI bus. Should be set to 1.
+- #size-cells: should be zero.
+- compatible:
+ - ti,dm6441-spi for SPI used similar to that on DM644x SoC family
+ - ti,da830-spi for SPI used similar to that on DA8xx SoC family
+- reg: Offset and length of SPI controller register space
+- num-cs: Number of chip selects
+- ti,davinci-spi-intr-line: interrupt line used to connect the SPI
+ IP to the interrupt controller withn the SoC. Possible values
+ are 0 and 1. Manual says one of the two possible interrupt
+ lines can be tied to the interrupt controller. Set this
+ based on a specifc SoC configuration.
+- interrupts: interrupt number mapped to CPU.
+- clocks: spi clk phandle
+
+Example of a NOR flash slave device (n25q032) connected to DaVinci
+SPI controller device over the SPI bus.
+
+spi0:spi@20BF {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = ti,dm6446-spi;
+ reg = 0x20BF 0x1000;
+ num-cs = 4;
+ ti,davinci-spi-intr-line= 0;
+ interrupts = 338;
+ clocks = clkspi;
+
+ flash: n25q032@0 {
+#address-cells = 1;
+#size-cells = 1;
+compatible = st,m25p32;
+spi-max-frequency = 2500;
+reg = 0;
+
+partition@0 {
+label = u-boot-spl;
+reg = 0x0 0x8;
+read-only;
+};
+
+partition@1 {
+label = test;
+reg = 0x8 0x38;
+};
+ };
Looks like the tabs were messed up when you took Murali's patch.
Ok I will fix this.
Thanks,
Prakash
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/5] Enable SPI flash support on da850-evm DT kernel
On 3/12/2013 1:40 PM, Manjunathappa, Prakash wrote: Patch enables support for m25p64 SPI flash support on da850-EVM. This patch set looks good to me except the comments I had on 2/5. I tested it using SPI flash on DA850 EVM and it worked fine on basic read/write tests. Grant, With your ack I would like to merge the series through DaVinci tree so its easy to manage the conflicts in DT files. Testing information: da850-evm comes with partitions specified in DT blob. Able to mount/umount and create/delete files on filesystem partition. Depends on below patch in spi-next branch of git://git.secretlab.ca/git/linux-2.6.git. spi/davinci: add OF support for the spi controller Prakash, there is no need to mention this dependency. The patch is already in mainline. Thanks, Sekhar ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 0/2] Adding USB 3.0 DRD-phy support for exynos5250
Changes from v6: - Changing the file names accordingly as per [PATCH] usb: phy: rename all phy drivers to phy-$name.c - Using devm_clk_get for PHY ref clocks ext_xtal and xusbxti - Adding the bindings documentation for separate USB 2.0 phy and USB 3.0 phy. Based on 'usb-next' plus Felipe's 'testing' branch patches; (some 194 patches in fact ;-), on top of 3.9rc2 tag). Tested after merging linux-samsung's 'for-next' into 'usb-next' to verify things with recently merged common clock framework for samsung's SoCs. Vivek Gautam (2): usb: phy: samsung: Common out the generic stuff usb: phy: samsung: Add PHY support for USB 3.0 controller .../devicetree/bindings/usb/samsung-usbphy.txt | 76 ++- drivers/usb/phy/Kconfig| 22 +- drivers/usb/phy/Makefile |2 + drivers/usb/phy/phy-samsung-usb.c | 726 +--- drivers/usb/phy/phy-samsung-usb.h | 327 + drivers/usb/phy/phy-samsung-usb2.c | 509 ++ drivers/usb/phy/phy-samsung-usb3.c | 349 ++ 7 files changed, 1291 insertions(+), 720 deletions(-) create mode 100644 drivers/usb/phy/phy-samsung-usb.h create mode 100644 drivers/usb/phy/phy-samsung-usb2.c create mode 100644 drivers/usb/phy/phy-samsung-usb3.c -- 1.7.6.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 1/2] usb: phy: samsung: Common out the generic stuff
Moving register and structure definitions to header file,
and keeping the generic functions to be used across
multiple PHYs in common phy helper driver under SAMSUNG_USBPHY,
and moving USB 2.0 PHY driver under SAMSUNG_USB2PHY.
Also allowing samsung PHY drivers be built as modules.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Signed-off-by: Felipe Balbi ba...@ti.com
Acked-by: Kukjin Kim kgene@samsung.com
---
.../devicetree/bindings/usb/samsung-usbphy.txt | 22 +-
drivers/usb/phy/Kconfig| 15 +-
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/phy-samsung-usb.c | 726 +---
drivers/usb/phy/phy-samsung-usb.h | 247 +++
drivers/usb/phy/phy-samsung-usb2.c | 509 ++
6 files changed, 800 insertions(+), 720 deletions(-)
create mode 100644 drivers/usb/phy/phy-samsung-usb.h
create mode 100644 drivers/usb/phy/phy-samsung-usb2.c
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
index 0331949..96940ab 100644
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -1,20 +1,25 @@
-* Samsung's usb phy transceiver
+SAMSUNG USB-PHY controllers
-The Samsung's phy transceiver is used for controlling usb phy for
-s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers
-across Samsung SOCs.
+** Samsung's usb 2.0 phy transceiver
+
+The Samsung's usb 2.0 phy transceiver is used for controlling
+usb 2.0 phy for s3c-hsotg as well as ehci-s5p and ohci-exynos
+usb controllers across Samsung SOCs.
TODO: Adding the PHY binding with controller(s) according to the under
developement generic PHY driver.
Required properties:
Exynos4210:
-- compatible : should be samsung,exynos4210-usbphy
+- compatible : should be samsung,exynos4210-usb2phy
- reg : base physical address of the phy registers and length of memory mapped
region.
+- clocks: Clock IDs array as required by the controller.
+- clock-names: names of clock correseponding IDs clock property as requested
+ by the controller driver.
Exynos5250:
-- compatible : should be samsung,exynos5250-usbphy
+- compatible : should be samsung,exynos5250-usb2phy
- reg : base physical address of the phy registers and length of memory mapped
region.
@@ -44,10 +49,13 @@ Example:
usbphy@125B {
#address-cells = 1;
#size-cells = 1;
- compatible = samsung,exynos4210-usbphy;
+ compatible = samsung,exynos4210-usb2phy;
reg = 0x125B 0x100;
ranges;
+ clocks = clock 2, clock 305;
+ clock-names = xusbxti, otg;
+
usbphy-sys {
/* USB device and host PHY_CONTROL registers */
reg = 0x10020704 0x8;
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 97de6de..e8cd52a 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -86,11 +86,18 @@ config OMAP_USB3
on/off the PHY.
config SAMSUNG_USBPHY
- bool Samsung USB PHY controller Driver
- depends on USB_S3C_HSOTG || USB_EHCI_S5P || USB_OHCI_EXYNOS
+ tristate Samsung USB PHY Driver
help
- Enable this to support Samsung USB phy controller for samsung
- SoCs.
+ Enable this to support Samsung USB phy helper driver for Samsung SoCs.
+ This driver provides common interface to interact, for Samsung USB
2.0 PHY
+ driver and later for Samsung USB 3.0 PHY driver.
+
+config SAMSUNG_USB2PHY
+ tristate Samsung USB 2.0 PHY controller Driver
+ select SAMSUNG_USBPHY
+ help
+ Enable this to support Samsung USB 2.0 (High Speed) PHY controller
+ driver for Samsung SoCs.
config TWL4030_USB
tristate TWL4030 USB Transceiver Driver
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 5fb4a5d..8cd355f 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_OMAP_CONTROL_USB)+=
phy-omap-control.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_OMAP_USB3)+= phy-omap-usb3.o
obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o
+obj-$(CONFIG_SAMSUNG_USB2PHY) += phy-samsung-usb2.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += phy-twl6030-usb.o
obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
diff --git a/drivers/usb/phy/phy-samsung-usb.c
b/drivers/usb/phy/phy-samsung-usb.c
index 967101e..7b118ee5 100644
--- a/drivers/usb/phy/phy-samsung-usb.c
+++ b/drivers/usb/phy/phy-samsung-usb.c
@@ -1,12 +1,13 @@
-/* linux/drivers/usb/phy/samsung-usbphy.c
+/*
[PATCH v7 2/2] usb: phy: samsung: Add PHY support for USB 3.0 controller
Adding PHY driver support for USB 3.0 controller for Samsung's
SoCs.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Signed-off-by: Felipe Balbi ba...@ti.com
Acked-by: Kukjin Kim kgene@samsung.com
---
.../devicetree/bindings/usb/samsung-usbphy.txt | 54 +++
drivers/usb/phy/Kconfig|7 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/phy-samsung-usb.h | 80 +
drivers/usb/phy/phy-samsung-usb3.c | 349
5 files changed, 491 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/phy/phy-samsung-usb3.c
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
index 96940ab..f575302 100644
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -61,3 +61,57 @@ Example:
reg = 0x10020704 0x8;
};
};
+
+
+** Samsung's usb 3.0 phy transceiver
+
+Starting exynso5250, Samsung's SoC have usb 3.0 phy transceiver
+which is used for controlling usb 3.0 phy for dwc3-exynos usb 3.0
+controllers across Samsung SOCs.
+
+Required properties:
+
+Exynos5250:
+- compatible : should be samsung,exynos5250-usb3phy
+- reg : base physical address of the phy registers and length of memory mapped
+ region.
+- clocks: Clock IDs array as required by the controller.
+- clock-names: names of clocks correseponding to IDs in the clock property
+ as requested by the controller driver.
+
+Optional properties:
+- #address-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- #size-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- ranges: allows valid translation between child's address space and parent's
+ address space.
+
+- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
+ interface for usb-phy. It should provide the following information required
by
+ usb-phy controller to control phy.
+ - reg : base physical address of PHY_CONTROL registers.
+ The size of this register is the total sum of size of all PHY_CONTROL
+ registers that the SoC has. For example, the size will be
+ '0x4' in case we have only one PHY_CONTROL register (e.g.
+ OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210)
+ and, '0x8' in case we have two PHY_CONTROL registers (e.g.
+ USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x).
+ and so on.
+
+Example:
+ usbphy@1210 {
+ compatible = samsung,exynos5250-usb3phy;
+ reg = 0x1210 0x100;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ clocks = clock 1, clock 286;
+ clock-names = ext_xtal, usbdrd30;
+
+ usbphy-sys {
+ /* USB device and host PHY_CONTROL registers */
+ reg = 0x10040704 0x8;
+ };
+ };
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index e8cd52a..7e8fe0f 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -99,6 +99,13 @@ config SAMSUNG_USB2PHY
Enable this to support Samsung USB 2.0 (High Speed) PHY controller
driver for Samsung SoCs.
+config SAMSUNG_USB3PHY
+ tristate Samsung USB 3.0 PHY controller Driver
+ select SAMSUNG_USBPHY
+ help
+ Enable this to support Samsung USB 3.0 (Super Speed) phy controller
+ for samsung SoCs.
+
config TWL4030_USB
tristate TWL4030 USB Transceiver Driver
depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 8cd355f..33863c0 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_OMAP_USB2) +=
phy-omap-usb2.o
obj-$(CONFIG_OMAP_USB3)+= phy-omap-usb3.o
obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o
obj-$(CONFIG_SAMSUNG_USB2PHY) += phy-samsung-usb2.o
+obj-$(CONFIG_SAMSUNG_USB3PHY) += phy-samsung-usb3.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += phy-twl6030-usb.o
obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
diff --git a/drivers/usb/phy/phy-samsung-usb.h
b/drivers/usb/phy/phy-samsung-usb.h
index 481737d7..70a9cae 100644
--- a/drivers/usb/phy/phy-samsung-usb.h
+++ b/drivers/usb/phy/phy-samsung-usb.h
@@ -145,6 +145,86 @@
#define EXYNOS5_PHY_OTG_TUNE (0x40)
+/* EXYNOS5: USB 3.0 DRD */
+#define EXYNOS5_DRD_LINKSYSTEM (0x04)
+
+#define LINKSYSTEM_FLADJ_MASK (0x3f 1)
+#define LINKSYSTEM_FLADJ(_x)
[PATCH 0/3] Davinci support for EHRPWM ECAP
This patch series enables EHRPWM ECAP driver support for da850 platforms. This patch series based on [1] and is available at [2]. This has been tested backlight support using EHRPWM in da850-evm. [1] https://gitorious.org/linux-pwm/linux-pwm/trees/for-next [2] https://github.com/avinashphilip/am335x_linux/tree/davinci-for-v3.9_soc_pwm Philip Avinash (3): pwm: davinci: Add Kconfig support for ECAP EHRPWM devices pwm: pwm-tiecap: Add device-tree binding support for da850 SOC pwm: pwm-tiehrpwm: Add device tree binding support for da850 SOC .../devicetree/bindings/pwm/pwm-tiecap.txt |2 +- .../devicetree/bindings/pwm/pwm-tiehrpwm.txt |2 +- drivers/pwm/Kconfig|8 +++- drivers/pwm/pwm-tiecap.c |1 + drivers/pwm/pwm-tiehrpwm.c |1 + drivers/pwm/pwm-tipwmss.h |2 +- 6 files changed, 8 insertions(+), 8 deletions(-) -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] pwm: davinci: Add Kconfig support for ECAP EHRPWM devices
Add EHRPWM and ECAP support build support for DAVINCI_DA850 platforms. Also, since DAVINCI platforms doesn't support TI-PWM-Subsystem module, remove the select option for CONFIG_PWM_TIPWMSS. Also, update CONFIG_PWM_TIPWMSS compiler directive appropriately in pwm-tipwmss.h to fix the below compiler error upon removal of CONFIG_PWM_TIPWMSS for Davinci platforms. drivers/pwm/pwm-tiecap.c: In function 'ecap_pwm_probe': drivers/pwm/pwm-tiecap.c:263:4: error: 'PWMSS_ECAPCLK_EN' undeclared (first use in this function) drivers/pwm/pwm-tiecap.c:263:4: note: each undeclared identifier is reported only once for each function it appears in drivers/pwm/pwm-tiecap.c:264:17: error: 'PWMSS_ECAPCLK_EN_ACK' undeclared (first use in this function) drivers/pwm/pwm-tiecap.c: In function 'ecap_pwm_remove': drivers/pwm/pwm-tiecap.c:291:49: error: 'PWMSS_ECAPCLK_STOP_REQ' undeclared (first use in this function) make[2]: *** [drivers/pwm/pwm-tiecap.o] Error 1 make[1]: *** [drivers/pwm] Error 2 make: *** [drivers] Error 2 Signed-off-by: Philip Avinash avinashphi...@ti.com --- :100644 100644 0e0bfa0... 897b53c... M drivers/pwm/Kconfig :100644 100644 11f76a1... 10ad804... M drivers/pwm/pwm-tipwmss.h drivers/pwm/Kconfig |8 +++- drivers/pwm/pwm-tipwmss.h |2 +- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 0e0bfa0..897b53c 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -147,8 +147,7 @@ config PWM_TEGRA config PWM_TIECAP tristate ECAP PWM support - depends on SOC_AM33XX - select PWM_TIPWMSS + depends on SOC_AM33XX || ARCH_DAVINCI_DA850 help PWM driver support for the ECAP APWM controller found on AM33XX TI SOC @@ -158,8 +157,7 @@ config PWM_TIECAP config PWM_TIEHRPWM tristate EHRPWM PWM support - depends on SOC_AM33XX - select PWM_TIPWMSS + depends on SOC_AM33XX || ARCH_DAVINCI_DA850 help PWM driver support for the EHRPWM controller found on AM33XX TI SOC @@ -169,7 +167,7 @@ config PWM_TIEHRPWM config PWM_TIPWMSS bool - depends on SOC_AM33XX (PWM_TIEHRPWM || PWM_TIECAP) + default y if SOC_AM33XX (PWM_TIECAP || PWM_TIEHRPWM) help PWM Subsystem driver support for AM33xx SOC. diff --git a/drivers/pwm/pwm-tipwmss.h b/drivers/pwm/pwm-tipwmss.h index 11f76a1..10ad804 100644 --- a/drivers/pwm/pwm-tipwmss.h +++ b/drivers/pwm/pwm-tipwmss.h @@ -18,7 +18,6 @@ #ifndef __TIPWMSS_H #define __TIPWMSS_H -#ifdef CONFIG_PWM_TIPWMSS /* PWM substem clock gating */ #define PWMSS_ECAPCLK_EN BIT(0) #define PWMSS_ECAPCLK_STOP_REQ BIT(1) @@ -28,6 +27,7 @@ #define PWMSS_ECAPCLK_EN_ACK BIT(0) #define PWMSS_EPWMCLK_EN_ACK BIT(8) +#ifdef CONFIG_PWM_TIPWMSS extern u16 pwmss_submodule_state_change(struct device *dev, int set); #else static inline u16 pwmss_submodule_state_change(struct device *dev, int set) -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/3] pwm: pwm-tiecap: Add device-tree binding support for da850 SOC
ECAP IP is used in da850 SOC's also. Hence adds ECAP device tree binding
support for da850.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
:100644 100644 131e8c1... fcbd3c1... M
Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
:100644 100644 22e96e2... e0d96c8... M drivers/pwm/pwm-tiecap.c
.../devicetree/bindings/pwm/pwm-tiecap.txt |2 +-
drivers/pwm/pwm-tiecap.c |1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
index 131e8c1..fcbd3c1 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
@@ -1,7 +1,7 @@
TI SOC ECAP based APWM controller
Required properties:
-- compatible: Must be ti,am33xx-ecap
+- compatible: Must be ti,am33xx-ecap or ti,da850-ecap
- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
First cell specifies the per-chip index of the PWM to use, the second
cell is the period in nanoseconds and bit 0 in the third cell is used to
diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index 22e96e2..e0d96c8 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -197,6 +197,7 @@ static const struct pwm_ops ecap_pwm_ops = {
static const struct of_device_id ecap_of_match[] = {
{ .compatible = ti,am33xx-ecap },
+ { .compatible = ti,da850-ecap },
{},
};
MODULE_DEVICE_TABLE(of, ecap_of_match);
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] pwm: pwm-tiehrpwm: Add device tree binding support for da850 SOC
EHRPWM IP is used in da850 SOC's also. Hence adds EHRPWM device tree
binding support for da850.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
:100644 100644 4fc7079... 0442d65... M
Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
:100644 100644 8b4c86f... 6561ec2... M drivers/pwm/pwm-tiehrpwm.c
.../devicetree/bindings/pwm/pwm-tiehrpwm.txt |2 +-
drivers/pwm/pwm-tiehrpwm.c |1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
index 4fc7079..0442d65 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -1,7 +1,7 @@
TI SOC EHRPWM based PWM controller
Required properties:
-- compatible : Must be ti,am33xx-ehrpwm
+- compatible : Must be ti,am33xx-ehrpwm or ti,da850-ehrpwm
- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
First cell specifies the per-chip index of the PWM to use, the second
cell is the period in nanoseconds and bit 0 in the third cell is used to
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index 8b4c86f..6561ec2 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -428,6 +428,7 @@ static const struct pwm_ops ehrpwm_pwm_ops = {
static const struct of_device_id ehrpwm_of_match[] = {
{ .compatible = ti,am33xx-ehrpwm },
+ { .compatible = ti,da850-ehrpwm },
{},
};
MODULE_DEVICE_TABLE(of, ehrpwm_of_match);
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/2] dwc3: exynos: Device tree fixes
This patch-set modifies dwc3-exynos as per latest bindings available for dwc3. Now the dwc3 core also has device support, there's no need to add platform device for core in glue layers. This change has come as a result of discussion happened in: [PATCH RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node. Additionally, now that Samsung exynos series has moved to common clock framework, we use clock_prepare_enable() and clock_disable_unprepare() APIs. Some cleanup is also done here. Based on 'usb-next' plus Felipe's 'testing' branch patches; (some 194 patches in fact ;-), on top of 3.9rc2 tag). Also based on: usb: dwc3: set dma_mask for dwc3_omap device by Kishon in which DMA mask for dwc3-core is being set from its parent. Vivek Gautam (2): usb: dwc3: exynos: Use of_platform API to create dwc3 core pdev usb: dwc3: exynos: use clk_prepare_enable and clk_disable_unprepare drivers/usb/dwc3/dwc3-exynos.c | 54 ++-- 1 files changed, 19 insertions(+), 35 deletions(-) -- 1.7.6.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] usb: dwc3: exynos: Use of_platform API to create dwc3 core pdev
Used of_platform_populate() to create dwc3 core platform_device
from device tree data. Additionally some cleanup is also done.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
CC: Felipe Balbi ba...@ti.com
CC: Kukjin Kim kgene@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 46 +---
1 files changed, 15 insertions(+), 31 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index e12e452..66ca9ac 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -22,9 +22,9 @@
#include linux/usb/otg.h
#include linux/usb/nop-usb-xceiv.h
#include linux/of.h
+#include linux/of_platform.h
struct dwc3_exynos {
- struct platform_device *dwc3;
struct platform_device *usb2_phy;
struct platform_device *usb3_phy;
struct device *dev;
@@ -90,17 +90,17 @@ static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
static int dwc3_exynos_probe(struct platform_device *pdev)
{
- struct platform_device *dwc3;
struct dwc3_exynos *exynos;
struct clk *clk;
struct device *dev = pdev-dev;
+ struct device_node *node = dev-of_node;
int ret = -ENOMEM;
exynos = devm_kzalloc(dev, sizeof(*exynos), GFP_KERNEL);
if (!exynos) {
dev_err(dev, not enough memory\n);
- return -ENOMEM;
+ goto err1;
}
/*
@@ -108,21 +108,15 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
* Since shared usb code relies on it, set it here for now.
* Once we move to full device tree support this will vanish off.
*/
- if (!pdev-dev.dma_mask)
- pdev-dev.dma_mask = dwc3_exynos_dma_mask;
+ if (!dev-dma_mask)
+ dev-dma_mask = dwc3_exynos_dma_mask;
platform_set_drvdata(pdev, exynos);
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
dev_err(dev, couldn't register PHYs\n);
- return ret;
- }
-
- dwc3 = platform_device_alloc(dwc3, PLATFORM_DEVID_AUTO);
- if (!dwc3) {
- dev_err(dev, couldn't allocate dwc3 device\n);
- return -ENOMEM;
+ goto err1;
}
clk = devm_clk_get(dev, usbdrd30);
@@ -132,27 +126,20 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
goto err1;
}
- dma_set_coherent_mask(dwc3-dev, dev-coherent_dma_mask);
-
- dwc3-dev.parent = dev;
- dwc3-dev.dma_mask = dev-dma_mask;
- dwc3-dev.dma_parms = dev-dma_parms;
- exynos-dwc3= dwc3;
exynos-dev = dev;
exynos-clk = clk;
clk_enable(exynos-clk);
- ret = platform_device_add_resources(dwc3, pdev-resource,
- pdev-num_resources);
- if (ret) {
- dev_err(dev, couldn't add resources to dwc3 device\n);
- goto err2;
- }
-
- ret = platform_device_add(dwc3);
- if (ret) {
- dev_err(dev, failed to register dwc3 device\n);
+ if (node) {
+ ret = of_platform_populate(node, NULL, NULL, dev);
+ if (ret) {
+ dev_err(dev, failed to add dwc3 core\n);
+ goto err2;
+ }
+ } else {
+ dev_err(dev, no device node, failed to add dwc3 core\n);
+ ret = -ENODEV;
goto err2;
}
@@ -161,8 +148,6 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
err2:
clk_disable(clk);
err1:
- platform_device_put(dwc3);
-
return ret;
}
@@ -170,7 +155,6 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
{
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
- platform_device_unregister(exynos-dwc3);
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
--
1.7.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 1/4] ARM: davinci: mmc: derive version information from device name
Prakash,
The series looks good to me. I tested it again on DA850 EVM (with and
without DT).
On 3/12/2013 7:43 PM, Manjunathappa, Prakash wrote:
Remove specifying mmc controller IP version information via platform
data, instead specify device name so that driver derives it from
platform_device_id table. Also change the clock node name to match
the changed dev_id.
Tested on da850-evm to make sure driver loads without clk_get failures.
Signed-off-by: Manjunathappa, Prakash prakash...@ti.com
Reviewed-by: Sekhar Nori nsek...@ti.com
---
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 27123f8..50e9782 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -1157,6 +1157,18 @@ static void __init init_mmcsd_host(struct
mmc_davinci_host *host)
mmc_davinci_reset_ctrl(host, 0);
}
+static struct platform_device_id davinci_mmc_devtype[] = {
+ {
+ .name = davinci-mmc-dm355,
+ .driver_data = MMC_CTLR_VERSION_1,
+ }, {
+ .name = davinci-mmc-da830,
+ .driver_data = MMC_CTLR_VERSION_2,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(platform, davinci_mmc_devtype);
I should have mentioned this previously, but your choice of name here is
too long. You can simply use dm355-mmc (rather dm6441-mmc?) and
da830-mmc instead like you did for SPI. This would have saved some long
lines. Sorry about not asking for this earlier. I know it would have
saved you a bunch of effort.
Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] pwm: davinci: Add Kconfig support for ECAP EHRPWM devices
On 3/14/2013 4:02 PM, Philip Avinash wrote: Add EHRPWM and ECAP support build support for DAVINCI_DA850 platforms. Also, since DAVINCI platforms doesn't support TI-PWM-Subsystem module, remove the select option for CONFIG_PWM_TIPWMSS. Also, update CONFIG_PWM_TIPWMSS compiler directive appropriately in pwm-tipwmss.h to fix the below compiler error upon removal of CONFIG_PWM_TIPWMSS for Davinci platforms. drivers/pwm/pwm-tiecap.c: In function 'ecap_pwm_probe': drivers/pwm/pwm-tiecap.c:263:4: error: 'PWMSS_ECAPCLK_EN' undeclared (first use in this function) drivers/pwm/pwm-tiecap.c:263:4: note: each undeclared identifier is reported only once for each function it appears in drivers/pwm/pwm-tiecap.c:264:17: error: 'PWMSS_ECAPCLK_EN_ACK' undeclared (first use in this function) drivers/pwm/pwm-tiecap.c: In function 'ecap_pwm_remove': drivers/pwm/pwm-tiecap.c:291:49: error: 'PWMSS_ECAPCLK_STOP_REQ' undeclared (first use in this function) make[2]: *** [drivers/pwm/pwm-tiecap.o] Error 1 make[1]: *** [drivers/pwm] Error 2 make: *** [drivers] Error 2 Signed-off-by: Philip Avinash avinashphi...@ti.com config PWM_TIECAP tristate ECAP PWM support - depends on SOC_AM33XX - select PWM_TIPWMSS + depends on SOC_AM33XX || ARCH_DAVINCI_DA850 Having such narrow dependencies is wrong. The same device is present on DaVinci DA830 too. A depends on should not be required at all since the driver should build on all architectures. But I have seen resistance to doing that since users don't like to see configuration options totally irrelevant for the architecture they are building for. So may be take a middle path and do 'depends on ARCH_ARM'? Thanks, Sekhar ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] pwm: pwm-tiecap: Add device-tree binding support for da850 SOC
On 3/14/2013 4:02 PM, Philip Avinash wrote:
ECAP IP is used in da850 SOC's also. Hence adds ECAP device tree binding
support for da850.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
:100644 100644 131e8c1... fcbd3c1... M
Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
:100644 100644 22e96e2... e0d96c8... Mdrivers/pwm/pwm-tiecap.c
.../devicetree/bindings/pwm/pwm-tiecap.txt |2 +-
drivers/pwm/pwm-tiecap.c |1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
index 131e8c1..fcbd3c1 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
@@ -1,7 +1,7 @@
TI SOC ECAP based APWM controller
Required properties:
-- compatible: Must be ti,am33xx-ecap
+- compatible: Must be ti,am33xx-ecap or ti,da850-ecap
- #pwm-cells: Should be 3. Number of cells being used to specify PWM
property.
First cell specifies the per-chip index of the PWM to use, the second
cell is the period in nanoseconds and bit 0 in the third cell is used to
diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index 22e96e2..e0d96c8 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -197,6 +197,7 @@ static const struct pwm_ops ecap_pwm_ops = {
static const struct of_device_id ecap_of_match[] = {
{ .compatible = ti,am33xx-ecap },
+ { .compatible = ti,da850-ecap },
{},
You add a new compatible, but don't really show any changes in driver in
this series. So why can't we simply use ti,am33xx-ecap on DA850 too?
Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 0/4] Add DT support for davinci_mmc driver
On 3/12/2013 7:43 PM, Manjunathappa, Prakash wrote: Patch set adds DT support for davinci_mmc driver and is verified on da850-evm without card_detect/write_protect and EDMA support. Also takecare to derive controller IP version from platform_device_id table, remove version specification in pdata. Applies on top of below patch under community review: Enable SPI flash support on da850-evm DT kernel http://www.spinics.net/lists/arm-kernel/msg229328.html Depends on patch waiting for acceptance: Patch mmc: davinci: allow driver to work without DMA resource http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg18771.html Since this patch did not get picked for v3.9, it may be worthwhile rebasing it and adding to this series. Thanks, Sekhar ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] usb: dwc3: exynos: Use of_platform API to create dwc3 core pdev
On Thu, Mar 14, 2013 at 4:21 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Mar 14, 2013 at 04:14:57PM +0530, Vivek Gautam wrote:
@@ -170,7 +155,6 @@ static int dwc3_exynos_remove(struct platform_device
*pdev)
{
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
- platform_device_unregister(exynos-dwc3);
don't you want to do what Kishon did here and have:
static int dwc3_exynos_remove_child(struct device *dev, void *unused)
{
struct platform_device *pdev = to_platform_device(dev);
platform_device_unregister(pdev);
return 0;
}
device_for_each_child(pdev-dev, NULL, dwc3_exynos_remove_child);
???
Hmm, right. We need to do that. :-)
--
balbi
--
Thanks Regards
Vivek
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: GPIO polarity in bindings for Freescale MXS
On 03/14/2013 11:02 AM, Hector Palacios wrote: Hello, Maybe I'm missing something but the MXS processors (at least i.MX23 and i.MX28) cannot set the polarity of the GPIOs, so shouldn't the #gpio-cells be 1? (From Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt): Sorry, I meant: from Documentation/devicetree/bindings/gpio/gpio-mxs.txt - #gpio-cells : Should be two. The first cell is the pin number and the second cell is used to specify the gpio polarity: 0 = active high 1 = active low Regards, ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 04/10] ASoC: Kconfig: imx-ssi needs imx-fiq and imx-dma
On Tue, Mar 12, 2013 at 06:55:10PM +, Mark Brown wrote: On Sun, Mar 10, 2013 at 07:33:05PM +0100, Markus Pargmann wrote: config SND_SOC_IMX_SSI + select SND_SOC_IMX_PCM_DMA + select SND_SOC_IMX_PCM_FIQ tristate Really? I'd expect this to be an or, if we've got DMA I can't see any reason why we'd want to use the FIQ. Yes, sorry, I looked at the returncodes of the devicedrivers, but devices actually don't have to be used. So this can be dropped. Thanks, Markus -- 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
[PATCH v2 1/2] usb: dwc3: exynos: Use of_platform API to create dwc3 core pdev
Used of_platform_populate() to create dwc3 core platform_device
from device tree data. Additionally some cleanup is also done.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
CC: Felipe Balbi ba...@ti.com
CC: Kukjin Kim kgene@samsung.com
---
Changes from v1:
- Added method to unregister dwc3 core from dwc3_exynos_remove()
using device_for_each_child() API, which we missed to do.
drivers/usb/dwc3/dwc3-exynos.c | 56 ++--
1 files changed, 25 insertions(+), 31 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index e12e452..f77ec75 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -22,9 +22,9 @@
#include linux/usb/otg.h
#include linux/usb/nop-usb-xceiv.h
#include linux/of.h
+#include linux/of_platform.h
struct dwc3_exynos {
- struct platform_device *dwc3;
struct platform_device *usb2_phy;
struct platform_device *usb3_phy;
struct device *dev;
@@ -86,21 +86,30 @@ err1:
return ret;
}
+static int dwc3_exynos_remove_child(struct device *dev, void *unused)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ platform_device_unregister(pdev);
+
+ return 0;
+}
+
static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
static int dwc3_exynos_probe(struct platform_device *pdev)
{
- struct platform_device *dwc3;
struct dwc3_exynos *exynos;
struct clk *clk;
struct device *dev = pdev-dev;
+ struct device_node *node = dev-of_node;
int ret = -ENOMEM;
exynos = devm_kzalloc(dev, sizeof(*exynos), GFP_KERNEL);
if (!exynos) {
dev_err(dev, not enough memory\n);
- return -ENOMEM;
+ goto err1;
}
/*
@@ -108,21 +117,15 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
* Since shared usb code relies on it, set it here for now.
* Once we move to full device tree support this will vanish off.
*/
- if (!pdev-dev.dma_mask)
- pdev-dev.dma_mask = dwc3_exynos_dma_mask;
+ if (!dev-dma_mask)
+ dev-dma_mask = dwc3_exynos_dma_mask;
platform_set_drvdata(pdev, exynos);
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
dev_err(dev, couldn't register PHYs\n);
- return ret;
- }
-
- dwc3 = platform_device_alloc(dwc3, PLATFORM_DEVID_AUTO);
- if (!dwc3) {
- dev_err(dev, couldn't allocate dwc3 device\n);
- return -ENOMEM;
+ goto err1;
}
clk = devm_clk_get(dev, usbdrd30);
@@ -132,27 +135,20 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
goto err1;
}
- dma_set_coherent_mask(dwc3-dev, dev-coherent_dma_mask);
-
- dwc3-dev.parent = dev;
- dwc3-dev.dma_mask = dev-dma_mask;
- dwc3-dev.dma_parms = dev-dma_parms;
- exynos-dwc3= dwc3;
exynos-dev = dev;
exynos-clk = clk;
clk_enable(exynos-clk);
- ret = platform_device_add_resources(dwc3, pdev-resource,
- pdev-num_resources);
- if (ret) {
- dev_err(dev, couldn't add resources to dwc3 device\n);
- goto err2;
- }
-
- ret = platform_device_add(dwc3);
- if (ret) {
- dev_err(dev, failed to register dwc3 device\n);
+ if (node) {
+ ret = of_platform_populate(node, NULL, NULL, dev);
+ if (ret) {
+ dev_err(dev, failed to add dwc3 core\n);
+ goto err2;
+ }
+ } else {
+ dev_err(dev, no device node, failed to add dwc3 core\n);
+ ret = -ENODEV;
goto err2;
}
@@ -161,8 +157,6 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
err2:
clk_disable(clk);
err1:
- platform_device_put(dwc3);
-
return ret;
}
@@ -170,9 +164,9 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
{
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
- platform_device_unregister(exynos-dwc3);
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
+ device_for_each_child(pdev-dev, NULL, dwc3_exynos_remove_child);
clk_disable(exynos-clk);
--
1.7.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 01/10] imx-ssi: Fix AC97 rates
On Wed, Mar 13, 2013 at 05:55:24PM -0500, Timur Tabi wrote: On Mon, Mar 11, 2013 at 2:51 PM, Markus Pargmann m...@pengutronix.de wrote: At the moment fsl-ssi and imx-ssi don't seem to have very much in common. However I could try to merge the imx-ssi driver code into fsl_ssi and make it handle imx27-ssi differently. imx-ssi is the legacy driver that supports older, non-DT IMX platforms. fsl-ssi is the new driver that supports PowerPC and IMX DT-enabled platforms. Okay, I will use the fsl-ssi driver then. Thanks Markus -- 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: [PATCH 08/10] ASoC: dmaengine_pcm: Add open function for DT DMA request
On Wed, Mar 13, 2013 at 10:18:29AM +0800, Shawn Guo wrote: On Tue, Mar 12, 2013 at 07:02:07PM +, Mark Brown wrote: On Sun, Mar 10, 2013 at 07:33:09PM +0100, Markus Pargmann wrote: Add a function to open a DMA PCM substream using devicetree data provided via the client device node. The patch introduces a public function and a private subfunction that is called by both open functions. Someone (I think it was Shawn) sent a very similar patch just recently which appears to have fallen out of my inbox unfortunately - can you please check what's going on there and coordinate with them? Let me know if you can't find the patch and I'll dig it out. It's here, Markus. http://thread.gmane.org/gmane.linux.alsa.devel/106027/focus=106031 Thanks. Do you already have a patch for the non-generic function which I could use instead? Regards Markus -- 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: [PATCH v3 0/5] Enable SPI flash support on da850-evm DT kernel
On Thu, Mar 14, 2013 at 15:54:26, Nori, Sekhar wrote: On 3/12/2013 1:40 PM, Manjunathappa, Prakash wrote: Patch enables support for m25p64 SPI flash support on da850-EVM. This patch set looks good to me except the comments I had on 2/5. I tested it using SPI flash on DA850 EVM and it worked fine on basic read/write tests. Thanks I will add your Reviewed-by. Grant, With your ack I would like to merge the series through DaVinci tree so its easy to manage the conflicts in DT files. Testing information: da850-evm comes with partitions specified in DT blob. Able to mount/umount and create/delete files on filesystem partition. Depends on below patch in spi-next branch of git://git.secretlab.ca/git/linux-2.6.git. spi/davinci: add OF support for the spi controller Prakash, there is no need to mention this dependency. The patch is already in mainline. Yes, I mentioned it here as my patches were based on linux-davinci: v3.9/dt-2 branch. Will rebase my next versions on davinci/master. Thanks, Prakash ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v5 1/4] ARM: davinci: mmc: derive version information from device name
On Thu, Mar 14, 2013 at 16:38:09, Nori, Sekhar wrote:
Prakash,
The series looks good to me. I tested it again on DA850 EVM (with and
without DT).
On 3/12/2013 7:43 PM, Manjunathappa, Prakash wrote:
Remove specifying mmc controller IP version information via platform
data, instead specify device name so that driver derives it from
platform_device_id table. Also change the clock node name to match
the changed dev_id.
Tested on da850-evm to make sure driver loads without clk_get failures.
Signed-off-by: Manjunathappa, Prakash prakash...@ti.com
Reviewed-by: Sekhar Nori nsek...@ti.com
---
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 27123f8..50e9782 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -1157,6 +1157,18 @@ static void __init init_mmcsd_host(struct
mmc_davinci_host *host)
mmc_davinci_reset_ctrl(host, 0);
}
+static struct platform_device_id davinci_mmc_devtype[] = {
+ {
+ .name = davinci-mmc-dm355,
+ .driver_data = MMC_CTLR_VERSION_1,
+ }, {
+ .name = davinci-mmc-da830,
+ .driver_data = MMC_CTLR_VERSION_2,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(platform, davinci_mmc_devtype);
I should have mentioned this previously, but your choice of name here is
too long. You can simply use dm355-mmc (rather dm6441-mmc?) and
da830-mmc instead like you did for SPI. This would have saved some long
lines. Sorry about not asking for this earlier. I know it would have
saved you a bunch of effort.
No problem, will change the name.
Thanks,
Prakash
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v5 0/4] Add DT support for davinci_mmc driver
On Thu, Mar 14, 2013 at 17:25:13, Nori, Sekhar wrote: On 3/12/2013 7:43 PM, Manjunathappa, Prakash wrote: Patch set adds DT support for davinci_mmc driver and is verified on da850-evm without card_detect/write_protect and EDMA support. Also takecare to derive controller IP version from platform_device_id table, remove version specification in pdata. Applies on top of below patch under community review: Enable SPI flash support on da850-evm DT kernel http://www.spinics.net/lists/arm-kernel/msg229328.html Depends on patch waiting for acceptance: Patch mmc: davinci: allow driver to work without DMA resource http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg18771.html Since this patch did not get picked for v3.9, it may be worthwhile rebasing it and adding to this series. Will do that. Thanks, Prakash ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 3/4] USB: Palmas OTG Transceiver Driver
On Thu, Mar 07, 2013 at 06:51:45PM +0530, Kishon Vijay Abraham I wrote: From: Graeme Gregory g...@slimlogic.co.uk This is the driver for the OTG transceiver built into the Palmas chip. It handles the various USB OTG events that can be generated by cable insertion/removal. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Ruchika Kharwar ruch...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Sebastien Guiriec s-guir...@ti.com --- .../devicetree/bindings/usb/twl-usb.txt| 15 + drivers/usb/otg/Kconfig|6 + drivers/usb/otg/Makefile |1 + drivers/usb/otg/palmas-usb.c | 396 this has to go to drivers/usb/phy/ and should be named phy-palmas.c or phy-twl$(whatever number palmas is).c :-) -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/4] usb: musb: omap2430: replace *_* with *-* in property names
On Thu, Mar 07, 2013 at 06:51:46PM +0530, Kishon Vijay Abraham I wrote: No functional change. Replace *_* with *-* in property names of otg to follow the general convention. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com this has been pending for quite a while, since nobody complained, I'm taking it for v3.10. -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] pinctrl: exynos5440: fix invalid use of sizeof in exynos5440_pinctrl_probe()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
sizeof() when applied to a pointer typed expression gives the
size of the pointer, not that of the pointed data.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/pinctrl/pinctrl-exynos5440.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-exynos5440.c
b/drivers/pinctrl/pinctrl-exynos5440.c
index 1376eb7..fe65739 100644
--- a/drivers/pinctrl/pinctrl-exynos5440.c
+++ b/drivers/pinctrl/pinctrl-exynos5440.c
@@ -854,7 +854,7 @@ static int exynos5440_pinctrl_probe(struct platform_device
*pdev)
return -ENODEV;
}
- priv = devm_kzalloc(dev, sizeof(priv), GFP_KERNEL);
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
dev_err(dev, could not allocate memory for private data\n);
return -ENOMEM;
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/6] mfd: omap-usb-host: Actually update hostconfig
On Tue, Mar 12, 2013 at 12:25:37PM +0200, Roger Quadros wrote: The helper functions omap_usbhs_rev1_hostconfig() and omap_usbhs_rev2_hostconfig() don't write into the hostconfig register. Make sure that we write the return value into the hostconfig register. Signed-off-by: Roger Quadros rog...@ti.com makes sense :-) Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 11/12] USB: ehci-omap: Try to get PHY even if not in PHY mode
On Tue, Mar 12, 2013 at 11:57:56AM -0400, Alan Stern wrote:
On Tue, 12 Mar 2013, Roger Quadros wrote:
Even when not in PHY mode, the USB device on the port (e.g. HUB)
might need resources like RESET which can be modelled as a PHY
device. So try to get the PHY device in any case.
Signed-off-by: Roger Quadros rog...@ti.com
CC: Alan Stern st...@rowland.harvard.edu
Acked-by: Alan Stern st...@rowland.harvard.edu
/* get the PHY device */
if (dev-of_node)
phy = devm_usb_get_phy_by_phandle(dev, phys, i);
else
phy = devm_usb_get_phy_dev(dev, i);
if (IS_ERR(phy) || !phy) {
+ /* Don't bail out if PHY is not absolutely necessary */
+ if (pdata-port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
+ continue;
+
ret = IS_ERR(phy) ? PTR_ERR(phy) : -ENODEV;
dev_err(dev, Can't get PHY device for port %d: %d\n,
i, ret);
Felipe, this is a strange interface. Why do we sometimes get an
error-pointer and sometimes get just NULL? Why not always an
error-pointer?
looks like we get NULL when PHY layer is disabled. Sounds like an
oversight to me. Do you want to send a patch, or do I cook one and put
yourself as Reported-by ?
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 3/4] USB: Palmas OTG Transceiver Driver
On Thursday 14 March 2013 07:26 PM, Felipe Balbi wrote: On Thu, Mar 07, 2013 at 06:51:45PM +0530, Kishon Vijay Abraham I wrote: From: Graeme Gregory g...@slimlogic.co.uk This is the driver for the OTG transceiver built into the Palmas chip. It handles the various USB OTG events that can be generated by cable insertion/removal. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Ruchika Kharwar ruch...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Sebastien Guiriec s-guir...@ti.com --- .../devicetree/bindings/usb/twl-usb.txt| 15 + drivers/usb/otg/Kconfig|6 + drivers/usb/otg/Makefile |1 + drivers/usb/otg/palmas-usb.c | 396 this has to go to drivers/usb/phy/ and should be named phy-palmas.c or phy-twl$(whatever number palmas is).c :-) Ok. I'll fix this and send Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
Salut Jon, On 03/08/2013 06:27 PM, Jon Hunter wrote: Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but re-sending here as a complete series for v3.10. This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2]. [1] https://patchwork.kernel.org/patch/2057111/ I've tried to follow the series review, and it seems that Florian was considering sending some other patches. It is not clear if this is a new version of the series or some additional patches. I still did not merge this series wondering what to do with it. Felipe's patch on this other hand is already applied in my branch. Regards, Benoit [2] https://patchwork.kernel.org/patch/2134711/ Jon Hunter (9): ARM: OMAP2+: Prepare for device-tree PMU support ARM: dts: OMAP2+: Add PMU nodes ARM: dts: OMAP2+: Add SDMA controller bindings and nodes ARM: dts: OMAP3: Add support for OMAP3430 SDP board ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5 ARM: dts: Add OMAP3430 SDP flash memory bindings ARM: dts: Add OMAP2 gpio bindings ARM: dts: OMAP3+: Correct gpio #interrupts-cells property ARM: dts: OMAP3: Add reg and interrupt properties for gpio .../devicetree/bindings/dma/omap-sdma.txt | 51 +++ arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/omap2.dtsi | 17 +++ arch/arm/boot/dts/omap2420.dtsi| 55 arch/arm/boot/dts/omap2430.dtsi| 66 + arch/arm/boot/dts/omap3.dtsi | 70 +- arch/arm/boot/dts/omap3430-sdp.dts | 141 arch/arm/boot/dts/omap4-panda-es.dts |2 + arch/arm/boot/dts/omap4.dtsi | 64 - arch/arm/boot/dts/omap4460.dtsi| 18 +++ arch/arm/boot/dts/omap5.dtsi | 68 -- arch/arm/mach-omap2/pmu.c | 14 +- 12 files changed, 544 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts create mode 100644 arch/arm/boot/dts/omap4460.dtsi ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 11/12] USB: ehci-omap: Try to get PHY even if not in PHY mode
On Thu, 14 Mar 2013, Felipe Balbi wrote:
if (IS_ERR(phy) || !phy) {
+ /* Don't bail out if PHY is not absolutely necessary */
+ if (pdata-port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
+ continue;
+
ret = IS_ERR(phy) ? PTR_ERR(phy) : -ENODEV;
dev_err(dev, Can't get PHY device for port %d: %d\n,
i, ret);
Felipe, this is a strange interface. Why do we sometimes get an
error-pointer and sometimes get just NULL? Why not always an
error-pointer?
looks like we get NULL when PHY layer is disabled. Sounds like an
oversight to me. Do you want to send a patch, or do I cook one and put
yourself as Reported-by ?
You're more familiar with that code. Reported-by is good enough for
me. :-)
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] ARM: OMAP2+: return -ENODEV if GPMC child device creation fails
gpmc_probe_nor_child() calls of_platform_device_create() to create a platform device for the NOR child. If this function fails the value of ret is returned to the caller but this value is zero since it was assigned the return of a previous call to gpmc_cs_program_settings() that had to succeed or otherwise gpmc_probe_nor_child() would have returned before. This means that if of_platform_device_create() fails, 0 will be returned to the caller instead of an appropriate error code. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/mach-omap2/gpmc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index d594e1d..8799aed 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -1505,6 +1505,7 @@ static int gpmc_probe_nor_child(struct platform_device *pdev, return 0; dev_err(pdev-dev, failed to create gpmc child %s\n, child-name); + ret = -ENODEV; err: gpmc_cs_free(cs); -- 1.7.7.6 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child
Hello Jon, As discussed before [1], this patch-set adds DT support for ethernet controllers connected to a TI GPMC by making gpmc_probe_nor_child() a generic function and reusing it to initialize ethernet child devices nodes too. It also adds documentation about the DT binding. The patch-set is based on top of your omap-gpmc-for-v3.10 branch [2] and is composed of the following patches: [PATCH 1/3] ARM: OMAP2+: return -ENODEV if GPMC child device [PATCH 2/3] ARM: OMAP2+: rename gpmc_probe_nor_child() to gpmc_probe_generic_child() [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child This was tested on an TI OMAP3 DM3735 based board (IGEPv2) Thanks a lot and best regards, Javier [1]: https://patchwork.kernel.org/patch/2245111/ [2]: https://github.com/jonhunter/linux/tree/omap-gpmc-for-v3.10 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/3] ARM: OMAP2+: rename gpmc_probe_nor_child() to gpmc_probe_generic_child()
The gpmc_probe_nor_child() function is used in the GPMC driver to
configure the GPMC for a NOR child device node.
But this function is quite generic and all the NOR specific configuration
is made by the driver of the actual NOR flash memory used.
Other Pseudo-SRAM devices such as ethernet controllers need a similar
setup so by making this function generic it can be used for those too.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/gpmc.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8799aed..898b44d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1439,14 +1439,14 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
#endif
/**
- * gpmc_probe_nor_child - configures the gpmc for a nor device
+ * gpmc_probe_generic_child - configures the gpmc for a child device
* @pdev: pointer to gpmc platform device
- * @child: pointer to device-tree node for nor device
+ * @child: pointer to device-tree node for child device
*
- * Allocates and configures a GPMC chip-select for a NOR flash device.
+ * Allocates and configures a GPMC chip-select for a child device.
* Returns 0 on success and appropriate negative error code on failure.
*/
-static int gpmc_probe_nor_child(struct platform_device *pdev,
+static int gpmc_probe_generic_child(struct platform_device *pdev,
struct device_node *child)
{
struct gpmc_settings gpmc_s;
@@ -1552,7 +1552,7 @@ static int gpmc_probe_dt(struct platform_device *pdev)
}
for_each_node_by_name(child, nor) {
- ret = gpmc_probe_nor_child(pdev, child);
+ ret = gpmc_probe_generic_child(pdev, child);
if (ret 0) {
of_node_put(child);
return ret;
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Documentation/devicetree/bindings/net/gpmc-eth.txt | 90
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..c45363c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,90 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width: Address width of the device in bytes. GPMC supports
8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Compatible string property for the ethernet child
device.
+- gpmc,cs-on: Chip-select assertion time
+- gpmc,cs-rd-off: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off: Chip-select de-assertion time for writes
+- gpmc,oe-on: Output-enable assertion time
+- gpmc,oe-off Output-enable de-assertion time
+- gpmc,we-on: Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle: Total read cycle time
+- gpmc,wr-cycle: Total write cycle time
+- reg: Chip-select, base address (relative to chip-select)
+ and size of the memory mapped for the device.
+ Note that base address will be typically 0 as this
+ is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Optional properties for partiton table parsing:
+- #address-cells: should be set to 1
+- #size-cells: should be set to 1
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x1000;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ ranges = 5 0 0x2c00 0x100;
+
+ ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 186;
+ gpmc,cs-wr-off = 186;
+ gpmc,adv-on = 12;
+ gpmc,adv-rd-off = 48;
+ gpmc,adv-wr-off = 48;
+ gpmc,oe-on = 54;
+ gpmc,oe-off = 168;
+ gpmc,we-on = 54;
+ gpmc,we-off = 168;
+ gpmc,rd-cycle = 186;
+ gpmc,wr-cycle = 186;
+ gpmc,access = 114;
+ gpmc,page-burst-access = 6;
+ gpmc,bus-turnaround = 12;
+ gpmc,cycle2cycle-delay = 18;
+ gpmc,wr-data-mux-bus = 90;
+ gpmc,wr-access = 186;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = gpio6;
+ interrupts = 16;
+ vmmc-supply = vddvario;
+ vmmc_aux-supply = vdd33a;
+ reg-io-width = 2;
+
+ smsc,save-mac-address;
+ };
+};
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 898b44d..2bc276b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1559,6 +1559,14 @@ static int gpmc_probe_dt(struct platform_device *pdev)
}
}
+ for_each_node_by_name(child, ethernet) {
+ ret = gpmc_probe_generic_child(pdev, child);
+ if (ret 0) {
+ of_node_put(child);
+ return ret;
+ }
+ }
+
return 0;
}
#else
--
1.7.7.6
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On 03/11/2013 06:56 PM, Jon Hunter wrote: On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote: Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a minimal address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. I agree with that. I am not sure if Tony/Benoit have any comments on what they would like to do here to be consistent for the omap bindings. Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Documentation/devicetree/bindings/net/gpmc-eth.txt | 90
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..c45363c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,90 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width:Address width of the device in bytes. GPMC
supports 8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
I am wondering if we should use reg-io-width here. The smsc driver is
using this to determine the width of the device. And so I am wondering
if this could cause problems.
Obviously this complicates gpmc_probe_generic_child() a little, but may
be would could pass the name of the width property to
gpmc_probe_generic_child() as well. What do you think?
+- compatible:Compatible string property for the ethernet
child device.
+- gpmc,cs-on:Chip-select assertion time
+- gpmc,cs-rd-off:Chip-select de-assertion time for reads
+- gpmc,cs-wr-off:Chip-select de-assertion time for writes
+- gpmc,oe-on:Output-enable assertion time
+- gpmc,oe-offOutput-enable de-assertion time
+- gpmc,we-on:Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle: Total read cycle time
+- gpmc,wr-cycle: Total write cycle time
+- reg: Chip-select, base address (relative to
chip-select)
+ and size of the memory mapped for the device.
+ Note that base address will be typically 0 as this
+ is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Optional properties for partiton table parsing:
+- #address-cells: should be set to 1
+- #size-cells: should be set to 1
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x1000;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ ranges = 5 0 0x2c00 0x100;
+
+ ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 186;
+ gpmc,cs-wr-off = 186;
+ gpmc,adv-on = 12;
+ gpmc,adv-rd-off = 48;
+ gpmc,adv-wr-off = 48;
+ gpmc,oe-on = 54;
+ gpmc,oe-off = 168;
+ gpmc,we-on = 54;
+ gpmc,we-off = 168;
+ gpmc,rd-cycle = 186;
+ gpmc,wr-cycle = 186;
+ gpmc,access = 114;
+ gpmc,page-burst-access = 6;
+ gpmc,bus-turnaround = 12;
+ gpmc,cycle2cycle-delay = 18;
+ gpmc,wr-data-mux-bus = 90;
+ gpmc,wr-access = 186;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = gpio6;
+ interrupts = 16;
+ vmmc-supply = vddvario;
+ vmmc_aux-supply = vdd33a;
+ reg-io-width = 2;
+
+ smsc,save-mac-address;
+ };
+};
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 898b44d..2bc276b 100644
Re: [PATCH] mmc: mxcmmc: DT support
On Mon, 25 Feb 2013 19:28:05 +0100
Markus Pargmann m...@pengutronix.de wrote:
Adding devicetree support for imx21-mmc and imx31-mmc. Based on generic
gpio helper functions by Guennadi and generic DMA devicetree bindings.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
.../devicetree/bindings/mmc/fsl-imx-mmc.txt| 24 +++
drivers/mmc/host/mxcmmc.c | 80
+-
2 files changed, 86 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
new file mode 100644
index 000..a5ab662
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
@@ -0,0 +1,24 @@
+* Freescale Secure Digital Host Controller for i.MX1/2 series
shouldn't it be ... for i.MX2/3 series?
...
+ if (!host-pdata) {
+ host-dma = of_dma_request_slave_channel(pdev-dev.of_node,
+ rx-tx);
please use dma_request_slave_channel(pdev-dev, rx-tx)
here. of_dma_request_slave_channel() is not exported for
modules, building the driver as a module will fail.
Thanks,
Anatolij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On 03/14/2013 10:45 AM, Benoit Cousson wrote: On 03/11/2013 06:56 PM, Jon Hunter wrote: On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote: Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a minimal address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. I agree with that. I am not sure if Tony/Benoit have any comments on what they would like to do here to be consistent for the omap bindings. Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Ok, what is best to use? The size from hwmod structures or the size from the documentation? Cheers Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
Hi Benoit, On 03/14/2013 03:57 PM, Benoit Cousson wrote: Salut Jon, On 03/08/2013 06:27 PM, Jon Hunter wrote: Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but re-sending here as a complete series for v3.10. This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2]. [1] https://patchwork.kernel.org/patch/2057111/ I've tried to follow the series review, and it seems that Florian was considering sending some other patches. It is not clear if this is a new version of the series or some additional patches. Concerning patch [1], it can be merged to add the GPMC binding for OMAP3. But please discard the rest of my original series, I will repost something later. Regards, Florian I still did not merge this series wondering what to do with it. Felipe's patch on this other hand is already applied in my branch. Regards, Benoit [2] https://patchwork.kernel.org/patch/2134711/ Jon Hunter (9): ARM: OMAP2+: Prepare for device-tree PMU support ARM: dts: OMAP2+: Add PMU nodes ARM: dts: OMAP2+: Add SDMA controller bindings and nodes ARM: dts: OMAP3: Add support for OMAP3430 SDP board ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5 ARM: dts: Add OMAP3430 SDP flash memory bindings ARM: dts: Add OMAP2 gpio bindings ARM: dts: OMAP3+: Correct gpio #interrupts-cells property ARM: dts: OMAP3: Add reg and interrupt properties for gpio .../devicetree/bindings/dma/omap-sdma.txt | 51 +++ arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/omap2.dtsi | 17 +++ arch/arm/boot/dts/omap2420.dtsi| 55 arch/arm/boot/dts/omap2430.dtsi| 66 + arch/arm/boot/dts/omap3.dtsi | 70 +- arch/arm/boot/dts/omap3430-sdp.dts | 141 arch/arm/boot/dts/omap4-panda-es.dts |2 + arch/arm/boot/dts/omap4.dtsi | 64 - arch/arm/boot/dts/omap4460.dtsi| 18 +++ arch/arm/boot/dts/omap5.dtsi | 68 -- arch/arm/mach-omap2/pmu.c | 14 +- 12 files changed, 544 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts create mode 100644 arch/arm/boot/dts/omap4460.dtsi ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On Thu, Mar 14, 2013 at 12:50 PM, Jon Hunter jon-hun...@ti.com wrote: Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Ok, what is best to use? The size from hwmod structures or the size from the documentation? My personal vote is: according to hardware documentation is the right thing, and it's what we're doing in mvebu. -- Ezequiel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On 03/14/2013 04:50 PM, Jon Hunter wrote: On 03/14/2013 10:45 AM, Benoit Cousson wrote: On 03/11/2013 06:56 PM, Jon Hunter wrote: On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote: Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a minimal address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. I agree with that. I am not sure if Tony/Benoit have any comments on what they would like to do here to be consistent for the omap bindings. Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Ok, what is best to use? The size from hwmod structures or the size from the documentation? Well, in theory both are supposed to be identical :-) I'm just applying a rounding to the closet power of two, that's why it cannot be 0x2d0. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
On 03/14/2013 10:45 AM, Florian Vaussard wrote: Hi Benoit, On 03/14/2013 03:57 PM, Benoit Cousson wrote: Salut Jon, On 03/08/2013 06:27 PM, Jon Hunter wrote: Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but re-sending here as a complete series for v3.10. This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2]. [1] https://patchwork.kernel.org/patch/2057111/ I've tried to follow the series review, and it seems that Florian was considering sending some other patches. It is not clear if this is a new version of the series or some additional patches. A bit of both. Sorry for the confusion :-) Concerning patch [1], it can be merged to add the GPMC binding for OMAP3. But please discard the rest of my original series, I will repost something later. Benoit, if you pick up Florian's patch, I will re-post my remaining patches for you to pick up. By the way, I see that you have picked up the PMU bindings, however, ideally we should merge the pmu prepare patch first. We agreed with Tony for you to take this with his ack [1]. Let me know if you just want me to re-post that one on top of your branch. Cheers Jon [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/91036 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On 03/14/2013 10:58 AM, Benoit Cousson wrote: On 03/14/2013 04:50 PM, Jon Hunter wrote: On 03/14/2013 10:45 AM, Benoit Cousson wrote: On 03/11/2013 06:56 PM, Jon Hunter wrote: On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote: Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a minimal address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. I agree with that. I am not sure if Tony/Benoit have any comments on what they would like to do here to be consistent for the omap bindings. Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Ok, what is best to use? The size from hwmod structures or the size from the documentation? Well, in theory both are supposed to be identical :-) I'm just applying a rounding to the closet power of two, that's why it cannot be 0x2d0. Ok I understand. However, still not clear what you want me to use :-( Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
Hi Florian, On 01/28/2013 06:54 PM, Florian Vaussard wrote: Add device-tree support for the GPMC controller on the OMAP3. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch Applied and pushed. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson b-cous...@ti.com wrote:
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent before
individually but re-sending here as a complete series for v3.10.
This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2].
[1] https://patchwork.kernel.org/patch/2057111/
I've tried to follow the series review, and it seems that Florian was
considering sending some other patches. It is not clear if this is a new
version of the series or some additional patches.
Hi Benoit,
According to [1] Jon suggested that it was not necessary to map all
the 16MB for the GPMC mapped register address space since in practice
is a very small fraction of that size is used.
I had the following patch but I did never post it because Jon said
that the I/O memory mapping is page-aligned and the minimum page
size for ARM is 4KB anyways, so there is no functional difference
between using 0x1000 or 0x02d0.
But now reading [2] I see that you prefer to do what the documentation
said and don't assume any the page size / alignment.
[2]: https://patchwork.kernel.org/patch/2239741/
From 68edff5a102bb8fc81e006738baa456eb69f080a Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Wed, 27 Feb 2013 02:30:51 +0100
Subject: [PATCH] ARM: dts: OMAP3: reduce GPMC mapped registers address space
Currently the OMAP General-Purpose Memory Controller (GPMC) device
node maps 16 MB of address space for its hardware registers.
This is because the OMAP Technical Reference Manual says that the
GPMC module register address space size is 16 MB. But in practice
the maximum address offset used by a GPMC register is 0x02d0.
So, there is no need to map such a big address space for GPMC regs.
This change was suggested by Jon Hunter [1].
[1]: https://patchwork.kernel.org/patch/2057111/
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 2ddae38..a60eaf1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -407,7 +407,7 @@
gpmc: gpmc@6e00 {
compatible = ti,omap3430-gpmc;
ti,hwmods = gpmc;
- reg = 0x6e00 0x100;
+ reg = 0x6e00 0x02d0;
interrupts = 20;
gpmc,num-cs = 8;
gpmc,num-waitpins = 4;
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
On 03/14/2013 04:59 PM, Jon Hunter wrote: On 03/14/2013 10:45 AM, Florian Vaussard wrote: Hi Benoit, On 03/14/2013 03:57 PM, Benoit Cousson wrote: Salut Jon, On 03/08/2013 06:27 PM, Jon Hunter wrote: Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but re-sending here as a complete series for v3.10. This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2]. [1] https://patchwork.kernel.org/patch/2057111/ I've tried to follow the series review, and it seems that Florian was considering sending some other patches. It is not clear if this is a new version of the series or some additional patches. A bit of both. Sorry for the confusion :-) Concerning patch [1], it can be merged to add the GPMC binding for OMAP3. But please discard the rest of my original series, I will repost something later. Benoit, if you pick up Florian's patch, I will re-post my remaining patches for you to pick up. By the way, I see that you have picked up the PMU bindings, however, ideally we should merge the pmu prepare patch first. We agreed with Tony for you to take this with his ack [1]. OK, no problem, I'll remove it from the for_3.10/dts and get it when I'll merge your branch. Let me know if you just want me to re-post that one on top of your branch. I guess you will have to repost your branch anyway? Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
Hi Javier,
On 03/14/2013 05:02 PM, Javier Martinez Canillas wrote:
On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson b-cous...@ti.com wrote:
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent before
individually but re-sending here as a complete series for v3.10.
This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2].
[1] https://patchwork.kernel.org/patch/2057111/
I've tried to follow the series review, and it seems that Florian was
considering sending some other patches. It is not clear if this is a new
version of the series or some additional patches.
Hi Benoit,
According to [1] Jon suggested that it was not necessary to map all
the 16MB for the GPMC mapped register address space since in practice
is a very small fraction of that size is used.
I had the following patch but I did never post it because Jon said
that the I/O memory mapping is page-aligned and the minimum page
size for ARM is 4KB anyways, so there is no functional difference
between using 0x1000 or 0x02d0.
But now reading [2] I see that you prefer to do what the documentation
said and don't assume any the page size / alignment.
[2]: https://patchwork.kernel.org/patch/2239741/
From 68edff5a102bb8fc81e006738baa456eb69f080a Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Wed, 27 Feb 2013 02:30:51 +0100
Subject: [PATCH] ARM: dts: OMAP3: reduce GPMC mapped registers address space
Currently the OMAP General-Purpose Memory Controller (GPMC) device
node maps 16 MB of address space for its hardware registers.
This is because the OMAP Technical Reference Manual says that the
GPMC module register address space size is 16 MB. But in practice
the maximum address offset used by a GPMC register is 0x02d0.
So, there is no need to map such a big address space for GPMC regs.
This change was suggested by Jon Hunter [1].
[1]: https://patchwork.kernel.org/patch/2057111/
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Thanks for that super fast patch :-)
Applied.
Regards,
Benoit
---
arch/arm/boot/dts/omap3.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 2ddae38..a60eaf1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -407,7 +407,7 @@
gpmc: gpmc@6e00 {
compatible = ti,omap3430-gpmc;
ti,hwmods = gpmc;
- reg = 0x6e00 0x100;
+ reg = 0x6e00 0x02d0;
interrupts = 20;
gpmc,num-cs = 8;
gpmc,num-waitpins = 4;
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: mxcmmc: DT support
On Thu, Mar 14, 2013 at 04:50:48PM +0100, Anatolij Gustschin wrote:
On Mon, 25 Feb 2013 19:28:05 +0100
Markus Pargmann m...@pengutronix.de wrote:
Adding devicetree support for imx21-mmc and imx31-mmc. Based on generic
gpio helper functions by Guennadi and generic DMA devicetree bindings.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
.../devicetree/bindings/mmc/fsl-imx-mmc.txt| 24 +++
drivers/mmc/host/mxcmmc.c | 80
+-
2 files changed, 86 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
new file mode 100644
index 000..a5ab662
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
@@ -0,0 +1,24 @@
+* Freescale Secure Digital Host Controller for i.MX1/2 series
shouldn't it be ... for i.MX2/3 series?
...
+ if (!host-pdata) {
+ host-dma = of_dma_request_slave_channel(pdev-dev.of_node,
+ rx-tx);
please use dma_request_slave_channel(pdev-dev, rx-tx)
here. of_dma_request_slave_channel() is not exported for
modules, building the driver as a module will fail.
Thank you, I changed both in version 2.
Regards,
Markus
--
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: [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter jon-hun...@ti.com wrote:
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Documentation/devicetree/bindings/net/gpmc-eth.txt | 90
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..c45363c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,90 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width:Address width of the device in bytes. GPMC
supports 8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
I am wondering if we should use reg-io-width here. The smsc driver is
using this to determine the width of the device. And so I am wondering
if this could cause problems.
Obviously this complicates gpmc_probe_generic_child() a little, but may
be would could pass the name of the width property to
gpmc_probe_generic_child() as well. What do you think?
Hi Jon,
Well now I'm confused. I thought that both were needed since a
combination of bank-width 16-bit / reg-io-width 32-bit is also
possible (in fact that is how I'm testing on my IGEPv2) and we have
talked about this before [1].
By reading both the OMAP3 TRM and the smsc LAN9221 data-sheet, it
seems that the reg-io-width is not about the data bus address width
but the CPU address width. The smsc data-sheet says:
The simple, yet highly functional host bus interface provides a
glue-less connection to most common 16-bit microprocessors and
microcontrollers as well as 32-bit microprocessors with a 16-bit
external bus
By looking at the smsc911x driver
(drivers/net/ethernet/smsc/smsc911x.c) I see that if you use
reg-io-width = 4 (SMSC911X_USE_32BIT) then the smsc911x hardware
registers can be read in one operation and if you use reg-io-width =
2 (SMSC911X_USE_16BIT) then you need two operations to read the
register:
static inline u32 __smsc911x_reg_read(struct smsc911x_data *pdata, u32 reg)
{
if (pdata-config.flags SMSC911X_USE_32BIT)
return readl(pdata-ioaddr + reg);
if (pdata-config.flags SMSC911X_USE_16BIT)
return ((readw(pdata-ioaddr + reg) 0x) |
((readw(pdata-ioaddr + reg + 2) 0x) 16));
BUG();
return 0;
}
Also, by reading at the OMAP3 TRM, I understand that even when the
GPMC has a maximum 16-bit address width, it support devices that has
32-bit registers by doing some sort of access adaptation.
So, as far as I understand the bank-width is to configure the GPMC
if is going to use a 8-bit or 16-bit width access and the
reg-io-width is how the smsc911x driver is going to read its
registers. So, I think we need both properties and there is no need to
change gpmc_probe_generic_child() neither pass the child name to it.
But to be honest I can be wrong here since data-sheet and technical
reference manuals can be quite confusing sometimes :-)
Thanks a lot for your feedback and best regards,
Javier
[1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85597.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/5] mmc: mxcmmc: add mpc512x SDHC support
The SDHC controller on mpc512x is compatible with i.MX31 SDHC,
so the mxcmmc driver can be used on mpc512x, too. Extend the
driver to support mpc512x as well.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/mmc/host/Kconfig | 10 +-
drivers/mmc/host/mxcmmc.c | 222 +
2 files changed, 167 insertions(+), 65 deletions(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index d88219e..eda4376 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -319,12 +319,12 @@ config MMC_MSM
support for SDIO devices.
config MMC_MXC
- tristate Freescale i.MX21/27/31 Multimedia Card Interface support
- depends on ARCH_MXC
+ tristate Freescale i.MX21/27/31 or MPC512x Multimedia Card support
+ depends on ARCH_MXC || PPC_MPC512x
help
- This selects the Freescale i.MX21, i.MX27 and i.MX31 Multimedia card
- Interface. If you have a i.MX platform with a Multimedia Card slot,
- say Y or M here.
+ This selects the Freescale i.MX21, i.MX27, i.MX31 or MPC512x
+ Multimedia Card Interface. If you have an i.MX or MPC512x platform
+ with a Multimedia Card slot, say Y or M here.
If unsure, say N.
diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
index 626698b..562f4e6 100644
--- a/drivers/mmc/host/mxcmmc.c
+++ b/drivers/mmc/host/mxcmmc.c
@@ -41,7 +41,6 @@
#include asm/dma.h
#include asm/irq.h
-#include asm/sizes.h
#include linux/platform_data/mmc-mxcmmc.h
#include linux/platform_data/dma-imx.h
@@ -119,8 +118,11 @@
enum mxcmci_type {
IMX21_MMC,
IMX31_MMC,
+ MPC512X_MMC,
};
+struct mxcmci_reg_ops;
+
struct mxcmci_host {
struct mmc_host *mmc;
struct resource *res;
@@ -162,6 +164,8 @@ struct mxcmci_host {
struct timer_list watchdog;
enum mxcmci_typedevtype;
+
+ struct mxcmci_reg_ops *reg_ops;
};
static struct platform_device_id mxcmci_devtype[] = {
@@ -172,6 +176,9 @@ static struct platform_device_id mxcmci_devtype[] = {
.name = imx31-mmc,
.driver_data = IMX31_MMC,
}, {
+ .name = mpc512x-sdhc,
+ .driver_data = MPC512X_MMC,
+ }, {
/* sentinel */
}
};
@@ -185,6 +192,9 @@ static const struct of_device_id mxcmci_of_match[] = {
.compatible = fsl,imx31-mmc,
.data = mxcmci_devtype[IMX31_MMC],
}, {
+ .compatible = fsl,mpc5121-sdhc,
+ .data = mxcmci_devtype[MPC512X_MMC],
+ }, {
/* sentinel */
}
};
@@ -195,6 +205,81 @@ static inline int is_imx31_mmc(struct mxcmci_host *host)
return host-devtype == IMX31_MMC;
}
+static inline int is_mpc512x_mmc(struct mxcmci_host *host)
+{
+ return host-devtype == MPC512X_MMC;
+}
+
+struct mxcmci_reg_ops {
+ void(*write_l)(struct mxcmci_host *host, u32 val, int reg);
+ u32 (*read_l)(struct mxcmci_host *host, int reg);
+ void(*write_w)(struct mxcmci_host *host, u16 val, int reg);
+ u16 (*read_w)(struct mxcmci_host *host, int reg);
+};
+
+#if IS_ENABLED(CONFIG_PPC_MPC512x)
+static void mpcmci_writel(struct mxcmci_host *host, u32 val, int reg)
+{
+ out_be32(host-base + reg, val);
+}
+
+static u32 mpcmci_readl(struct mxcmci_host *host, int reg)
+{
+ return in_be32(host-base + reg);
+}
+
+static void mpcmci_writew(struct mxcmci_host *host, u16 val, int reg)
+{
+ out_be32(host-base + reg, val);
+}
+
+static u16 mpcmci_readw(struct mxcmci_host *host, int reg)
+{
+ return in_be32(host-base + reg);
+}
+
+struct mxcmci_reg_ops mxcmci_reg_ops = {
+ .read_l = mpcmci_readl,
+ .write_l = mpcmci_writel,
+ .read_w = mpcmci_readw,
+ .write_w = mpcmci_writew,
+};
+#else
+struct mxcmci_reg_ops mxcmci_reg_ops;
+#endif
+
+static inline u32 mxcmci_readl(struct mxcmci_host *host, int reg)
+{
+ if (host-reg_ops-read_l)
+ return host-reg_ops-read_l(host, reg);
+ else
+ return readl(host-base + reg);
+}
+
+static inline void mxcmci_writel(struct mxcmci_host *host, u32 val, int reg)
+{
+ if (host-reg_ops-write_l)
+ host-reg_ops-write_l(host, val, reg);
+ else
+ writel(val, host-base + reg);
+}
+
+static inline u16 mxcmci_readw(struct mxcmci_host *host, int reg)
+{
+ if (host-reg_ops-read_w)
+ return host-reg_ops-read_w(host, reg);
+ else
+ return readw(host-base + reg);
+}
+
+static inline void mxcmci_writew(struct mxcmci_host *host, u16 val, int reg)
+{
+ if (host-reg_ops-write_w)
+ host-reg_ops-write_w(host, val, reg);
+ else
+ writew(val, host-base + reg);
+}
+
static void mxcmci_set_clk_rate(struct mxcmci_host *host, unsigned int
clk_ios);
static inline void
[PATCH 2/5] mmc: mxcmmc: use slot-gpio API for write-protect detection
slot-gpio API suppors read-only detection when wp-gpios property is present in the device tree mmc node. Use this API for write-protect detection. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/mmc/host/mxcmmc.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c index 562f4e6..dc25802 100644 --- a/drivers/mmc/host/mxcmmc.c +++ b/drivers/mmc/host/mxcmmc.c @@ -38,6 +38,7 @@ #include linux/of_device.h #include linux/of_dma.h #include linux/of_gpio.h +#include linux/mmc/slot-gpio.h #include asm/dma.h #include asm/irq.h @@ -943,10 +944,11 @@ static int mxcmci_get_ro(struct mmc_host *mmc) if (host-pdata host-pdata-get_ro) return !!host-pdata-get_ro(mmc_dev(mmc)); /* -* Board doesn't support read only detection; let the mmc core -* decide what to do. +* If board doesn't support read only detection (no mmc_gpio +* context or gpio is invalid), then let the mmc core decide +* what to do. */ - return -ENOSYS; + return mmc_gpio_get_ro(mmc); } static void mxcmci_enable_sdio_irq(struct mmc_host *mmc, int enable) -- 1.7.5.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/5] mmc: mxcmmc: constify mxcmci_devtype and fix build warning
Fix:
drivers/mmc/host/mxcmmc.c: In function 'mxcmci_probe':
drivers/mmc/host/mxcmmc.c:1137:41: warning: initialization discards
'const' qualifier from pointer target type [enabled by default]
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/mmc/host/mxcmmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
index dc25802..c0115e9 100644
--- a/drivers/mmc/host/mxcmmc.c
+++ b/drivers/mmc/host/mxcmmc.c
@@ -169,7 +169,7 @@ struct mxcmci_host {
struct mxcmci_reg_ops *reg_ops;
};
-static struct platform_device_id mxcmci_devtype[] = {
+static const struct platform_device_id mxcmci_devtype[] = {
{
.name = imx21-mmc,
.driver_data = IMX21_MMC,
@@ -1091,7 +1091,7 @@ static int mxcmci_probe(struct platform_device *pdev)
host-reg_ops = mxcmci_reg_ops;
if (of_id) {
- struct platform_device_id *id_entry = of_id-data;
+ const struct platform_device_id *id_entry = of_id-data;
host-devtype = id_entry-driver_data;
} else {
host-devtype = pdev-id_entry-driver_data;
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/5] mmc: mxcmmc: fix race conditions for host-req and host-data access
mxcmci_dma_callback() is invoked by DMA drivers in soft-irq
context and can be interrupted by the mxcmci_irq() interrupt
which can finish the mmc request or data transfer and set
host-req or host-data pointers to NULL. Then mxcmci_data_done()
crashes with a null pointer dereferences. Protect all accesses
to host-req and host-data by spin locks.
Also check host-data pointer in mxcmci_watchdog() before
dereferencing it.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/mmc/host/mxcmmc.c | 31 ---
1 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
index 48e3fd8..aef6299 100644
--- a/drivers/mmc/host/mxcmmc.c
+++ b/drivers/mmc/host/mxcmmc.c
@@ -736,24 +736,40 @@ static void mxcmci_datawork(struct work_struct *work)
static void mxcmci_data_done(struct mxcmci_host *host, unsigned int stat)
{
- struct mmc_data *data = host-data;
+ struct mmc_request *req;
int data_error;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-lock, flags);
- if (!data)
+ if (!host-data) {
+ spin_unlock_irqrestore(host-lock, flags);
return;
+ }
+
+ if (!host-req) {
+ spin_unlock_irqrestore(host-lock, flags);
+ return;
+ }
+
+ req = host-req;
+ if (!req-stop)
+ host-req = NULL; /* we will handle finish req below */
data_error = mxcmci_finish_data(host, stat);
+ spin_unlock_irqrestore(host-lock, flags);
+
mxcmci_read_response(host, stat);
host-cmd = NULL;
- if (host-req-stop) {
- if (mxcmci_start_cmd(host, host-req-stop, 0)) {
- mxcmci_finish_request(host, host-req);
+ if (req-stop) {
+ if (mxcmci_start_cmd(host, req-stop, 0)) {
+ mxcmci_finish_request(host, req);
return;
}
} else {
- mxcmci_finish_request(host, host-req);
+ mxcmci_finish_request(host, req);
}
}
@@ -1047,7 +1063,8 @@ static void mxcmci_watchdog(unsigned long data)
/* Mark transfer as erroneus and inform the upper layers */
- host-data-error = -ETIMEDOUT;
+ if (host-data)
+ host-data-error = -ETIMEDOUT;
host-req = NULL;
host-cmd = NULL;
host-data = NULL;
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] mmc: mxcmmc: add mpc512x SDHC support
On Thursday 14 March 2013 17:40:49 Anatolij Gustschin wrote:
+
+struct mxcmci_reg_ops mxcmci_reg_ops = {
+ .read_l = mpcmci_readl,
+ .write_l = mpcmci_writel,
+ .read_w = mpcmci_readw,
+ .write_w = mpcmci_writew,
+};
+#else
+struct mxcmci_reg_ops mxcmci_reg_ops;
+#endif
Should the struct be static?
+static inline u32 mxcmci_readl(struct mxcmci_host *host, int reg)
+{
+ if (host-reg_ops-read_l)
+ return host-reg_ops-read_l(host, reg);
+ else
+ return readl(host-base + reg);
+}
This seems a bit strange. I would suggest you either use the ops structure
all the time and provide an imx variant, or you make it completely
compile-time selected.
@@ -1026,24 +1115,33 @@ static int mxcmci_probe(struct platform_device *pdev)
host-res = r;
host-irq = irq;
- host-clk_ipg = devm_clk_get(pdev-dev, ipg);
- if (IS_ERR(host-clk_ipg)) {
- ret = PTR_ERR(host-clk_ipg);
- goto out_iounmap;
- }
+ if (!is_mpc512x_mmc(host)) {
+ host-clk_ipg = devm_clk_get(pdev-dev, ipg);
+ if (IS_ERR(host-clk_ipg)) {
+ ret = PTR_ERR(host-clk_ipg);
+ goto out_iounmap;
+ }
Does mpc512x have no clock management? I think it should still
work without modifications if CONFIG_HAVE_CLK is disabled.
In that case, devm_clk_get() will return NULL and we don't
error out here.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Roger Quadros rog...@ti.com [130314 08:45]:
OK. Let me know how the below patch looks. After that, the board code
will look like.
static struct usbhs_phy_data phy_data[] = {
{
.reset_gpio = 147,
.vcc_gpio = 148
.vcc_polarity = 1,
.phy_id = nop_usb_xceiv.2,
},
{}, /* Terminator */
};
usbhs_init_phys(phy_data);
Great, looks good to me.
Patch to implement usbhs_init_phys();
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 5706bdc..b9d6bff 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -22,8 +22,12 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/dma-mapping.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
+#include linux/string.h
#include asm/io.h
+#include asm/gpio.h
Please change these both to linux/io.h and linux/gpio.h.
#include soc.h
#include omap_device.h
@@ -472,6 +476,141 @@ void __init setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
}
}
+static const char *reset_supply = reset;
+static const char *vcc_supply = vcc;
+
+/* Template for PHY regulators */
+static struct regulator_consumer_supply hsusb_reg_supplies[] = {
+ { /* .supply .dev_name filled later */ },
+};
+
+static struct regulator_init_data hsusb_reg_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .consumer_supplies = hsusb_reg_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(hsusb_reg_supplies),
+};
+
+static struct fixed_voltage_config hsusb_reg_config = {
+ /* .supply_name filled later */
+ .microvolts = 330,
+ .gpio = -1, /* updated later */
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1, /* updated later */
+ .enabled_at_boot = 0, /* keep in RESET */
+ /* .init_data filled later */
+};
+
+static struct platform_device_info hsusb_reg_pdev_info = {
+ .name = reg-fixed-voltage,
+ .id = PLATFORM_DEVID_AUTO,
+};
+
+int __init usbhs_init_phys(struct usbhs_phy_data *phy)
+{
+ struct regulator_consumer_supply *supplies;
+ struct regulator_init_data *reg_data;
+ struct fixed_voltage_config *config;
+ char *supply_name;
+ int i;
+
+
+ for (i = 1; i = OMAP3_HS_USB_PORTS; i++) {
Maybe pass the number of ports to initialize too to the
function? Might be more future proof, although it will only
be needed until we have converted to DT.
+
+ if (!phy-phy_id) /* Terminator ? */
+ break;
+
+ if (!gpio_is_valid(phy-reset_gpio))
+ goto check_vcc;
+
+ supplies = kmemdup(hsusb_reg_supplies,
+ ARRAY_SIZE(hsusb_reg_supplies) *
+ sizeof(struct regulator_consumer_supply),
+ GFP_KERNEL);
+ if (!supplies)
+ return -ENOMEM;
+
+ supplies-supply = reset_supply;
+ supplies-dev_name = phy-phy_id;
+
+ reg_data = kmemdup(hsusb_reg_data, sizeof(hsusb_reg_data),
+ GFP_KERNEL);
+ if (!reg_data)
+ return -ENOMEM;
+
+ reg_data-consumer_supplies = supplies;
+
+ config = kmemdup(hsusb_reg_config, sizeof(hsusb_reg_config),
+ GFP_KERNEL);
+ if (!config)
+ return -ENOMEM;
+
+ supply_name = kmalloc(14, GFP_KERNEL);
+ if (!supply_name)
+ return -ENOMEM;
+
+ scnprintf(supply_name, 13, hsusb%d_reset, i);
+ config-supply_name = supply_name;
+ config-gpio = phy-reset_gpio;
+ config-init_data = reg_data;
+
+ hsusb_reg_pdev_info.data = config;
+ hsusb_reg_pdev_info.size_data = sizeof(hsusb_reg_config);
+ platform_device_register_full(hsusb_reg_pdev_info);
+
+check_vcc:
+ if (!gpio_is_valid(phy-vcc_gpio))
+ goto next;
+
+ supplies = kmemdup(hsusb_reg_supplies,
+ ARRAY_SIZE(hsusb_reg_supplies) *
+ sizeof(struct regulator_consumer_supply),
+ GFP_KERNEL);
+ if (!supplies)
+ return -ENOMEM;
+
+ supplies-supply = vcc_supply;
+ supplies-dev_name = phy-phy_id;
+
+ reg_data = kmemdup(hsusb_reg_data, sizeof(hsusb_reg_data),
+ GFP_KERNEL);
+ if (!reg_data)
+ return -ENOMEM;
+
+ reg_data-consumer_supplies = supplies;
+
+ config =
Re: [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On Thu, Mar 14, 2013 at 5:37 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter jon-hun...@ti.com wrote: Hi Javier, On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote: Besides being used to interface with external memory devices, the General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices such as ethernet controllers to OMAP2+ processors using the TI GPMC as a data bus. This patch allows an ethernet chip to be defined as an GPMC child device node. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Documentation/devicetree/bindings/net/gpmc-eth.txt | 90 arch/arm/mach-omap2/gpmc.c |8 ++ 2 files changed, 98 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt new file mode 100644 index 000..c45363c --- /dev/null +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt @@ -0,0 +1,90 @@ +Device tree bindings for Ethernet chip connected to TI GPMC + +Besides being used to interface with external memory devices, the +General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices +such as ethernet controllers to processors using the TI GPMC as a data bus. + +Ethernet controllers connected to TI GPMC are represented as child nodes of +the GPMC controller with an ethernet name. + +All timing relevant properties as well as generic GPMC child properties are +explained in a separate documents. Please refer to +Documentation/devicetree/bindings/bus/ti-gpmc.txt + +Required properties: +- bank-width:Address width of the device in bytes. GPMC supports 8-bit + and 16-bit devices and so must be either 1 or 2 bytes. I am wondering if we should use reg-io-width here. The smsc driver is using this to determine the width of the device. And so I am wondering if this could cause problems. Obviously this complicates gpmc_probe_generic_child() a little, but may be would could pass the name of the width property to gpmc_probe_generic_child() as well. What do you think? Hi Jon, Well now I'm confused. I thought that both were needed since a combination of bank-width 16-bit / reg-io-width 32-bit is also possible (in fact that is how I'm testing on my IGEPv2) and we have talked about this before [1]. By reading both the OMAP3 TRM and the smsc LAN9221 data-sheet, it seems that the reg-io-width is not about the data bus address width but the CPU address width. The smsc data-sheet says: Hi Jon, By the way, here is the smsc LAN9221 data-sheet if you don't have it and want to take it a look: http://www.smsc.com/Downloads/SMSC/Downloads_Public/Data_Sheets/9221.pdf Thanks a lot and best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems
[trimm'd the cc list]
On Thu, Mar 14, 2013 at 10:01:20AM +0100, Thierry Reding wrote:
It turns out that this works with the Tegra driver because it uses the
new of_pci_process_ranges() function and simply overwrites earlier
matches by subsequent ones.
ranges = 0x8200 0 0 0x8000 0 0x1000 /* port 0 registers
*/
0x8200 0 0 0x80001000 0 0x1000 /* port 1 registers
*/
0x8100 0 0 0x8200 0 0x0001 /* downstream I/O */
0x8200 0 0 0xa000 0 0x1000 /* non-prefetchable
memory */
0xc200 0 0 0xb000 0 0x1000; /* prefetchable
memory */
Okay.. There is still something funny here, the 3rd dword of the child
address should not be 0 in every line and there shouldn't be overlaps
in the child address space.
I'm assuming 0x8000, 0xa000 and 0xb000 are real CPU physical
addresses?
Then it should probably look like:
ranges = 0x8200 0 0x8000 0x8000 0 0x1000 /* port 0
registers */
0x8200 0 0x80001000 0x80001000 0 0x1000 /* port 1
registers */
0x8100 0 0 0x8200 0 0x0001 /* downstream I/O
*/
0x8200 0 0xa000 0xa000 0 0x1000 /*
non-prefetchable memory */
0xc200 0 0xb000 0xb000 0 0x1000; /* prefetchable
memory */
Which says 'access to CPU address 0xa000 produces a PCI-E memory TLP with
address 0xa000' - this is the 'normal' case, I assume that is what
happens on tegra?
It also says 'access to CPU address 0x8200 produces a PCI-E IO TLP
with address 0' - this translation is something Linux typically
expects..
Then you'd go on to have:
pci@1,0 {
device_type = pci;
assigned-addresses = 0x8200 0 0x8000 0
0x1000;
reg = 0x000800 0 0 0 0;
}
pci@2,0 {
device_type = pci;
assigned-addresses = 0x8200 0 0x80001000 0
0x1000;
reg = 0x001000 0 0 0 0;
}
Notice I've made the upper dw of assigned-addresses's size 0 and
included the full 3dw from the appropriate ranges line.
So the above will actually work along with the corresponding root-port
assigned-addresses properties. I still don't like it much because I
don't think it accurately reflects the hardware.
There are lots of valid ways to model the same HW :(
Bear in mind, for the PCI case - the OF PCI bindings model the HW
through the eyes of the abstractions in the PCI specification. That is
to say, they are not supposed to be an exact representation of the on
chip architecture.
Perhaps this would be clearer if you used 'pcie-root-complex' as the
name of the top level node?
same kludgy, non-spec conformant smack that my original proposal had
because it uses assigned-addresses for something it wasn't intended
to.
Yes, only the top level 'reg' method avoids going outside any specs.
Regards,
Jason
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] mv643xx_eth: use mvmdio MDIO bus driver
Florian, Any word on version 2 of this series? I'd like to base the conversion of kirkwood to DT based ethernet init on it. thx, Jason. On Tue, Jan 29, 2013 at 04:24:03PM +0100, Florian Fainelli wrote: Hi all, This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver instead of rolling its own implementation. As a result, all users of this mv643xx_eth driver are converted to register an orion-mdio platform_device. The mvmdio driver is also updated to support an interrupt line which reports SMI error/completion, and to allow traditionnal platform device registration instead of just device tree. David, I think it makes sense for you to merge all of this, since we do not want the architecture files to be desynchronized from the mv643xx_eth to avoid runtime breakage. The potential for merge conflicts should be very small. You can probably safely merge patches 1 to 4 if Thomas agrees, and we will see what kind of feeback I get on patch 5. Florian Fainelli (5): net: mvmdio: unmap base register address at driver removal net: mvmdio: rename base register cookie from smireg to regs net: mvmdio: enhance driver to support SMI error/done interrupts net: mvmdio: allow Device Tree and platform device to coexist mv643xx_eth: convert to use the Marvell Orion MDIO driver .../devicetree/bindings/net/marvell-orion-mdio.txt |3 + arch/arm/plat-orion/common.c | 84 +++-- arch/powerpc/platforms/chrp/pegasos_eth.c | 20 +++ arch/powerpc/sysdev/mv64x60_dev.c | 14 +- drivers/net/ethernet/marvell/Kconfig |1 + drivers/net/ethernet/marvell/mv643xx_eth.c | 187 +--- drivers/net/ethernet/marvell/mvmdio.c | 136 +++--- 7 files changed, 226 insertions(+), 219 deletions(-) -- 1.7.10.4 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: GPIO polarity in bindings for Freescale MXS
On 03/14/2013 04:02 AM, Hector Palacios wrote: Hello, Maybe I'm missing something but the MXS processors (at least i.MX23 and i.MX28) cannot set the polarity of the GPIOs, so shouldn't the #gpio-cells be 1? (From Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt): - #gpio-cells : Should be two. The first cell is the pin number and the second cell is used to specify the gpio polarity: 0 = active high 1 = active low This field describes how software should interpret the GPIO values. So, if the GPIO is specified as active-high, then software will gpio_set_value(the_value_it_wants), whereas if the GPIO is specified as active-low, then software will gpio_set_value(!the_value_it_wants). Note that software here refers to the driver that requests/uses the GPIO, and the flags can be retrieve using of_get_gpio_flags(). ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] mv643xx_eth: use mvmdio MDIO bus driver
Hello Jason, Le 03/14/13 18:25, Jason Cooper a écrit : Florian, Any word on version 2 of this series? I'd like to base the conversion of kirkwood to DT based ethernet init on it. Just sent them out for review, thanks for reminder, they were sitting in my tree for a couple days already. -- Florian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] mmc: mxcmmc: add mpc512x SDHC support
On Thu, 14 Mar 2013 17:50:08 +0100
Arnd Bergmann a...@arndb.de wrote:
On Thursday 14 March 2013 17:40:49 Anatolij Gustschin wrote:
+
+struct mxcmci_reg_ops mxcmci_reg_ops = {
+ .read_l = mpcmci_readl,
+ .write_l = mpcmci_writel,
+ .read_w = mpcmci_readw,
+ .write_w = mpcmci_writew,
+};
+#else
+struct mxcmci_reg_ops mxcmci_reg_ops;
+#endif
Should the struct be static?
yes, it should.
+static inline u32 mxcmci_readl(struct mxcmci_host *host, int reg)
+{
+ if (host-reg_ops-read_l)
+ return host-reg_ops-read_l(host, reg);
+ else
+ return readl(host-base + reg);
+}
This seems a bit strange. I would suggest you either use the ops structure
all the time and provide an imx variant, or you make it completely
compile-time selected.
I wanted to avoid additional levels of indirection and function calls
on i.MX. If something like
static inline u32 mxcmci_readl(struct mxcmci_host *host, int reg)
{
#if IS_ENABLED(CONFIG_PPC_MPC512x)
return in_be32(host-base + reg);
#else
return readl(host-base + reg);
#endif
}
is acceptable, I'll use it.
@@ -1026,24 +1115,33 @@ static int mxcmci_probe(struct platform_device
*pdev)
host-res = r;
host-irq = irq;
- host-clk_ipg = devm_clk_get(pdev-dev, ipg);
- if (IS_ERR(host-clk_ipg)) {
- ret = PTR_ERR(host-clk_ipg);
- goto out_iounmap;
- }
+ if (!is_mpc512x_mmc(host)) {
+ host-clk_ipg = devm_clk_get(pdev-dev, ipg);
+ if (IS_ERR(host-clk_ipg)) {
+ ret = PTR_ERR(host-clk_ipg);
+ goto out_iounmap;
+ }
Does mpc512x have no clock management? I think it should still
work without modifications if CONFIG_HAVE_CLK is disabled.
In that case, devm_clk_get() will return NULL and we don't
error out here.
It does have some clock management (a platform clock driver) and
the platform selects CONFIG_HAVE_CLK. But we do not have ipg
and per clocks on that platform, but sdhc_clk instead.
Thanks,
Anatolij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5] mmc: mxcmmc: constify mxcmci_devtype and fix build warning
On Thu, 14 Mar 2013 17:40:52 +0100 Anatolij Gustschin ag...@denx.de wrote: Fix: drivers/mmc/host/mxcmmc.c: In function 'mxcmci_probe': drivers/mmc/host/mxcmmc.c:1137:41: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/mmc/host/mxcmmc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) that one has been sent by accident, please ignore it. Sorry for that. Anatolij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] mv643xx_eth: use mvmdio MDIO bus driver
On Thu, Mar 14, 2013 at 07:09:18PM +0100, Florian Fainelli wrote: Hello Jason, Le 03/14/13 18:25, Jason Cooper a écrit : Florian, Any word on version 2 of this series? I'd like to base the conversion of kirkwood to DT based ethernet init on it. Just sent them out for review, thanks for reminder, they were sitting in my tree for a couple days already. Great! I'll give this a spin. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
Hi all, This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver instead of rolling its own implementation. As a result, all users of this mv643xx_eth driver are converted to register an orion-mdio platform_device. The mvmdio driver is also updated to support an interrupt line which reports SMI error/completion, and to allow traditionnal platform device registration instead of just device tree. David, I think it makes sense for you to merge all of this, since we do not want the architecture files to be desynchronized from the mv643xx_eth to avoid runtime breakage. The potential for merge conflicts should be very small. Florian Fainelli (4): net: mvmdio: allow platform device style registration net: mvmdio: rename base register cookie from smireg to regs net: mvmdio: enhance driver to support SMI error/done interrupts mv643xx_eth: convert to use the Marvell Orion MDIO driver .../devicetree/bindings/net/marvell-orion-mdio.txt |3 + arch/arm/plat-orion/common.c | 97 +++--- arch/powerpc/platforms/chrp/pegasos_eth.c | 20 +++ arch/powerpc/sysdev/mv64x60_dev.c | 14 +- drivers/net/ethernet/marvell/Kconfig |1 + drivers/net/ethernet/marvell/mv643xx_eth.c | 186 +--- drivers/net/ethernet/marvell/mvmdio.c | 111 +--- include/linux/mv643xx_eth.h|1 - 8 files changed, 207 insertions(+), 226 deletions(-) -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/4 v2] net: mvmdio: rename base register cookie from smireg to regs
This patch renames the base register cookie in the mvmdio drive from
smireg to regs since a subsequent patch is going to use an ioremap()
cookie whose size is larger than a single register of 4 bytes. No
functionnal code change introduced.
Acked-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Florian Fainelli flor...@openwrt.org
---
Changes since v1:
- added Thomas Acked-by tag
drivers/net/ethernet/marvell/mvmdio.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c
b/drivers/net/ethernet/marvell/mvmdio.c
index 8a182f1..595deea 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -38,7 +38,7 @@
struct orion_mdio_dev {
struct mutex lock;
- void __iomem *smireg;
+ void __iomem *regs;
};
/* Wait for the SMI unit to be ready for another operation
@@ -51,7 +51,7 @@ static int orion_mdio_wait_ready(struct mii_bus *bus)
count = 0;
while (1) {
- val = readl(dev-smireg);
+ val = readl(dev-regs);
if (!(val MVMDIO_SMI_BUSY))
break;
@@ -86,12 +86,12 @@ static int orion_mdio_read(struct mii_bus *bus, int mii_id,
writel(((mii_id MVMDIO_SMI_PHY_ADDR_SHIFT) |
(regnum MVMDIO_SMI_PHY_REG_SHIFT) |
MVMDIO_SMI_READ_OPERATION),
- dev-smireg);
+ dev-regs);
/* Wait for the value to become available */
count = 0;
while (1) {
- val = readl(dev-smireg);
+ val = readl(dev-regs);
if (val MVMDIO_SMI_READ_VALID)
break;
@@ -128,7 +128,7 @@ static int orion_mdio_write(struct mii_bus *bus, int mii_id,
(regnum MVMDIO_SMI_PHY_REG_SHIFT) |
MVMDIO_SMI_WRITE_OPERATION|
(value MVMDIO_SMI_DATA_SHIFT)),
- dev-smireg);
+ dev-regs);
mutex_unlock(dev-lock);
@@ -177,8 +177,8 @@ static int orion_mdio_probe(struct platform_device *pdev)
bus-irq[i] = PHY_POLL;
dev = bus-priv;
- dev-smireg = devm_ioremap(pdev-dev, r-start, resource_size(r));
- if (!dev-smireg) {
+ dev-regs = devm_ioremap(pdev-dev, r-start, resource_size(r));
+ if (!dev-regs) {
dev_err(pdev-dev, Unable to remap SMI register\n);
kfree(bus-irq);
mdiobus_free(bus);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/4 v2] net: mvmdio: enhance driver to support SMI error/done interrupts
This patch enhances the mvmdio to support a SMI error/done interrupt
line which can be used along with a wait queue instead of doing
busy-waiting on the registers. This is a feature which is available in
the mv643xx_eth SMI code and thus reduces again the gap between the two.
Signed-off-by: Florian Fainelli flor...@openwrt.org
---
Chances since v1:
- always use orion_smi_is_done() helper
- make interrupt/non-interrupt code path entirely independant
.../devicetree/bindings/net/marvell-orion-mdio.txt |3 +
drivers/net/ethernet/marvell/mvmdio.c | 83 +---
2 files changed, 74 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index 34e7aaf..052b5f2 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -9,6 +9,9 @@ Required properties:
- compatible: marvell,orion-mdio
- reg: address and length of the SMI register
+Optional properties:
+- interrupts: interrupt line number for the SMI error/done interrupt
+
The child nodes of the MDIO driver are the individual PHY devices
connected to this MDIO bus. They must have a reg property given the
PHY address on the MDIO bus.
diff --git a/drivers/net/ethernet/marvell/mvmdio.c
b/drivers/net/ethernet/marvell/mvmdio.c
index 595deea..7ac83de 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -24,9 +24,12 @@
#include linux/module.h
#include linux/mutex.h
#include linux/phy.h
+#include linux/interrupt.h
#include linux/platform_device.h
#include linux/delay.h
#include linux/io.h
+#include linux/sched.h
+#include linux/wait.h
#define MVMDIO_SMI_DATA_SHIFT 0
#define MVMDIO_SMI_PHY_ADDR_SHIFT 16
@@ -35,33 +38,58 @@
#define MVMDIO_SMI_WRITE_OPERATION 0
#define MVMDIO_SMI_READ_VALID BIT(27)
#define MVMDIO_SMI_BUSYBIT(28)
+#define MVMDIO_ERR_INT_CAUSE 0x007C
+#define MVMDIO_ERR_INT_SMI_DONE 0x0010
+#define MVMDIO_ERR_INT_MASK 0x0080
struct orion_mdio_dev {
struct mutex lock;
void __iomem *regs;
+ /*
+* If we have access to the error interrupt pin (which is
+* somewhat misnamed as it not only reflects internal errors
+* but also reflects SMI completion), use that to wait for
+* SMI access completion instead of polling the SMI busy bit.
+*/
+ int err_interrupt;
+ wait_queue_head_t smi_busy_wait;
};
+static int orion_mdio_smi_is_done(struct orion_mdio_dev *dev)
+{
+ return !(readl(dev-regs) MVMDIO_SMI_BUSY);
+}
+
/* Wait for the SMI unit to be ready for another operation
*/
static int orion_mdio_wait_ready(struct mii_bus *bus)
{
struct orion_mdio_dev *dev = bus-priv;
int count;
- u32 val;
- count = 0;
- while (1) {
- val = readl(dev-regs);
- if (!(val MVMDIO_SMI_BUSY))
- break;
+ if (dev-err_interrupt == NO_IRQ) {
+ count = 0;
+ while (1) {
+ if (orion_mdio_smi_is_done(dev))
+ break;
- if (count 100) {
- dev_err(bus-parent, Timeout: SMI busy for too
long\n);
- return -ETIMEDOUT;
- }
+ if (count 100) {
+ dev_err(bus-parent,
+ Timeout: SMI busy for too long\n);
+ return -ETIMEDOUT;
+ }
- udelay(10);
- count++;
+ udelay(10);
+ count++;
+ }
+ } else {
+ if (!orion_mdio_smi_is_done(dev)) {
+ wait_event_timeout(dev-smi_busy_wait,
+ orion_mdio_smi_is_done(dev),
+ msecs_to_jiffies(100));
+ if (!orion_mdio_smi_is_done(dev))
+ return -ETIMEDOUT;
+ }
}
return 0;
@@ -140,6 +168,21 @@ static int orion_mdio_reset(struct mii_bus *bus)
return 0;
}
+static irqreturn_t orion_mdio_err_irq(int irq, void *dev_id)
+{
+ struct orion_mdio_dev *dev = dev_id;
+
+ if (readl(dev-regs + MVMDIO_ERR_INT_CAUSE)
+ MVMDIO_ERR_INT_SMI_DONE) {
+ writel(~MVMDIO_ERR_INT_SMI_DONE,
+ dev-regs + MVMDIO_ERR_INT_CAUSE);
+ wake_up(dev-smi_busy_wait);
+ return IRQ_HANDLED;
+ }
+
+ return IRQ_NONE;
+}
+
static int orion_mdio_probe(struct platform_device *pdev)
{
struct resource *r;
@@ -185,6 +228,19 @@ static int orion_mdio_probe(struct
[PATCH] mv643xx_eth: convert to use the Marvell Orion MDIO driver
This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell MV643XX ethernet driver are also updated to
register a Marvell Orion MDIO driver. This driver voluntarily overlaps
with the Marvell Ethernet shared registers because it will use a subset
of this shared register (shared_base + 0x4 - shared_base + 0x84). The
Ethernet driver is also updated to look up for a PHY device using the
Orion MDIO bus driver.
Signed-off-by: Florian Fainelli flor...@openwrt.org
---
arch/arm/plat-orion/common.c | 97 +++
arch/powerpc/platforms/chrp/pegasos_eth.c | 20 +++
arch/powerpc/sysdev/mv64x60_dev.c | 14 ++-
drivers/net/ethernet/marvell/Kconfig |1 +
drivers/net/ethernet/marvell/mv643xx_eth.c | 186 ++--
include/linux/mv643xx_eth.h|1 -
6 files changed, 117 insertions(+), 202 deletions(-)
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index 2d4b641..dc4345e 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -238,6 +238,7 @@ static __init void ge_complete(
struct mv643xx_eth_shared_platform_data *orion_ge_shared_data,
struct resource *orion_ge_resource, unsigned long irq,
struct platform_device *orion_ge_shared,
+ struct platform_device *orion_ge_mvmdio,
struct mv643xx_eth_platform_data *eth_data,
struct platform_device *orion_ge)
{
@@ -247,6 +248,8 @@ static __init void ge_complete(
orion_ge-dev.platform_data = eth_data;
platform_device_register(orion_ge_shared);
+ if (orion_ge_mvmdio)
+ platform_device_register(orion_ge_mvmdio);
platform_device_register(orion_ge);
}
@@ -258,8 +261,6 @@ struct mv643xx_eth_shared_platform_data
orion_ge00_shared_data;
static struct resource orion_ge00_shared_resources[] = {
{
.name = ge00 base,
- }, {
- .name = ge00 err irq,
},
};
@@ -271,6 +272,19 @@ static struct platform_device orion_ge00_shared = {
},
};
+static struct resource orion_ge00_mvmdio_resources[] = {
+ {
+ .name = ge00 mvmdio base,
+ }, {
+ .name = ge00 mvmdio irr irq,
+ },
+};
+
+static struct platform_device orion_ge00_mvmdio = {
+ .name = orion-mdio,
+ .id = 0,
+};
+
static struct resource orion_ge00_resources[] = {
{
.name = ge00 irq,
@@ -295,26 +309,25 @@ void __init orion_ge00_init(struct
mv643xx_eth_platform_data *eth_data,
unsigned int tx_csum_limit)
{
fill_resources(orion_ge00_shared, orion_ge00_shared_resources,
- mapbase + 0x2000, SZ_16K - 1, irq_err);
+ mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
+ fill_resources(orion_ge00_mvmdio, orion_ge00_mvmdio_resources,
+ mapbase + 0x2004, 0x84 - 1, irq_err);
orion_ge00_shared_data.tx_csum_limit = tx_csum_limit;
ge_complete(orion_ge00_shared_data,
orion_ge00_resources, irq, orion_ge00_shared,
+ orion_ge00_mvmdio,
eth_data, orion_ge00);
}
/*
* GE01
/
-struct mv643xx_eth_shared_platform_data orion_ge01_shared_data = {
- .shared_smi = orion_ge00_shared,
-};
+struct mv643xx_eth_shared_platform_data orion_ge01_shared_data;
static struct resource orion_ge01_shared_resources[] = {
{
.name = ge01 base,
- }, {
- .name = ge01 err irq,
- },
+ }
};
static struct platform_device orion_ge01_shared = {
@@ -325,6 +338,19 @@ static struct platform_device orion_ge01_shared = {
},
};
+static struct resource orion_ge01_mvmdio_resources[] = {
+ {
+ .name = ge01 mdio base,
+ }, {
+ .name = ge01 mdio err irq,
+ },
+};
+
+static struct platform_device orion_ge01_mvmdio = {
+ .name = orion-mdio,
+ .id = 1,
+};
+
static struct resource orion_ge01_resources[] = {
{
.name = ge01 irq,
@@ -349,26 +375,25 @@ void __init orion_ge01_init(struct
mv643xx_eth_platform_data *eth_data,
unsigned int tx_csum_limit)
{
fill_resources(orion_ge01_shared, orion_ge01_shared_resources,
- mapbase + 0x2000, SZ_16K - 1, irq_err);
+ mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
+ fill_resources(orion_ge01_mvmdio, orion_ge01_mvmdio_resources,
+ mapbase + 0x2004, 0x84 - 1, irq_err);
orion_ge01_shared_data.tx_csum_limit = tx_csum_limit;
[PATCH 1/4 v2] net: mvmdio: allow platform device style registration
This patch changes the mvmdio driver not to use device tree
helper functions such as of_mdiobus_register() and of_iomap() so we can
instantiate this driver using a classic platform_device approach. Use
the device manager helper to ioremap() the base register cookie so we
get automatic freeing upon error and removal. This change is harmless
for Device Tree platforms because they will get the driver be registered
the same way as it was before.
Signed-off-by: Florian Fainelli flor...@openwrt.org
---
Changes since v1:
- use device managed helpers to fix an ioremap leak in remove function
- remove the use of Device Tree specific helpers to allow platform-style
registration
drivers/net/ethernet/marvell/mvmdio.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c
b/drivers/net/ethernet/marvell/mvmdio.c
index 77b7c80..8a182f1 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -24,10 +24,9 @@
#include linux/module.h
#include linux/mutex.h
#include linux/phy.h
-#include linux/of_address.h
-#include linux/of_mdio.h
#include linux/platform_device.h
#include linux/delay.h
+#include linux/io.h
#define MVMDIO_SMI_DATA_SHIFT 0
#define MVMDIO_SMI_PHY_ADDR_SHIFT 16
@@ -143,11 +142,17 @@ static int orion_mdio_reset(struct mii_bus *bus)
static int orion_mdio_probe(struct platform_device *pdev)
{
- struct device_node *np = pdev-dev.of_node;
+ struct resource *r;
struct mii_bus *bus;
struct orion_mdio_dev *dev;
int i, ret;
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!r) {
+ dev_err(pdev-dev, No SMI register address given\n);
+ return -ENODEV;
+ }
+
bus = mdiobus_alloc_size(sizeof(struct orion_mdio_dev));
if (!bus) {
dev_err(pdev-dev, Cannot allocate MDIO bus\n);
@@ -172,9 +177,9 @@ static int orion_mdio_probe(struct platform_device *pdev)
bus-irq[i] = PHY_POLL;
dev = bus-priv;
- dev-smireg = of_iomap(pdev-dev.of_node, 0);
+ dev-smireg = devm_ioremap(pdev-dev, r-start, resource_size(r));
if (!dev-smireg) {
- dev_err(pdev-dev, No SMI register address given in DT\n);
+ dev_err(pdev-dev, Unable to remap SMI register\n);
kfree(bus-irq);
mdiobus_free(bus);
return -ENODEV;
@@ -182,10 +187,9 @@ static int orion_mdio_probe(struct platform_device *pdev)
mutex_init(dev-lock);
- ret = of_mdiobus_register(bus, np);
+ ret = mdiobus_register(bus);
if (ret 0) {
dev_err(pdev-dev, Cannot register MDIO bus (%d)\n, ret);
- iounmap(dev-smireg);
kfree(bus-irq);
mdiobus_free(bus);
return ret;
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On 03/14/2013 11:37 AM, Javier Martinez Canillas wrote:
On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter jon-hun...@ti.com wrote:
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Documentation/devicetree/bindings/net/gpmc-eth.txt | 90
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..c45363c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,90 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM
devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width:Address width of the device in bytes. GPMC
supports 8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
I am wondering if we should use reg-io-width here. The smsc driver is
using this to determine the width of the device. And so I am wondering
if this could cause problems.
Obviously this complicates gpmc_probe_generic_child() a little, but may
be would could pass the name of the width property to
gpmc_probe_generic_child() as well. What do you think?
Hi Jon,
Well now I'm confused. I thought that both were needed since a
combination of bank-width 16-bit / reg-io-width 32-bit is also
possible (in fact that is how I'm testing on my IGEPv2) and we have
talked about this before [1].
Yes you are right. Sorry about that ...
By reading both the OMAP3 TRM and the smsc LAN9221 data-sheet, it
seems that the reg-io-width is not about the data bus address width
but the CPU address width. The smsc data-sheet says:
The simple, yet highly functional host bus interface provides a
glue-less connection to most common 16-bit microprocessors and
microcontrollers as well as 32-bit microprocessors with a 16-bit
external bus
By looking at the smsc911x driver
(drivers/net/ethernet/smsc/smsc911x.c) I see that if you use
reg-io-width = 4 (SMSC911X_USE_32BIT) then the smsc911x hardware
registers can be read in one operation and if you use reg-io-width =
2 (SMSC911X_USE_16BIT) then you need two operations to read the
register:
static inline u32 __smsc911x_reg_read(struct smsc911x_data *pdata, u32 reg)
{
if (pdata-config.flags SMSC911X_USE_32BIT)
return readl(pdata-ioaddr + reg);
if (pdata-config.flags SMSC911X_USE_16BIT)
return ((readw(pdata-ioaddr + reg) 0x) |
((readw(pdata-ioaddr + reg + 2) 0x) 16));
BUG();
return 0;
}
Looking at the above, then I don't see any issue with this then.
Also, by reading at the OMAP3 TRM, I understand that even when the
GPMC has a maximum 16-bit address width, it support devices that has
32-bit registers by doing some sort of access adaptation.
Yes I believe that is correct.
So, as far as I understand the bank-width is to configure the GPMC
if is going to use a 8-bit or 16-bit width access and the
reg-io-width is how the smsc911x driver is going to read its
registers. So, I think we need both properties and there is no need to
change gpmc_probe_generic_child() neither pass the child name to it.
But to be honest I can be wrong here since data-sheet and technical
reference manuals can be quite confusing sometimes :-)
Ok, so do you think that we should add some documentation to the
gpmc-eth.txt so say that set reg-io-width = 4; for OMAP regardless
of bank-width?
Cheers
Jon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] ARM: OMAP2+: return -ENODEV if GPMC child device creation fails
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote: gpmc_probe_nor_child() calls of_platform_device_create() to create a platform device for the NOR child. If this function fails the value of ret is returned to the caller but this value is zero since it was assigned the return of a previous call to gpmc_cs_program_settings() that had to succeed or otherwise gpmc_probe_nor_child() would have returned before. This means that if of_platform_device_create() fails, 0 will be returned to the caller instead of an appropriate error code. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/mach-omap2/gpmc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index d594e1d..8799aed 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -1505,6 +1505,7 @@ static int gpmc_probe_nor_child(struct platform_device *pdev, return 0; dev_err(pdev-dev, failed to create gpmc child %s\n, child-name); + ret = -ENODEV; err: gpmc_cs_free(cs); Good catch! Thanks for the fix, I will pick this up. Cheers Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] ARM: OMAP2+: rename gpmc_probe_nor_child() to gpmc_probe_generic_child()
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
The gpmc_probe_nor_child() function is used in the GPMC driver to
configure the GPMC for a NOR child device node.
But this function is quite generic and all the NOR specific configuration
is made by the driver of the actual NOR flash memory used.
Other Pseudo-SRAM devices such as ethernet controllers need a similar
setup so by making this function generic it can be used for those too.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/gpmc.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8799aed..898b44d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1439,14 +1439,14 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
#endif
/**
- * gpmc_probe_nor_child - configures the gpmc for a nor device
+ * gpmc_probe_generic_child - configures the gpmc for a child device
* @pdev:pointer to gpmc platform device
- * @child: pointer to device-tree node for nor device
+ * @child: pointer to device-tree node for child device
*
- * Allocates and configures a GPMC chip-select for a NOR flash device.
+ * Allocates and configures a GPMC chip-select for a child device.
* Returns 0 on success and appropriate negative error code on failure.
*/
-static int gpmc_probe_nor_child(struct platform_device *pdev,
+static int gpmc_probe_generic_child(struct platform_device *pdev,
struct device_node *child)
{
struct gpmc_settings gpmc_s;
@@ -1552,7 +1552,7 @@ static int gpmc_probe_dt(struct platform_device *pdev)
}
for_each_node_by_name(child, nor) {
- ret = gpmc_probe_nor_child(pdev, child);
+ ret = gpmc_probe_generic_child(pdev, child);
if (ret 0) {
of_node_put(child);
return ret;
Thanks, looks good. I will pick this up too.
Cheers
Jon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mv643xx_eth: convert to use the Marvell Orion MDIO driver
Florian,
On Thu, Mar 14, 2013 at 07:08:32PM +0100, Florian Fainelli wrote:
This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell MV643XX ethernet driver are also updated to
register a Marvell Orion MDIO driver. This driver voluntarily overlaps
with the Marvell Ethernet shared registers because it will use a subset
of this shared register (shared_base + 0x4 - shared_base + 0x84). The
Ethernet driver is also updated to look up for a PHY device using the
Orion MDIO bus driver.
Signed-off-by: Florian Fainelli flor...@openwrt.org
---
arch/arm/plat-orion/common.c | 97 +++
arch/powerpc/platforms/chrp/pegasos_eth.c | 20 +++
arch/powerpc/sysdev/mv64x60_dev.c | 14 ++-
drivers/net/ethernet/marvell/Kconfig |1 +
drivers/net/ethernet/marvell/mv643xx_eth.c | 186
++--
include/linux/mv643xx_eth.h|1 -
6 files changed, 117 insertions(+), 202 deletions(-)
Isn't this the old version of 4/4 ?
thx,
Jason.
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index 2d4b641..dc4345e 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -238,6 +238,7 @@ static __init void ge_complete(
struct mv643xx_eth_shared_platform_data *orion_ge_shared_data,
struct resource *orion_ge_resource, unsigned long irq,
struct platform_device *orion_ge_shared,
+ struct platform_device *orion_ge_mvmdio,
struct mv643xx_eth_platform_data *eth_data,
struct platform_device *orion_ge)
{
@@ -247,6 +248,8 @@ static __init void ge_complete(
orion_ge-dev.platform_data = eth_data;
platform_device_register(orion_ge_shared);
+ if (orion_ge_mvmdio)
+ platform_device_register(orion_ge_mvmdio);
platform_device_register(orion_ge);
}
@@ -258,8 +261,6 @@ struct mv643xx_eth_shared_platform_data
orion_ge00_shared_data;
static struct resource orion_ge00_shared_resources[] = {
{
.name = ge00 base,
- }, {
- .name = ge00 err irq,
},
};
@@ -271,6 +272,19 @@ static struct platform_device orion_ge00_shared = {
},
};
+static struct resource orion_ge00_mvmdio_resources[] = {
+ {
+ .name = ge00 mvmdio base,
+ }, {
+ .name = ge00 mvmdio irr irq,
+ },
+};
+
+static struct platform_device orion_ge00_mvmdio = {
+ .name = orion-mdio,
+ .id = 0,
+};
+
static struct resource orion_ge00_resources[] = {
{
.name = ge00 irq,
@@ -295,26 +309,25 @@ void __init orion_ge00_init(struct
mv643xx_eth_platform_data *eth_data,
unsigned int tx_csum_limit)
{
fill_resources(orion_ge00_shared, orion_ge00_shared_resources,
-mapbase + 0x2000, SZ_16K - 1, irq_err);
+mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
+ fill_resources(orion_ge00_mvmdio, orion_ge00_mvmdio_resources,
+ mapbase + 0x2004, 0x84 - 1, irq_err);
orion_ge00_shared_data.tx_csum_limit = tx_csum_limit;
ge_complete(orion_ge00_shared_data,
orion_ge00_resources, irq, orion_ge00_shared,
+ orion_ge00_mvmdio,
eth_data, orion_ge00);
}
/*
* GE01
/
-struct mv643xx_eth_shared_platform_data orion_ge01_shared_data = {
- .shared_smi = orion_ge00_shared,
-};
+struct mv643xx_eth_shared_platform_data orion_ge01_shared_data;
static struct resource orion_ge01_shared_resources[] = {
{
.name = ge01 base,
- }, {
- .name = ge01 err irq,
- },
+ }
};
static struct platform_device orion_ge01_shared = {
@@ -325,6 +338,19 @@ static struct platform_device orion_ge01_shared = {
},
};
+static struct resource orion_ge01_mvmdio_resources[] = {
+ {
+ .name = ge01 mdio base,
+ }, {
+ .name = ge01 mdio err irq,
+ },
+};
+
+static struct platform_device orion_ge01_mvmdio = {
+ .name = orion-mdio,
+ .id = 1,
+};
+
static struct resource orion_ge01_resources[] = {
{
.name = ge01 irq,
@@ -349,26 +375,25 @@ void __init orion_ge01_init(struct
mv643xx_eth_platform_data *eth_data,
unsigned int tx_csum_limit)
{
fill_resources(orion_ge01_shared, orion_ge01_shared_resources,
-mapbase + 0x2000, SZ_16K - 1, irq_err);
+mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
+ fill_resources(orion_ge01_mvmdio, orion_ge01_mvmdio_resources,
+
Re: [PATCH] mv643xx_eth: convert to use the Marvell Orion MDIO driver
Hello Jason, Le 14/03/2013 20:02, Jason Cooper a écrit : Florian, On Thu, Mar 14, 2013 at 07:08:32PM +0100, Florian Fainelli wrote: This patch converts the Marvell MV643XX ethernet driver to use the Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms registering the Marvell MV643XX ethernet driver are also updated to register a Marvell Orion MDIO driver. This driver voluntarily overlaps with the Marvell Ethernet shared registers because it will use a subset of this shared register (shared_base + 0x4 - shared_base + 0x84). The Ethernet driver is also updated to look up for a PHY device using the Orion MDIO bus driver. Signed-off-by: Florian Fainelli flor...@openwrt.org --- arch/arm/plat-orion/common.c | 97 +++ arch/powerpc/platforms/chrp/pegasos_eth.c | 20 +++ arch/powerpc/sysdev/mv64x60_dev.c | 14 ++- drivers/net/ethernet/marvell/Kconfig |1 + drivers/net/ethernet/marvell/mv643xx_eth.c | 186 ++-- include/linux/mv643xx_eth.h|1 - 6 files changed, 117 insertions(+), 202 deletions(-) Isn't this the old version of 4/4 ? No this really is v2, but I reformatted just that one and sent it without the v2 changelog, you should have received the proper version a couple minutes later once I realized my mistake. -- Florian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] mmc: mxcmmc: add mpc512x SDHC support
On Thu, Mar 14, 2013 at 07:13:32PM +0100, Anatolij Gustschin wrote:
On Thu, 14 Mar 2013 17:50:08 +0100
Arnd Bergmann a...@arndb.de wrote:
On Thursday 14 March 2013 17:40:49 Anatolij Gustschin wrote:
+
+struct mxcmci_reg_ops mxcmci_reg_ops = {
+ .read_l = mpcmci_readl,
+ .write_l = mpcmci_writel,
+ .read_w = mpcmci_readw,
+ .write_w = mpcmci_writew,
+};
+#else
+struct mxcmci_reg_ops mxcmci_reg_ops;
+#endif
Should the struct be static?
yes, it should.
+static inline u32 mxcmci_readl(struct mxcmci_host *host, int reg)
+{
+ if (host-reg_ops-read_l)
+ return host-reg_ops-read_l(host, reg);
+ else
+ return readl(host-base + reg);
+}
This seems a bit strange. I would suggest you either use the ops structure
all the time and provide an imx variant, or you make it completely
compile-time selected.
I wanted to avoid additional levels of indirection and function calls
on i.MX. If something like
static inline u32 mxcmci_readl(struct mxcmci_host *host, int reg)
{
#if IS_ENABLED(CONFIG_PPC_MPC512x)
return in_be32(host-base + reg);
#else
return readl(host-base + reg);
#endif
I really wish we would have native endianess accessors...
is acceptable, I'll use it.
Looks better to me.
@@ -1026,24 +1115,33 @@ static int mxcmci_probe(struct platform_device
*pdev)
host-res = r;
host-irq = irq;
- host-clk_ipg = devm_clk_get(pdev-dev, ipg);
- if (IS_ERR(host-clk_ipg)) {
- ret = PTR_ERR(host-clk_ipg);
- goto out_iounmap;
- }
+ if (!is_mpc512x_mmc(host)) {
+ host-clk_ipg = devm_clk_get(pdev-dev, ipg);
+ if (IS_ERR(host-clk_ipg)) {
+ ret = PTR_ERR(host-clk_ipg);
+ goto out_iounmap;
+ }
Does mpc512x have no clock management? I think it should still
work without modifications if CONFIG_HAVE_CLK is disabled.
In that case, devm_clk_get() will return NULL and we don't
error out here.
It does have some clock management (a platform clock driver) and
the platform selects CONFIG_HAVE_CLK. But we do not have ipg
and per clocks on that platform, but sdhc_clk instead.
The clocks should be modelled after the input clocks the MMC controller
has, not after the clocks the SoC provides control for. So if you cannot
software control a clock then you should provide a dummy clock for it.
That said, 'ipg' is not a very good name for a mpc SoC,
something like 'bus' would probably be better.
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: [PATCH 4/5] mmc: mxcmmc: enable DMA support on mpc512x
On Thu, Mar 14, 2013 at 05:40:53PM +0100, Anatolij Gustschin wrote: Add SDHC DMA channel description to the mpc512x device tree to enable slave channel requesting in the mxcmmc driver. mpc512x DMA engine doesn't support endianness conversion when reading/writing data from peripheral's FIFO, so we have to swap data buffers before each DMA write and after each DMA read transfer manually. Since chained SDHC DMA transfers are not supported on mpc512x, limit 'max_segs' tunable parameter to one and initialise it to 64 only when running on i.MX platforms. They are also not supported on the older i.MX platforms. Shouldn't this be handled in the DMA driver? 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
[PATCH v2 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1:
- Improve the DT binding documentation explaining that even when the GPMC
maximum bus address width is 16-bit, it supports devices with 32-bit
registers address width and the device property especifying this has to
be set accordingly; suggested by Jon Hunter.
Documentation/devicetree/bindings/net/gpmc-eth.txt | 101
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 109 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..8c8be58
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,101 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For the properties relevant to the ethernet controller connected to the GPMC
+refer to the binding documentation of the device. For example, the
documentation
+for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt
+
+Child nodes need to specify the GPMC bus address width using the bank-width
+property but is possible that an ethernet controller also has a property to
+specify the I/O registers address width. Even when the GPMC has a maximum
16-bit
+address width, it supports devices with 32-bit word registers.
+For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an
+OMAP2+ board, bank-width = 2; and reg-io-width = 4;.
+
+Required properties:
+- bank-width: Address width of the device in bytes. GPMC supports
8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Compatible string property for the ethernet child
device.
+- gpmc,cs-on: Chip-select assertion time
+- gpmc,cs-rd-off: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off: Chip-select de-assertion time for writes
+- gpmc,oe-on: Output-enable assertion time
+- gpmc,oe-off Output-enable de-assertion time
+- gpmc,we-on: Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle: Total read cycle time
+- gpmc,wr-cycle: Total write cycle time
+- reg: Chip-select, base address (relative to chip-select)
+ and size of the memory mapped for the device.
+ Note that base address will be typically 0 as this
+ is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Optional properties for partiton table parsing:
+- #address-cells: should be set to 1
+- #size-cells: should be set to 1
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x1000;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ ranges = 5 0 0x2c00 0x100;
+
+ ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 186;
+ gpmc,cs-wr-off = 186;
+ gpmc,adv-on = 12;
+ gpmc,adv-rd-off = 48;
+ gpmc,adv-wr-off = 48;
+ gpmc,oe-on = 54;
+ gpmc,oe-off = 168;
+ gpmc,we-on = 54;
+ gpmc,we-off = 168;
+ gpmc,rd-cycle = 186;
+ gpmc,wr-cycle = 186;
+ gpmc,access = 114;
+ gpmc,page-burst-access = 6;
+ gpmc,bus-turnaround = 12;
+ gpmc,cycle2cycle-delay = 18;
+ gpmc,wr-data-mux-bus
Re: [PATCH] mv643xx_eth: convert to use the Marvell Orion MDIO driver
On Thu, Mar 14, 2013 at 08:32:57PM +0100, Florian Fainelli wrote: Hello Jason, Le 14/03/2013 20:02, Jason Cooper a écrit : Florian, On Thu, Mar 14, 2013 at 07:08:32PM +0100, Florian Fainelli wrote: This patch converts the Marvell MV643XX ethernet driver to use the Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms registering the Marvell MV643XX ethernet driver are also updated to register a Marvell Orion MDIO driver. This driver voluntarily overlaps with the Marvell Ethernet shared registers because it will use a subset of this shared register (shared_base + 0x4 - shared_base + 0x84). The Ethernet driver is also updated to look up for a PHY device using the Orion MDIO bus driver. Signed-off-by: Florian Fainelli flor...@openwrt.org --- arch/arm/plat-orion/common.c | 97 +++ arch/powerpc/platforms/chrp/pegasos_eth.c | 20 +++ arch/powerpc/sysdev/mv64x60_dev.c | 14 ++- drivers/net/ethernet/marvell/Kconfig |1 + drivers/net/ethernet/marvell/mv643xx_eth.c | 186 ++-- include/linux/mv643xx_eth.h|1 - 6 files changed, 117 insertions(+), 202 deletions(-) Isn't this the old version of 4/4 ? No this really is v2, but I reformatted just that one and sent it without the v2 changelog, you should have received the proper version a couple minutes later once I realized my mistake. Yes, I received both, just making sure. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems
On Thu, Mar 14, 2013 at 11:25:55AM -0600, Jason Gunthorpe wrote:
[trimm'd the cc list]
On Thu, Mar 14, 2013 at 10:01:20AM +0100, Thierry Reding wrote:
It turns out that this works with the Tegra driver because it uses the
new of_pci_process_ranges() function and simply overwrites earlier
matches by subsequent ones.
ranges = 0x8200 0 0 0x8000 0 0x1000 /* port 0 registers
*/
0x8200 0 0 0x80001000 0 0x1000 /* port 1 registers
*/
0x8100 0 0 0x8200 0 0x0001 /* downstream I/O */
0x8200 0 0 0xa000 0 0x1000 /* non-prefetchable
memory */
0xc200 0 0 0xb000 0 0x1000; /* prefetchable
memory */
Okay.. There is still something funny here, the 3rd dword of the child
address should not be 0 in every line and there shouldn't be overlaps
in the child address space.
I'm assuming 0x8000, 0xa000 and 0xb000 are real CPU physical
addresses?
Yes.
Then it should probably look like:
ranges = 0x8200 0 0x8000 0x8000 0 0x1000 /* port 0
registers */
0x8200 0 0x80001000 0x80001000 0 0x1000 /* port 1
registers */
0x8100 0 0 0x8200 0 0x0001 /* downstream I/O
*/
0x8200 0 0xa000 0xa000 0 0x1000 /*
non-prefetchable memory */
0xc200 0 0xb000 0xb000 0 0x1000; /* prefetchable
memory */
Which says 'access to CPU address 0xa000 produces a PCI-E memory TLP with
address 0xa000' - this is the 'normal' case, I assume that is what
happens on tegra?
It also says 'access to CPU address 0x8200 produces a PCI-E IO TLP
with address 0' - this translation is something Linux typically
expects..
Then you'd go on to have:
pci@1,0 {
device_type = pci;
assigned-addresses = 0x8200 0 0x8000 0
0x1000;
reg = 0x000800 0 0 0 0;
}
pci@2,0 {
device_type = pci;
assigned-addresses = 0x8200 0 0x80001000 0
0x1000;
reg = 0x001000 0 0 0 0;
}
Notice I've made the upper dw of assigned-addresses's size 0 and
included the full 3dw from the appropriate ranges line.
Okay, that all makes sense.
So the above will actually work along with the corresponding root-port
assigned-addresses properties. I still don't like it much because I
don't think it accurately reflects the hardware.
There are lots of valid ways to model the same HW :(
Bear in mind, for the PCI case - the OF PCI bindings model the HW
through the eyes of the abstractions in the PCI specification. That is
to say, they are not supposed to be an exact representation of the on
chip architecture.
That seems to be at odds with most other uses of DT that I've come
across. Generally the guideline seems to be to describe hardware
irrespective of the underlying implementation and leave it up to the
driver to translate the DT description into something the OS can use.
Perhaps this would be clearer if you used 'pcie-root-complex' as the
name of the top level node?
Perhaps. I'm not sure.
same kludgy, non-spec conformant smack that my original proposal had
because it uses assigned-addresses for something it wasn't intended
to.
Yes, only the top level 'reg' method avoids going outside any specs.
Yes. It has a couple of other disadvantages, though, so if what we've
been discussing here is in any way acceptable I'd rather go with that
solution, even if I'm not entirely happy about it either.
Thierry
pgpGI38IF1s1R.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote: Besides being used to interface with external memory devices, the General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices such as ethernet controllers to OMAP2+ processors using the TI GPMC as a data bus. This patch allows an ethernet chip to be defined as an GPMC child device node. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - Improve the DT binding documentation explaining that even when the GPMC maximum bus address width is 16-bit, it supports devices with 32-bit registers address width and the device property especifying this has to be set accordingly; suggested by Jon Hunter. Documentation/devicetree/bindings/net/gpmc-eth.txt | 101 arch/arm/mach-omap2/gpmc.c |8 ++ 2 files changed, 109 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt new file mode 100644 index 000..8c8be58 --- /dev/null +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt @@ -0,0 +1,101 @@ +Device tree bindings for Ethernet chip connected to TI GPMC + +Besides being used to interface with external memory devices, the +General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices +such as ethernet controllers to processors using the TI GPMC as a data bus. + +Ethernet controllers connected to TI GPMC are represented as child nodes of +the GPMC controller with an ethernet name. + +All timing relevant properties as well as generic GPMC child properties are +explained in a separate documents. Please refer to +Documentation/devicetree/bindings/bus/ti-gpmc.txt + +For the properties relevant to the ethernet controller connected to the GPMC +refer to the binding documentation of the device. For example, the documentation +for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt + +Child nodes need to specify the GPMC bus address width using the bank-width +property but is possible that an ethernet controller also has a property to +specify the I/O registers address width. Even when the GPMC has a maximum 16-bit +address width, it supports devices with 32-bit word registers. +For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an +OMAP2+ board, bank-width = 2; and reg-io-width = 4;. + +Required properties: +- bank-width:Address width of the device in bytes. GPMC supports 8-bit + and 16-bit devices and so must be either 1 or 2 bytes. +- compatible:Compatible string property for the ethernet child device. +- gpmc,cs-on:Chip-select assertion time +- gpmc,cs-rd-off:Chip-select de-assertion time for reads +- gpmc,cs-wr-off:Chip-select de-assertion time for writes +- gpmc,oe-on:Output-enable assertion time +- gpmc,oe-offOutput-enable de-assertion time +- gpmc,we-on:Write-enable assertion time +- gpmc,we-off: Write-enable de-assertion time +- gpmc,access: Start cycle to first data capture (read access) +- gpmc,rd-cycle: Total read cycle time +- gpmc,wr-cycle: Total write cycle time +- reg: Chip-select, base address (relative to chip-select) + and size of the memory mapped for the device. + Note that base address will be typically 0 as this + is the start of the chip-select. + +Optional properties: +- gpmc,XXX Additional GPMC timings and settings parameters. See + Documentation/devicetree/bindings/bus/ti-gpmc.txt Should we add reg-io-width here and say can be 2 or 4 and to refer to the above description? + +Optional properties for partiton table parsing: +- #address-cells: should be set to 1 +- #size-cells: should be set to 1 Sorry should have caught this earlier. The above is not relevant for ethernet. Otherwise looks good. Cheers Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/8] ARM: dts: OMAP34xx: move CPU OPP tables to device tree
Add DT OPP table for OMAP34xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 10 ++
arch/arm/mach-omap2/opp3xxx_data.c | 11 ---
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..9a15066 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -23,6 +23,16 @@
cpus {
cpu@0 {
compatible = arm,cortex-a8;
+ /* OMAP3430 variants OPP1-5 */
+ operating-points =
+ /* kHzuV */
+ 125000 975000
+ 25 1075000
+ 50 120
+ 55 127
+ 60 135
+ ;
+ clock-latency = 30; /* From legacy driver */
};
};
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index fc67add..1de18c2 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -87,17 +87,6 @@ struct omap_volt_data omap36xx_vddcore_volt_data[] = {
/* OPP data */
static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
- /* MPU OPP1 */
- OPP_INITIALIZER(mpu, true, 12500, OMAP3430_VDD_MPU_OPP1_UV),
- /* MPU OPP2 */
- OPP_INITIALIZER(mpu, true, 25000, OMAP3430_VDD_MPU_OPP2_UV),
- /* MPU OPP3 */
- OPP_INITIALIZER(mpu, true, 5, OMAP3430_VDD_MPU_OPP3_UV),
- /* MPU OPP4 */
- OPP_INITIALIZER(mpu, true, 55000, OMAP3430_VDD_MPU_OPP4_UV),
- /* MPU OPP5 */
- OPP_INITIALIZER(mpu, true, 6, OMAP3430_VDD_MPU_OPP5_UV),
-
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
* almost the same than the one at 83MHz thus providing very little
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
The following series arose from trying to use BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in migrating the cpufreq support only through device tree (part of the effort to migrate away from non-DT configurations for OMAP). Unfortunately, as already known, we have a bunch of legacy code and mutually dependent device tree conversion that is pending. Key features pending: A) clock framework transition to DT - this should happen soon, so this series hacks the clock node for the time being as suggested in review of original series B) on processors that use voltage controller, voltage processor (VC/VP hardware loop using I2C_SR path) - we have started work on transitioning them to regulator framework driven by DT. C) Adaptive Body Bias and SmartReflex AVS conversion to DT. As a result of these pending features: - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators associated at the moment - fortunately, we boot at highest voltage, so things still work. - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work, where certain OPPs need enabling based on efuse programmed bit sequences - since it is an add-on work, it is not addressed here. Note: Somewhere in the future, when we have regulators driven off CCF and OMAP converted to CCF, we could remove the DT regulator requirements there as well. Key benefit of the series is to allow all relevant TI platforms now to use a single cpufreq driver and equivalent frameworks in addition be part of the transition to DT. As a result of this series, CPUFreq feature will not be available for non-DT boot systems. Original discussion thread which triggered this series: http://marc.info/?l=linux-pmm=136304313700602w=2 https://patchwork.kernel.org/patch/2251841/ https://patchwork.kernel.org/patch/2251851/ Test coverage: test script: http://pastebin.com/MpCRY0SB Platforms verified: beaglebone(rev A6a) - AM33xx compatible beagleboard (rev C1D) - OMAP3430 compatible omap3-beagle-xm -OMAP3630 compatible Pandaboard -(OMAP4430 ES2.3) verified with omapconf Pandaboard-ES -(OMAP4460 ES1.1) verified with omapconf Series is based on v3.9-rc2 tag Also available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1 git link: git://github.com/nmenon/linux-2.6-playground.git branch: cpufreq-cpu0-omap-all-v1 Nishanth Menon (8): ARM: dts: OMAP34xx: move CPU OPP tables to device tree ARM: dts: OMAP36xx: move CPU OPP tables to device tree ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU ARM: dts: OMAP443x: move CPU OPP tables to device tree ARM: dts: omap4-panda: move generic sections to panda-common ARM: dts: OMAP446x: move CPU OPP tables to device tree ARM: OMAP3+: use cpu0-cpufreq driver cpufreq: omap: remove omap-cpufreq MAINTAINERS |1 - arch/arm/boot/dts/omap3-beagle-xm.dts |6 + arch/arm/boot/dts/omap3-beagle.dts|6 + arch/arm/boot/dts/omap3-evm.dts |6 + arch/arm/boot/dts/omap3.dtsi | 10 + arch/arm/boot/dts/omap36xx.dtsi | 12 ++ arch/arm/boot/dts/omap4-panda-a4.dts |5 +- arch/arm/boot/dts/omap4-panda-common.dtsi | 205 arch/arm/boot/dts/omap4-panda-es.dts |5 +- arch/arm/boot/dts/omap4-panda.dts | 200 +--- arch/arm/boot/dts/omap4.dtsi | 10 + arch/arm/boot/dts/omap446x.dtsi | 27 +++ arch/arm/boot/dts/twl4030.dtsi|6 + arch/arm/mach-omap2/board-generic.c |4 + arch/arm/mach-omap2/cclock33xx_data.c |2 +- arch/arm/mach-omap2/cclock3xxx_data.c |2 +- arch/arm/mach-omap2/cclock44xx_data.c |2 +- arch/arm/mach-omap2/opp3xxx_data.c| 20 -- arch/arm/mach-omap2/opp4xxx_data.c| 23 --- drivers/cpufreq/Kconfig.arm |6 - drivers/cpufreq/Makefile |1 - drivers/cpufreq/omap-cpufreq.c| 291 - 22 files changed, 305 insertions(+), 545 deletions(-) create mode 100644 arch/arm/boot/dts/omap4-panda-common.dtsi create mode 100644 arch/arm/boot/dts/omap446x.dtsi delete mode 100644 drivers/cpufreq/omap-cpufreq.c Size change information: add/remove: 0/0 grow/shrink: 3/5 up/down: 74/-291 (-217) function old new delta omap_generic_init 96 140 +44 vermagic 49 64 +15 linux_banner 130 145 +15 kernel_config_data 18333 18330 -3 omap443x_opp_def_list144 80 -64 omap36xx_opp_def_list
[PATCH 4/8] ARM: dts: OMAP443x: move CPU OPP tables to device tree
Add DT OPP table for OMAP443x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 10 ++
arch/arm/mach-omap2/opp4xxx_data.c |8
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..08983a3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -31,6 +31,16 @@
cpu@0 {
compatible = arm,cortex-a9;
next-level-cache = L2;
+ /* OMAP4430 variants OPP50-OPPNT */
+ operating-points =
+ /* kHzuV */
+ 30 1025000
+ 60 120
+ 80 1313000
+ 1008000 1375000
+ ;
+ clock-latency = 30; /* From omap-cpufreq driver */
+ voltage-tolerance = 2; /* 2 % */
};
cpu@1 {
compatible = arm,cortex-a9;
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 1ef7a3e..478e2ee 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -65,14 +65,6 @@ struct omap_volt_data omap443x_vdd_core_volt_data[] = {
static struct omap_opp_def __initdata omap443x_opp_def_list[] = {
- /* MPU OPP1 - OPP50 */
- OPP_INITIALIZER(mpu, true, 3, OMAP4430_VDD_MPU_OPP50_UV),
- /* MPU OPP2 - OPP100 */
- OPP_INITIALIZER(mpu, true, 6, OMAP4430_VDD_MPU_OPP100_UV),
- /* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER(mpu, true, 8, OMAP4430_VDD_MPU_OPPTURBO_UV),
- /* MPU OPP4 - OPP-SB */
- OPP_INITIALIZER(mpu, true, 100800, OMAP4430_VDD_MPU_OPPNITRO_UV),
/* L3 OPP1 - OPP50 */
OPP_INITIALIZER(l3_main_1, true, 1,
OMAP4430_VDD_CORE_OPP50_UV),
/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
Add DT OPP table for OMAP36xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function. This
overrides the default OMAP34xx CPU OPP table definition.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap36xx.dtsi| 12
arch/arm/mach-omap2/opp3xxx_data.c |9 -
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 96bf028..743eaa1 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -15,6 +15,18 @@
serial3 = uart4;
};
+ cpus {
+ /* OMAP3630 'standard device' variants OPP50 to OPP130 */
+ cpu@0 {
+ operating-points =
+ /* kHzuV */
+ 30 975000
+ 60 1075000
+ 80 120
+ ;
+ clock-latency = 30; /* From omap-cpufreq driver */
+ };
+ };
ocp {
uart4: serial@49042000 {
compatible = ti,omap3-uart;
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index 1de18c2..cf7b3ab 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -114,15 +114,6 @@ static struct omap_opp_def __initdata
omap34xx_opp_def_list[] = {
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
- /* MPU OPP1 - OPP50 */
- OPP_INITIALIZER(mpu, true, 3, OMAP3630_VDD_MPU_OPP50_UV),
- /* MPU OPP2 - OPP100 */
- OPP_INITIALIZER(mpu, true, 6, OMAP3630_VDD_MPU_OPP100_UV),
- /* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER(mpu, false, 8, OMAP3630_VDD_MPU_OPP120_UV),
- /* MPU OPP4 - OPP-SB */
- OPP_INITIALIZER(mpu, false, 10, OMAP3630_VDD_MPU_OPP1G_UV),
-
/* L3 OPP1 - OPP50 */
OPP_INITIALIZER(l3_main, true, 1, OMAP3630_VDD_CORE_OPP50_UV),
/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 6/8] ARM: dts: OMAP446x: move CPU OPP tables to device tree
OMAP4430 and 4460 have different OPP definitions. So, create an SoC
variant dtsi file for 4460 and move the OPP definitions to it.
Add DT OPP table for OMAP446x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap4-panda-es.dts |2 +-
arch/arm/boot/dts/omap446x.dtsi | 27 +++
arch/arm/mach-omap2/opp4xxx_data.c | 15 ---
3 files changed, 28 insertions(+), 16 deletions(-)
create mode 100644 arch/arm/boot/dts/omap446x.dtsi
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 6422d7c..c52455b 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap4.dtsi
+/include/ omap446x.dtsi
/include/ omap4-panda-common.dtsi
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
diff --git a/arch/arm/boot/dts/omap446x.dtsi b/arch/arm/boot/dts/omap446x.dtsi
new file mode 100644
index 000..8f7a080
--- /dev/null
+++ b/arch/arm/boot/dts/omap446x.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Source for OMAP446x SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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/ omap4.dtsi
+
+/ {
+ cpus {
+ /* OMAP446x 'standard device' variants OPP50 to OPPTurbo */
+ cpu@0 {
+ operating-points =
+ /* kHzuV */
+ 35 975000
+ 70 1075000
+ 92 120
+ ;
+ clock-latency = 30; /* From omap-cpufreq driver */
+ voltage-tolerance = 2; /* 2 % */
+ };
+ };
+};
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 478e2ee..4c5c038 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -116,21 +116,6 @@ struct omap_volt_data omap446x_vdd_core_volt_data[] = {
};
static struct omap_opp_def __initdata omap446x_opp_def_list[] = {
- /* MPU OPP1 - OPP50 */
- OPP_INITIALIZER(mpu, true, 35000, OMAP4460_VDD_MPU_OPP50_UV),
- /* MPU OPP2 - OPP100 */
- OPP_INITIALIZER(mpu, true, 7, OMAP4460_VDD_MPU_OPP100_UV),
- /* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER(mpu, true, 92000, OMAP4460_VDD_MPU_OPPTURBO_UV),
- /*
-* MPU OPP4 - OPP-Nitro + Disabled as the reference schematics
-* recommends TPS623631 - confirm and enable the opp in board file
-* XXX: May be we should enable these based on mpu capability and
-* Exception board files disable it...
-*/
- OPP_INITIALIZER(mpu, false, 12, OMAP4460_VDD_MPU_OPPNITRO_UV),
- /* MPU OPP4 - OPP-Nitro SpeedBin */
- OPP_INITIALIZER(mpu, false, 15, OMAP4460_VDD_MPU_OPPNITRO_UV),
/* L3 OPP1 - OPP50 */
OPP_INITIALIZER(l3_main_1, true, 1,
OMAP4460_VDD_CORE_OPP50_UV),
/* L3 OPP2 - OPP100 */
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 7/8] ARM: OMAP3+: use cpu0-cpufreq driver
With OMAP3+ and AM33xx supported SoC having defined CPU DT
entries with operating-points defined, we can now
use the SoC generic cpu0-cpufreq driver to start
using it, lets now switch to the generic driver.
As part of this change, switch the dummy clock node to use
cpufreq-cpu0. This is an suggested solution till we have
OMAP clock nodes in DT. Once the DT conversion is complete,
we can then do: clocks = dpll_mpu_ck; or the SoC specific
equivalent.
Inspired by patch: https://patchwork.kernel.org/patch/2067841/
now made generic.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/board-generic.c |4
arch/arm/mach-omap2/cclock33xx_data.c |2 +-
arch/arm/mach-omap2/cclock3xxx_data.c |2 +-
arch/arm/mach-omap2/cclock44xx_data.c |2 +-
4 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..970c6f4 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -49,6 +49,10 @@ static void __init omap_generic_init(void)
omap4_panda_display_init_of();
else if (of_machine_is_compatible(ti,omap4-sdp))
omap_4430sdp_display_init_of();
+ if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+ struct platform_device_info devinfo = { .name = cpufreq-cpu0,
};
+ platform_device_register_full(devinfo);
+ }
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index 476b820..cf7e736 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -852,7 +852,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, dpll_core_m5_ck, dpll_core_m5_ck,
CK_AM33XX),
CLK(NULL, dpll_core_m6_ck, dpll_core_m6_ck,
CK_AM33XX),
CLK(NULL, dpll_mpu_ck, dpll_mpu_ck, CK_AM33XX),
- CLK(cpu0, NULL, dpll_mpu_ck, CK_AM33XX),
+ CLK(cpufreq-cpu0.0, NULL, dpll_mpu_ck,
CK_AM33XX),
CLK(NULL, dpll_mpu_m2_ck, dpll_mpu_m2_ck,
CK_AM33XX),
CLK(NULL, dpll_ddr_ck, dpll_ddr_ck, CK_AM33XX),
CLK(NULL, dpll_ddr_m2_ck, dpll_ddr_m2_ck,
CK_AM33XX),
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..5f68286 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3501,7 +3501,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, uart4_ick,uart4_ick_am35xx, CK_AM35XX),
CLK(NULL, timer_32k_ck, omap_32k_fck, CK_3XXX),
CLK(NULL, timer_sys_ck, sys_ck,CK_3XXX),
- CLK(NULL, cpufreq_ck, dpll1_ck, CK_3XXX),
+ CLK(cpufreq-cpu0.0, NULL, dpll1_ck, CK_3XXX),
};
static const char *enable_init_clks[] = {
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 3d58f33..6e933e3 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1660,7 +1660,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(4013a000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(4013c000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(4013e000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
- CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
+ CLK(cpufreq-cpu0.0, NULL, dpll_mpu_ck, CK_443X),
};
int __init omap4xxx_clk_init(void)
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/8] ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU
Define VDD1 regulator in twl4030 DT and mark it as the supply for the
various OMAP3 platforms.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts |6 ++
arch/arm/boot/dts/omap3-beagle.dts|6 ++
arch/arm/boot/dts/omap3-evm.dts |6 ++
arch/arm/boot/dts/twl4030.dtsi|6 ++
4 files changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..7152746 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -13,6 +13,12 @@
model = TI OMAP3 BeagleBoard xM;
compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
memory {
device_type = memory;
reg = 0x8000 0x2000; /* 512 MB */
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..8886617 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -13,6 +13,12 @@
model = TI OMAP3 BeagleBoard;
compatible = ti,omap3-beagle, ti,omap3;
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
memory {
device_type = memory;
reg = 0x8000 0x1000; /* 256 MB */
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..d36d19f 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -13,6 +13,12 @@
model = TI OMAP3 EVM (OMAP3530, AM/DM37x);
compatible = ti,omap3-evm, ti,omap3;
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
memory {
device_type = memory;
reg = 0x8000 0x1000; /* 256 MB */
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index ed0bc95..608f2e6 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -23,6 +23,12 @@
compatible = ti,twl4030-wdt;
};
+ vcc: regulator-vdd1 {
+ compatible = ti,twl4030-vdd1;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 145;
+ };
+
vdac: regulator-vdac {
compatible = ti,twl4030-vdac;
regulator-min-microvolt = 180;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 8/8] cpufreq: omap: remove omap-cpufreq
We can now use cpufreq-cpu0 driver using DT entries.
remove the redundant omap-cpufreq driver from the tree.
Remove MAINTAINERS file entry for the same as well.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
MAINTAINERS|1 -
drivers/cpufreq/Kconfig.arm|6 -
drivers/cpufreq/Makefile |1 -
drivers/cpufreq/omap-cpufreq.c | 291
4 files changed, 299 deletions(-)
delete mode 100644 drivers/cpufreq/omap-cpufreq.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 9561658..d9c11bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5654,7 +5654,6 @@ M:Kevin Hilman khil...@ti.com
L: linux-o...@vger.kernel.org
S: Maintained
F: arch/arm/*omap*/*pm*
-F: drivers/cpufreq/omap-cpufreq.c
OMAP POWERDOMAIN/CLOCKDOMAIN SOC ADAPTATION LAYER SUPPORT
M: Rajendra Nayak rna...@ti.com
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 030ddf6..1cb810a 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -2,12 +2,6 @@
# ARM CPU Frequency scaling drivers
#
-config ARM_OMAP2PLUS_CPUFREQ
- bool TI OMAP2+
- depends on ARCH_OMAP2PLUS
- default ARCH_OMAP2PLUS
- select CPU_FREQ_TABLE
-
config ARM_S3C2416_CPUFREQ
bool S3C2416 CPU Frequency scaling support
depends on CPU_S3C2416
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 863fd18..d52076c 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -53,7 +53,6 @@ obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
-obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
deleted file mode 100644
index 9128c07..000
--- a/drivers/cpufreq/omap-cpufreq.c
+++ /dev/null
@@ -1,291 +0,0 @@
-/*
- * CPU frequency scaling for OMAP using OPP information
- *
- * Copyright (C) 2005 Nokia Corporation
- * Written by Tony Lindgren t...@atomide.com
- *
- * Based on cpu-sa1110.c, Copyright (C) 2001 Russell King
- *
- * Copyright (C) 2007-2011 Texas Instruments, Inc.
- * - OMAP3/4 support by Rajendra Nayak, Santosh Shilimkar
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include linux/types.h
-#include linux/kernel.h
-#include linux/sched.h
-#include linux/cpufreq.h
-#include linux/delay.h
-#include linux/init.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/io.h
-#include linux/opp.h
-#include linux/cpu.h
-#include linux/module.h
-#include linux/regulator/consumer.h
-
-#include asm/smp_plat.h
-#include asm/cpu.h
-
-/* OPP tolerance in percentage */
-#defineOPP_TOLERANCE 4
-
-static struct cpufreq_frequency_table *freq_table;
-static atomic_t freq_table_users = ATOMIC_INIT(0);
-static struct clk *mpu_clk;
-static struct device *mpu_dev;
-static struct regulator *mpu_reg;
-
-static int omap_verify_speed(struct cpufreq_policy *policy)
-{
- if (!freq_table)
- return -EINVAL;
- return cpufreq_frequency_table_verify(policy, freq_table);
-}
-
-static unsigned int omap_getspeed(unsigned int cpu)
-{
- unsigned long rate;
-
- if (cpu = NR_CPUS)
- return 0;
-
- rate = clk_get_rate(mpu_clk) / 1000;
- return rate;
-}
-
-static int omap_target(struct cpufreq_policy *policy,
- unsigned int target_freq,
- unsigned int relation)
-{
- unsigned int i;
- int r, ret = 0;
- struct cpufreq_freqs freqs;
- struct opp *opp;
- unsigned long freq, volt = 0, volt_old = 0, tol = 0;
-
- if (!freq_table) {
- dev_err(mpu_dev, %s: cpu%d: no freq table!\n, __func__,
- policy-cpu);
- return -EINVAL;
- }
-
- ret = cpufreq_frequency_table_target(policy, freq_table, target_freq,
- relation, i);
- if (ret) {
- dev_dbg(mpu_dev, %s: cpu%d: no freq match for %d(ret=%d)\n,
- __func__, policy-cpu, target_freq, ret);
- return
[PATCH 5/8] ARM: dts: omap4-panda: move generic sections to panda-common
PandaBoard, PandaBoard-A4 revisions use OMAP4430.
PandaBoard-ES version of the board uses OMAP4460.
Move the original panda dts file into a common dtsi used by all panda
variants. This allows us to introduce SoC variation for PandaBoard ES
without impacting other PandaBoard versions that are supported.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
NOTE: even though this patch was generated with -M, the diff might be a bit
confusing.
arch/arm/boot/dts/omap4-panda-a4.dts |5 +-
arch/arm/boot/dts/omap4-panda-common.dtsi | 205 +
arch/arm/boot/dts/omap4-panda-es.dts |5 +-
arch/arm/boot/dts/omap4-panda.dts | 200 +---
4 files changed, 215 insertions(+), 200 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-panda-common.dtsi
diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts
b/arch/arm/boot/dts/omap4-panda-a4.dts
index 75466d2..f89b0ee 100644
--- a/arch/arm/boot/dts/omap4-panda-a4.dts
+++ b/arch/arm/boot/dts/omap4-panda-a4.dts
@@ -5,7 +5,10 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-/include/ omap4-panda.dts
+/dts-v1/;
+
+/include/ omap4.dtsi
+/include/ omap4-panda-common.dtsi
/* Pandaboard Rev A4+ have external pullups on SCL SDA */
dss_hdmi_pins {
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
new file mode 100644
index 000..3a22e09
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -0,0 +1,205 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/include/ elpida_ecb240abacn.dtsi
+
+/ {
+ model = TI OMAP4 PandaBoard;
+ compatible = ti,omap4-panda, ti,omap4430, ti,omap4;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1 GB */
+ };
+
+ leds {
+ compatible = gpio-leds;
+ heartbeat {
+ label = pandaboard::status1;
+ gpios = gpio1 7 0;
+ linux,default-trigger = heartbeat;
+ };
+
+ mmc {
+ label = pandaboard::status2;
+ gpios = gpio1 8 0;
+ linux,default-trigger = mmc0;
+ };
+ };
+
+ sound: sound {
+ compatible = ti,abe-twl6040;
+ ti,model = PandaBoard;
+
+ ti,mclk-freq = 3840;
+
+ ti,mcpdm = mcpdm;
+
+ ti,twl6040 = twl6040;
+
+ /* Audio routing */
+ ti,audio-routing =
+ Headset Stereophone, HSOL,
+ Headset Stereophone, HSOR,
+ Ext Spk, HFL,
+ Ext Spk, HFR,
+ Line Out, AUXL,
+ Line Out, AUXR,
+ HSMIC, Headset Mic,
+ Headset Mic, Headset Mic Bias,
+ AFML, Line In,
+ AFMR, Line In;
+ };
+};
+
+omap4_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ twl6040_pins
+ mcpdm_pins
+ mcbsp1_pins
+ dss_hdmi_pins
+ tpd12s015_pins
+ ;
+
+ twl6040_pins: pinmux_twl6040_pins {
+ pinctrl-single,pins =
+ 0xe0 0x3/* hdq_sio.gpio_127 OUTPUT | MODE3 */
+ 0x160 0x100 /* sys_nirq2.sys_nirq2 INPUT | MODE0 */
+ ;
+ };
+
+ mcpdm_pins: pinmux_mcpdm_pins {
+ pinctrl-single,pins =
+ 0xc6 0x108 /* abe_pdm_ul_data.abe_pdm_ul_data
INPUT PULLDOWN | MODE0 */
+ 0xc8 0x108 /* abe_pdm_dl_data.abe_pdm_dl_data
INPUT PULLDOWN | MODE0 */
+ 0xca 0x118 /* abe_pdm_frame.abe_pdm_frame INPUT
PULLUP | MODE0 */
+ 0xcc 0x108 /* abe_pdm_lb_clk.abe_pdm_lb_clk INPUT
PULLDOWN | MODE0 */
+ 0xce 0x108 /* abe_clks.abe_clks INPUT PULLDOWN |
MODE0 */
+ ;
+ };
+
+ mcbsp1_pins: pinmux_mcbsp1_pins {
+ pinctrl-single,pins =
+ 0xbe 0x100 /* abe_mcbsp1_clkx.abe_mcbsp1_clkx
INPUT | MODE0 */
Re: [PATCH v2 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Javier Hi Jon, On 14/03/2013, at 21:43, Jon Hunter jon-hun...@ti.com wrote: On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote: Besides being used to interface with external memory devices, the General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices such as ethernet controllers to OMAP2+ processors using the TI GPMC as a data bus. This patch allows an ethernet chip to be defined as an GPMC child device node. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - Improve the DT binding documentation explaining that even when the GPMC maximum bus address width is 16-bit, it supports devices with 32-bit registers address width and the device property especifying this has to be set accordingly; suggested by Jon Hunter. Documentation/devicetree/bindings/net/gpmc-eth.txt | 101 arch/arm/mach-omap2/gpmc.c |8 ++ 2 files changed, 109 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt new file mode 100644 index 000..8c8be58 --- /dev/null +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt @@ -0,0 +1,101 @@ +Device tree bindings for Ethernet chip connected to TI GPMC + +Besides being used to interface with external memory devices, the +General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices +such as ethernet controllers to processors using the TI GPMC as a data bus. + +Ethernet controllers connected to TI GPMC are represented as child nodes of +the GPMC controller with an ethernet name. + +All timing relevant properties as well as generic GPMC child properties are +explained in a separate documents. Please refer to +Documentation/devicetree/bindings/bus/ti-gpmc.txt + +For the properties relevant to the ethernet controller connected to the GPMC +refer to the binding documentation of the device. For example, the documentation +for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt + +Child nodes need to specify the GPMC bus address width using the bank-width +property but is possible that an ethernet controller also has a property to +specify the I/O registers address width. Even when the GPMC has a maximum 16-bit +address width, it supports devices with 32-bit word registers. +For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an +OMAP2+ board, bank-width = 2; and reg-io-width = 4;. + +Required properties: +- bank-width:Address width of the device in bytes. GPMC supports 8-bit +and 16-bit devices and so must be either 1 or 2 bytes. +- compatible:Compatible string property for the ethernet child device. +- gpmc,cs-on:Chip-select assertion time +- gpmc,cs-rd-off:Chip-select de-assertion time for reads +- gpmc,cs-wr-off:Chip-select de-assertion time for writes +- gpmc,oe-on:Output-enable assertion time +- gpmc,oe-offOutput-enable de-assertion time +- gpmc,we-on:Write-enable assertion time +- gpmc,we-off:Write-enable de-assertion time +- gpmc,access:Start cycle to first data capture (read access) +- gpmc,rd-cycle:Total read cycle time +- gpmc,wr-cycle:Total write cycle time +- reg:Chip-select, base address (relative to chip-select) +and size of the memory mapped for the device. +Note that base address will be typically 0 as this +is the start of the chip-select. + +Optional properties: +- gpmc,XXXAdditional GPMC timings and settings parameters. See +Documentation/devicetree/bindings/bus/ti-gpmc.txt Should we add reg-io-width here and say can be 2 or 4 and to refer to the above description? I'm not sure about that, this property is not used (neither relevant) to the GPMC driver but is used by the smsc911x driver. Other Ethernet chips could not need that (e.g: supports only 32 bit word accesses) or can have a different property. Uses should check the documentation binding for the connected device. + +Optional properties for partiton table parsing: +- #address-cells: should be set to 1 +- #size-cells: should be set to 1 Sorry should have caught this earlier. The above is not relevant for ethernet. I should have catch that before sending the first version! I took the properties from your gpmc-nor.txt documentation and this is a left over. Will send a v3 removing that. Sorry for being so carelessly... Otherwise looks good. Cheers Jon Thanks a lot and best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems
On Thu, Mar 14, 2013 at 11:25:55AM -0600, Jason Gunthorpe wrote: [...] I'm assuming 0x8000, 0xa000 and 0xb000 are real CPU physical addresses? Then it should probably look like: ranges = 0x8200 0 0x8000 0x8000 0 0x1000 /* port 0 registers */ 0x8200 0 0x80001000 0x80001000 0 0x1000 /* port 1 registers */ 0x8100 0 0 0x8200 0 0x0001 /* downstream I/O */ 0x8200 0 0xa000 0xa000 0 0x1000 /* non-prefetchable memory */ 0xc200 0 0xb000 0xb000 0 0x1000; /* prefetchable memory */ Which says 'access to CPU address 0xa000 produces a PCI-E memory TLP with address 0xa000' - this is the 'normal' case, I assume that is what happens on tegra? It also says 'access to CPU address 0x8200 produces a PCI-E IO TLP with address 0' - this translation is something Linux typically expects.. Both of the above paragraphs are true. However accesses to the windows at 0x8000 and 0x80001000 don't generate memory TLPs but type 0 configuration space TLPs. So my first instinct was to make the first cell of the first two entries 0, but that doesn't work, since the OF core expects to find either memory or I/O spaces. ss == 2 isn't quite right here. Thierry pgpugR_bgV6T_.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/5] mmc: mxcmmc: enable DMA support on mpc512x
On Thu, 14 Mar 2013 21:11:39 +0100 Sascha Hauer s.ha...@pengutronix.de wrote: On Thu, Mar 14, 2013 at 05:40:53PM +0100, Anatolij Gustschin wrote: Add SDHC DMA channel description to the mpc512x device tree to enable slave channel requesting in the mxcmmc driver. mpc512x DMA engine doesn't support endianness conversion when reading/writing data from peripheral's FIFO, so we have to swap data buffers before each DMA write and after each DMA read transfer manually. Since chained SDHC DMA transfers are not supported on mpc512x, limit 'max_segs' tunable parameter to one and initialise it to 64 only when running on i.MX platforms. They are also not supported on the older i.MX platforms. Shouldn't this be handled in the DMA driver? This could be handled in the DMA driver, but up to now nobody cared to extend the DMA driver so. Anatolij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On 03/14/2013 04:08 PM, Javier Martinez Canillas wrote: Javier Hi Jon, On 14/03/2013, at 21:43, Jon Hunter jon-hun...@ti.com wrote: On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote: Besides being used to interface with external memory devices, the General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices such as ethernet controllers to OMAP2+ processors using the TI GPMC as a data bus. This patch allows an ethernet chip to be defined as an GPMC child device node. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - Improve the DT binding documentation explaining that even when the GPMC maximum bus address width is 16-bit, it supports devices with 32-bit registers address width and the device property especifying this has to be set accordingly; suggested by Jon Hunter. Documentation/devicetree/bindings/net/gpmc-eth.txt | 101 arch/arm/mach-omap2/gpmc.c |8 ++ 2 files changed, 109 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt new file mode 100644 index 000..8c8be58 --- /dev/null +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt @@ -0,0 +1,101 @@ +Device tree bindings for Ethernet chip connected to TI GPMC + +Besides being used to interface with external memory devices, the +General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices +such as ethernet controllers to processors using the TI GPMC as a data bus. + +Ethernet controllers connected to TI GPMC are represented as child nodes of +the GPMC controller with an ethernet name. + +All timing relevant properties as well as generic GPMC child properties are +explained in a separate documents. Please refer to +Documentation/devicetree/bindings/bus/ti-gpmc.txt + +For the properties relevant to the ethernet controller connected to the GPMC +refer to the binding documentation of the device. For example, the documentation +for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt + +Child nodes need to specify the GPMC bus address width using the bank-width +property but is possible that an ethernet controller also has a property to +specify the I/O registers address width. Even when the GPMC has a maximum 16-bit +address width, it supports devices with 32-bit word registers. +For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an +OMAP2+ board, bank-width = 2; and reg-io-width = 4;. + +Required properties: +- bank-width:Address width of the device in bytes. GPMC supports 8-bit +and 16-bit devices and so must be either 1 or 2 bytes. +- compatible:Compatible string property for the ethernet child device. +- gpmc,cs-on:Chip-select assertion time +- gpmc,cs-rd-off:Chip-select de-assertion time for reads +- gpmc,cs-wr-off:Chip-select de-assertion time for writes +- gpmc,oe-on:Output-enable assertion time +- gpmc,oe-offOutput-enable de-assertion time +- gpmc,we-on:Write-enable assertion time +- gpmc,we-off:Write-enable de-assertion time +- gpmc,access:Start cycle to first data capture (read access) +- gpmc,rd-cycle:Total read cycle time +- gpmc,wr-cycle:Total write cycle time +- reg:Chip-select, base address (relative to chip-select) +and size of the memory mapped for the device. +Note that base address will be typically 0 as this +is the start of the chip-select. + +Optional properties: +- gpmc,XXXAdditional GPMC timings and settings parameters. See +Documentation/devicetree/bindings/bus/ti-gpmc.txt Should we add reg-io-width here and say can be 2 or 4 and to refer to the above description? I'm not sure about that, this property is not used (neither relevant) to the GPMC driver but is used by the smsc911x driver. Other Ethernet chips could not need that (e.g: supports only 32 bit word accesses) or can have a different property. Uses should check the documentation binding for the connected device. Good point. Let's not bother adding that. + +Optional properties for partiton table parsing: +- #address-cells: should be set to 1 +- #size-cells: should be set to 1 Sorry should have caught this earlier. The above is not relevant for ethernet. I should have catch that before sending the first version! I took the properties from your gpmc-nor.txt documentation and this is a left over. Will send a v3 removing that. Sorry for being so carelessly... No problem. Thanks for getting this done. Now just to figure out how to handle the darn gpio interrupt ;-) Jon ___
Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems
On Thu, Mar 14, 2013 at 10:09:26PM +0100, Thierry Reding wrote: ranges = 0x8200 0 0x8000 0x8000 0 0x1000 /* port 0 registers */ 0x8200 0 0x80001000 0x80001000 0 0x1000 /* port 1 registers */ 0x8100 0 0 0x8200 0 0x0001 /* downstream I/O */ 0x8200 0 0xa000 0xa000 0 0x1000 /* non-prefetchable memory */ 0xc200 0 0xb000 0xb000 0 0x1000; /* prefetchable memory */ Which says 'access to CPU address 0xa000 produces a PCI-E memory TLP with address 0xa000' - this is the 'normal' case, I assume that is what happens on tegra? It also says 'access to CPU address 0x8200 produces a PCI-E IO TLP with address 0' - this translation is something Linux typically expects.. Both of the above paragraphs are true. However accesses to the windows at 0x8000 and 0x80001000 don't generate memory TLPs but type 0 configuration space TLPs. By my understanding access to 0x8000/0x80001000 doesn't generate any externally visible TLPs? IHMO modeling this register space as a controller-internal MMIO region associated with the bridge is reasonable... After all, you are iomapping it and accessing it with readl/writel - those are MMIO functions.. So my first instinct was to make the first cell of the first two entries 0, but that doesn't work, since the OF core expects to find either memory or I/O spaces. Right, there is no specified way to translate config ss through ranges. Regards, Jason ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems
On Thu, Mar 14, 2013 at 03:29:21PM -0600, Jason Gunthorpe wrote: On Thu, Mar 14, 2013 at 10:09:26PM +0100, Thierry Reding wrote: ranges = 0x8200 0 0x8000 0x8000 0 0x1000 /* port 0 registers */ 0x8200 0 0x80001000 0x80001000 0 0x1000 /* port 1 registers */ 0x8100 0 0 0x8200 0 0x0001 /* downstream I/O */ 0x8200 0 0xa000 0xa000 0 0x1000 /* non-prefetchable memory */ 0xc200 0 0xb000 0xb000 0 0x1000; /* prefetchable memory */ Which says 'access to CPU address 0xa000 produces a PCI-E memory TLP with address 0xa000' - this is the 'normal' case, I assume that is what happens on tegra? It also says 'access to CPU address 0x8200 produces a PCI-E IO TLP with address 0' - this translation is something Linux typically expects.. Both of the above paragraphs are true. However accesses to the windows at 0x8000 and 0x80001000 don't generate memory TLPs but type 0 configuration space TLPs. By my understanding access to 0x8000/0x80001000 doesn't generate any externally visible TLPs? Now that you mention it, that's probably correct, yes. IHMO modeling this register space as a controller-internal MMIO region associated with the bridge is reasonable... After all, you are iomapping it and accessing it with readl/writel - those are MMIO functions.. Yes, I think that'd be okay. Thierry pgpMF5f0R1h9a.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
