Re: [PATCH 2/2] usb: dwc3: exynos: use clk_prepare_enable and clk_disable_unprepare
Hi, On Thu, Mar 14, 2013 at 4:23 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Thu, Mar 14, 2013 at 04:14:58PM +0530, Vivek Gautam wrote: Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. 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 |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index 66ca9ac..b03f609 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -129,7 +129,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev) exynos-dev = dev; exynos-clk = clk; - clk_enable(exynos-clk); + clk_prepare_enable(exynos-clk); eventually we need to pass this clock handling to dwc3/core.c. Just make sure it's optional since not all platforms need it. True, as of now i could see only exynos platform getting a device clock for dwc3-glue. So, if not all platforms need to do this, why should we plan to move this to dwc3/core.c ? I guess the best way would be to handle clocks via -runtime_suspend()/-runtime_resume() ?? Right, but there was a doubt actually if you can please clear that. In device probe, after enabling runtime_pm we would need to 'pm_runtime_get_sync' the device. Thereby, in runtime_resume the clocks will be enabled. Now as soon as the device probe finishes, the device will go in suspend state, calling runtime_suspend and the clocks would be disabled. Now would it be possible for the controller to detect any connect/disconnect. Pardon me if there is something very silly i am missing out. -- balbi -- Thanks Regards Vivek ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] usb: dwc3: exynos: use clk_prepare_enable and clk_disable_unprepare
Hi, On Fri, Mar 15, 2013 at 11:36:00AM +0530, Vivek Gautam wrote: Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. 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 |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index 66ca9ac..b03f609 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -129,7 +129,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev) exynos-dev = dev; exynos-clk = clk; - clk_enable(exynos-clk); + clk_prepare_enable(exynos-clk); eventually we need to pass this clock handling to dwc3/core.c. Just make sure it's optional since not all platforms need it. True, as of now i could see only exynos platform getting a device clock for dwc3-glue. So, if not all platforms need to do this, why should we plan to move this to dwc3/core.c ? what if dwc3.ko's probe fail ? Clock will be left enabled ;-) I guess the best way would be to handle clocks via -runtime_suspend()/-runtime_resume() ?? Right, but there was a doubt actually if you can please clear that. In device probe, after enabling runtime_pm we would need to 'pm_runtime_get_sync' the device. Thereby, in runtime_resume the clocks will be enabled. Now as soon as the device probe finishes, the device will go in suspend state, calling runtime_suspend and the clocks would be disabled. Now would it be possible for the controller to detect any connect/disconnect. it depends on how you have configured your core in coreConsultant and how you're implementing the actual IP. If you have retention flip-flops then gating clocks (but not cutting Vcc) will not loose context and, if PHYs are still enabled, you will see new connect events. But that part of PM optimization has to be done as a last step, as it tends to break things apart. -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 0/2] ARM: Exynos5250: Enabling samsung usb phy
Based on 'for-next' of linux-samsung tree with following patches from Doug on top: usb: Document clocks in samsung, exynos4210-ehci/ohci bindings ARM: dts: add usb 2.0 clock references to exynos5250 device tree Also depending upon following patch-series for Samsung-usb-phy driver: [PATCH v7 0/2] Adding USB 3.0 DRD-phy support for exynos5250 Changes from v3: Added 'clocks' and 'clock-names' entry also in device nodes, aligning with common clock framework for Samsung's SoCs. Vivek Gautam (2): ARM: Exynos5250: Enabling samsung-usb2phy driver ARM: Exynos5250: Enabling samsung-usb3phy driver arch/arm/boot/dts/exynos5250.dtsi | 29 + 1 files changed, 29 insertions(+), 0 deletions(-) -- 1.7.6.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 1/2] ARM: Exynos5250: Enabling samsung-usb2phy driver
Adding usbphy node for Exynos5250 along with the
necessary device data to be parsed.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 59be603..5ef9c1e 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -416,6 +416,21 @@
clock-names = usbhost;
};
+ usbphy@1213 {
+ compatible = samsung,exynos5250-usb2phy;
+ reg = 0x1213 0x100;
+ clocks = clock 1, clock 285;
+ clock-names = ext_xtal, usbhost;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbphy-sys {
+ reg = 0x10040704 0x8,
+ 0x10050230 0x4;
+ };
+ };
+
amba {
#address-cells = 1;
#size-cells = 1;
--
1.7.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 2/2] ARM: Exynos5250: Enabling samsung-usb3phy driver
Adding usb3.0 phy node for Exynos5250 along with the
necessary device data to be parsed.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 5ef9c1e..5b6f8c8 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -398,6 +398,20 @@
dma-names = tx, rx;
};
+ usbphy@1210 {
+ compatible = samsung,exynos5250-usb3phy;
+ reg = 0x1210 0x100;
+ clocks = clock 1, clock 286;
+ clock-names = ext_xtal, usbdrd30;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbphy-sys {
+ reg = 0x10040704 0x8;
+ };
+ };
+
usb@1211 {
compatible = samsung,exynos4210-ehci;
reg = 0x1211 0x100;
--
1.7.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 0/3] ARM: Exynos5250: Enabling dwc3-exynos driver
This patch-set is in continuation with patch-series: [PATCH v4 0/4] Enable ehci, ohci and dwc3 devices on exynos5250 out of which follwowing patches have been picked up: ARM: Exynos5250: Enabling ehci-s5p driver ARM: Exynos5250: Enabling ohci-exynos driver Based on following patch-set for Samsung's usb PHY enablement: [PATCH v4 0/2] ARM: Exynos5250: Enabling samsung usb phy and further depends on dwc3-exynos driver patch-set: [PATCH 0/2] dwc3: exynos: Device tree fixes Changes from v4: - Aligning with the recently merged common clock framework, thereby no place for clock file changes. ;-) - Adding proper binding documentation as per latest bindings changes in dwc3 driver (dwc3/core.c as well as for dwc3-exynos.c change reflected by above patch-set. - Bifurcating the patch to separate our Documentation, arch and dts changes. Vivek Gautam (3): usb: Add device tree bindings for dwc3-exynos ARM: exynos5250: dts: Enabling dwc3-exynos driver ARM: exynos5: Enable XHCI support on exynos5 .../devicetree/bindings/usb/exynos-usb.txt | 34 arch/arm/boot/dts/exynos5250.dtsi | 20 ++- arch/arm/mach-exynos/Kconfig |1 + 3 files changed, 53 insertions(+), 2 deletions(-) -- 1.7.6.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 1/3] usb: Add device tree bindings for dwc3-exynos
Document device tree binding information as required by the
Samsung' USB 3.0 controller.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/usb/exynos-usb.txt | 34
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index b3abde7..d967ba1 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -48,3 +48,37 @@ Example:
clocks = clock 285;
clock-names = usbhost;
};
+
+DWC3
+Required properties:
+ - compatible: should be samsung,exynos5250-dwusb3 for USB 3.0 DWC3
+ controller.
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+with 'reg' property.
+ - ranges: allows valid 1:1 translation between child's address space and
+ parent's address space
+ - clocks: Clock IDs array as required by the controller.
+ - clock-names: names of clocks correseponding to IDs in the clock property
+
+Sub-nodes:
+The dwc3 core should be added as subnode to Exynos dwc3 glue.
+- dwc3 :
+ The binding details of dwc3 can be found in:
+ Documentation/devicetree/bindings/usb/dwc3.txt
+
+Example:
+ usb@1200 {
+ compatible = samsung,exynos5250-dwusb3;
+ clocks = clock 286;
+ clock-names = usbdrd30;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dwc3 {
+ compatible = synopsys,dwc3;
+ reg = 0x1200 0x1;
+ interrupts = 0 72 0;
+ usb-phy = usb2_phy usb3_phy;
+ };
+ };
--
1.7.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 2/3] ARM: exynos5250: dts: Enabling dwc3-exynos driver
Adding DWC3 device tree node for Exynos5250 needed to
parse device tree data.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 5b6f8c8..e0feedb 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -398,7 +398,23 @@
dma-names = tx, rx;
};
- usbphy@1210 {
+ usb@1200 {
+ compatible = samsung,exynos5250-dwusb3;
+ clocks = clock 286;
+ clock-names = usbdrd30;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dwc3 {
+ compatible = synopsys,dwc3;
+ reg = 0x1200 0x1;
+ interrupts = 0 72 0;
+ usb-phy = usb2_phy usb3_phy;
+ };
+ };
+
+ usb3_phy: usbphy@1210 {
compatible = samsung,exynos5250-usb3phy;
reg = 0x1210 0x100;
clocks = clock 1, clock 286;
@@ -430,7 +446,7 @@
clock-names = usbhost;
};
- usbphy@1213 {
+ usb2_phy: usbphy@1213 {
compatible = samsung,exynos5250-usb2phy;
reg = 0x1213 0x100;
clocks = clock 1, clock 285;
--
1.7.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 3/3] ARM: exynos5: Enable XHCI support on exynos5
This patch enables support for XHCI on exynos5 series of SOCs, to support host side USB 3.0 support. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- arch/arm/mach-exynos/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index ef3b69a..1c582cf 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -420,6 +420,7 @@ config MACH_EXYNOS5_DT depends on ARCH_EXYNOS5 select ARM_AMBA select CLKSRC_OF + select USB_ARCH_HAS_XHCI select USE_OF help Machine support for Samsung EXYNOS5 machine with device tree enabled. -- 1.7.6.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/4] iio: adc: Document the regulator/clocks for exynos-adc
Doug,
On 14 March 2013 02:09, Doug Anderson diand...@chromium.org wrote:
The exynos ADC won't work without a regulator called vdd and a clock
called adc. Document this fact in the device tree bindings.
Signed-off-by: Doug Anderson diand...@chromium.org
Thanks for the correction. Clocks and regulator is needed.
I missed it out, as i did not submit the arch side changes
---
Changes in v2: None
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index f686378..96db940 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -20,6 +20,9 @@ Required properties:
format is being dependent on which interrupt
controller
the Samsung device uses.
- #io-channel-cells = 1; As ADC has multiple outputs
+- clocks From common clock binding: handle to adc clock.
+- clock-names From common clock binding: Shall be adc.
+- vdd-supply VDD input supply.
Note: child nodes can be added for auto probing from device tree.
@@ -31,6 +34,11 @@ adc: adc@12D1 {
interrupts = 0 106 0;
#io-channel-cells = 1;
io-channel-ranges;
+
+ clocks = clock 303;
+ clock-names = adc;
+
+ vdd-supply = buck5_reg;
};
--
1.8.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Shine bright,
(: Nav :)
___
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 Fri, Mar 15, 2013 at 11:42:48AM +0800, Shawn Guo wrote: On Thu, Mar 14, 2013 at 02:08:32PM +0100, Markus Pargmann wrote: 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? I do not follow. With my patch in place, there will be two dmaengine_pcm APIs. int snd_dmaengine_pcm_open(struct snd_pcm_substream *substream, dma_filter_fn filter_fn, void *filter_data) int snd_dmaengine_generic_pcm_open(struct snd_pcm_substream *substream, struct device *dev, const char *name) The first one is for users that their dmaengine driver hasn't converted to generic device tree bindings, and the second one is for users that their dmaengine driver is converted to generic device tree bindings. Sorry, I mixed up different patch versions and was confused. 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 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
On 03/14/2013 06:54 PM, Tony Lindgren wrote:
* 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.
OK.
#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.
OK. I'll add a port index parameter to the usbhs_phy_data structure
to indicate which port the data belongs to and a number of ports
to usbhs_init_phys()
board code can then do
static struct usbhs_phy_data phy_data[] = {
{
.port = 1, /* First USB port */
.reset_gpio = 147,
.vcc_gpio = 148
.vcc_polarity = 1,
.phy_id = nop_usb_xceiv.2,
},
};
usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
+
+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),
+
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
Hi Kishon, On 03/13/2013 10:11 AM, kishon wrote: Benoit, Will you be queuing this patch series? I'm reviewing them right now. Regards, Benoit Thanks Kishon On Thursday 07 March 2013 07:05 PM, Kishon Vijay Abraham I wrote: Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Changes from v2: * squashed the dt data for dwc3-omap with dwc3 core into a single patch. Changes from v1: Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with names that has _. It's replaced with a - here. This patch is developed on Linux 3.9-rc1. Kishon Vijay Abraham I (7): ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap and dwc3 core dt data Documentation/devicetree/bindings/usb/omap-usb.txt |1 + arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++ arch/arm/boot/dts/omap3-evm.dts|6 +++ arch/arm/boot/dts/omap3-overo.dtsi |6 +++ arch/arm/boot/dts/omap3.dtsi | 12 + arch/arm/boot/dts/omap4-panda.dts |6 +++ arch/arm/boot/dts/omap4-sdp.dts|6 +++ arch/arm/boot/dts/omap4.dtsi | 26 +++ arch/arm/boot/dts/omap5.dtsi | 48 arch/arm/boot/dts/twl4030.dtsi |2 +- 10 files changed, 118 insertions(+), 1 deletion(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND 0/2] davinci: Add device tree data for tps6507x.
Hi Mark, On 3/7/2013 11:56 AM, Vishwanathrao Badarkhe, Manish wrote: Add device tree data for regulator via tps6507x mfd device in da850-evm. Applies on top of v3.9-rc1 of linus tree. I would like to take this series via the davinci tree to manage dependencies with rest of the DT patches. Any comments/objections on this series? It will be nice to get your Acked-by/Reviewed-by. Thanks, Sekhar ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4 v2] mv643xx_eth: convert to use the Marvell Orion MDIO driver
Le 03/14/13 19:08, Florian Fainelli a écrit : 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. Thanks to the help of Andrew Lunn, there is at least two known issues with this patch version: - we need to move up the mvmdio line in drivers/net/ethernet/marvell/Makefile to make sure that configs having both mvmdio and mv643xx_eth built-in get the probing order right - the bus name used by mv643xx_eth is not the right now (orion-mdio.0 vs expected orion-mdio) so the PHY device will not be found during phy_connect() I will fix these two issues in the next version of the patchset. -- Florian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Mar 8, 2013 at 12:14 AM, Jon Hunter jon-hun...@ti.com wrote:
On 03/02/2013 02:05 PM, Grant Likely wrote:
On Tue, 26 Feb 2013 17:01:22 -0600, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 04:44 PM, Stephen Warren wrote:
On 02/26/2013 03:40 PM, Jon Hunter wrote:
On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
Are you requesting the gpio anywhere? If not then this is not going to
work as-is. This was discussed fairly recently [1] and the conclusion
was that the gpio needs to be requested before we can use as an interrupt.
That seems wrong; the GPIO/IRQ driver should handle this internally. The
Ethernet driver shouldn't know/care whether the interrupt it's given is
some form of dedicated interrupt or a GPIO-based interrupt, and even if
it somehow did, there's no irq_to_gpio() any more, so the driver can't
tell which GPIO ID it should request, unless it's given yet another
property to represent this.
I agree that ideally this should be handled internally. Did you read the
discussion on the thread that I referenced [1]? If you have any thoughts
we are open to ideas :-)
I'm on an airplane right now, but I agree 100% with Stephen. I'll try to
remember to go read that thread and respond, but this falls firmly in
the its-a-bug category for me. :-)
Grant, did you have chance to review the thread [1]?
I am trying to figure out if we should just take the original patch
proposed in the thread (although Linus had some objections) or look at
alternative solutions such as adding a irq_chip request as Stephen
suggested.
Cheers
Jon
[1] comments.gmane.org/gmane.linux.ports.arm.omap/92192
Hello Grant,
I was wondering if you have any opinions on this issue. As Jon said,
Stephen proposed [2] to add a request callback to irq_chip.
I hacked a very simple and naive patch (just to validate the idea) and
is working. The GPIO bank is requested before calling the gpio-omap
.irq_set_type function handler (gpio_irq_type) when using a GPIO as an
IRQ on a DT. So is not necessary to call it explicitly anymore.
But the patch is obviously wrong (to say the least) since the kernel
runtime locking validator complains that possible circular locking
dependency detected
I just wanted to know if I was on the right track or completely lost here.
Thanks a lot and best regards,
javier
[2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 159f5c5..f5feb43 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -807,6 +807,13 @@ static void gpio_unmask_irq(struct irq_data *d)
spin_unlock_irqrestore(bank-lock, flags);
}
+static int gpio_irq_request(struct irq_data *d)
+{
+ struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+
+ return gpio_request(irq_to_gpio(bank, d-irq), gpio-irq);
+}
+
static struct irq_chip gpio_irq_chip = {
.name = GPIO,
.irq_shutdown = gpio_irq_shutdown,
@@ -815,6 +822,7 @@ static struct irq_chip gpio_irq_chip = {
.irq_unmask = gpio_unmask_irq,
.irq_set_type = gpio_irq_type,
.irq_set_wake = gpio_wake_enable,
+ .irq_request= gpio_irq_request,
};
/*-*/
diff --git a/include/linux/irq.h b/include/linux/irq.h
index bc4e066..2aeaa24 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -303,6 +303,7 @@ struct irq_chip {
void(*irq_shutdown)(struct irq_data *data);
void(*irq_enable)(struct irq_data *data);
void(*irq_disable)(struct irq_data *data);
+ int (*irq_request)(struct irq_data *data);
void(*irq_ack)(struct irq_data *data);
void(*irq_mask)(struct irq_data *data);
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index fa17855..07c20f7 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1093,6 +1093,13 @@ __setup_irq(unsigned int irq, struct irq_desc
*desc, struct irqaction *new)
if (!shared) {
init_waitqueue_head(desc-wait_for_threads);
+ if (desc-irq_data.chip-irq_request) {
+ ret = desc-irq_data.chip-irq_request(desc-irq_data);
+
+ if (ret)
+ goto out_mask;
+ }
+
/* Setup the type (level, edge polarity) if configured: */
if (new-flags IRQF_TRIGGER_MASK) {
ret = __irq_set_trigger(desc, irq,
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4 v2] mv643xx_eth: convert to use the Marvell Orion MDIO driver
Dear Florian Fainelli, On Fri, 15 Mar 2013 12:07:12 +0100, Florian Fainelli wrote: Thanks to the help of Andrew Lunn, there is at least two known issues with this patch version: - we need to move up the mvmdio line in drivers/net/ethernet/marvell/Makefile to make sure that configs having both mvmdio and mv643xx_eth built-in get the probing order right I don't think it's the right way of fixing the problem. If there is no dependency on the two devices through the device model (i.e they don't have a parent-child relationship), then the mv643xx_eth driver should probably return -EPROBE_DEFER when it can't find its PHY so that its -probe() operation gets called once again by the kernel when other drivers (including mvmdio) have been probed. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/4] iio: adc: Add dt support for turning on the phy in exynos-adc
On 14 March 2013 02:10, Doug Anderson diand...@chromium.org wrote:
Without this change the exynos adc controller needed to have its phy
enabled in some out-of-driver C code. Add support for specifying the
phy enable register by listing it in the reg list.
Signed-off-by: Doug Anderson diand...@chromium.org
Worked for me, Its needed for Exynos5250 and future versions too.
Tested on SMDK5250.
---
Changes in v2: None
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 4 ++--
drivers/iio/adc/exynos_adc.c | 14
+-
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 96db940..05be151 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -15,7 +15,7 @@ Required properties:
Must be samsung,exynos-adc-v2 for
future controllers.
- reg: Contains ADC register address range (base address and
- length).
+ length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the timer. The
format is being dependent on which interrupt
controller
the Samsung device uses.
@@ -30,7 +30,7 @@ Example: adding device info in dtsi file
adc: adc@12D1 {
compatible = samsung,exynos-adc-v1;
- reg = 0x12D1 0x100;
+ reg = 0x12D1 0x100, 0x10040718 0x4;
interrupts = 0 106 0;
#io-channel-cells = 1;
io-channel-ranges;
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index ed6fdd7..5ab0dfd 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -85,6 +85,7 @@ enum adc_version {
struct exynos_adc {
void __iomem*regs;
+ void __iomem*enable_reg;
struct clk *clk;
unsigned intirq;
struct regulator*vdd;
@@ -269,13 +270,19 @@ static int exynos_adc_probe(struct platform_device
*pdev)
info = iio_priv(indio_dev);
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
info-regs = devm_request_and_ioremap(pdev-dev, mem);
if (!info-regs) {
ret = -ENOMEM;
goto err_iio;
}
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ info-enable_reg = devm_request_and_ioremap(pdev-dev, mem);
+ if (!info-enable_reg) {
+ ret = -ENOMEM;
+ goto err_iio;
+ }
+
irq = platform_get_irq(pdev, 0);
if (irq 0) {
dev_err(pdev-dev, no irq resource?\n);
@@ -295,6 +302,8 @@ static int exynos_adc_probe(struct platform_device *pdev)
goto err_iio;
}
+ writel(1, info-enable_reg);
+
info-clk = devm_clk_get(pdev-dev, adc);
if (IS_ERR(info-clk)) {
dev_err(pdev-dev, failed getting clock, err = %ld\n,
@@ -370,6 +379,7 @@ static int exynos_adc_remove(struct platform_device *pdev)
exynos_adc_remove_devices);
regulator_disable(info-vdd);
clk_disable_unprepare(info-clk);
+ writel(0, info-enable_reg);
iio_device_unregister(indio_dev);
free_irq(info-irq, info);
iio_device_free(indio_dev);
@@ -395,6 +405,7 @@ static int exynos_adc_suspend(struct device *dev)
}
clk_disable_unprepare(info-clk);
+ writel(0, info-enable_reg);
regulator_disable(info-vdd);
return 0;
@@ -410,6 +421,7 @@ static int exynos_adc_resume(struct device *dev)
if (ret)
return ret;
+ writel(1, info-enable_reg);
clk_prepare_enable(info-clk);
exynos_adc_hw_init(info);
--
1.8.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Shine bright,
(: Nav :)
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the description
for the #interrupt-cells property after the interrupt-controller.
This is confusing so is better to move the interrupt-controller after
#interrupt-cells description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/gpio/gpio.txt.
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
Hello,
Any comments on this patch?
I know is just a trivial documentation fix but I think it can be quite
helpful for people referring to gpio-omap binding.
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
+ Jon Hi Kishon, On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote: Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Changes from v2: * squashed the dt data for dwc3-omap with dwc3 core into a single patch. Changes from v1: Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with names that has _. It's replaced with a - here. This patch is developed on Linux 3.9-rc1. The patches looks really good. I've just had to rebase on top of my HEAD due to some conflict with GPMC patch already applied. I cleaned as well some subject and changelog for consistency. The patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Jon, You might have to rebase your series on top of the new HEAD before reposting. Thanks, Benoit Kishon Vijay Abraham I (7): ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap and dwc3 core dt data Documentation/devicetree/bindings/usb/omap-usb.txt |1 + arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++ arch/arm/boot/dts/omap3-evm.dts|6 +++ arch/arm/boot/dts/omap3-overo.dtsi |6 +++ arch/arm/boot/dts/omap3.dtsi | 12 + arch/arm/boot/dts/omap4-panda.dts |6 +++ arch/arm/boot/dts/omap4-sdp.dts|6 +++ arch/arm/boot/dts/omap4.dtsi | 26 +++ arch/arm/boot/dts/omap5.dtsi | 48 arch/arm/boot/dts/twl4030.dtsi |2 +- 10 files changed, 118 insertions(+), 1 deletion(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: Florian Fainelli flor...@openwrt.org Date: Thu, 14 Mar 2013 19:08:31 +0100 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. All applied to net-next, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
Le 03/15/13 13:53, David Miller a écrit : From: Florian Fainelli flor...@openwrt.org Date: Thu, 14 Mar 2013 19:08:31 +0100 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. All applied to net-next, thanks. Oh woah that was fast, maybe too fast, I will submit a follow-up patch for patch 4 to address the issues I mentionned earlier. -- Florian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: David Miller da...@davemloft.net Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT) From: Florian Fainelli flor...@openwrt.org Date: Thu, 14 Mar 2013 19:08:31 +0100 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. All applied to net-next, thanks. Actually, reverted. Please send me code which actually compiles: drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_wait_ready’: drivers/net/ethernet/marvell/mvmdio.c:70:28: error: ‘NO_IRQ’ undeclared (first use in this function) drivers/net/ethernet/marvell/mvmdio.c:70:28: note: each undeclared identifier is reported only once for each function it appears in drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_probe’: drivers/net/ethernet/marvell/mvmdio.c:242:24: error: ‘NO_IRQ’ undeclared (first use in this function) make[4]: *** [drivers/net/ethernet/marvell/mvmdio.o] Error 1 And don't use Kconfig dependencies to work around this, fix it properly. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
Hi Javier,
On 03/15/2013 01:18 PM, Javier Martinez Canillas wrote:
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the description
for the #interrupt-cells property after the interrupt-controller.
This is confusing so is better to move the interrupt-controller after
#interrupt-cells description.
Mmm, your are doing the opposite :-)
I guess what we do want is that:
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
So we move #interrupt-cells after the interrupt-controller description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/gpio/gpio.txt.
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
Hello,
Any comments on this patch?
I know is just a trivial documentation fix but I think it can be quite
helpful for people referring to gpio-omap binding.
I do agree. The patch is good, but the changelog is confusing.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
Le 03/15/13 13:55, David Miller a écrit : From: David Miller da...@davemloft.net Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT) From: Florian Fainelli flor...@openwrt.org Date: Thu, 14 Mar 2013 19:08:31 +0100 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. All applied to net-next, thanks. Actually, reverted. Please send me code which actually compiles: drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_wait_ready’: drivers/net/ethernet/marvell/mvmdio.c:70:28: error: ‘NO_IRQ’ undeclared (first use in this function) drivers/net/ethernet/marvell/mvmdio.c:70:28: note: each undeclared identifier is reported only once for each function it appears in drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_probe’: drivers/net/ethernet/marvell/mvmdio.c:242:24: error: ‘NO_IRQ’ undeclared (first use in this function) make[4]: *** [drivers/net/ethernet/marvell/mvmdio.o] Error 1 And don't use Kconfig dependencies to work around this, fix it properly. Is there any platform out there for which we do not have a NO_IRQ definition by now? If so, what is it? -- Florian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: Florian Fainelli flor...@openwrt.org Date: Fri, 15 Mar 2013 13:53:10 +0100 Le 03/15/13 13:55, David Miller a écrit : From: David Miller da...@davemloft.net Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT) From: Florian Fainelli flor...@openwrt.org Date: Thu, 14 Mar 2013 19:08:31 +0100 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. All applied to net-next, thanks. Actually, reverted. Please send me code which actually compiles: drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_wait_ready’: drivers/net/ethernet/marvell/mvmdio.c:70:28: error: ‘NO_IRQ’ undeclared (first use in this function) drivers/net/ethernet/marvell/mvmdio.c:70:28: note: each undeclared identifier is reported only once for each function it appears in drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_probe’: drivers/net/ethernet/marvell/mvmdio.c:242:24: error: ‘NO_IRQ’ undeclared (first use in this function) make[4]: *** [drivers/net/ethernet/marvell/mvmdio.o] Error 1 And don't use Kconfig dependencies to work around this, fix it properly. Is there any platform out there for which we do not have a NO_IRQ definition by now? If so, what is it? Obviously if x86_64 doesn't even build your changes, that is one such platform. Also, is grep not working on your computer? Platforms are absolutely no required to have this define, zero is the only valid no IRQ which is portable in any way. This is an old and tired topic, portable code does not use NO_IRQ, and that's simply the end of it. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
Le 03/15/13 14:05, David Miller a écrit : From: Florian Fainelli flor...@openwrt.org Date: Fri, 15 Mar 2013 13:53:10 +0100 Le 03/15/13 13:55, David Miller a écrit : From: David Miller da...@davemloft.net Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT) From: Florian Fainelli flor...@openwrt.org Date: Thu, 14 Mar 2013 19:08:31 +0100 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. All applied to net-next, thanks. Actually, reverted. Please send me code which actually compiles: drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_wait_ready’: drivers/net/ethernet/marvell/mvmdio.c:70:28: error: ‘NO_IRQ’ undeclared (first use in this function) drivers/net/ethernet/marvell/mvmdio.c:70:28: note: each undeclared identifier is reported only once for each function it appears in drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_probe’: drivers/net/ethernet/marvell/mvmdio.c:242:24: error: ‘NO_IRQ’ undeclared (first use in this function) make[4]: *** [drivers/net/ethernet/marvell/mvmdio.o] Error 1 And don't use Kconfig dependencies to work around this, fix it properly. Is there any platform out there for which we do not have a NO_IRQ definition by now? If so, what is it? Obviously if x86_64 doesn't even build your changes, that is one such platform. Also, is grep not working on your computer? I built tested on PowerPC and ARM which are the platforms actually *using* these drivers and forgot that you build for x86_64. Platforms are absolutely no required to have this define, zero is the only valid no IRQ which is portable in any way. This is an old and tired topic, portable code does not use NO_IRQ, and that's simply the end of it. I changed not to rely on NO_IRQ anymore. Thanks! -- Florian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
On Fri, Mar 15, 2013 at 1:56 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Javier,
On 03/15/2013 01:18 PM, Javier Martinez Canillas wrote:
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the description
for the #interrupt-cells property after the interrupt-controller.
This is confusing so is better to move the interrupt-controller after
#interrupt-cells description.
Mmm, your are doing the opposite :-)
I guess what we do want is that:
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
So we move #interrupt-cells after the interrupt-controller description.
Indeed!
I got confused I guess...
I'll send a v3 patch fixing the changelog
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/gpio/gpio.txt.
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
Hello,
Any comments on this patch?
I know is just a trivial documentation fix but I think it can be quite
helpful for people referring to gpio-omap binding.
I do agree. The patch is good, but the changelog is confusing.
Regards,
Benoit
Thanks a lot for your feedback and best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] ARM: davinci: da850 evm: update clock rate for UART 1/2 DT nodes
Hi Sekhar,
On Thu, Feb 28, 2013 at 16:09:47, Nori, Sekhar wrote:
Prakash,
On 2/19/2013 2:02 PM, Manjunathappa, Prakash wrote:
DT kernel with latest of denx SPL U-boot boots with garbled UART
logs. This is because in U-boot UART2 gets sourced by PLL0_SYSCLK2
configured for 150MHz. But later in kernel UART2 gets mapped to
PLL1_SYSCLK2 and is configured for 132MHz not for 150MHz.
PLL1 is configured for 264MHz to support mDDR on the EVM. That is
memory controller driving mDDR can be configured for 150MHz and
mDDR it self can operate at 132MHz.
So override UART1 and UART2 DT node clock-frequency property with
rate available on da850 EVM.
Signed-off-by: Manjunathappa, Prakash prakash...@ti.com
How about dropping the clock-frequency attribute altogether? of_serial.c
seems to be falling back on clk apis if frequency is not passed and that
should make the kernel work with all versions of U-Boot.
Yes it can be dropped by having duplicate clock node for UART having only
dev_id. This is required because DT kernel does the clk_get with only dev_id
and non-DT kernel only with con_id. In DT kernel clk_get is done from generic
code of_platform_serial_setup:of_serial.c and in non-DT kernel is done from
platform code, davinci_serial_setup_clk:arch/arm/mach-davinci/serial.c
Please let me know your opinion on this.
Thanks,
Prakash
Thanks,
Sekhar
---
arch/arm/boot/dts/da850-evm.dts |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts
b/arch/arm/boot/dts/da850-evm.dts
index f712fb6..c359872 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -22,9 +22,11 @@
status = okay;
};
serial1: serial@1d0c000 {
+ clock-frequency = 13200;
status = okay;
};
serial2: serial@1d0d000 {
+ clock-frequency = 13200;
status = okay;
};
rtc0: rtc@1c23000 {
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
The binding documentation for the OMAP GPIO controller has the
#interrupt-cells property listed before #interrupt-controller
property but its description after.
This is confusing so we move #interrupt-cells after the
interrupt-controller property so is followed by its description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
and Documentation/devicetree/bindings/gpio/gpio.txt.
According with these docs, the order of the properties for a gpio-omap
device node should be:
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
Changes since v2:
- Fix changelog that explained the opposite of what the patch was doing as
suggested by Benoit Cousson.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
On Friday 15 March 2013 06:11 PM, Benoit Cousson wrote: + Jon Hi Kishon, On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote: Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Changes from v2: * squashed the dt data for dwc3-omap with dwc3 core into a single patch. Changes from v1: Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with names that has _. It's replaced with a - here. This patch is developed on Linux 3.9-rc1. The patches looks really good. I've just had to rebase on top of my HEAD due to some conflict with GPMC patch already applied. I cleaned as well some subject and changelog for consistency. Ok. Thanks :-) Regards Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 0/3] gpio: Add device driver for GRGPIO cores and support custom accessors with gpio-generic
Differences since v4: - Split out changes to gpio-generic into patch 1 - Make the basic driver without any irq support into patch 2, so that things can be applied so far if more revisions needs to be done for the irq support parts. - Change irq support to use irq domain and put it in patch 3 Signed-off-by: Andreas Larsson andr...@gaisler.com Andreas Larsson (3): gpio: gpio-generic: Add 16 and 32 bit big endian byte order support gpio: grgpio: Add device driver for GRGPIO cores gpio: grgpio: Add irq support .../devicetree/bindings/gpio/gpio-grgpio.txt | 29 ++ drivers/gpio/Kconfig |9 + drivers/gpio/Makefile |1 + drivers/gpio/gpio-generic.c| 56 ++- drivers/gpio/gpio-grgpio.c | 489 include/linux/basic_mmio_gpio.h|1 + 6 files changed, 576 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-grgpio.txt create mode 100644 drivers/gpio/gpio-grgpio.c -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 1/3] gpio: gpio-generic: Add 16 and 32 bit big endian byte order support
There is no general support for 64-bit big endian accesses, so that is
left unsupported.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
drivers/gpio/gpio-generic.c | 56 ---
include/linux/basic_mmio_gpio.h |1 +
2 files changed, 48 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
index 05fcc0f..42d4706 100644
--- a/drivers/gpio/gpio-generic.c
+++ b/drivers/gpio/gpio-generic.c
@@ -104,6 +104,26 @@ static unsigned long bgpio_read64(void __iomem *reg)
}
#endif /* BITS_PER_LONG = 64 */
+static void bgpio_write16be(void __iomem *reg, unsigned long data)
+{
+ iowrite16be(data, reg);
+}
+
+static unsigned long bgpio_read16be(void __iomem *reg)
+{
+ return ioread16be(reg);
+}
+
+static void bgpio_write32be(void __iomem *reg, unsigned long data)
+{
+ iowrite32be(data, reg);
+}
+
+static unsigned long bgpio_read32be(void __iomem *reg)
+{
+ return ioread32be(reg);
+}
+
static unsigned long bgpio_pin2mask(struct bgpio_chip *bgc, unsigned int pin)
{
return 1 pin;
@@ -249,7 +269,8 @@ static int bgpio_dir_out_inv(struct gpio_chip *gc, unsigned
int gpio, int val)
static int bgpio_setup_accessors(struct device *dev,
struct bgpio_chip *bgc,
-bool be)
+bool bit_be,
+bool byte_be)
{
switch (bgc-bits) {
@@ -258,17 +279,33 @@ static int bgpio_setup_accessors(struct device *dev,
bgc-write_reg = bgpio_write8;
break;
case 16:
- bgc-read_reg = bgpio_read16;
- bgc-write_reg = bgpio_write16;
+ if (byte_be) {
+ bgc-read_reg = bgpio_read16be;
+ bgc-write_reg = bgpio_write16be;
+ } else {
+ bgc-read_reg = bgpio_read16;
+ bgc-write_reg = bgpio_write16;
+ }
break;
case 32:
- bgc-read_reg = bgpio_read32;
- bgc-write_reg = bgpio_write32;
+ if (byte_be) {
+ bgc-read_reg = bgpio_read32be;
+ bgc-write_reg = bgpio_write32be;
+ } else {
+ bgc-read_reg = bgpio_read32;
+ bgc-write_reg = bgpio_write32;
+ }
break;
#if BITS_PER_LONG = 64
case 64:
- bgc-read_reg = bgpio_read64;
- bgc-write_reg = bgpio_write64;
+ if (byte_be) {
+ dev_err(dev,
+ 64 bit big endian byte order unsupported\n);
+ return -EINVAL;
+ } else {
+ bgc-read_reg = bgpio_read64;
+ bgc-write_reg = bgpio_write64;
+ }
break;
#endif /* BITS_PER_LONG = 64 */
default:
@@ -276,7 +313,7 @@ static int bgpio_setup_accessors(struct device *dev,
return -EINVAL;
}
- bgc-pin2mask = be ? bgpio_pin2mask_be : bgpio_pin2mask;
+ bgc-pin2mask = bit_be ? bgpio_pin2mask_be : bgpio_pin2mask;
return 0;
}
@@ -385,7 +422,8 @@ int bgpio_init(struct bgpio_chip *bgc, struct device *dev,
if (ret)
return ret;
- ret = bgpio_setup_accessors(dev, bgc, flags BGPIOF_BIG_ENDIAN);
+ ret = bgpio_setup_accessors(dev, bgc, flags BGPIOF_BIG_ENDIAN,
+ flags BGPIOF_BIG_ENDIAN_BYTE_ORDER);
if (ret)
return ret;
diff --git a/include/linux/basic_mmio_gpio.h b/include/linux/basic_mmio_gpio.h
index 1c504ca..d8a97ec 100644
--- a/include/linux/basic_mmio_gpio.h
+++ b/include/linux/basic_mmio_gpio.h
@@ -72,5 +72,6 @@ int bgpio_init(struct bgpio_chip *bgc, struct device *dev,
#define BGPIOF_BIG_ENDIAN BIT(0)
#define BGPIOF_UNREADABLE_REG_SET BIT(1) /* reg_set is unreadable */
#define BGPIOF_UNREADABLE_REG_DIR BIT(2) /* reg_dir is unreadable */
+#define BGPIOF_BIG_ENDIAN_BYTE_ORDER BIT(3)
#endif /* __BASIC_MMIO_GPIO_H */
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 2/3] gpio: grgpio: Add device driver for GRGPIO cores
This driver supports GRGPIO gpio cores available in the GRLIB VHDL IP
core library from Aeroflex Gaisler.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
.../devicetree/bindings/gpio/gpio-grgpio.txt | 24 +++
drivers/gpio/Kconfig |9 ++
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-grgpio.c | 164
4 files changed, 198 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
create mode 100644 drivers/gpio/gpio-grgpio.c
diff --git a/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
b/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
new file mode 100644
index 000..1050dc8
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
@@ -0,0 +1,24 @@
+Aeroflex Gaisler GRGPIO General Purpose I/O cores.
+
+The GRGPIO GPIO core is available in the GRLIB VHDL IP core library.
+
+Note: In the ordinary environment for the GRGPIO core, a Leon SPARC system,
+these properties are built from information in the AMBA plugplay.
+
+Required properties:
+
+- name : Should be GAISLER_GPIO or 01_01a
+
+- reg : Address and length of the register set for the device
+
+- interrupts : Interrupt numbers for this device
+
+Optional properties:
+
+- base : The base gpio number for the core. A dynamic base is used if not
+ present
+
+- nbits : The number of gpio lines. If not present driver assumes 32 lines.
+
+For further information look in the documentation for the GLIB IP core library:
+http://www.gaisler.com/products/grlib/grip.pdf
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 93aaadf..32f068d 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -309,6 +309,15 @@ config GPIO_LYNXPOINT
driver for GPIO functionality on Intel Lynxpoint PCH chipset
Requires ACPI device enumeration code to set up a platform device.
+config GPIO_GRGPIO
+ tristate Aeroflex Gaisler GRGPIO support
+ depends on OF
+ select GPIO_GENERIC
+ select IRQ_DOMAIN
+ help
+ Select this to support Aeroflex Gaisler GRGPIO cores from the GRLIB
+ VHDL IP core library.
+
comment I2C GPIO expanders:
config GPIO_ARIZONA
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 22e07bc..3e6be51 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_DAVINCI)+= gpio-davinci.o
obj-$(CONFIG_GPIO_EM) += gpio-em.o
obj-$(CONFIG_GPIO_EP93XX) += gpio-ep93xx.o
obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
+obj-$(CONFIG_GPIO_GRGPIO) += gpio-grgpio.o
obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
obj-$(CONFIG_GPIO_IT8761E) += gpio-it8761e.o
obj-$(CONFIG_GPIO_JANZ_TTL)+= gpio-janz-ttl.o
diff --git a/drivers/gpio/gpio-grgpio.c b/drivers/gpio/gpio-grgpio.c
new file mode 100644
index 000..f8902da
--- /dev/null
+++ b/drivers/gpio/gpio-grgpio.c
@@ -0,0 +1,164 @@
+/*
+ * Driver for Aeroflex Gaisler GRGPIO General Purpose I/O cores.
+ *
+ * 2013 (c) Aeroflex Gaisler AB
+ *
+ * This driver supports the GRGPIO GPIO core available in the GRLIB VHDL
+ * IP core library.
+ *
+ * Full documentation of the GRGPIO core can be found here:
+ * http://www.gaisler.com/products/grlib/grip.pdf
+ *
+ * See Documentation/devicetree/bindings/gpio/gpio-grgpio.txt for
+ * information on open firmware properties.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * Contributors: Andreas Larsson andr...@gaisler.com
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/spinlock.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/of_platform.h
+#include linux/gpio.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/basic_mmio_gpio.h
+
+#define GRGPIO_MAX_NGPIO 32
+
+struct grgpio_regs {
+ u32 data; /* 0x00 */
+ u32 output; /* 0x04 */
+ u32 dir;/* 0x08 */
+ u32 imask; /* 0x0c */
+ u32 ipol; /* 0x10 */
+ u32 iedge; /* 0x14 */
+ u32 bypass; /* 0x18 */
+ u32 __reserved; /* 0x1c */
+ u32 imap[8];/* 0x20-0x3c */
+};
+
+struct grgpio_priv {
+ struct bgpio_chip bgc;
+ struct grgpio_regs __iomem *regs;
+ struct device *dev;
+};
+
+static inline struct grgpio_priv *grgpio_gc_to_priv(struct gpio_chip *gc)
+{
+ struct bgpio_chip *bgc = to_bgpio_chip(gc);
+
+ return container_of(bgc, struct grgpio_priv, bgc);
+}
+
+static int grgpio_to_irq(struct gpio_chip *gc, unsigned offset)
+{
+ return -ENXIO;
+}
+
+static int grgpio_probe(struct platform_device *ofdev)
+{
+ struct device_node *np = ofdev-dev.of_node;
+
[PATCH v5 3/3] gpio: grgpio: Add irq support
The drivers sets up an irq domain and hands out unique virqs to irq
capable gpio lines regardless of which underlying irqs maps to which gpio
line.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
.../devicetree/bindings/gpio/gpio-grgpio.txt |5 +
drivers/gpio/gpio-grgpio.c | 333 +++-
2 files changed, 334 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
b/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
index 1050dc8..e28bc3c 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
@@ -20,5 +20,10 @@ Optional properties:
- nbits : The number of gpio lines. If not present driver assumes 32 lines.
+- irqmap : An array with an index for each gpio line. An index is either a
valid
+ index into the interrupts property array, or 0x that indicates
+ no irq for that line. Driver provides no interrupt support if not
+ present.
+
For further information look in the documentation for the GLIB IP core library:
http://www.gaisler.com/products/grlib/grip.pdf
diff --git a/drivers/gpio/gpio-grgpio.c b/drivers/gpio/gpio-grgpio.c
index f8902da..3acff77 100644
--- a/drivers/gpio/gpio-grgpio.c
+++ b/drivers/gpio/gpio-grgpio.c
@@ -32,6 +32,9 @@
#include linux/slab.h
#include linux/err.h
#include linux/basic_mmio_gpio.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/irqdomain.h
#define GRGPIO_MAX_NGPIO 32
@@ -47,10 +50,41 @@ struct grgpio_regs {
u32 imap[8];/* 0x20-0x3c */
};
+struct grgpio_uirq {
+ u8 refcnt; /* Reference counter to manage requesting/freeing of uirq */
+ u8 uirq; /* Underlying virq of the gpio driver */
+};
+
+struct grgpio_lirq {
+ s8 index; /* Index into struct grgpio_priv's uirqs, or -1 */
+ u8 virq; /* virq for the gpio line */
+};
+
struct grgpio_priv {
struct bgpio_chip bgc;
struct grgpio_regs __iomem *regs;
struct device *dev;
+
+ u32 imask; /* irq mask shadow register */
+
+ /* The grgpio core can have multiple irqs. Severeal gpio lines can
+* potentially be mapped to the same irq. This driver sets up an
+* irq domain and hands out separate virqs to each gpio line
+*/
+ struct irq_domain *domain;
+
+ /* This array contains information on each underlying irq, each
+* irq of the grgpio core itself.
+*/
+ struct grgpio_uirq uirqs[GRGPIO_MAX_NGPIO];
+
+ /* This array contains information for each gpio line on the
+* virtual irqs obtains from this driver. An index value of -1 for
+* a certain gpio line indicates that the line has no
+* irq. Otherwise the index connects the virq to the underlying
+* irq by pointing into the uirqs array.
+*/
+ struct grgpio_lirq lirqs[GRGPIO_MAX_NGPIO];
};
static inline struct grgpio_priv *grgpio_gc_to_priv(struct gpio_chip *gc)
@@ -60,11 +94,231 @@ static inline struct grgpio_priv *grgpio_gc_to_priv(struct
gpio_chip *gc)
return container_of(bgc, struct grgpio_priv, bgc);
}
+static void grgpio_set_imask(struct grgpio_priv *priv, unsigned int offset,
+int val)
+{
+ struct bgpio_chip *bgc = priv-bgc;
+ unsigned long mask = bgc-pin2mask(bgc, offset);
+ unsigned long flags;
+
+ spin_lock_irqsave(bgc-lock, flags);
+
+ if (val)
+ priv-imask |= mask;
+ else
+ priv-imask = ~mask;
+ bgc-write_reg(priv-regs-imask, priv-imask);
+
+ spin_unlock_irqrestore(bgc-lock, flags);
+}
+
static int grgpio_to_irq(struct gpio_chip *gc, unsigned offset)
{
- return -ENXIO;
+ struct grgpio_priv *priv = grgpio_gc_to_priv(gc);
+
+ if (offset gc-ngpio)
+ return -ENXIO;
+
+ if (priv-lirqs[offset].index 0)
+ return -ENXIO;
+
+ return irq_create_mapping(priv-domain, offset);
+}
+
+/* IRQ chip functions */
+
+static int grgpio_irq_set_type(struct irq_data *d, unsigned int type)
+{
+ struct grgpio_priv *priv = irq_data_get_irq_chip_data(d);
+ unsigned long flags;
+ u32 mask = BIT(d-hwirq);
+ u32 ipol;
+ u32 iedge;
+ u32 pol;
+ u32 edge;
+
+ switch (type) {
+ case IRQ_TYPE_LEVEL_LOW:
+ pol = 0;
+ edge = 0;
+ break;
+ case IRQ_TYPE_LEVEL_HIGH:
+ pol = mask;
+ edge = 0;
+ break;
+ case IRQ_TYPE_EDGE_FALLING:
+ pol = 0;
+ edge = mask;
+ break;
+ case IRQ_TYPE_EDGE_RISING:
+ pol = mask;
+ edge = mask;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ spin_lock_irqsave(priv-bgc.lock, flags);
+
+ ipol
Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 16:42-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: 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. OMAP has been converted to the common clock framework (CCF). Are you referring to clock framework transition to DT or something else? I should have been explicit here - we do not have DT entries for clock nodes for OMAP. For example, compare: git grep clocks arch/arm/boot/dts/omap*.dts* Vs git grep clocks arch/arm/boot/dts/imx*.dts* The specific comment above was intended to see the following series equivalent in upstream: https://patchwork.kernel.org/patch/2195431/ https://patchwork.kernel.org/patch/2195421/ https://patchwork.kernel.org/patch/2195451/ https://patchwork.kernel.org/patch/2195441/ https://patchwork.kernel.org/patch/2195461/ -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
On 16:44-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: 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. Not sure I following the last sentence. The tables are in a different dtsi file and only the relevant file should be included, right? omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx). The opp tables introduced by this patch in omap36xx.dtsi will override the ones defined on omap3.dtsi. Will the following rephrase help clarify this? Original: This overrides the default OMAP34xx CPU OPP table definition. Suggested; This overrides the default OMAP34xx CPU OPP table definition in omap3.dtsi. -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 0/8] ARM: dts: Various OMAP2+ device-tree updates
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 Benoit's for_3.10/dts branch [1]. Branch available here [2]. V2 changes: - Rebased on Benoit's for_3.10/dts branch - Squashed patches adding support for OMAP3430 SDP board and patch to add flash support for OMAP3430 SDP board. [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts [2] git://github.com/jonhunter/linux.git omap-dt-for-v3.10 Jon Hunter (8): 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: Add GPMC node for OMAP2, OMAP4 and OMAP5 ARM: dts: Add OMAP2 gpio bindings ARM: dts: OMAP3+: Correct gpio #interrupts-cells property ARM: dts: OMAP3: Add reg and interrupt properties for gpio ARM: dts: OMAP3: Add support for OMAP3430 SDP board 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 +++- 11 files changed, 493 insertions(+), 23 deletions(-) create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts create mode 100644 arch/arm/boot/dts/omap4460.dtsi -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 1/8] ARM: OMAP2+: Prepare for device-tree PMU support
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/pmu.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 9debf82..9ace8ea 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,6 +11,8 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
+#include linux/of.h
+
#include asm/pmu.h
#include soc.h
@@ -63,6 +65,15 @@ static int __init omap_init_pmu(void)
unsigned oh_num;
char **oh_names;
+ /* XXX Remove this check when the CTI driver is available */
+ if (cpu_is_omap443x()) {
+ pr_info(ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n);
+ return 0;
+ }
+
+ if (of_have_populated_dt())
+ return 0;
+
/*
* To create an ARM-PMU device the following HWMODs
* are required for the various OMAP2+ devices.
@@ -75,9 +86,6 @@ static int __init omap_init_pmu(void)
if (cpu_is_omap443x()) {
oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
oh_names = omap4430_pmu_oh_names;
- /* XXX Remove the next two lines when CTI driver available */
- pr_info(ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n);
- return 0;
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 2/8] ARM: dts: OMAP2+: Add PMU nodes
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the absence of a cross-trigger
interface driver.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |6 ++
arch/arm/boot/dts/omap4-panda-es.dts |2 ++
arch/arm/boot/dts/omap4460.dtsi | 18 ++
4 files changed, 31 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4460.dtsi
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..27f5ea1 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -26,6 +26,11 @@
};
};
+ pmu {
+ compatible = arm,arm1136-pmu;
+ interrupts = 3;
+ };
+
soc {
compatible = ti,omap-infra;
mpu {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d9970de..0ec7d5c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -26,6 +26,12 @@
};
};
+ pmu {
+ compatible = arm,cortex-a8-pmu;
+ interrupts = 3;
+ ti,hwmods = debugss;
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..2a6e344 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
/include/ omap4-panda.dts
+/include/ omap4460.dtsi
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
sound {
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
new file mode 100644
index 000..0a1d38b
--- /dev/null
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4460 SoC
+ *
+ * Copyright (C) 2012 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.
+ */
+
+/ {
+ pmu {
+ compatible = arm,cortex-a9-pmu;
+ interrupts = 0 54 0x4,
+0 55 0x4;
+ ti,hwmods = debugss;
+ };
+};
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 4/8] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 11 +++
arch/arm/boot/dts/omap2430.dtsi | 11 +++
arch/arm/boot/dts/omap4.dtsi| 11 +++
arch/arm/boot/dts/omap5.dtsi| 11 +++
4 files changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index af65609..d4ce6c2 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -29,6 +29,17 @@
pinctrl-single,function-mask = 0x3f;
};
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc;
+ reg = 0x6800a000 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ ti,hwmods = gpmc;
+ };
+
mcbsp1: mcbsp@48074000 {
compatible = ti,omap2420-mcbsp;
reg = 0x48074000 0xff;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c392445..832f184 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -29,6 +29,17 @@
pinctrl-single,function-mask = 0x3f;
};
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap2430-gpmc;
+ reg = 0x6e00 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ ti,hwmods = gpmc;
+ };
+
mcbsp1: mcbsp@48074000 {
compatible = ti,omap2430-mcbsp;
reg = 0x48074000 0xff;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 6669311..bcd64f5 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -196,6 +196,17 @@
#interrupt-cells = 1;
};
+ gpmc: gpmc@5000 {
+ compatible = ti,omap4430-gpmc;
+ reg = 0x5000 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ interrupts = 0 20 0x4;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ ti,hwmods = gpmc;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap4-uart;
reg = 0x4806a000 0x100;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index f840499..61cbd1c 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -208,6 +208,17 @@
#interrupt-cells = 1;
};
+ gpmc: gpmc@5000 {
+ compatible = ti,omap4430-gpmc;
+ reg = 0x5000 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ interrupts = 0 20 0x4;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ ti,hwmods = gpmc;
+ };
+
i2c1: i2c@4807 {
compatible = ti,omap4-i2c;
reg = 0x4807 0x100;
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 5/8] ARM: dts: Add OMAP2 gpio bindings
Add gpios bindings for OMAP2420 and OMAP2430 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 44 +++
arch/arm/boot/dts/omap2430.dtsi | 55 +++
2 files changed, 99 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index d4ce6c2..eee902f 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -29,6 +29,50 @@
pinctrl-single,function-mask = 0x3f;
};
+ gpio1: gpio@48018000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x48018000 0x200;
+ interrupts = 29;
+ ti,hwmods = gpio1;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio2: gpio@4801a000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x4801a000 0x200;
+ interrupts = 30;
+ ti,hwmods = gpio2;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio3: gpio@4801c000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x4801c000 0x200;
+ interrupts = 31;
+ ti,hwmods = gpio3;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio4: gpio@4801e000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x4801e000 0x200;
+ interrupts = 32;
+ ti,hwmods = gpio4;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
gpmc: gpmc@6800a000 {
compatible = ti,omap2420-gpmc;
reg = 0x6800a000 0x1000;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 832f184..fb74382 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -29,6 +29,61 @@
pinctrl-single,function-mask = 0x3f;
};
+ gpio1: gpio@4900c000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x4900c000 0x200;
+ interrupts = 29;
+ ti,hwmods = gpio1;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio2: gpio@4900e000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x4900e000 0x200;
+ interrupts = 30;
+ ti,hwmods = gpio2;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio3: gpio@4901 {
+ compatible = ti,omap2-gpio;
+ reg = 0x4901 0x200;
+ interrupts = 31;
+ ti,hwmods = gpio3;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio4: gpio@49012000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x49012000 0x200;
+ interrupts = 32;
+ ti,hwmods = gpio4;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio5: gpio@480b6000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x480b6000 0x200;
+ interrupts = 33;
+ ti,hwmods = gpio5;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
gpmc: gpmc@6e00 {
compatible = ti,omap2430-gpmc;
reg = 0x6e00 0x1000;
--
1.7.10.4
___
devicetree-discuss mailing
[PATCH V2 7/8] ARM: dts: OMAP3: Add reg and interrupt properties for gpio
The OMAP3 gpio bindings are currently missing the reg and interrupt
properties and so add these properties.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index badedc8..0cc65b5 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,6 +113,8 @@
gpio1: gpio@4831 {
compatible = ti,omap3-gpio;
+ reg = 0x4831 0x200;
+ interrupts = 29;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;
@@ -122,6 +124,8 @@
gpio2: gpio@4905 {
compatible = ti,omap3-gpio;
+ reg = 0x4905 0x200;
+ interrupts = 30;
ti,hwmods = gpio2;
gpio-controller;
#gpio-cells = 2;
@@ -131,6 +135,8 @@
gpio3: gpio@49052000 {
compatible = ti,omap3-gpio;
+ reg = 0x49052000 0x200;
+ interrupts = 31;
ti,hwmods = gpio3;
gpio-controller;
#gpio-cells = 2;
@@ -140,6 +146,8 @@
gpio4: gpio@49054000 {
compatible = ti,omap3-gpio;
+ reg = 0x49054000 0x200;
+ interrupts = 32;
ti,hwmods = gpio4;
gpio-controller;
#gpio-cells = 2;
@@ -149,6 +157,8 @@
gpio5: gpio@49056000 {
compatible = ti,omap3-gpio;
+ reg = 0x49056000 0x200;
+ interrupts = 33;
ti,hwmods = gpio5;
gpio-controller;
#gpio-cells = 2;
@@ -158,6 +168,8 @@
gpio6: gpio@49058000 {
compatible = ti,omap3-gpio;
+ reg = 0x49058000 0x200;
+ interrupts = 34;
ti,hwmods = gpio6;
gpio-controller;
#gpio-cells = 2;
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2 3/8] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC peripheral on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap2.dtsi | 12
arch/arm/boot/dts/omap3.dtsi | 40
arch/arm/boot/dts/omap4.dtsi | 41 +
arch/arm/boot/dts/omap5.dtsi | 41 +
4 files changed, 134 insertions(+)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 27f5ea1..84183f0 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -54,6 +54,18 @@
reg = 0x480FE000 0x1000;
};
+ sdma: dma-controller@48056000 {
+ compatible = ti,omap2430-sdma, ti,omap2420-sdma;
+ reg = 0x48056000 0x1000;
+ interrupts = 12,
+13,
+14,
+15;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 64;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap2-uart;
ti,hwmods = uart1;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 0ec7d5c..1dc72ea 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -81,6 +81,18 @@
reg = 0x4820 0x1000;
};
+ sdma: dma-controller@48056000 {
+ compatible = ti,omap3630-sdma, ti,omap3430-sdma;
+ reg = 0x48056000 0x1000;
+ interrupts = 12,
+13,
+14,
+15;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 96;
+ };
+
omap3_pmx_core: pinmux@48002030 {
compatible = ti,omap3-padconf, pinctrl-single;
reg = 0x48002030 0x05cc;
@@ -198,6 +210,16 @@
#size-cells = 0;
ti,hwmods = mcspi1;
ti,spi-num-cs = 4;
+ dmas = sdma 35,
+ sdma 36,
+ sdma 37,
+ sdma 38,
+ sdma 39,
+ sdma 40,
+ sdma 41,
+ sdma 42;
+ dma-names = tx0, rx0, tx1, rx1,
+ tx2, rx2, tx3, rx3;
};
mcspi2: spi@4809a000 {
@@ -206,6 +228,11 @@
#size-cells = 0;
ti,hwmods = mcspi2;
ti,spi-num-cs = 2;
+ dmas = sdma 43,
+ sdma 44,
+ sdma 45,
+ sdma 46;
+ dma-names = tx0, rx0, tx1, rx1;
};
mcspi3: spi@480b8000 {
@@ -214,6 +241,11 @@
#size-cells = 0;
ti,hwmods = mcspi3;
ti,spi-num-cs = 2;
+ dmas = sdma 15,
+ sdma 16,
+ sdma 23,
+ sdma 24;
+ dma-names = tx0, rx0, tx1, rx1;
};
mcspi4: spi@480ba000 {
@@ -222,22 +254,30 @@
#size-cells = 0;
ti,hwmods = mcspi4;
ti,spi-num-cs = 1;
+ dmas = sdma 70, sdma 71;
+ dma-names = tx0, rx0;
};
mmc1: mmc@4809c000 {
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc1;
ti,dual-volt;
+ dmas = sdma 61, sdma 62;
+ dma-names = tx, rx;
};
mmc2: mmc@480b4000 {
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc2;
+ dmas = sdma 47, sdma 48;
+ dma-names = tx, rx;
};
mmc3: mmc@480ad000 {
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
+
[PATCH V2 8/8] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM, 128MB ONENAND flash, 256MB NAND flash and uses the TWL4030
power management IC.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3430-sdp.dts | 141
2 files changed, 142 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index de29da5..a38dcd4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -115,6 +115,7 @@ dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
imx28-tx28.dtb
dtb-$(CONFIG_ARCH_NOMADIK) += ste-nomadik-s8815.dtb
dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
+ omap3430-sdp.dtb \
omap3-beagle.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
new file mode 100644
index 000..535a6f9
--- /dev/null
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -0,0 +1,141 @@
+/*
+ * Copyright (C) 2013 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.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+ model = TI OMAP3430 SDP;
+ compatible = ti,omap3430-sdp, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ };
+};
+
+/include/ twl4030.dtsi
+
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
+ bus-width = 8;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+gpmc {
+ ranges = 1 0 0x2800 0x0800,
+2 0 0x2000 0x1000;
+
+ nand@1,0 {
+ linux,mtd-name= micron,mt29f1g08abb;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 1 0 0x0800;
+ nand-bus-width = 8;
+
+ ti,nand-ecc-opt = sw;
+ gpmc,device-nand;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 36;
+ gpmc,cs-wr-off = 36;
+ gpmc,adv-on = 6;
+ gpmc,adv-rd-off = 24;
+ gpmc,adv-wr-off = 36;
+ gpmc,oe-on = 6;
+ gpmc,oe-off = 48;
+ gpmc,we-on = 6;
+ gpmc,we-off = 30;
+ gpmc,rd-cycle = 72;
+ gpmc,wr-cycle = 72;
+ gpmc,access = 54;
+ gpmc,wr-access = 30;
+
+ partition@0 {
+ label = xloader-nand;
+ reg = 0 0x8;
+ };
+ partition@0x8 {
+ label = bootloader-nand;
+ reg = 0x8 0x14;
+ };
+ partition@0x1c {
+ label = params-nand;
+ reg = 0x1c 0xc;
+ };
+ partition@0x28 {
+ label = kernel-nand;
+ reg = 0x28 0x50;
+ };
+ partition@0x78 {
+ label = filesystem-nand;
+ reg = 0x78 0x788;
+ };
+ };
+
+ onenand@2,0 {
+ linux,mtd-name= samsung,kfm2g16q2m-deb8;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 2 0 0x1000;
+
+ gpmc,device-width = 2;
+ gpmc,mux-add-data = 2;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 84;
+ gpmc,cs-wr-off = 72;
+ gpmc,adv-on = 0;
+ gpmc,adv-rd-off = 18;
+ gpmc,adv-wr-off = 18;
+ gpmc,oe-on = 30;
+ gpmc,oe-off = 84;
+ gpmc,we-on = 0;
+ gpmc,we-off = 42;
+ gpmc,rd-cycle = 108;
+ gpmc,wr-cycle = 96;
+ gpmc,access = 78;
+ gpmc,wr-data-mux-bus = 30;
+
+ partition@0 {
+ label = xloader-onenand;
+ reg = 0 0x8;
+ };
+ partition@0x8 {
+ label = bootloader-onenand;
+ reg = 0x8 0x4;
+ };
+ partition@0xc {
+ label = params-onenand;
+ reg = 0xc 0x2;
+ };
+ partition@0xe {
+ label = kernel-onenand;
+ reg = 0xe 0x20;
+ };
Re: [PATCH 6/8] ARM: dts: OMAP446x: move CPU OPP tables to device tree
On 16:49-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: OMAP4430 and 4460 have different OPP definitions. So, create an SoC variant dtsi file for 4460 and move the OPP definitions to it. FYI, I had to create a similar file for PMU [1]. However, I called it omap4460.dtsi and not omap446x.dtsi as there is only one omap446x Hmm, guess I was paranoid about marketing folks spinning off another omap446x variant out into the market. Since it is not yet done, nor known if they will ever do it, am OK with 4460 convention. device. That should go into to v3.10 and so may be worth basing this on top. I do like your omap4-panda-common.dtsi that is a nice clean-up. Thanks on the tip - Sounds good, since this series is based on DT, I will base my changes on top of for_3.10 branch. Cheers Jon [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/commit/?h=for_3.10/dtsid=5e64b6b1137a54f353528d6da60071c1ef0043ba -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 8/8] cpufreq: omap: remove omap-cpufreq
On Thu, Mar 14, 2013 at 11:51 PM, Viresh Kumar viresh.ku...@linaro.org wrote: On Fri, Mar 15, 2013 at 2:28 AM, Nishanth Menon n...@ti.com wrote: 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 Acked-by: Viresh Kumar viresh.ku...@linaro.org Thanks Viresh, but based on the direction of the discussion going on (keeping this driver active for non-DT configuration), I will have to drop this patch in it's entirety. --- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
On 03/15/2013 08:56 AM, Nishanth Menon wrote: On 16:44-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: 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. Not sure I following the last sentence. The tables are in a different dtsi file and only the relevant file should be included, right? omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx). The opp tables introduced by this patch in omap36xx.dtsi will override the ones defined on omap3.dtsi. Will the following rephrase help clarify this? Original: This overrides the default OMAP34xx CPU OPP table definition. Suggested; This overrides the default OMAP34xx CPU OPP table definition in omap3.dtsi. Sorry, I just missed that the omap3430 opps were in omap3.dtsi and not omap34xx.dtsi. I guess I am not familiar with how the DTC overrides nodes, however, at least from a readability standpoint it would seem nice to have the omap3430 opps in a omap3430 specific dtsi and not omap3.dtsi. However, thats just my opinion. Cheers Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 0/8] ARM: dts: Various OMAP2+ device-tree updates
Hi Jon, On 03/15/2013 02:57 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 Benoit's for_3.10/dts branch [1]. Branch available here [2]. V2 changes: - Rebased on Benoit's for_3.10/dts branch - Squashed patches adding support for OMAP3430 SDP board and patch to add flash support for OMAP3430 SDP board. [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts [2] git://github.com/jonhunter/linux.git omap-dt-for-v3.10 Thanks for the repost. I've just applied your branch in my for_3.10/dts branch. Regards, Benoit Jon Hunter (8): 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: Add GPMC node for OMAP2, OMAP4 and OMAP5 ARM: dts: Add OMAP2 gpio bindings ARM: dts: OMAP3+: Correct gpio #interrupts-cells property ARM: dts: OMAP3: Add reg and interrupt properties for gpio ARM: dts: OMAP3: Add support for OMAP3430 SDP board 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 +++- 11 files changed, 493 insertions(+), 23 deletions(-) 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 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
On 09:26-20130315, Jon Hunter wrote: On 03/15/2013 08:56 AM, Nishanth Menon wrote: On 16:44-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: 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. Not sure I following the last sentence. The tables are in a different dtsi file and only the relevant file should be included, right? omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx). The opp tables introduced by this patch in omap36xx.dtsi will override the ones defined on omap3.dtsi. Will the following rephrase help clarify this? Original: This overrides the default OMAP34xx CPU OPP table definition. Suggested; This overrides the default OMAP34xx CPU OPP table definition in omap3.dtsi. Sorry, I just missed that the omap3430 opps were in omap3.dtsi and not omap34xx.dtsi. I guess I am not familiar with how the DTC overrides nodes, however, at least from a readability standpoint it would seem nice to have the omap3430 opps in a omap3430 specific dtsi and not omap3.dtsi. However, thats just my opinion. most of omap3630 is based off omap3430. I know from an readability point of view, it might have been good to split that to omap3-common.dtsi, omap34xx.dtsi, omap36xx.dtsi etc.. But there is no real need at this point in time to do that. Unless, ofcourse, we'd like to set that up as an standard for all OMAP SoCs... -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: davinci: da850 evm: update clock rate for UART 1/2 DT nodes
On 3/15/2013 6:56 PM, Manjunathappa, Prakash wrote: Hi Sekhar, On Thu, Feb 28, 2013 at 16:09:47, Nori, Sekhar wrote: Prakash, On 2/19/2013 2:02 PM, Manjunathappa, Prakash wrote: DT kernel with latest of denx SPL U-boot boots with garbled UART logs. This is because in U-boot UART2 gets sourced by PLL0_SYSCLK2 configured for 150MHz. But later in kernel UART2 gets mapped to PLL1_SYSCLK2 and is configured for 132MHz not for 150MHz. PLL1 is configured for 264MHz to support mDDR on the EVM. That is memory controller driving mDDR can be configured for 150MHz and mDDR it self can operate at 132MHz. So override UART1 and UART2 DT node clock-frequency property with rate available on da850 EVM. Signed-off-by: Manjunathappa, Prakash prakash...@ti.com How about dropping the clock-frequency attribute altogether? of_serial.c seems to be falling back on clk apis if frequency is not passed and that should make the kernel work with all versions of U-Boot. Yes it can be dropped by having duplicate clock node for UART having only You meant an additional clk_lookup entry? That's different from a new 'struct clk' node. dev_id. This is required because DT kernel does the clk_get with only dev_id and non-DT kernel only with con_id. In DT kernel clk_get is done from generic code of_platform_serial_setup:of_serial.c and in non-DT kernel is done from platform code, davinci_serial_setup_clk:arch/arm/mach-davinci/serial.c Please let me know your opinion on this. When only one clock is present, con_id of NULL is more appropriate. How about fixing arch/arm/mach-davinci/serial.c and existing clk_lookup entries to use this? Thanks, Sekhar ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 03/15/2013 09:21 AM, Nishanth Menon wrote: On 10:48-20130315, Santosh Shilimkar wrote: On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote: 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. Thanks for looking into it. Yes, this should be the next stage to solve. 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. As commented by Jon on internal thread, I am also against the idea of dropping non-DT support now. Till we migrate to 100 % DT, it is best to keep support alive. Especial OMAP3 based devices. Why don't you take phased approach and have both supported for time being. Then once we move to DT only, we just drop the non-DT support as we plan to do for many more stuff. BTW, we are using only CPUFreq driver before this series as well. I guess you mean the common CPUFReq drivers used by other ARM SOCs. I had removed the entries for OPPs and clock nodes used by omap-cpufreq.c and deleted the omap-cpufreq.c as well - so the statement CPUFreq wont work in non-DT configuration was accurate. My intent was as follows: - This series is driven mainly from maintenance angle - having to maintain two different drivers (legacy omap-cpufreq.c and cpufreq-cpu0.c), ensuring the data is proper in both OPP tables in kernel and DT entries is sure to cause mayhem sometime. This is not just an pain for OMAP community, but for cpufreq community as well (since there is absolutely no reason other than OMAP legacy burden for making cpu0-cpufreq work in non-DT world). - as long as non-DT supported boot provides all features, there is no real feature incentive to move to DT. You are missing the point. Before you can migrate people over to DT, you need to be ready. IMO OMAP is still not quite ready unfortunately. But, that said, there is one path I see possible: - keep omap-cpufreq alive (BUT I will add a patch that will not let it init when in DT entries are present) - add DT entries for all relevant OMAPs - in DT mode, we will *only* support cpufreq-cpu0 - All future SoCs will continue to use cpufreq-cpu0 using DT, as was the alignment I believe. Yes that is what we are doing for other drivers and should be done here. Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
On 03/15/2013 09:38 AM, Nishanth Menon wrote: On 09:26-20130315, Jon Hunter wrote: On 03/15/2013 08:56 AM, Nishanth Menon wrote: On 16:44-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: 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. Not sure I following the last sentence. The tables are in a different dtsi file and only the relevant file should be included, right? omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx). The opp tables introduced by this patch in omap36xx.dtsi will override the ones defined on omap3.dtsi. Will the following rephrase help clarify this? Original: This overrides the default OMAP34xx CPU OPP table definition. Suggested; This overrides the default OMAP34xx CPU OPP table definition in omap3.dtsi. Sorry, I just missed that the omap3430 opps were in omap3.dtsi and not omap34xx.dtsi. I guess I am not familiar with how the DTC overrides nodes, however, at least from a readability standpoint it would seem nice to have the omap3430 opps in a omap3430 specific dtsi and not omap3.dtsi. However, thats just my opinion. most of omap3630 is based off omap3430. I know from an readability point of view, it might have been good to split that to omap3-common.dtsi, omap34xx.dtsi, omap36xx.dtsi etc.. But there is no real need at this point in time to do that. Unless, ofcourse, we'd like to set that up as an standard for all OMAP SoCs... How would omap3-common.dtsi be any different from omap3.dtsi? I don't wish us to go nuts with creating dtsi files either, but having an omap3430.dtsi does not seem unreasonable to me, but that is just my opinion. Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 09:56-20130315, Jon Hunter wrote: [..] But, that said, there is one path I see possible: - keep omap-cpufreq alive (BUT I will add a patch that will not let it init when in DT entries are present) - add DT entries for all relevant OMAPs - in DT mode, we will *only* support cpufreq-cpu0 - All future SoCs will continue to use cpufreq-cpu0 using DT, as was the alignment I believe. Yes that is what we are doing for other drivers and should be done here. OK. I guess we have not much of a choice with the legacy baggage we carry around :(. Will redo the series for the same. -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
On 09:58-20130315, Jon Hunter wrote: On 03/15/2013 09:38 AM, Nishanth Menon wrote: On 09:26-20130315, Jon Hunter wrote: On 03/15/2013 08:56 AM, Nishanth Menon wrote: On 16:44-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: 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. Not sure I following the last sentence. The tables are in a different dtsi file and only the relevant file should be included, right? omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx). The opp tables introduced by this patch in omap36xx.dtsi will override the ones defined on omap3.dtsi. Will the following rephrase help clarify this? Original: This overrides the default OMAP34xx CPU OPP table definition. Suggested; This overrides the default OMAP34xx CPU OPP table definition in omap3.dtsi. Sorry, I just missed that the omap3430 opps were in omap3.dtsi and not omap34xx.dtsi. I guess I am not familiar with how the DTC overrides nodes, however, at least from a readability standpoint it would seem nice to have the omap3430 opps in a omap3430 specific dtsi and not omap3.dtsi. However, thats just my opinion. most of omap3630 is based off omap3430. I know from an readability point of view, it might have been good to split that to omap3-common.dtsi, omap34xx.dtsi, omap36xx.dtsi etc.. But there is no real need at this point in time to do that. Unless, ofcourse, we'd like to set that up as an standard for all OMAP SoCs... How would omap3-common.dtsi be any different from omap3.dtsi? I don't wish us to go nuts with creating dtsi files either, but having an omap3430.dtsi does not seem unreasonable to me, but that is just my opinion. considering omap34xx variants, omap343x.dtsi ;). Will do in v2. -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
Hello, It took me some time to get back to this topic due to my holidays and other urgent issues. I hope that this I will be able to participate a bit more actively. On 2/14/2013 10:30 PM, Sascha Hauer wrote: Hi Marek, On Thu, Feb 14, 2013 at 01:45:26PM +0100, Marek Szyprowski wrote: Hello, Here is my initial proposal for device tree integration for Contiguous Memory Allocator. The code is quite straightforward, however I expect that the memory bindings require some discussion. The proposed bindings allows to define contiguous memory regions of specified base address and size. Then, the defined regions can be assigned to the given device(s) by adding a property with a phanle to the defined contiguous memory region. From the device tree perspective that's all. Once the bindings are added, all the memory allocations from dma-mapping subsystem will be served from the defined contiguous memory regions. I think CMA regions should not be described in the devicetre at all. The devicetree is about hardware description and it should be OS agnostic, but CMA is only a Linux specific implementation detail. It's not even specific to a particular board, it's specific to a particular usecase of a board. Well, I see your point. The main problem is the fact that board files consisted of both hw related definitions AND particular kernel configuration for the device drivers (like the dma_declare_contiguous() calls for example). Now hw related definitions are being moved to device tree, but what should we do with the kernel configuration data, which was previously in the board files? I know that in the ideal scenario there should be no such data at all and all drivers should be able to automatically configure all related parameters or give userspace a method for changing them in runtime. The real world is not ideal however. There is a set of kernel configuration data/parameters which can be set only once, usually early in the boot process. How should we handle it? There is kernel command line parameter (surprisingly stored also in device tree, which should not have such data...), but it intended mainly for debug/development purposes and simple, usually one value parameters. There have been discussion about CMA configuration via kernel cmd line long time ago (in early CMA development days), but such attempt has been rejected, because it introduced too complicated kernel parameters, see http://thread.gmane.org/gmane.linux.kernel.mm/50669/focus=50679 So we need another solution. I'm aware of the idea that DT should be limited to hw description. This principle is good and it might let us to find some better, more generic approach. However, we already have some of Linux kernel specific attributes (git grep 'linux,' -- Documentation/devicetree | wc -l gives 71, most of them are in keypad and buttons drivers). Are there any KNOWN use cases for using exiting DTS from Linux kernel with other operating systems? I believe that 99% of the DTS files will be both developed and used only together with Linux kernel. I'm also seeing the DT as a generic way of describing different variants of the same hardware (what is quite common in the development process) and a method for standardizing the hw description to ease the developers (for a good example please just compare some old OMAP and Exynos board files - each used completely different way of describing the same things). The CMA DT patches are quite short and lets anyone to put the required kernel configuration together with the respective HW definitions in a very convenient way. Especially referencing regions and device entries by phandle pointers allows us to avoid any text-based config entries and in-kernel parsers for them. If the presented approach is definitely prohibited then what way should we go? As an alternative I'm thinking about extending 'chosen' node for such cases. Embedding the CMA configuration data into a few sub-nodes and attributes there should not be a problem. It would also keep all the config related entries in a single place. The another advantage I see is the possibility to update 'chosen' node from the extended dt-aware bootloaders, which might also let one to edit them. What's your opinion? Best regards -- Marek Szyprowski Samsung Poland RD Center ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 00/23] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Tony, These patches provide the SoC side code required to support the changes in the OMAP USB Host drivers done in [1], [2] [3]. Device tree support is added for Beagleboard and Panda. NOTE: The first patch needs to be shared between the OMAP tree and Felipe's USB tree. v2: - Added helper function usbhs_init_phys() that can be used by board files to simplify adding of PHY regulators for USB host ports. [1] MFD side changes to omap-usb-host and omap-usb-tll https://lkml.org/lkml/2013/3/12/179 [2] USB EHCI side changes to ehci-omap http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86265.html [3] USB PHY driver changes http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86293.html The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://github.com/rogerq/linux.git usbhost-arm-next Roger Quadros (23): usb: phy: nop: Add some parameters to platform data ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys() ARM: OMAP2+: omap4panda: Provide USB Host's PHY platform data ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes ARM: OMAP3: Beagle: Adapt to ehci-omap changes ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes ARM: OMAP: AM3517crane: Adapt to ehci-omap changes ARM: OMAP: AM3517evm: Adapt to ehci-omap changes ARM: OMAP3: cm-t35: Adapt to ehci-omap changes ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes ARM: OMAP: devkit8000: Adapt to ehci-omap changes ARM: OMAP3: igep0020: Adapt to ehci-omap changes ARM: OMAP3: omap3evm: Adapt to ehci-omap changes ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes ARM: OMAP3: overo: Adapt to ehci-omap changes ARM: OMAP: zoom: Adapt to ehci-omap changes ARM: dts: OMAP4: Add HS USB Host IP nodes ARM: dts: omap4-panda: Add USB Host support ARM: dts: OMAP3: Add HS USB Host IP nodes ARM: dts: omap3-beagle: Add USB Host support arch/arm/boot/dts/omap3-beagle.dts | 71 ++ arch/arm/boot/dts/omap3.dtsi | 31 ++ arch/arm/boot/dts/omap4-panda.dts | 56 +++ arch/arm/boot/dts/omap4.dtsi | 30 ++ arch/arm/mach-omap2/board-3430sdp.c| 47 - arch/arm/mach-omap2/board-3630sdp.c| 48 +- arch/arm/mach-omap2/board-am3517crane.c| 38 +--- arch/arm/mach-omap2/board-am3517evm.c | 41 +++- arch/arm/mach-omap2/board-cm-t35.c | 45 - arch/arm/mach-omap2/board-cm-t3517.c | 45 - arch/arm/mach-omap2/board-devkit8000.c | 20 +++-- arch/arm/mach-omap2/board-igep0020.c | 66 +++--- arch/arm/mach-omap2/board-omap3beagle.c| 44 +++-- arch/arm/mach-omap2/board-omap3evm.c | 41 ++--- arch/arm/mach-omap2/board-omap3pandora.c | 31 +-- arch/arm/mach-omap2/board-omap3stalker.c | 29 +-- arch/arm/mach-omap2/board-omap3touchbook.c | 38 ++-- arch/arm/mach-omap2/board-omap4panda.c | 67 +++--- arch/arm/mach-omap2/board-overo.c | 32 +- arch/arm/mach-omap2/board-zoom.c | 32 +- arch/arm/mach-omap2/usb-host.c | 138 +++- arch/arm/mach-omap2/usb.h |9 ++ include/linux/usb/nop-usb-xceiv.h |5 + 23 files changed, 849 insertions(+), 155 deletions(-) -- 1.7.4.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 01/23] usb: phy: nop: Add some parameters to platform data
Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that rate during probe.
Also add 2 flags, needs_vcc and needs_reset.
If the flag is set and the regulator couldn't be found
then the driver will bail out with -EPROBE_DEFER.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
include/linux/usb/nop-usb-xceiv.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/nop-usb-xceiv.h
b/include/linux/usb/nop-usb-xceiv.h
index 28884c7..148d351 100644
--- a/include/linux/usb/nop-usb-xceiv.h
+++ b/include/linux/usb/nop-usb-xceiv.h
@@ -5,6 +5,11 @@
struct nop_usb_xceiv_platform_data {
enum usb_phy_type type;
+ unsigned long clk_rate;
+
+ /* if set fails with -EPROBE_DEFER if can't get regulator */
+ unsigned int needs_vcc:1;
+ unsigned int needs_reset:1;
};
#if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE)
defined(MODULE))
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 02/23] ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys()
This helper allows board support code to add the PHY's
VCC and RESET regulators which are GPIO controlled.
It also links the vcc and reset supplies to the
PHY's device ID that is supplied in the struct usbhs_phy_data
argument.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 138 +++-
arch/arm/mach-omap2/usb.h |9 +++
2 files changed, 145 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 5706bdc..e788fe5 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -22,8 +22,11 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/dma-mapping.h
-
-#include asm/io.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
+#include linux/string.h
+#include linux/io.h
+#include linux/gpio.h
#include soc.h
#include omap_device.h
@@ -526,3 +529,134 @@ void __init usbhs_init(struct usbhs_omap_platform_data
*pdata)
}
#endif
+
+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 usbhs_init_phys(struct usbhs_phy_data *phy, int num_phys)
+{
+ struct regulator_consumer_supply *supplies;
+ struct regulator_init_data *reg_data;
+ struct fixed_voltage_config *config;
+ char *supply_name;
+ int i;
+
+ for (i = 0; i num_phys; i++) {
+
+ if (!phy-phy_id || !phy-port) {
+ pr_info(%s: Invalid phy_id or port\n, __func__);
+ continue;
+ }
+
+ 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, phy-port);
+ 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 = kmemdup(hsusb_reg_config, sizeof(hsusb_reg_config),
+ GFP_KERNEL);
+ if
[PATCH v2 03/23] ARM: OMAP2+: omap4panda: Provide USB Host's PHY platform data
Add platform device and data for 'nop-usb-xceiv'. This will be used
as PHY for HS USB port 1, so provide binding information for it.
Get rid of managing the PHY clock as it will be done by the PHY driver.
For that to work we create a clock alias that links the PHY clock name
to the PHY device name.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 34 ++-
1 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b02c2f0..feffde6 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -31,6 +31,7 @@
#include linux/ti_wilink_st.h
#include linux/usb/musb.h
#include linux/usb/phy.h
+#include linux/usb/nop-usb-xceiv.h
#include linux/wl12xx.h
#include linux/irqchip/arm-gic.h
#include linux/platform_data/omap-abe-twl6040.h
@@ -132,12 +133,27 @@ static struct platform_device btwilink_device = {
.id = -1,
};
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct nop_usb_xceiv_platform_data hsusb1_phy_data = {
+ /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
+ .clk_rate = 1920,
+};
+
+static struct platform_device hsusb1_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 1,
+ .dev= {
+ .platform_data = hsusb1_phy_data,
+ },
+};
+
static struct platform_device *panda_devices[] __initdata = {
leds_gpio,
wl1271_device,
panda_abe_audio,
panda_hdmi_audio_codec,
btwilink_device,
+ hsusb1_phy_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
@@ -158,16 +174,6 @@ static struct gpio panda_ehci_gpios[] __initdata = {
static void __init omap4_ehci_init(void)
{
int ret;
- struct clk *phy_ref_clk;
-
- /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
- phy_ref_clk = clk_get(NULL, auxclk3_ck);
- if (IS_ERR(phy_ref_clk)) {
- pr_err(Cannot request auxclk3\n);
- return;
- }
- clk_set_rate(phy_ref_clk, 1920);
- clk_prepare_enable(phy_ref_clk);
/* disable the power to the usb hub prior to init and reset phy+hub */
ret = gpio_request_array(panda_ehci_gpios,
@@ -181,6 +187,14 @@ static void __init omap4_ehci_init(void)
gpio_export(GPIO_HUB_NRESET, 0);
gpio_set_value(GPIO_HUB_NRESET, 1);
+ /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
+ ret = clk_add_alias(main_clk, nop_usb_xceiv.1, auxclk3_ck, NULL);
+ if (ret)
+ pr_err(Failed to add main_clk alias to auxclk3_ck\n);
+
+ /* PHY on HS USB Port 1 i.e. index 0 */
+ usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+
usbhs_init(usbhs_bdata);
/* enable power to hub */
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 04/23] ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators.
The VCC and RESET will then be managed by the PHY driver.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 37 +--
1 files changed, 11 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index feffde6..1c22880 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -147,6 +147,16 @@ static struct platform_device hsusb1_phy_device = {
},
};
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = GPIO_HUB_NRESET,
+ .vcc_gpio = GPIO_HUB_POWER,
+ .vcc_polarity = 1,
+ .phy_id = nop_usb_xceiv.1,
+ },
+};
+
static struct platform_device *panda_devices[] __initdata = {
leds_gpio,
wl1271_device,
@@ -158,35 +168,12 @@ static struct platform_device *panda_devices[] __initdata
= {
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = false,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL
-};
-
-static struct gpio panda_ehci_gpios[] __initdata = {
- { GPIO_HUB_POWER, GPIOF_OUT_INIT_LOW, hub_power },
- { GPIO_HUB_NRESET, GPIOF_OUT_INIT_LOW, hub_nreset },
};
static void __init omap4_ehci_init(void)
{
int ret;
- /* disable the power to the usb hub prior to init and reset phy+hub */
- ret = gpio_request_array(panda_ehci_gpios,
-ARRAY_SIZE(panda_ehci_gpios));
- if (ret) {
- pr_err(Unable to initialize EHCI power/reset\n);
- return;
- }
-
- gpio_export(GPIO_HUB_POWER, 0);
- gpio_export(GPIO_HUB_NRESET, 0);
- gpio_set_value(GPIO_HUB_NRESET, 1);
-
/* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
ret = clk_add_alias(main_clk, nop_usb_xceiv.1, auxclk3_ck, NULL);
if (ret)
@@ -195,10 +182,8 @@ static void __init omap4_ehci_init(void)
/* PHY on HS USB Port 1 i.e. index 0 */
usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
-
- /* enable power to hub */
- gpio_set_value(GPIO_HUB_POWER, 1);
}
static struct omap_musb_board_data musb_board_data = {
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 05/23] ARM: OMAP3: Beagle: Adapt to ehci-omap changes
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 44 ---
1 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index c3558f9..566c434 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -33,6 +33,7 @@
#include linux/mtd/nand.h
#include linux/mmc/host.h
#include linux/usb/phy.h
+#include linux/usb/nop-usb-xceiv.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
@@ -277,6 +278,30 @@ static struct regulator_consumer_supply
beagle_vsim_supply[] = {
static struct gpio_led gpio_leds[];
+/* PHY's VCC regulator might be added later, so flag that we need it */
+static struct nop_usb_xceiv_platform_data hsusb2_phy_data = {
+ .needs_vcc = true,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+ .dev = {
+ .platform_data = hsusb2_phy_data,
+ },
+};
+
+static struct usbhs_phy_data phy_data[] = {
+ {
+ .port = 2,
+ .reset_gpio = 147,
+ .vcc_gpio = -1, /* updated in beagle_twl_gpio_setup */
+ .vcc_polarity = 1, /* updated in beagle_twl_gpio_setup */
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -318,9 +343,11 @@ static int beagle_twl_gpio_setup(struct device *dev,
}
dvi_panel.power_down_gpio = beagle_config.dvi_pd_gpio;
- gpio_request_one(gpio + TWL4030_GPIO_MAX, beagle_config.usb_pwr_level,
- nEN_USB_PWR);
+ /* TWL4030_GPIO_MAX i.e. LED_GPO controls HS USB Port 2 power */
+ phy_data[0].vcc_gpio = gpio + TWL4030_GPIO_MAX;
+ phy_data[0].vcc_polarity = beagle_config.usb_pwr_level;
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
return 0;
}
@@ -450,18 +477,11 @@ static struct platform_device *omap3_beagle_devices[]
__initdata = {
keys_gpio,
madc_hwmon,
leds_pwm,
+ hsusb2_phy_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 147,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -543,7 +563,11 @@ static void __init omap3_beagle_init(void)
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
+
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
usbhs_init(usbhs_bdata);
+
board_nand_init(omap3beagle_nand_partitions,
ARRAY_SIZE(omap3beagle_nand_partitions), NAND_CS,
NAND_BUSWIDTH_16, NULL);
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 06/23] ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 47 ++
1 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ce812de..5584682 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -21,6 +21,7 @@
#include linux/spi/spi.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/usb/phy.h
#include linux/io.h
#include linux/gpio.h
#include linux/mmc/host.h
@@ -445,16 +446,37 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = 57,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.1,
+ },
+ {
+ .port = 2,
+ .reset_gpio = 61,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = 57,
- .reset_gpio_port[1] = 61,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -585,6 +607,11 @@ static struct flash_partitions sdp_flash_partitions[] = {
},
};
+static struct platform_device *sdp3430_devices[] __initdata = {
+ hsusb1_phy_device,
+ hsusb2_phy_device,
+};
+
static void __init omap_3430sdp_init(void)
{
int gpio_pendown;
@@ -606,6 +633,14 @@ static void __init omap_3430sdp_init(void)
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
enable_board_wakeup_source();
+
+ platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
+ /* PHY on HSUSB Port 1 i.e. index 0 */
+ usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
}
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 07/23] ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-3630sdp.c | 48 ++
1 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 67447bd..4c205e3 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -12,6 +12,7 @@
#include linux/input.h
#include linux/gpio.h
#include linux/mtd/nand.h
+#include linux/usb/phy.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -53,16 +54,37 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = 126,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.1,
+ },
+ {
+ .port = 2,
+ .reset_gpio = 61,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = 126,
- .reset_gpio_port[1] = 61,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -189,6 +211,11 @@ static struct flash_partitions sdp_flash_partitions[] = {
},
};
+static struct platform_device *sdp3630_devices[] __initdata = {
+ hsusb1_phy_device,
+ hsusb2_phy_device,
+};
+
static void __init omap_sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
@@ -199,6 +226,15 @@ static void __init omap_sdp_init(void)
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
enable_board_wakeup_source();
+
+ platform_add_devices(sdp3630_devices, ARRAY_SIZE(sdp3630_devices));
+
+ /* PHY on HSUSB Port 1 i.e. index 0 */
+ usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
}
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 08/23] ARM: OMAP: AM3517crane: Adapt to ehci-omap changes
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 1, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-am3517crane.c | 38 +-
1 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 7d3358b..f6ec36a 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -24,6 +24,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
+#include linux/usb/phy.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -47,15 +48,28 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 1,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = GPIO_HUB_NRESET,
+ .vcc_gpio = GPIO_HUB_POWER,
+ .vcc_polarity = 1,
+ .phy_id = nop_usb_xceiv.1,
+ },
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
+};
- .phy_reset = true,
- .reset_gpio_port[0] = GPIO_USB_NRESET,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL
+static struct platform_device *am3517_crane_devices[] __initdata = {
+ hsusb1_phy_device,
};
static struct mtd_partition crane_nand_partitions[] = {
@@ -131,13 +145,13 @@ static void __init am3517_crane_init(void)
return;
}
- ret = gpio_request_one(GPIO_USB_POWER, GPIOF_OUT_INIT_HIGH,
- usb_ehci_enable);
- if (ret 0) {
- pr_err(Can not request GPIO %d\n, GPIO_USB_POWER);
- return;
- }
+ platform_add_devices(am3517_crane_devices,
+ ARRAY_SIZE(am3517_crane_devices));
+
+ /* PHY on HSUSB Port 1 i.e. index 0 */
+ usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
am35xx_emac_init(AM35XX_DEFAULT_MDIO_FREQUENCY, 1);
}
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 09/23] ARM: OMAP: AM3517evm: Adapt to ehci-omap changes
Add 2 platform devices for 'nop-usb-xceiv'. These will be used as a
PHY for HS USB Port 1 and 2, so provide binding information for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 41 -
1 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 9fb8590..4e1283d 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -25,6 +25,7 @@
#include linux/can/platform/ti_hecc.h
#include linux/davinci_emac.h
#include linux/mmc/host.h
+#include linux/usb/phy.h
#include linux/usb/musb.h
#include linux/platform_data/gpio-omap.h
@@ -274,6 +275,27 @@ static __init void am3517_evm_mcbsp1_init(void)
omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0);
}
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = 57,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.1,
+ },
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
@@ -282,12 +304,6 @@ static struct usbhs_omap_platform_data usbhs_bdata
__initdata = {
#else
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
#endif
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = 57,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -349,6 +365,10 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
+static struct platform_device *am3517evm_devices[] __initdata = {
+ hsusb1_phy_device,
+ hsusb2_phy_device,
+};
static void __init am3517_evm_init(void)
{
@@ -361,6 +381,15 @@ static void __init am3517_evm_init(void)
/* Configure GPIO for EHCI port */
omap_mux_init_gpio(57, OMAP_PIN_OUTPUT);
+
+ platform_add_devices(am3517evm_devices, ARRAY_SIZE(am3517evm_devices));
+
+ /* PHY on HSUSB Port 1 i.e. index 0 */
+ usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
am3517_evm_hecc_init(am3517_evm_hecc_pdata);
/* DSS */
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 10/23] ARM: OMAP3: cm-t35: Adapt to ehci-omap changes
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 45
1 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index af2bb21..50a6517 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -29,6 +29,7 @@
#include linux/i2c/twl.h
#include linux/regulator/fixed.h
#include linux/regulator/machine.h
+#include linux/usb/phy.h
#include linux/mmc/host.h
#include linux/usb/phy.h
@@ -419,15 +420,41 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = OMAP_MAX_GPIO_LINES + 6,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.1,
+ },
+ {
+ .port = 2,
+ .reset_gpio = OMAP_MAX_GPIO_LINES + 7,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
+};
- .phy_reset = true,
- .reset_gpio_port[0] = OMAP_MAX_GPIO_LINES + 6,
- .reset_gpio_port[1] = OMAP_MAX_GPIO_LINES + 7,
- .reset_gpio_port[2] = -EINVAL
+static struct platform_device *usbhs_devices[] = {
+ hsusb1_phy_device,
+ hsusb2_phy_device,
};
static void __init cm_t35_init_usbh(void)
@@ -444,6 +471,14 @@ static void __init cm_t35_init_usbh(void)
msleep(1);
}
+ platform_add_devices(usbhs_devices, ARRAY_SIZE(usbhs_devices));
+
+ /* PHY on HSUSB Port 1 i.e. index 0 */
+ usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
}
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 11/23] ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-cm-t3517.c | 45 ++
1 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index a66da80..5e64be1 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -34,6 +34,7 @@
#include linux/mtd/partitions.h
#include linux/mmc/host.h
#include linux/can/platform/ti_hecc.h
+#include linux/usb/phy.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -188,15 +189,41 @@ static inline void cm_t3517_init_rtc(void) {}
#define HSUSB2_RESET_GPIO (147)
#define USB_HUB_RESET_GPIO (152)
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = HSUSB1_RESET_GPIO,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.1,
+ },
+ {
+ .port = 2,
+ .reset_gpio = HSUSB2_RESET_GPIO,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
static struct usbhs_omap_platform_data cm_t3517_ehci_pdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
+};
- .phy_reset = true,
- .reset_gpio_port[0] = HSUSB1_RESET_GPIO,
- .reset_gpio_port[1] = HSUSB2_RESET_GPIO,
- .reset_gpio_port[2] = -EINVAL,
+static struct platform_device *usbhs_devices[] = {
+ hsusb1_phy_device,
+ hsusb2_phy_device,
};
static int __init cm_t3517_init_usbh(void)
@@ -213,6 +240,14 @@ static int __init cm_t3517_init_usbh(void)
msleep(1);
}
+ platform_add_devices(usbhs_devices, ARRAY_SIZE(usbhs_devices));
+
+ /* PHY on HSUSB Port 1 i.e. index 0 */
+ usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(cm_t3517_ehci_pdata);
return 0;
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 12/23] ARM: OMAP: devkit8000: Adapt to ehci-omap changes
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 1, so provide binding information for it.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-devkit8000.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 53056c3..922ca91 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -33,6 +33,7 @@
#include linux/regulator/machine.h
#include linux/i2c/twl.h
+#include linux/usb/phy.h
#include id.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -430,22 +431,21 @@ static void __init omap_dm9000_init(void)
eth_addr[5] = (odi.id_0 0x00ff);
}
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 1,
+};
+
static struct platform_device *devkit8000_devices[] __initdata = {
leds_gpio,
keys_gpio,
omap_dm9000_dev,
+ hsusb1_phy_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -625,6 +625,10 @@ static void __init devkit8000_init(void)
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
+
+ /* PHY on HSUSB Port 1 i.e. index 0 */
+ usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+
usbhs_init(usbhs_bdata);
board_nand_init(devkit8000_nand_partitions,
ARRAY_SIZE(devkit8000_nand_partitions), NAND_CS,
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 13/23] ARM: OMAP3: igep0020: Adapt to ehci-omap changes
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-igep0020.c | 66 ++---
1 files changed, 52 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index bf92678..8b0b2fb 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -22,6 +22,7 @@
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
+#include linux/usb/phy.h
#include linux/i2c/twl.h
#include linux/mmc/host.h
@@ -527,26 +528,50 @@ static void __init igep_i2c_init(void)
omap3_pmic_init(twl4030, igep_twldata);
}
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data igep2_phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = IGEP2_GPIO_USBH_NRESET,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.1,
+ },
+};
+
+static struct usbhs_phy_data igep3_phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = IGEP3_GPIO_USBH_NRESET,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
+static struct platform_device *igep2_devices[] __initdata = {
+ hsusb1_phy_device,
+};
+
+static struct platform_device *igep3_devices[] __initdata = {
+ hsusb2_phy_device,
+};
+
static struct usbhs_omap_platform_data igep2_usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = IGEP2_GPIO_USBH_NRESET,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL,
};
static struct usbhs_omap_platform_data igep3_usbhs_bdata __initdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = IGEP3_GPIO_USBH_NRESET,
- .reset_gpio_port[2] = -EINVAL,
};
#ifdef CONFIG_OMAP_MUX
@@ -642,8 +667,21 @@ static void __init igep_init(void)
if (machine_is_igep0020()) {
omap_display_init(igep2_dss_data);
igep2_init_smsc911x();
+
+ platform_add_devices(igep2_devices, ARRAY_SIZE(igep2_devices));
+
+ /* PHY on HSUSB Port 1 i.e. index 0 */
+ usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+
+ usbhs_init_phys(igep2_phy_data, ARRAY_SIZE(igep2_phy_data));
usbhs_init(igep2_usbhs_bdata);
} else {
+ platform_add_devices(igep3_devices, ARRAY_SIZE(igep3_devices));
+
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(igep3_phy_data, ARRAY_SIZE(igep3_phy_data));
usbhs_init(igep3_usbhs_bdata);
}
}
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 14/23] ARM: OMAP3: omap3evm: Adapt to ehci-omap changes
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's RESET regulator.
VAUX2 supplies the PHY's VCC.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 41 --
1 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 48789e0..aaa01ae 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -34,6 +34,7 @@
#include linux/usb/otg.h
#include linux/usb/musb.h
#include linux/usb/nop-usb-xceiv.h
+#include linux/usb/phy.h
#include linux/smsc911x.h
#include linux/wl12xx.h
@@ -496,7 +497,7 @@ struct wl12xx_platform_data omap3evm_wlan_data __initdata =
{
static struct regulator_consumer_supply omap3evm_vaux2_supplies[] = {
REGULATOR_SUPPLY(VDD_CSIPHY1, omap3isp),/* OMAP ISP */
REGULATOR_SUPPLY(VDD_CSIPHY2, omap3isp),/* OMAP ISP */
- REGULATOR_SUPPLY(hsusb1, ehci-omap.0),
+ REGULATOR_SUPPLY(vcc, nop_usb_xceiv.2), /* hsusb port 2 */
REGULATOR_SUPPLY(vaux2, NULL),
};
@@ -539,17 +540,27 @@ static int __init omap3_evm_i2c_init(void)
return 0;
}
-static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
- .port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = -1, /* set at runtime */
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
- .phy_reset = true,
- /* PHY reset GPIO will be runtime programmed based on EVM version */
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL
+static struct platform_device *omap3evm_devices[] __initdata = {
+ hsusb2_phy_device,
+};
+
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
+ .port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
};
#ifdef CONFIG_OMAP_MUX
@@ -725,7 +736,7 @@ static void __init omap3_evm_init(void)
/* setup EHCI phy reset config */
omap_mux_init_gpio(21, OMAP_PIN_INPUT_PULLUP);
- usbhs_bdata.reset_gpio_port[1] = 21;
+ phy_data[0].reset_gpio = 21;
/* EVM REV = E can supply 500mA with EXTVBUS programming */
musb_board_data.power = 500;
@@ -733,10 +744,16 @@ static void __init omap3_evm_init(void)
} else {
/* setup EHCI phy reset on MDC */
omap_mux_init_gpio(135, OMAP_PIN_OUTPUT);
- usbhs_bdata.reset_gpio_port[1] = 135;
+ phy_data[0].reset_gpio = 135;
}
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(musb_board_data);
+
+ platform_add_devices(omap3evm_devices, ARRAY_SIZE(omap3evm_devices));
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
board_nand_init(omap3evm_nand_partitions,
ARRAY_SIZE(omap3evm_nand_partitions), NAND_CS,
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 15/23] ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's RESET regulator.
VAUX2 supplies the PHY's VCC.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3pandora.c | 31 +
1 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 2bba362..82a4fe3 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -23,6 +23,7 @@
#include linux/spi/spi.h
#include linux/regulator/machine.h
+#include linux/usb/phy.h
#include linux/i2c/twl.h
#include linux/wl12xx.h
#include linux/mtd/partitions.h
@@ -346,7 +347,7 @@ static struct regulator_consumer_supply
pandora_vcc_lcd_supply[] = {
};
static struct regulator_consumer_supply pandora_usb_phy_supply[] = {
- REGULATOR_SUPPLY(hsusb1, ehci-omap.0),
+ REGULATOR_SUPPLY(vcc, nop_usb_xceiv.2), /* hsusb port 2 */
};
/* ads7846 on SPI and 2 nub controllers on I2C */
@@ -561,23 +562,31 @@ fail:
printk(KERN_ERR wl1251 board initialisation failed\n);
}
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = 16,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
static struct platform_device *omap3pandora_devices[] __initdata = {
pandora_leds_gpio,
pandora_keys_gpio,
pandora_vwlan_device,
pandora_backlight,
+ hsusb2_phy_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 16,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -601,7 +610,11 @@ static void __init omap3pandora_init(void)
spi_register_board_info(omap3pandora_spi_board_info,
ARRAY_SIZE(omap3pandora_spi_board_info));
omap_ads7846_init(1, OMAP3_PANDORA_TS_GPIO, 0, NULL);
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
+
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
gpmc_nand_init(pandora_nand_data, NULL);
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 16/23] ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3stalker.c | 29 ++---
1 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 95c10b3..bf6a108 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -26,6 +26,7 @@
#include linux/regulator/fixed.h
#include linux/regulator/machine.h
+#include linux/usb/phy.h
#include linux/i2c/twl.h
#include linux/mmc/host.h
#include linux/input/matrix_keypad.h
@@ -358,19 +359,28 @@ static int __init omap3_stalker_i2c_init(void)
#define OMAP3_STALKER_TS_GPIO 175
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = 21,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
static struct platform_device *omap3_stalker_devices[] __initdata = {
keys_gpio,
+ hsusb2_phy_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 21,
- .reset_gpio_port[2] = -EINVAL,
};
#ifdef CONFIG_OMAP_MUX
@@ -407,6 +417,11 @@ static void __init omap3_stalker_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
+
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
omap_ads7846_init(1, OMAP3_STALKER_TS_GPIO, 310, NULL);
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 17/23] ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes
Add 2 platform devices for 'nop-usb-xceiv'. These will be used as a
PHY for HS USB Ports 1 and 2, so provide binding information for them.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3touchbook.c | 38 ++-
1 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index bcd44fb..e8fa884 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -36,6 +36,7 @@
#include linux/spi/ads7846.h
#include linux/regulator/machine.h
+#include linux/usb/phy.h
#include linux/i2c/twl.h
#include asm/mach-types.h
@@ -305,21 +306,37 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = 147,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
static struct platform_device *omap3_touchbook_devices[] __initdata = {
leds_gpio,
keys_gpio,
+ hsusb1_phy_device,
+ hsusb2_phy_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 147,
- .reset_gpio_port[2] = -EINVAL
};
static void omap3_touchbook_poweroff(void)
@@ -368,6 +385,13 @@ static void __init omap3_touchbook_init(void)
omap_ads7846_init(4, OMAP3_TS_GPIO, 310, ads7846_pdata);
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
+
+ /* PHY on HSUSB Port 1 i.e. index 0 */
+ usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
board_nand_init(omap3touchbook_nand_partitions,
ARRAY_SIZE(omap3touchbook_nand_partitions), NAND_CS,
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 18/23] ARM: OMAP3: overo: Adapt to ehci-omap changes
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-overo.c | 32 ++--
1 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 86bab51..024cc25 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -31,6 +31,7 @@
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
#include linux/spi/spi.h
+#include linux/usb/phy.h
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
@@ -458,14 +459,27 @@ static int __init overo_spi_init(void)
return 0;
}
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = OVERO_GPIO_USBH_NRESET,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
+static struct platform_device *overo_devices[] __initdata = {
+ hsusb2_phy_device,
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = OVERO_GPIO_USBH_NRESET,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -502,6 +516,12 @@ static void __init overo_init(void)
ARRAY_SIZE(overo_nand_partitions), NAND_CS, 0, NULL);
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
+
+ platform_add_devices(overo_devices, ARRAY_SIZE(overo_devices));
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
overo_spi_init();
overo_init_smsc911x();
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 19/23] ARM: OMAP: zoom: Adapt to ehci-omap changes
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-zoom.c | 32 ++--
1 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom.c b/arch/arm/mach-omap2/board-zoom.c
index 5e4d4c9..220e07c 100644
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@ -17,6 +17,7 @@
#include linux/gpio.h
#include linux/i2c/twl.h
#include linux/mtd/nand.h
+#include linux/usb/phy.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -92,14 +93,27 @@ static struct mtd_partition zoom_nand_partitions[] = {
},
};
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = ZOOM3_EHCI_RESET_GPIO,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
+static struct platform_device *zoom3_devices[] __initdata = {
+ hsusb2_phy_device,
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = ZOOM3_EHCI_RESET_GPIO,
- .reset_gpio_port[2] = -EINVAL,
};
static void __init omap_zoom_init(void)
@@ -109,6 +123,12 @@ static void __init omap_zoom_init(void)
} else if (machine_is_omap_zoom3()) {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
omap_mux_init_gpio(ZOOM3_EHCI_RESET_GPIO, OMAP_PIN_OUTPUT);
+
+ platform_add_devices(zoom3_devices, ARRAY_SIZE(zoom3_devices));
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
}
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 20/23] ARM: dts: OMAP4: Add HS USB Host IP nodes
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..b7db1a2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,35 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+ usbhstll: usbhstll@4a062000 {
+ compatible = ti,usbhs-tll;
+ reg = 0x4a062000 0x1000;
+ interrupts = 0 78 0x4;
+ ti,hwmods = usb_tll_hs;
+ };
+
+ usbhshost: usbhshost@4a064000 {
+ compatible = ti,usbhs-host;
+ reg = 0x4a064000 0x800;
+ ti,hwmods = usb_host_hs;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbhsohci: ohci@4a064800 {
+ compatible = ti,ohci-omap3, usb-ohci;
+ reg = 0x4a064800 0x400;
+ interrupt-parent = gic;
+ interrupts = 0 76 0x4;
+ };
+
+ usbhsehci: ehci@4a064c00 {
+ compatible = ti,ehci-omap, usb-ehci;
+ reg = 0x4a064c00 0x400;
+ interrupt-parent = gic;
+ interrupts = 0 77 0x4;
+ };
+ };
};
};
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 21/23] ARM: dts: omap4-panda: Add USB Host support
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 56 +
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..cfc7683 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -57,6 +57,36 @@
AFML, Line In,
AFMR, Line In;
};
+
+ /* HS USB Port 1 RESET */
+ hsusb1_reset: hsusb1_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio2 30 0; /* gpio_62 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 1 Power */
+ hsusb1_power: hsusb1_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio1 1 0;/* gpio_1 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 1 */
+ hsusb1_phy: hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb1_reset;
+ vcc-supply = hsusb1_power;
+ clock-frequency = 1920;
+ };
};
omap4_pmx_core {
@@ -67,6 +97,7 @@
mcbsp1_pins
dss_hdmi_pins
tpd12s015_pins
+ hsusbb1_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -110,6 +141,23 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
;
};
+
+ hsusbb1_pins: pinmux_hsusbb1_pins {
+ pinctrl-single,pins =
+ 0x82 0x10C /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */
+ 0x84 0x4/*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x86 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x88 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x8a 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x8c 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x8e 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x90 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x92 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x94 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x96 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x98 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ ;
+ };
};
i2c1 {
@@ -206,3 +254,11 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+usbhshost {
+ port1-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = hsusb1_phy;
+};
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 22/23] ARM: dts: OMAP3: Add HS USB Host IP nodes
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..a14f74b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,36 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ usbhstll: usbhstll@48062000 {
+ compatible = ti,usbhs-tll;
+ reg = 0x48062000 0x1000;
+ interrupts = 78;
+ ti,hwmods = usb_tll_hs;
+ };
+
+ usbhshost: usbhshost@48064000 {
+ compatible = ti,usbhs-host;
+ reg = 0x48064000 0x400;
+ ti,hwmods = usb_host_hs;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbhsohci: ohci@48064400 {
+ compatible = ti,ohci-omap3, usb-ohci;
+ reg = 0x48064400 0x400;
+ interrupt-parent = intc;
+ interrupts = 76;
+ };
+
+ usbhsehci: ehci@48064800 {
+ compatible = ti,ehci-omap, usb-ehci;
+ reg = 0x48064800 0x400;
+ interrupt-parent = intc;
+ interrupts = 77;
+ };
+ };
+
};
};
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 23/23] ARM: dts: omap3-beagle: Add USB Host support
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 71
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..02d23f1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -38,6 +38,57 @@
};
};
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio5 19 0; /* gpio_147 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = twl_gpio 18 0;/* GPIO LEDA */
+ startup-delay-us = 7;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb2_reset;
+ vcc-supply = hsusb2_power;
+ };
+};
+
+omap3_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusbb2_pins
+ ;
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins =
+ 0x5c0 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+ 0x5c2 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x5c4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x5c6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x5c8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x5cA 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x1a4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x1a6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x1a8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x1aa 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x1ac 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x1ae 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ ;
+ };
};
i2c1 {
@@ -65,3 +116,23 @@
mmc3 {
status = disabled;
};
+
+usbhshost {
+ port2-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy;
+};
+
+twl_gpio {
+ ti,use-leds;
+ /* pullups: BIT(1) */
+ ti,pullups = 0x02;
+ /*
+* pulldowns:
+* BIT(2), BIT(6), BIT(7), BIT(8), BIT(13)
+* BIT(15), BIT(16), BIT(17)
+*/
+ ti,pulldowns = 0x03a1c4;
+};
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 00/18] ARM: OMAP2+: GPMC clean-up and DT update
While adding device-tree support for NOR memories, it became apparent that there is no common way for configuring various GPMC settings for devices that interface to the GPMC. These settings include bus-width, synchronous/asynchronous mode, burst settings, wait monitoring etc. Therefore, to simplify the GPMC code and add device-tree support for NOR, it was first necessary to consolidate how these settings are programmed. Series based upon Mark Jackson's patch [1] and Ezequiel Garcia GPMC clean-up series [2]. Entire series available here [3]. V3 changes: - Rebased on RMK's IS_ERR_VALUE() patch and removed usage of IS_ERR_VALUE() from series. - Fixed BUG in NAND code introduced in V2 by making gpmc_settings structure a local variable (I forgot to initialise structure to zero). - Added fix from Javier to correct return value from gpmc_probe_nor(). V2 changes: - Made gpmc_settings structure local in gpmc_nand_init(). - Use resource_size() API in probe_nor(). - Add kernel-doc for gpmc_cs_program_settings() function. - Use of_platform_device_create() to register NOR devices in probe_nor(). - Add support for GPMC address-address-data multiplexing which required changing GPMC DT property gpmc,mux-add-data to store a 32-bit value and changing mux_add_data member of gpmc_settings to be a 32-bit type instead of bool. - Add detection for incorrect GPMC chip-select base addresses. - Cleaned-up code in gpmc_mem_init() and changed gpmc_mem_init() so that it would not return an error when the GPMC driver is being probed. V1 changes: - Clean-up/simplification of ONENAND initialisation code. - Add a new GPMC structure to unify storage of various GPMC settings (that are non-timing related) for client devices and add a new function to program these settings in a common way. - Migrate initialisation code for existing flash, usb and networking devices to use the new structure and function for GPMC settings. - Add device-tree support for NOR flash memories. - Add additional GPMC timing parameters to GPMC device-tree binding. - Update GPMC NAND and ONENAND device-tree support to retrieve GPMC settings from device-tree. Testing includes: - Boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 SDP with and without device-tree present. - OMAP2420 H4 board has NOR flash and OMAP3430 SDP has NOR, NAND and ONENAND flash. So verified that flash is detected on boot as expected. Note additional patches [4] are required for OMAP2420 H4 and OMAP3430 SDP dts files in order to enable flash memory support. - All of the above boards use GPMC for interfacing to a networking chip and so verified that networking is working wit this series. However, please note that networking is not currently supported on these boards when booting with DT and so networking is only tested without DT. [1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/94765 [2] http://comments.gmane.org/gmane.linux.ports.arm.omap/93784 [3] https://github.com/jonhunter/linux/tree/omap-gpmc-for-v3.10 [4] https://github.com/jonhunter/linux/tree/omap-dt-for-v3.10 Javier Martinez Canillas (1): ARM: OMAP2+: return -ENODEV if GPMC child device creation fails Jon Hunter (17): ARM: OMAP2+: Simplify code configuring ONENAND devices ARM: OMAP2+: Add variable to store number of GPMC waitpins ARM: OMAP2+: Add structure for storing GPMC settings ARM: OMAP2+: Add function for configuring GPMC settings ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings() ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings() ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings() ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings() ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure() ARM: OMAP2+: Add function to read GPMC settings from device-tree ARM: OMAP2+: Add device-tree support for NOR flash ARM: OMAP2+: Add additional GPMC timing parameters ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DT ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DT ARM: OMAP2+: Detect incorrectly aligned GPMC base address ARM: OMAP2+: Remove unnecesssary GPMC definitions and variable ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping fails Documentation/devicetree/bindings/bus/ti-gpmc.txt | 48 +- Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 98 .../devicetree/bindings/mtd/gpmc-onenand.txt |3 + arch/arm/mach-omap2/gpmc-nand.c| 39 +- arch/arm/mach-omap2/gpmc-onenand.c | 110 ++-- arch/arm/mach-omap2/gpmc-smc91x.c | 30 +- arch/arm/mach-omap2/gpmc.c | 524 +++- arch/arm/mach-omap2/gpmc.h | 37 +- arch/arm/mach-omap2/usb-tusb6010.c | 62 ++- 9 files changed, 691 insertions(+), 260 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nor.txt -- 1.7.10.4
[PATCH V3 01/18] ARM: OMAP2+: Simplify code configuring ONENAND devices
The OMAP2+ code that configures the GPMC for ONENAND devices is copying
structures between functions unnecessarily. Avoid this by passing
pointers instead and simplify the code.
A pointer to structure omap_onenand_platform_data is passed to the
function omap2_onenand_calc_sync_timings(), but only the flags member
of the structure is used. Simplify the code by only passing the flags
member and not the entire structure.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 4c91752..db52c4b 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -47,10 +47,9 @@ static struct platform_device gpmc_onenand_device = {
.resource = gpmc_onenand_resource,
};
-static struct gpmc_timings omap2_onenand_calc_async_timings(void)
+static void omap2_onenand_calc_async_timings(struct gpmc_timings *t)
{
struct gpmc_device_timings dev_t;
- struct gpmc_timings t;
const int t_cer = 15;
const int t_avdp = 12;
@@ -76,9 +75,7 @@ static struct gpmc_timings
omap2_onenand_calc_async_timings(void)
dev_t.t_wpl = t_wpl * 1000;
dev_t.t_wph = t_wph * 1000;
- gpmc_calc_timings(t, dev_t);
-
- return t;
+ gpmc_calc_timings(t, dev_t);
}
static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
@@ -158,12 +155,11 @@ static int omap2_onenand_get_freq(struct
omap_onenand_platform_data *cfg,
return freq;
}
-static struct gpmc_timings
-omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
- int freq)
+static void omap2_onenand_calc_sync_timings(struct gpmc_timings *t,
+ unsigned int flags,
+ int freq)
{
struct gpmc_device_timings dev_t;
- struct gpmc_timings t;
const int t_cer = 15;
const int t_avdp = 12;
const int t_cez = 20; /* max of t_cez, t_oez */
@@ -172,9 +168,9 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
int div, gpmc_clk_ns;
- if (cfg-flags ONENAND_SYNC_READ)
+ if (flags ONENAND_SYNC_READ)
onenand_flags = ONENAND_FLAG_SYNCREAD;
- else if (cfg-flags ONENAND_SYNC_READWRITE)
+ else if (flags ONENAND_SYNC_READWRITE)
onenand_flags = ONENAND_FLAG_SYNCREAD | ONENAND_FLAG_SYNCWRITE;
switch (freq) {
@@ -265,9 +261,7 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
dev_t.cyc_aavdh_oe = 1;
dev_t.t_rdyo = t_rdyo * 1000 + min_gpmc_clk_period;
- gpmc_calc_timings(t, dev_t);
-
- return t;
+ gpmc_calc_timings(t, dev_t);
}
static int gpmc_set_sync_mode(int cs, struct gpmc_timings *t)
@@ -300,7 +294,7 @@ static int omap2_onenand_setup_async(void __iomem
*onenand_base)
omap2_onenand_set_async_mode(onenand_base);
- t = omap2_onenand_calc_async_timings();
+ omap2_onenand_calc_async_timings(t);
ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t);
if (ret 0)
@@ -322,7 +316,7 @@ static int omap2_onenand_setup_sync(void __iomem
*onenand_base, int *freq_ptr)
set_onenand_cfg(onenand_base);
}
- t = omap2_onenand_calc_sync_timings(gpmc_onenand_data, freq);
+ omap2_onenand_calc_sync_timings(t, gpmc_onenand_data-flags, freq);
ret = gpmc_set_sync_mode(gpmc_onenand_data-cs, t);
if (ret 0)
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 02/18] ARM: OMAP2+: Add variable to store number of GPMC waitpins
The GPMC has wait-pin signals that can be assigned to a chip-select
to monitor the ready signal of an external device. Add a variable to
indicate the total number of wait-pins for a given device. This will
allow us to detect if the wait-pin being selected is valid or not.
When booting with device-tree read the number of wait-pins from the
device-tree blob. When device-tree is not used set the number of
wait-pins to 4 which is valid for OMAP2-5 devices. Newer devices
that have less wait-pins (such as AM335x) only support booting with
device-tree and so hard-coding the wait-pin number when not using
device-tree is fine.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ef655d9..88a261c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -108,6 +108,8 @@
#defineGPMC_HAS_WR_ACCESS 0x1
#defineGPMC_HAS_WR_DATA_MUX_BUS0x2
+#define GPMC_NR_WAITPINS 4
+
/* XXX: Only NAND irq has been considered,currently these are the only ones
used
*/
#defineGPMC_NR_IRQ 2
@@ -153,6 +155,7 @@ static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
/* Define chip-selects as reserved by default until probe completes */
static unsigned int gpmc_cs_map = ((1 GPMC_CS_NUM) - 1);
+static unsigned int gpmc_nr_waitpins;
static struct device *gpmc_dev;
static int gpmc_irq;
static resource_size_t phys_base, mem_size;
@@ -1297,6 +1300,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)
if (!of_id)
return 0;
+ ret = of_property_read_u32(pdev-dev.of_node, gpmc,num-waitpins,
+ gpmc_nr_waitpins);
+ if (ret 0) {
+ pr_err(%s: number of wait pins not found!\n, __func__);
+ return ret;
+ }
+
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
if (ret 0) {
@@ -1372,6 +1382,12 @@ static int gpmc_probe(struct platform_device *pdev)
if (gpmc_setup_irq() 0)
dev_warn(gpmc_dev, gpmc_setup_irq failed\n);
+ /* Now the GPMC is initialised, unreserve the chip-selects */
+ gpmc_cs_map = 0;
+
+ if (!pdev-dev.of_node)
+ gpmc_nr_waitpins = GPMC_NR_WAITPINS;
+
rc = gpmc_probe_dt(pdev);
if (rc 0) {
clk_disable_unprepare(gpmc_l3_clk);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 04/18] ARM: OMAP2+: Add function for configuring GPMC settings
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no common function for configuring these options and
various devices set these options by either programming the GPMC CONFIG1
register directly or by calling gpmc_cs_configure() to set some of the
options.
Add a new function for configuring all of the GPMC options. Having a common
function for configuring this options will simplify code and ease the
migration to device-tree.
Also add a new capability flag to detect devices that support the
address-address-data multiplexing mode.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 100
arch/arm/mach-omap2/gpmc.h |6 +++
2 files changed, 106 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 7cc07b5..760c26d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -107,6 +107,7 @@
#defineGPMC_HAS_WR_ACCESS 0x1
#defineGPMC_HAS_WR_DATA_MUX_BUS0x2
+#defineGPMC_HAS_MUX_AAD0x4
#define GPMC_NR_WAITPINS 4
@@ -1129,6 +1130,90 @@ int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
return 0;
}
+/**
+ * gpmc_cs_program_settings - programs non-timing related settings
+ * @cs:GPMC chip-select to program
+ * @p: pointer to GPMC settings structure
+ *
+ * Programs non-timing related settings for a GPMC chip-select, such as
+ * bus-width, burst configuration, etc. Function should be called once
+ * for each chip-select that is being used and must be called before
+ * calling gpmc_cs_set_timings() as timing parameters in the CONFIG1
+ * register will be initialised to zero by this function. Returns 0 on
+ * success and appropriate negative error code on failure.
+ */
+int gpmc_cs_program_settings(int cs, struct gpmc_settings *p)
+{
+ u32 config1;
+
+ if ((!p-device_width) || (p-device_width GPMC_DEVWIDTH_16BIT)) {
+ pr_err(%s: invalid width %d!, __func__, p-device_width);
+ return -EINVAL;
+ }
+
+ /* Address-data multiplexing not supported for NAND devices */
+ if (p-device_nand p-mux_add_data) {
+ pr_err(%s: invalid configuration!\n, __func__);
+ return -EINVAL;
+ }
+
+ if ((p-mux_add_data GPMC_MUX_AD) ||
+ ((p-mux_add_data == GPMC_MUX_AAD)
+!(gpmc_capability GPMC_HAS_MUX_AAD))) {
+ pr_err(%s: invalid multiplex configuration!\n, __func__);
+ return -EINVAL;
+ }
+
+ /* Page/burst mode supports lengths of 4, 8 and 16 bytes */
+ if (p-burst_read || p-burst_write) {
+ switch (p-burst_len) {
+ case GPMC_BURST_4:
+ case GPMC_BURST_8:
+ case GPMC_BURST_16:
+ break;
+ default:
+ pr_err(%s: invalid page/burst-length (%d)\n,
+ __func__, p-burst_len);
+ return -EINVAL;
+ }
+ }
+
+ if ((p-wait_on_read || p-wait_on_write)
+ (p-wait_pin gpmc_nr_waitpins)) {
+ pr_err(%s: invalid wait-pin (%d)\n, __func__, p-wait_pin);
+ return -EINVAL;
+ }
+
+ config1 = GPMC_CONFIG1_DEVICESIZE((p-device_width - 1));
+
+ if (p-sync_read)
+ config1 |= GPMC_CONFIG1_READTYPE_SYNC;
+ if (p-sync_write)
+ config1 |= GPMC_CONFIG1_WRITETYPE_SYNC;
+ if (p-wait_on_read)
+ config1 |= GPMC_CONFIG1_WAIT_READ_MON;
+ if (p-wait_on_write)
+ config1 |= GPMC_CONFIG1_WAIT_WRITE_MON;
+ if (p-wait_on_read || p-wait_on_write)
+ config1 |= GPMC_CONFIG1_WAIT_PIN_SEL(p-wait_pin);
+ if (p-device_nand)
+ config1 |= GPMC_CONFIG1_DEVICETYPE(GPMC_DEVICETYPE_NAND);
+ if (p-mux_add_data)
+ config1 |= GPMC_CONFIG1_MUXTYPE(p-mux_add_data);
+ if (p-burst_read)
+ config1 |= GPMC_CONFIG1_READMULTIPLE_SUPP;
+ if (p-burst_write)
+ config1 |= GPMC_CONFIG1_WRITEMULTIPLE_SUPP;
+ if (p-burst_read || p-burst_write) {
+ config1 |= GPMC_CONFIG1_PAGE_LEN(p-burst_len 3);
+ config1 |= p-burst_wrap ? GPMC_CONFIG1_WRAPBURST_SUPP : 0;
+ }
+
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, config1);
+
+ return 0;
+}
+
#ifdef CONFIG_OF
static struct of_device_id gpmc_dt_ids[] = {
{ .compatible = ti,omap2420-gpmc },
@@ -1375,8 +1460,23 @@ static int gpmc_probe(struct platform_device *pdev)
gpmc_dev = pdev-dev;
l = gpmc_read_reg(GPMC_REVISION);
+
+ /*
+* FIXME: Once device-tree migration is complete the below flags
+* should be populated based upon the device-tree compatible
+
[PATCH V3 03/18] ARM: OMAP2+: Add structure for storing GPMC settings
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no central structure for storing all these options
when configuring the GPMC for a given device. Some of the options are
stored in the GPMC timing structure and some are directly programmed
into the GPMC configuration register. Add a new structure to store
these options and convert code to use this structure. Adding this
structure will allow us to create a common function for configuring
these options.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 18 ++-
arch/arm/mach-omap2/gpmc-smc91x.c |2 +-
arch/arm/mach-omap2/gpmc.c | 45 +---
arch/arm/mach-omap2/gpmc.h | 28 --
arch/arm/mach-omap2/usb-tusb6010.c | 19 ---
5 files changed, 72 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index db52c4b..e175ceb 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -47,6 +47,15 @@ static struct platform_device gpmc_onenand_device = {
.resource = gpmc_onenand_resource,
};
+static struct gpmc_settings onenand_async = {
+ .mux_add_data = GPMC_MUX_AD,
+};
+
+static struct gpmc_settings onenand_sync = {
+ .burst_read = true,
+ .mux_add_data = GPMC_MUX_AD,
+};
+
static void omap2_onenand_calc_async_timings(struct gpmc_timings *t)
{
struct gpmc_device_timings dev_t;
@@ -63,7 +72,6 @@ static void omap2_onenand_calc_async_timings(struct
gpmc_timings *t)
memset(dev_t, 0, sizeof(dev_t));
- dev_t.mux = true;
dev_t.t_avdp_r = max_t(int, t_avdp, t_cer) * 1000;
dev_t.t_avdp_w = dev_t.t_avdp_r;
dev_t.t_aavdh = t_aavdh * 1000;
@@ -75,7 +83,7 @@ static void omap2_onenand_calc_async_timings(struct
gpmc_timings *t)
dev_t.t_wpl = t_wpl * 1000;
dev_t.t_wph = t_wph * 1000;
- gpmc_calc_timings(t, dev_t);
+ gpmc_calc_timings(t, onenand_async, dev_t);
}
static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
@@ -235,10 +243,8 @@ static void omap2_onenand_calc_sync_timings(struct
gpmc_timings *t,
/* Set synchronous read timings */
memset(dev_t, 0, sizeof(dev_t));
- dev_t.mux = true;
- dev_t.sync_read = true;
if (onenand_flags ONENAND_FLAG_SYNCWRITE) {
- dev_t.sync_write = true;
+ onenand_sync.sync_write = true;
} else {
dev_t.t_avdp_w = max(t_avdp, t_cer) * 1000;
dev_t.t_wpl = t_wpl * 1000;
@@ -261,7 +267,7 @@ static void omap2_onenand_calc_sync_timings(struct
gpmc_timings *t,
dev_t.cyc_aavdh_oe = 1;
dev_t.t_rdyo = t_rdyo * 1000 + min_gpmc_clk_period;
- gpmc_calc_timings(t, dev_t);
+ gpmc_calc_timings(t, onenand_sync, dev_t);
}
static int gpmc_set_sync_mode(int cs, struct gpmc_timings *t)
diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c
b/arch/arm/mach-omap2/gpmc-smc91x.c
index 11d0b75..4b78338 100644
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -104,7 +104,7 @@ static int smc91c96_gpmc_retime(void)
dev_t.t_cez_w = t4_w * 1000;
dev_t.t_wr_cycle = (t20 - t3) * 1000;
- gpmc_calc_timings(t, dev_t);
+ gpmc_calc_timings(t, NULL, dev_t);
return gpmc_cs_set_timings(gpmc_cfg-cs, t);
}
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 88a261c..7cc07b5 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -817,9 +817,9 @@ static u32 gpmc_round_ps_to_sync_clk(u32 time_ps, u32
sync_clk)
/* XXX: can the cycles be avoided ? */
static int gpmc_calc_sync_read_timings(struct gpmc_timings *gpmc_t,
- struct gpmc_device_timings *dev_t)
+ struct gpmc_device_timings *dev_t,
+ bool mux)
{
- bool mux = dev_t-mux;
u32 temp;
/* adv_rd_off */
@@ -872,9 +872,9 @@ static int gpmc_calc_sync_read_timings(struct gpmc_timings
*gpmc_t,
}
static int gpmc_calc_sync_write_timings(struct gpmc_timings *gpmc_t,
- struct gpmc_device_timings *dev_t)
+ struct gpmc_device_timings *dev_t,
+ bool mux)
{
- bool mux = dev_t-mux;
u32 temp;
/* adv_wr_off */
@@ -934,9 +934,9 @@ static int gpmc_calc_sync_write_timings(struct gpmc_timings
*gpmc_t,
}
static int gpmc_calc_async_read_timings(struct gpmc_timings *gpmc_t,
- struct gpmc_device_timings *dev_t)
+ struct gpmc_device_timings *dev_t,
+ bool mux)
{
- bool
[PATCH V3 05/18] ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings()
Convert the OMAP2+ ONENAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 61 +++-
1 file changed, 25 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index e175ceb..46aac83 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -48,18 +48,22 @@ static struct platform_device gpmc_onenand_device = {
};
static struct gpmc_settings onenand_async = {
+ .device_width = GPMC_DEVWIDTH_16BIT,
.mux_add_data = GPMC_MUX_AD,
};
static struct gpmc_settings onenand_sync = {
.burst_read = true,
+ .burst_wrap = true,
+ .burst_len = GPMC_BURST_16,
+ .device_width = GPMC_DEVWIDTH_16BIT,
.mux_add_data = GPMC_MUX_AD,
+ .wait_pin = 0,
};
static void omap2_onenand_calc_async_timings(struct gpmc_timings *t)
{
struct gpmc_device_timings dev_t;
-
const int t_cer = 15;
const int t_avdp = 12;
const int t_aavdh = 7;
@@ -86,16 +90,6 @@ static void omap2_onenand_calc_async_timings(struct
gpmc_timings *t)
gpmc_calc_timings(t, onenand_async, dev_t);
}
-static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
-{
- /* Configure GPMC for asynchronous read */
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
- GPMC_CONFIG1_DEVICESIZE_16 |
- GPMC_CONFIG1_MUXADDDATA);
-
- return gpmc_cs_set_timings(cs, t);
-}
-
static void omap2_onenand_set_async_mode(void __iomem *onenand_base)
{
u32 reg;
@@ -243,8 +237,11 @@ static void omap2_onenand_calc_sync_timings(struct
gpmc_timings *t,
/* Set synchronous read timings */
memset(dev_t, 0, sizeof(dev_t));
+ if (onenand_flags ONENAND_FLAG_SYNCREAD)
+ onenand_sync.sync_read = true;
if (onenand_flags ONENAND_FLAG_SYNCWRITE) {
onenand_sync.sync_write = true;
+ onenand_sync.burst_write = true;
} else {
dev_t.t_avdp_w = max(t_avdp, t_cer) * 1000;
dev_t.t_wpl = t_wpl * 1000;
@@ -270,29 +267,6 @@ static void omap2_onenand_calc_sync_timings(struct
gpmc_timings *t,
gpmc_calc_timings(t, onenand_sync, dev_t);
}
-static int gpmc_set_sync_mode(int cs, struct gpmc_timings *t)
-{
- unsigned sync_read = onenand_flags ONENAND_FLAG_SYNCREAD;
- unsigned sync_write = onenand_flags ONENAND_FLAG_SYNCWRITE;
-
- /* Configure GPMC for synchronous read */
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
- GPMC_CONFIG1_WRAPBURST_SUPP |
- GPMC_CONFIG1_READMULTIPLE_SUPP |
- (sync_read ? GPMC_CONFIG1_READTYPE_SYNC : 0) |
- (sync_write ? GPMC_CONFIG1_WRITEMULTIPLE_SUPP : 0) |
- (sync_write ? GPMC_CONFIG1_WRITETYPE_SYNC : 0) |
- GPMC_CONFIG1_PAGE_LEN(2) |
- (cpu_is_omap34xx() ? 0 :
- (GPMC_CONFIG1_WAIT_READ_MON |
-GPMC_CONFIG1_WAIT_PIN_SEL(0))) |
- GPMC_CONFIG1_DEVICESIZE_16 |
- GPMC_CONFIG1_DEVICETYPE_NOR |
- GPMC_CONFIG1_MUXADDDATA);
-
- return gpmc_cs_set_timings(cs, t);
-}
-
static int omap2_onenand_setup_async(void __iomem *onenand_base)
{
struct gpmc_timings t;
@@ -302,7 +276,11 @@ static int omap2_onenand_setup_async(void __iomem
*onenand_base)
omap2_onenand_calc_async_timings(t);
- ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t);
+ ret = gpmc_cs_program_settings(gpmc_onenand_data-cs, onenand_async);
+ if (ret 0)
+ return ret;
+
+ ret = gpmc_cs_set_timings(gpmc_onenand_data-cs, t);
if (ret 0)
return ret;
@@ -322,9 +300,20 @@ static int omap2_onenand_setup_sync(void __iomem
*onenand_base, int *freq_ptr)
set_onenand_cfg(onenand_base);
}
+ /*
+* FIXME: Appears to be legacy code from initial ONENAND commit.
+* Unclear what boards this is for and if this can be removed.
+*/
+ if (!cpu_is_omap34xx())
+ onenand_sync.wait_on_read = true;
+
omap2_onenand_calc_sync_timings(t, gpmc_onenand_data-flags, freq);
- ret = gpmc_set_sync_mode(gpmc_onenand_data-cs, t);
+ ret = gpmc_cs_program_settings(gpmc_onenand_data-cs, onenand_sync);
+ if (ret 0)
+ return ret;
+
+ ret = gpmc_cs_set_timings(gpmc_onenand_data-cs, t);
if (ret 0)
return ret;
--
1.7.10.4
___
devicetree-discuss mailing list
Re: [Linaro-mm-sig] [PATCH 2/2] drivers: dma-contiguous: add initialization from device tree
Hello,
On 2/14/2013 10:34 PM, Laura Abbott wrote:
On 2/14/2013 4:45 AM, Marek Szyprowski wrote:
snip
+name:an name given to the defined region.
+base-address:the base address of the defined region.
+size:the size of the memory region.
+linux,contiguous-region: property indicating that the defined memory
+region is used for contiguous memory allocations,
+Linux specific (optional)
+linux,default-contiguous-region: property indicating that the region
+is the default region for all contiguous memory
+allocations, Linux specific (optional)
+
+
I don't see any code actually implementing the
default-contiguous-region binding. Currently on ARM systems we will
still setup the default region based on the Kconfig. Is this intentional?
Nope, this was my fault. I've missed the fixup which added support for
default-contiguous-region (it was just a few lines more to cma_fdt_scan()
function).
diff --git a/drivers/base/dma-contiguous.c
b/drivers/base/dma-contiguous.c
index 085389c..5761f73 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -24,6 +24,9 @@
#include linux/memblock.h
#include linux/err.h
+#include linux/of.h
+#include linux/of_fdt.h
+#include linux/of_platform.h
#include linux/mm.h
#include linux/mutex.h
#include linux/page-isolation.h
@@ -177,6 +180,35 @@ no_mem:
return ERR_PTR(ret);
}
+/*/
+
+#ifdef CONFIG_OF
+int __init cma_fdt_scan(unsigned long node, const char *uname,
+int depth, void *data)
+{
+phys_addr_t base, size;
+unsigned long len;
+__be32 *prop;
+
+if (strncmp(uname, region@, 7) != 0 || depth != 2 ||
+!of_get_flat_dt_prop(node, contiguous-region, NULL))
The documentation says linux,contiguous-region
Right, lack of another fixup. It looks that I posted an incomplete
version, I'm sorry.
I hurried that time (it was my last day in the office before going for
holidays).
+#ifdef CONFIG_OF
+static void cma_assign_device_from_dt(struct device *dev)
+{
+struct device_node *node;
+struct cma *cma;
+u32 value;
+
+node = of_parse_phandle(dev-of_node, linux,contiguous-region,
0);
+if (!node)
+return;
+if (of_property_read_u32(node, reg, value) !value)
+return;
+cma = cma_get_area(value);
+if (!cma)
+return;
+
+dev_set_cma_area(dev, cma);
+pr_info(Assigned CMA region at %lx to %s device\n, (unsigned
long)value, dev_name(dev));
+}
+
This scheme of associating devices with CMA regions by base does not
work if you want to let CMA figure out where to place the region (base
= 0). Can we use the name to associate the device with the region? I
had been working on something similar internally and that was the only
solution I had come up with to associate arbitrary CMA nodes with devices.
Right, support for base = 0 requires different handling, but I thought
that if
we use the device tree approach, the designer already knows the complete
memory
configuration, so providing the correct base address is not that hard.
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 06/18] ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings()
Convert the OMAP2+ NAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
This moves the configuration of some GPMC options outside the
nand_gpmc_retime() because these options should only need to be set once
regardless of whether the gpmc timing is changing dynamically at runtime.
The programming of where the wait-pin is also moved slightly, but this
will not have any impact to existing devices as no boards are currently
setting the dev_ready variable.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index e50e438..75feb95 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -74,14 +74,6 @@ static int omap2_nand_gpmc_retime(
t.cs_wr_off = gpmc_t-cs_wr_off;
t.wr_cycle = gpmc_t-wr_cycle;
- /* Configure GPMC */
- if (gpmc_nand_data-devsize == NAND_BUSWIDTH_16)
- gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_DEV_SIZE, 1);
- else
- gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_DEV_SIZE, 0);
- gpmc_cs_configure(gpmc_nand_data-cs,
- GPMC_CONFIG_DEV_TYPE, GPMC_DEVICETYPE_NAND);
- gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_WP, 0);
err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
if (err)
return err;
@@ -115,8 +107,11 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
struct gpmc_timings *gpmc_t)
{
int err = 0;
+ struct gpmc_settings s;
struct device *dev = gpmc_nand_device.dev;
+ memset(s, 0, sizeof(struct gpmc_settings));
+
gpmc_nand_device.dev.platform_data = gpmc_nand_data;
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
@@ -141,11 +136,27 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
dev_err(dev, Unable to set gpmc timings: %d\n, err);
return err;
}
- }
- /* Enable RD PIN Monitoring Reg */
- if (gpmc_nand_data-dev_ready) {
- gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_RDY_BSY, 1);
+ s.device_nand = true;
+
+ /* Enable RD PIN Monitoring Reg */
+ if (gpmc_nand_data-dev_ready) {
+ s.wait_on_read = true;
+ s.wait_on_write = true;
+ }
+
+ if (gpmc_nand_data-devsize == NAND_BUSWIDTH_16)
+ s.device_width = GPMC_DEVWIDTH_16BIT;
+ else
+ s.device_width = GPMC_DEVWIDTH_8BIT;
+
+ err = gpmc_cs_program_settings(gpmc_nand_data-cs, s);
+ if (err 0)
+ goto out_free_cs;
+
+ err = gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_WP, 0);
+ if (err 0)
+ goto out_free_cs;
}
gpmc_update_nand_reg(gpmc_nand_data-reg, gpmc_nand_data-cs);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 07/18] ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings()
Convert the OMAP2+ SMC91x code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Move configuration of the GPMC settings outside retime function and
this does not need to be done if the timings are changed dynamically
at runtime.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-smc91x.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c
b/arch/arm/mach-omap2/gpmc-smc91x.c
index 4b78338..61a0635 100644
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -49,6 +49,10 @@ static struct platform_device gpmc_smc91x_device = {
.resource = gpmc_smc91x_resources,
};
+static struct gpmc_settings smc91x_settings = {
+ .device_width = GPMC_DEVWIDTH_16BIT,
+};
+
/*
* Set the gpmc timings for smc91c96. The timings are taken
* from the data sheet available at:
@@ -67,18 +71,6 @@ static int smc91c96_gpmc_retime(void)
const int t7 = 5; /* Figure 12.4 write */
const int t8 = 5; /* Figure 12.4 write */
const int t20 = 185;/* Figure 12.2 read and 12.4 write */
- u32 l;
-
- l = GPMC_CONFIG1_DEVICESIZE_16;
- if (gpmc_cfg-flags GPMC_MUX_ADD_DATA)
- l |= GPMC_CONFIG1_MUXADDDATA;
- if (gpmc_cfg-flags GPMC_READ_MON)
- l |= GPMC_CONFIG1_WAIT_READ_MON;
- if (gpmc_cfg-flags GPMC_WRITE_MON)
- l |= GPMC_CONFIG1_WAIT_WRITE_MON;
- if (gpmc_cfg-wait_pin)
- l |= GPMC_CONFIG1_WAIT_PIN_SEL(gpmc_cfg-wait_pin);
- gpmc_cs_write_reg(gpmc_cfg-cs, GPMC_CS_CONFIG1, l);
/*
* FIXME: Calculate the address and data bus muxed timings.
@@ -104,7 +96,7 @@ static int smc91c96_gpmc_retime(void)
dev_t.t_cez_w = t4_w * 1000;
dev_t.t_wr_cycle = (t20 - t3) * 1000;
- gpmc_calc_timings(t, NULL, dev_t);
+ gpmc_calc_timings(t, smc91x_settings, dev_t);
return gpmc_cs_set_timings(gpmc_cfg-cs, t);
}
@@ -133,6 +125,18 @@ void __init gpmc_smc91x_init(struct
omap_smc91x_platform_data *board_data)
gpmc_smc91x_resources[0].end = cs_mem_base + 0x30f;
gpmc_smc91x_resources[1].flags |= (gpmc_cfg-flags IRQF_TRIGGER_MASK);
+ if (gpmc_cfg-flags GPMC_MUX_ADD_DATA)
+ smc91x_settings.mux_add_data = GPMC_MUX_AD;
+ if (gpmc_cfg-flags GPMC_READ_MON)
+ smc91x_settings.wait_on_read = true;
+ if (gpmc_cfg-flags GPMC_WRITE_MON)
+ smc91x_settings.wait_on_write = true;
+ if (gpmc_cfg-wait_pin)
+ smc91x_settings.wait_pin = gpmc_cfg-wait_pin;
+ ret = gpmc_cs_program_settings(gpmc_cfg-cs, smc91x_settings);
+ if (ret 0)
+ goto free1;
+
if (gpmc_cfg-retime) {
ret = gpmc_cfg-retime();
if (ret != 0)
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 08/18] ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings()
Convert the OMAP2+ TUSB code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/usb-tusb6010.c | 43
1 file changed, 19 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c
b/arch/arm/mach-omap2/usb-tusb6010.c
index faaf96d..e832bc7 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
+#include linux/err.h
#include linux/string.h
#include linux/types.h
#include linux/errno.h
@@ -27,12 +28,21 @@ static u8 async_cs, sync_cs;
static unsignedrefclk_psec;
static struct gpmc_settings tusb_async = {
+ .wait_on_read = true,
+ .wait_on_write = true,
+ .device_width = GPMC_DEVWIDTH_16BIT,
.mux_add_data = GPMC_MUX_AD,
};
static struct gpmc_settings tusb_sync = {
+ .burst_read = true,
+ .burst_write= true,
.sync_read = true,
.sync_write = true,
+ .wait_on_read = true,
+ .wait_on_write = true,
+ .burst_len = GPMC_BURST_16,
+ .device_width = GPMC_DEVWIDTH_16BIT,
.mux_add_data = GPMC_MUX_AD,
};
@@ -168,18 +178,12 @@ tusb6010_setup_interface(struct musb_hdrc_platform_data
*data,
return status;
}
tusb_resources[0].end = tusb_resources[0].start + 0x9ff;
+ tusb_async.wait_pin = waitpin;
async_cs = async;
- gpmc_cs_write_reg(async, GPMC_CS_CONFIG1,
- GPMC_CONFIG1_PAGE_LEN(2)
- | GPMC_CONFIG1_WAIT_READ_MON
- | GPMC_CONFIG1_WAIT_WRITE_MON
- | GPMC_CONFIG1_WAIT_PIN_SEL(waitpin)
- | GPMC_CONFIG1_READTYPE_ASYNC
- | GPMC_CONFIG1_WRITETYPE_ASYNC
- | GPMC_CONFIG1_DEVICESIZE_16
- | GPMC_CONFIG1_DEVICETYPE_NOR
- | GPMC_CONFIG1_MUXADDDATA);
+ status = gpmc_cs_program_settings(async_cs, tusb_async);
+ if (status 0)
+ return status;
/* SYNC region, primarily for DMA */
status = gpmc_cs_request(sync, SZ_16M, (unsigned long *)
@@ -189,21 +193,12 @@ tusb6010_setup_interface(struct musb_hdrc_platform_data
*data,
return status;
}
tusb_resources[1].end = tusb_resources[1].start + 0x9ff;
+ tusb_sync.wait_pin = waitpin;
sync_cs = sync;
- gpmc_cs_write_reg(sync, GPMC_CS_CONFIG1,
- GPMC_CONFIG1_READMULTIPLE_SUPP
- | GPMC_CONFIG1_READTYPE_SYNC
- | GPMC_CONFIG1_WRITEMULTIPLE_SUPP
- | GPMC_CONFIG1_WRITETYPE_SYNC
- | GPMC_CONFIG1_PAGE_LEN(2)
- | GPMC_CONFIG1_WAIT_READ_MON
- | GPMC_CONFIG1_WAIT_WRITE_MON
- | GPMC_CONFIG1_WAIT_PIN_SEL(waitpin)
- | GPMC_CONFIG1_DEVICESIZE_16
- | GPMC_CONFIG1_DEVICETYPE_NOR
- | GPMC_CONFIG1_MUXADDDATA
- /* fclk divider gets set later */
- );
+
+ status = gpmc_cs_program_settings(sync_cs, tusb_sync);
+ if (status 0)
+ return status;
/* IRQ */
status = gpio_request_one(irq, GPIOF_IN, TUSB6010 irq);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 09/18] ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure()
With the addition of the gpmc_cs_program_settings(), we no longer need
or use gpmc_cs_configure() to configure some of the GPMC chip-select
options. So rename the function to gpmc_configure() and remove code that
modifies options in the CONFIG1 register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c |2 +-
arch/arm/mach-omap2/gpmc.c | 49 ++-
arch/arm/mach-omap2/gpmc.h |5 +---
3 files changed, 9 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 75feb95..12e9753 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -154,7 +154,7 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
if (err 0)
goto out_free_cs;
- err = gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_WP, 0);
+ err = gpmc_configure(GPMC_CONFIG_WP, 0);
if (err 0)
goto out_free_cs;
}
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 760c26d..3ec1937 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -550,16 +550,14 @@ void gpmc_cs_free(int cs)
EXPORT_SYMBOL(gpmc_cs_free);
/**
- * gpmc_cs_configure - write request to configure gpmc
- * @cs: chip select number
+ * gpmc_configure - write request to configure gpmc
* @cmd: command type
* @wval: value to write
* @return status of the operation
*/
-int gpmc_cs_configure(int cs, int cmd, int wval)
+int gpmc_configure(int cmd, int wval)
{
- int err = 0;
- u32 regval = 0;
+ u32 regval;
switch (cmd) {
case GPMC_ENABLE_IRQ:
@@ -579,47 +577,14 @@ int gpmc_cs_configure(int cs, int cmd, int wval)
gpmc_write_reg(GPMC_CONFIG, regval);
break;
- case GPMC_CONFIG_RDY_BSY:
- regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
- if (wval)
- regval |= WR_RD_PIN_MONITORING;
- else
- regval = ~WR_RD_PIN_MONITORING;
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
- break;
-
- case GPMC_CONFIG_DEV_SIZE:
- regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
-
- /* clear 2 target bits */
- regval = ~GPMC_CONFIG1_DEVICESIZE(3);
-
- /* set the proper value */
- regval |= GPMC_CONFIG1_DEVICESIZE(wval);
-
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
- break;
-
- case GPMC_CONFIG_DEV_TYPE:
- regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
- /* clear 4 target bits */
- regval = ~(GPMC_CONFIG1_DEVICETYPE(3) |
- GPMC_CONFIG1_MUXTYPE(3));
- /* set the proper value */
- regval |= GPMC_CONFIG1_DEVICETYPE(wval);
- if (wval == GPMC_DEVICETYPE_NOR)
- regval |= GPMC_CONFIG1_MUXADDDATA;
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
- break;
-
default:
- printk(KERN_ERR gpmc_configure_cs: Not supported\n);
- err = -EINVAL;
+ pr_err(%s: command not supported\n, __func__);
+ return -EINVAL;
}
- return err;
+ return 0;
}
-EXPORT_SYMBOL(gpmc_cs_configure);
+EXPORT_SYMBOL(gpmc_configure);
void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
{
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index ce6ae21..87d2a22 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -59,9 +59,6 @@
#define GPMC_CONFIG1_DEVICETYPE(val)((val 3) 10)
#define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
#define GPMC_CONFIG1_MUXTYPE(val) ((val 3) 8)
-#define GPMC_CONFIG1_MUXNONMUX GPMC_CONFIG1_MUXTYPE(0)
-#define GPMC_CONFIG1_MUXAAD GPMC_CONFIG1_MUXTYPE(GPMC_MUX_AAD)
-#define GPMC_CONFIG1_MUXADDDATA GPMC_CONFIG1_MUXTYPE(GPMC_MUX_AD)
#define GPMC_CONFIG1_TIME_PARA_GRAN (1 4)
#define GPMC_CONFIG1_FCLK_DIV(val) (val 3)
#define GPMC_CONFIG1_FCLK_DIV2 (GPMC_CONFIG1_FCLK_DIV(1))
@@ -227,6 +224,6 @@ extern int gpmc_cs_request(int cs, unsigned long size,
unsigned long *base);
extern void gpmc_cs_free(int cs);
extern void omap3_gpmc_save_context(void);
extern void omap3_gpmc_restore_context(void);
-extern int gpmc_cs_configure(int cs, int cmd, int wval);
+extern int gpmc_configure(int cmd, int wval);
#endif
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 10/18] ARM: OMAP2+: Add function to read GPMC settings from device-tree
Adds a function to read the various GPMC chip-select settings from
device-tree and store them in the gpmc_settings structure.
Update the GPMC device-tree binding documentation to describe these
options.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 23 ++
arch/arm/mach-omap2/gpmc.c| 49 +
arch/arm/mach-omap2/gpmc.h|2 +
3 files changed, 74 insertions(+)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
index 5ddb2e9..6fde1cf 100644
--- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -65,6 +65,29 @@ The following are only applicable to OMAP3+ and AM335x:
- gpmc,wr-access
- gpmc,wr-data-mux-bus
+GPMC chip-select settings properties for child nodes. All are optional.
+
+- gpmc,burst-lengthPage/burst length. Must be 4, 8 or 16.
+- gpmc,burst-wrap Enables wrap bursting
+- gpmc,burst-read Enables read page/burst mode
+- gpmc,burst-write Enables write page/burst mode
+- gpmc,device-nand Device is NAND
+- gpmc,device-widthTotal width of device(s) connected to a GPMC
+ chip-select in bytes. The GPMC supports 8-bit
+ and 16-bit devices and so this property must be
+ 1 or 2.
+- gpmc,mux-add-dataAddress and data multiplexing configuration.
+ Valid values are 1 for address-address-data
+ multiplexing mode and 2 for address-data
+ multiplexing mode.
+- gpmc,sync-read Enables synchronous read. Defaults to asynchronous
+ is this is not set.
+- gpmc,sync-write Enables synchronous writes. Defaults to asynchronous
+ is this is not set.
+- gpmc,wait-pinWait-pin used by client. Must be less than
+ gpmc,num-waitpins.
+- gpmc,wait-on-readEnables wait monitoring on reads.
+- gpmc,wait-on-write Enables wait monitoring on writes.
Example for an AM33xx board:
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 3ec1937..1e7eef3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1190,6 +1190,55 @@ static struct of_device_id gpmc_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, gpmc_dt_ids);
+/**
+ * gpmc_read_settings_dt - read gpmc settings from device-tree
+ * @np:pointer to device-tree node for a gpmc child device
+ * @p: pointer to gpmc settings structure
+ *
+ * Reads the GPMC settings for a GPMC child device from device-tree and
+ * stores them in the GPMC settings structure passed. The GPMC settings
+ * structure is initialise to zero by this function and so any previously
+ * stored settings will be clearer.
+ */
+void gpmc_read_settings_dt(struct device_node *np, struct gpmc_settings *p)
+{
+ memset(p, 0, sizeof(struct gpmc_settings));
+
+ if (of_find_property(np, gpmc,sync-read, NULL))
+ p-sync_read = true;
+ if (of_find_property(np, gpmc,sync-write, NULL))
+ p-sync_write = true;
+
+ if (!of_property_read_u32(np, gpmc,burst-length, p-burst_len)) {
+ if (of_find_property(np, gpmc,burst-wrap, NULL))
+ p-burst_wrap = true;
+ if (of_find_property(np, gpmc,burst-read, NULL))
+ p-burst_read = true;
+ if (of_find_property(np, gpmc,burst-write, NULL))
+ p-burst_write = true;
+ if (!p-burst_read !p-burst_write)
+ pr_warn(%s: page/burst-length set but not used!\n,
+ __func__);
+ }
+
+ if (!of_property_read_u32(np, gpmc,wait-pin, p-wait_pin)) {
+ if (of_find_property(np, gpmc,wait-on-read, NULL))
+ p-wait_on_read = true;
+ if (of_find_property(np, gpmc,wait-on-write, NULL))
+ p-wait_on_write = true;
+ if (!p-wait_on_read !p-wait_on_write)
+ pr_warn(%s: read/write wait monitoring not enabled!\n,
+ __func__);
+ }
+
+ of_property_read_u32(np, gpmc,device-width, p-device_width);
+
+ if (of_find_property(np, gpmc,device-nand, NULL))
+ p-device_nand = true;
+
+ of_property_read_u32(np, gpmc,mux-add-data, p-mux_add_data);
+}
+
static void __maybe_unused gpmc_read_timings_dt(struct device_node *np,
struct gpmc_timings *gpmc_t)
{
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index 87d2a22..707f6d5 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -225,5 +225,7 @@ extern void gpmc_cs_free(int cs);
extern void omap3_gpmc_save_context(void);
[PATCH V3 12/18] ARM: OMAP2+: Add additional GPMC timing parameters
Some of the GPMC timings parameters are currently missing from the GPMC
device-tree binding. Add these parameters to the binding documentation
as well as code to read them.
The existing code in gpmc_read_timings_dt() is checking the value of
of_property_read_u32() and only is successful storing the value read
in the gpmc_timings structure. Checking the return value in this case
is not necessary and we can simply read the value, if present, and
store directly in the gpmc_timings structure. Therefore, simplify the
code by removing these checks.
The comment in the gpmc_read_timings_dt() function, only for OMAP3430
is also incorrect as it is applicable to all OMAP3+ devices. So correct
this too.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 25 +-
arch/arm/mach-omap2/gpmc.c| 93 ++---
2 files changed, 66 insertions(+), 52 deletions(-)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
index 6fde1cf..a63bd93 100644
--- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -56,10 +56,27 @@ Timing properties for child nodes. All are optional and
default to 0.
- gpmc,oe-off:Deassertion time
Access time and cycle time timings corresponding to GPMC_CONFIG5:
- - gpmc,page-burst-access: Multiple access word delay
- - gpmc,access:Start-cycle to first data valid delay
- - gpmc,rd-cycle: Total read cycle time
- - gpmc,wr-cycle: Total write cycle time
+ - gpmc,page-burst-access: Multiple access word delay
+ - gpmc,access:Start-cycle to first data valid delay
+ - gpmc,rd-cycle: Total read cycle time
+ - gpmc,wr-cycle: Total write cycle time
+ - gpmc,bus-turnaround:Turn-around time between successive
accesses
+ - gpmc,cycle2cycle-delay: Delay between chip-select pulses
+ - gpmc,clk-activation:GPMC clock activation time
+ - gpmc,wait-monitoring: Start of wait monitoring with regard to valid
+ data
+
+Boolean timing parameters. If property is present parameter enabled and
+disabled if omitted:
+ - gpmc,adv-extra-delay: ADV signal is delayed by half GPMC clock
+ - gpmc,cs-extra-delay:CS signal is delayed by half GPMC clock
+ - gpmc,cycle2cycle-diffcsen: Add cycle2cycle-delay between successive
+ accesses to a different CS
+ - gpmc,cycle2cycle-samecsen: Add cycle2cycle-delay between successive
+ accesses to the same CS
+ - gpmc,oe-extra-delay:OE signal is delayed by half GPMC clock
+ - gpmc,we-extra-delay:WE signal is delayed by half GPMC clock
+ - gpmc,time-para-granularity: Multiply all access times by 2
The following are only applicable to OMAP3+ and AM335x:
- gpmc,wr-access
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 85b1a35..c928a8c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1274,67 +1274,64 @@ void gpmc_read_settings_dt(struct device_node *np,
struct gpmc_settings *p)
static void __maybe_unused gpmc_read_timings_dt(struct device_node *np,
struct gpmc_timings *gpmc_t)
{
- u32 val;
-
memset(gpmc_t, 0, sizeof(*gpmc_t));
/* minimum clock period for syncronous mode */
- if (!of_property_read_u32(np, gpmc,sync-clk, val))
- gpmc_t-sync_clk = val;
+ of_property_read_u32(np, gpmc,sync-clk, gpmc_t-sync_clk);
/* chip select timtings */
- if (!of_property_read_u32(np, gpmc,cs-on, val))
- gpmc_t-cs_on = val;
-
- if (!of_property_read_u32(np, gpmc,cs-rd-off, val))
- gpmc_t-cs_rd_off = val;
-
- if (!of_property_read_u32(np, gpmc,cs-wr-off, val))
- gpmc_t-cs_wr_off = val;
+ of_property_read_u32(np, gpmc,cs-on, gpmc_t-cs_on);
+ of_property_read_u32(np, gpmc,cs-rd-off, gpmc_t-cs_rd_off);
+ of_property_read_u32(np, gpmc,cs-wr-off, gpmc_t-cs_wr_off);
/* ADV signal timings */
- if (!of_property_read_u32(np, gpmc,adv-on, val))
- gpmc_t-adv_on = val;
-
- if (!of_property_read_u32(np, gpmc,adv-rd-off, val))
- gpmc_t-adv_rd_off = val;
-
- if (!of_property_read_u32(np, gpmc,adv-wr-off, val))
- gpmc_t-adv_wr_off = val;
+ of_property_read_u32(np, gpmc,adv-on, gpmc_t-adv_on);
+ of_property_read_u32(np, gpmc,adv-rd-off, gpmc_t-adv_rd_off);
+ of_property_read_u32(np, gpmc,adv-wr-off, gpmc_t-adv_wr_off);
/* WE signal timings */
- if (!of_property_read_u32(np, gpmc,we-on, val))
- gpmc_t-we_on = val;
-
- if (!of_property_read_u32(np, gpmc,we-off, val))
-
[PATCH V3 11/18] ARM: OMAP2+: Add device-tree support for NOR flash
NOR flash is not currently supported when booting with device-tree
on OMAP2+ devices. Add support to detect and configure NOR devices
when booting with device-tree.
Add documentation for the TI GPMC NOR binding.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 98 +
arch/arm/mach-omap2/gpmc.c | 115
2 files changed, 213 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nor.txt
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
new file mode 100644
index 000..8c638fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
@@ -0,0 +1,98 @@
+Device tree bindings for NOR flash connect to TI GPMC
+
+NOR flash connected to the TI GPMC (found on OMAP boards) are represented as
+child nodes of the GPMC controller with a name of nor.
+
+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: Width of NOR flash in bytes. GPMC supports 8-bit and
+ 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+- 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
+- linux,mtd-name: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+- reg: Chip-select, base address (relative to chip-select)
+ and size of NOR flash. 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, simple-bus;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x1000;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ ranges = 0 0 0x1000 0x0800;
+
+ nor@0,0 {
+ compatible = cfi-flash;
+ linux,mtd-name= intel,pf48f6000m0y1be;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0 0 0x0800;
+ 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;
+
+ partition@0 {
+ label = bootloader-nor;
+ reg = 0 0x4;
+ };
+ partition@0x4 {
+ label = params-nor;
+ reg = 0x4 0x4;
+ };
+ partition@0x8 {
+ label = kernel-nor;
+ reg = 0x8 0x20;
+ };
+ partition@0x28 {
+ label = filesystem-nor;
+ reg = 0x24 0x7d8;
+ };
+ };
+};
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1e7eef3..85b1a35 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -26,6 +26,7 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include linux/of.h
+#include linux/of_address.h
#include linux/of_mtd.h
#include linux/of_device.h
#include linux/mtd/nand.h
@@ -499,6 +500,37 @@ static int gpmc_cs_delete_mem(int cs)
[PATCH V3 14/18] ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DT
When booting with device-tree, retrieve GPMC settings for ONENAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
The user must now specify the ONENAND device width in the device-tree
binding so that the GPMC can be programmed correctly. Therefore, update
the device-tree binding documentation for ONENAND devices connected to
the GPMC to reflect this.
Please note that this does not include GPMC timings for ONENAND. The
timings are being calculated at runtime.
There is some legacy code that only enables read wait monitoring for
non-OMAP3 devices. There are no known OMAP3 device issues that prevent
this feature being enabled and so when booting with device-tree use the
wait-monitoring settings described in the device-tree blob.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
.../devicetree/bindings/mtd/gpmc-onenand.txt |3 +++
arch/arm/mach-omap2/gpmc-onenand.c | 21 ++--
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
index deec9da..b752942 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -10,6 +10,8 @@ Documentation/devicetree/bindings/bus/ti-gpmc.txt
Required properties:
- reg:The CS line the peripheral is connected to
+ - gpmc,device-width Width of the ONENAND device connected to the GPMC
+ in bytes. Must be 1 or 2.
Optional properties:
@@ -34,6 +36,7 @@ Example for an OMAP3430 board:
onenand@0 {
reg = 0 0 0; /* CS0, offset 0 */
+ gpmc,device-width = 2;
#address-cells = 1;
#size-cells = 1;
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 46aac83..64b5a83 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -272,6 +272,10 @@ static int omap2_onenand_setup_async(void __iomem
*onenand_base)
struct gpmc_timings t;
int ret;
+ if (gpmc_onenand_data-of_node)
+ gpmc_read_settings_dt(gpmc_onenand_data-of_node,
+ onenand_async);
+
omap2_onenand_set_async_mode(onenand_base);
omap2_onenand_calc_async_timings(t);
@@ -300,12 +304,17 @@ static int omap2_onenand_setup_sync(void __iomem
*onenand_base, int *freq_ptr)
set_onenand_cfg(onenand_base);
}
- /*
-* FIXME: Appears to be legacy code from initial ONENAND commit.
-* Unclear what boards this is for and if this can be removed.
-*/
- if (!cpu_is_omap34xx())
- onenand_sync.wait_on_read = true;
+ if (gpmc_onenand_data-of_node) {
+ gpmc_read_settings_dt(gpmc_onenand_data-of_node,
+ onenand_sync);
+ } else {
+ /*
+* FIXME: Appears to be legacy code from initial ONENAND commit.
+* Unclear what boards this is for and if this can be removed.
+*/
+ if (!cpu_is_omap34xx())
+ onenand_sync.wait_on_read = true;
+ }
omap2_onenand_calc_sync_timings(t, gpmc_onenand_data-flags, freq);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 13/18] ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DT
When booting with device-tree, retrieve GPMC settings for NAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 12e9753..d9c2719 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -137,12 +137,16 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
return err;
}
- s.device_nand = true;
-
- /* Enable RD PIN Monitoring Reg */
- if (gpmc_nand_data-dev_ready) {
- s.wait_on_read = true;
- s.wait_on_write = true;
+ if (gpmc_nand_data-of_node) {
+ gpmc_read_settings_dt(gpmc_nand_data-of_node, s);
+ } else {
+ s.device_nand = true;
+
+ /* Enable RD PIN Monitoring Reg */
+ if (gpmc_nand_data-dev_ready) {
+ s.wait_on_read = true;
+ s.wait_on_write = true;
+ }
}
if (gpmc_nand_data-devsize == NAND_BUSWIDTH_16)
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 15/18] ARM: OMAP2+: Detect incorrectly aligned GPMC base address
Each GPMC chip-select can be configured to map 16MB, 32MB, 64MB or 128MB
of address space. The physical base address where a chip-select starts
is also configurable and must be aligned on a boundary that is equal to
or greater than the size of the address space mapped bt the chip-select.
When enabling a GPMC chip-select, ensure that the base address is aligned
to the appropriate boundary.
Reported-by: Mark Jackson mpfj-l...@mimc.co.uk
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index c928a8c..a6f2b71 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -403,11 +403,18 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
return 0;
}
-static void gpmc_cs_enable_mem(int cs, u32 base, u32 size)
+static int gpmc_cs_enable_mem(int cs, u32 base, u32 size)
{
u32 l;
u32 mask;
+ /*
+* Ensure that base address is aligned on a
+* boundary equal to or greater than size.
+*/
+ if (base (size - 1))
+ return -EINVAL;
+
mask = (1 GPMC_SECTION_SHIFT) - size;
l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
l = ~0x3f;
@@ -416,6 +423,8 @@ static void gpmc_cs_enable_mem(int cs, u32 base, u32 size)
l |= ((mask GPMC_CHUNK_SHIFT) 0x0f) 8;
l |= GPMC_CONFIG7_CSVALID;
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG7, l);
+
+ return 0;
}
static void gpmc_cs_disable_mem(int cs)
@@ -526,7 +535,9 @@ static int gpmc_cs_remap(int cs, u32 base)
ret = gpmc_cs_insert_mem(cs, base, size);
if (ret 0)
return ret;
- gpmc_cs_enable_mem(cs, base, size);
+ ret = gpmc_cs_enable_mem(cs, base, size);
+ if (ret 0)
+ return ret;
return 0;
}
@@ -556,7 +567,12 @@ int gpmc_cs_request(int cs, unsigned long size, unsigned
long *base)
if (r 0)
goto out;
- gpmc_cs_enable_mem(cs, res-start, resource_size(res));
+ r = gpmc_cs_enable_mem(cs, res-start, resource_size(res));
+ if (r 0) {
+ release_resource(res);
+ goto out;
+ }
+
*base = res-start;
gpmc_cs_set_reserved(cs, 1);
out:
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 16/18] ARM: OMAP2+: Remove unnecesssary GPMC definitions and variable
With commit 21cc2bd (ARM: OMAP2+: Remove apollon board support) the
variable boot_rom_space is now not needed and the code surrounding
this variable can be cleaned up and simplified. Remove unnecessary
definitions and clean-up the comment as well.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a6f2b71..5239d47 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -92,9 +92,7 @@
#define GPMC_CS_SIZE 0x30
#defineGPMC_BCH_SIZE 0x10
-#define GPMC_MEM_START 0x
#define GPMC_MEM_END 0x3FFF
-#define BOOT_ROM_SPACE 0x10/* 1MB */
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
@@ -790,13 +788,13 @@ static void gpmc_mem_exit(void)
static int gpmc_mem_init(void)
{
int cs, rc;
- unsigned long boot_rom_space = 0;
- /* never allocate the first page, to facilitate bug detection;
-* even if we didn't boot from ROM.
+ /*
+* The first 1MB of GPMC address space is typically mapped to
+* the internal ROM. Never allocate the first page, to
+* facilitate bug detection; even if we didn't boot from ROM.
*/
- boot_rom_space = BOOT_ROM_SPACE;
- gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
+ gpmc_mem_root.start = SZ_1M;
gpmc_mem_root.end = GPMC_MEM_END;
/* Reserve all regions that has been set up by bootloader */
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 17/18] ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping fails
When the GPMC driver is probed, we call gpmc_mem_init() to see which
chip-selects have already been configured and enabled by the boot-loader
and allocate space for them. If we fail to allocate space for one
chip-select, then we return failure from the probe and the GPMC driver
will not be available.
Rather than render the GPMC useless for all GPMC devices, if we fail to
allocate space for one chip-select print a warning and disable the
chip-select. This way other GPMC clients can still be used.
There is no downside to this approach, because all GPMC clients need to
request a chip-select before they can use the GPMC and on requesting a
chip-select, if memory has not already been reserved for the chip-select
then it will be.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5239d47..ee6601c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -785,9 +785,9 @@ static void gpmc_mem_exit(void)
}
-static int gpmc_mem_init(void)
+static void gpmc_mem_init(void)
{
- int cs, rc;
+ int cs;
/*
* The first 1MB of GPMC address space is typically mapped to
@@ -804,16 +804,12 @@ static int gpmc_mem_init(void)
if (!gpmc_cs_mem_enabled(cs))
continue;
gpmc_cs_get_memconf(cs, base, size);
- rc = gpmc_cs_insert_mem(cs, base, size);
- if (rc 0) {
- while (--cs = 0)
- if (gpmc_cs_mem_enabled(cs))
- gpmc_cs_delete_mem(cs);
- return rc;
+ if (gpmc_cs_insert_mem(cs, base, size)) {
+ pr_warn(%s: disabling cs %d mapped at 0x%x-0x%x\n,
+ __func__, cs, base, base + size);
+ gpmc_cs_disable_mem(cs);
}
}
-
- return 0;
}
static u32 gpmc_round_ps_to_sync_clk(u32 time_ps, u32 sync_clk)
@@ -1620,13 +1616,7 @@ static int gpmc_probe(struct platform_device *pdev)
dev_info(gpmc_dev, GPMC revision %d.%d\n, GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
- rc = gpmc_mem_init();
- if (rc 0) {
- clk_disable_unprepare(gpmc_l3_clk);
- clk_put(gpmc_l3_clk);
- dev_err(gpmc_dev, failed to reserve memory\n);
- return rc;
- }
+ gpmc_mem_init();
if (gpmc_setup_irq() 0)
dev_warn(gpmc_dev, gpmc_setup_irq failed\n);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 18/18] ARM: OMAP2+: return -ENODEV if GPMC child device creation fails
From: Javier Martinez Canillas javier.marti...@collabora.co.uk 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 Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/gpmc.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index ee6601c..d4ec5bb 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -1504,6 +1504,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.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
