Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
* Grant Likely grant.lik...@secretlab.ca [110719 14:29]: On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: * Grant Likely grant.lik...@secretlab.ca [110716 22:08]: The way I see it, you've got two options: 1) modify the of_platform_bus_create() to call some kind of of_platform_bus_create_omap() for devices that match ti,omap3-device or something. 2) Leave of_platform_bus_create(), and instead us a notifier to attach hwmod data to normal platform devices. omap_device_build() is actually pretty simple. It allocated a device, it attaches platform_data and hwmod pointers to the device and registers it. omap_device_register() is just a wrapper around platform_device_register(). My preference is definitely #2, but there is a wrinkle in this approach. Unfortunately omap_devices are not simply plain platform_devices with extra data attached, an omap_device actually embeds the platform_device inside it, which cannot be attached after the fact. I think I had talked with Kevin (cc'd) about eliminating the embedding, but I cannot remember clearly on this point. As long as platform_device remains embedded inside struct omap_device, #2 won't work. In either case, looking up the correct hwmod data should be easy for any device provided the omap code maintains a lookup table of compatible strings and base addresses of devices (much like auxdata). In fact, I'd be okay with extending auxdata to include OMAP fields if that would be easiest since the whole point of auxdata is to ease the transition to DT support. When a matching device is created, the hwmod pointer can easily be attached. This should work transparently for all omap devices, not just the i2c bus. Well we should be able to automgagically build the omap_device for each device tree entry. And then the device driver probe and runtime PM should be able to take care of the rest for the driver. And then there's no more driver specific platform init code needed ;) Right! That's the solution I'd like to see. How about if we just have the hwmod code call omap_device_build for each device tree entry? I think that is pretty much equivalent to suggestion #1 above, only I'm suggesting to take advantage of the infrastructure already available in driver/of/platform.c in the form of of_platform_populate(). The of_platform_bus_create_omap() function suggested above I assumed would directly call omap_device_build(). OK There are already hooks in the _populate call path to handle the creation of amba_devices. I have no problem doing the same thing for omap devices. OK Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Hi, On Thu, Jul 21, 2011 at 02:25:03PM +0530, Rajendra Nayak wrote: On 7/20/2011 3:04 AM, Grant Likely wrote: On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: * Grant Likelygrant.lik...@secretlab.ca [110716 22:08]: The way I see it, you've got two options: 1) modify the of_platform_bus_create() to call some kind of of_platform_bus_create_omap() for devices that match ti,omap3-device or something. 2) Leave of_platform_bus_create(), and instead us a notifier to attach hwmod data to normal platform devices. omap_device_build() is actually pretty simple. It allocated a device, it attaches platform_data and hwmod pointers to the device and registers it. omap_device_register() is just a wrapper around platform_device_register(). My preference is definitely #2, but there is a wrinkle in this approach. Unfortunately omap_devices are not simply plain platform_devices with extra data attached, an omap_device actually embeds the platform_device inside it, which cannot be attached after the fact. I think I had talked with Kevin (cc'd) about eliminating the embedding, but I cannot remember clearly on this point. As long as platform_device remains embedded inside struct omap_device, #2 won't work. In either case, looking up the correct hwmod data should be easy for any device provided the omap code maintains a lookup table of compatible strings and base addresses of devices (much like auxdata). In fact, I'd be okay with extending auxdata to include OMAP fields if that would be easiest since the whole point of auxdata is to ease the transition to DT support. When a matching device is created, the hwmod pointer can easily be attached. This should work transparently for all omap devices, not just the i2c bus. Well we should be able to automgagically build the omap_device for each device tree entry. And then the device driver probe and runtime PM should be able to take care of the rest for the driver. And then there's no more driver specific platform init code needed ;) Right! That's the solution I'd like to see. How about if we just have the hwmod code call omap_device_build for each device tree entry? I think that is pretty much equivalent to suggestion #1 above, only I'm suggesting to take advantage of the infrastructure already available in driver/of/platform.c in the form of of_platform_populate(). The of_platform_bus_create_omap() function suggested above I assumed would directly call omap_device_build(). In fact a lot of what omap_device_build() does today might not even be needed anymore. A lot of what it does is populate the platform_device structure by looking up the hwmod structs. Most of that information would now come from DT and hence all of that can be taken off from the hwmod structs. What will still be needed in hwmod is other data needed to runtime enable/idle the devices. That data however still needs to be linked with the platform_device's that DT would create which is what I guess could be done in something like a of_platform_bus_create_omap(). Paul/Benoit, do you guys agree we can get rid of some of the data from hwmod, whatever would now get passed in from DT, and keep only the PRCM/OCP related stuff for runtime handling? IMHO, all omap_hwmod_*_data.c files become pretty much useless if we move completely to DT. All hwmod data is passing today, can be passed via DT and in a similar Hierarchical manner. Now WRT omap_device_build() and PM, I think that's still necessary because it simplifies a lot PM handling. But the data files themselves can easily be purged from kernel and converted into DT. -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Hi, On Thu, Jul 21, 2011 at 03:03:24PM +0530, Rajendra Nayak wrote: IMHO, all omap_hwmod_*_data.c files become pretty much useless if we move completely to DT. All hwmod data is passing today, can be passed via DT and in a similar Hierarchical manner. Would the data representation be equally readable? That's one of the problems I faced when I started looking at it initially trying to move a lot of these structures. not to my eyes, heh. I'm too used to C, though. -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] Add character literal parsing in bytestrings
Well, to be honest I'd love to have this syntax several years ago :). [...] Ok, here's what I suggest. For now, can you create a patch which recognizes the character construct syntax in the lexer (including escapes), and allows its use in cell context. That won't actually do what you want, but it gets a fair chunk of the code in a testable, upstreamable form without making syntax changes I'm uncomfortable with. While we're getting that merged we can debate which/how to proceed with either variable size cell syntax or allowing the character literals in bytestring context. Is it worth investigating any of the work I did down this line several years ago? It's all still in the test branch if so. jdl ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] of/irq: use of_find_property() to check for interrupt-controller
The interrupt-controller property is used as a marker with no value.
This check should check for existence of the property, rather than for
a non-NULL property value.
On the OLPC XO-1.5, this marker property exists in the correct place
but was not being picked up due to having no value. Using
of_find_property() avoids this issue.
Signed-off-by: Daniel Drake d...@laptop.org
---
drivers/of/irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 9f689f1..f86cc43 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -155,7 +155,7 @@ int of_irq_map_raw(struct device_node *parent, const __be32
*intspec,
/* Now check if cursor is an interrupt-controller and if it is
* then we are done
*/
- if (of_get_property(ipar, interrupt-controller, NULL) !=
+ if (of_find_property(ipar, interrupt-controller, NULL) !=
NULL) {
pr_debug( - got it !\n);
for (i = 0; i intsize; i++)
--
1.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] gpio-vx855: add device tree binding
This is needed to enable the HDD LED on the OLPC XO-1.5 laptop, enabled through devicetree and the gpio-leds driver. Signed-off-by: Daniel Drake d...@laptop.org --- .../devicetree/bindings/gpio/gpio_vx855.txt|8 drivers/gpio/gpio-vx855.c |5 + 2 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio_vx855.txt Grant, please review the chosen scheme (based on gpio_nvidia). Is the via,vx855-gpio compatible tag OK? I made it up. diff --git a/Documentation/devicetree/bindings/gpio/gpio_vx855.txt b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt new file mode 100644 index 000..93c0747 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt @@ -0,0 +1,8 @@ +VIA VX855 GPIO controller + +Required properties: +- compatible : via,vx855-gpio +- #gpio-cells : Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted) +- gpio-controller : Marks the device node as a GPIO controller. diff --git a/drivers/gpio/gpio-vx855.c b/drivers/gpio/gpio-vx855.c index ef5aabd..5b7e9ba 100644 --- a/drivers/gpio/gpio-vx855.c +++ b/drivers/gpio/gpio-vx855.c @@ -31,6 +31,7 @@ #include linux/platform_device.h #include linux/pci.h #include linux/io.h +#include linux/of.h #define MODULE_NAME vx855_gpio @@ -216,6 +217,10 @@ static void vx855gpio_gpio_setup(struct vx855_gpio *vg) c-ngpio = NR_VX855_GP; c-can_sleep = 0; c-names = vx855gpio_names; + +#ifdef CONFIG_OF_GPIO + c-of_node = of_find_compatible_node(NULL, NULL, via,vx855-gpio); +#endif } /* This platform device is ordinarily registered by the vx855 mfd driver */ -- 1.7.6 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Same parts of DT being probed twice
Hi,
We're working on enabling the HDD LED on the XO-1.5 laptop using
gpio-leds and its automatic interaction with the device tree. I have
it working locally, but there is something not quite right.
We have modified the device tree to add /pci/isa/gpios
gpios then has a child gpio-leds which has a child hdd as
described in Documentation/devicetree/bindings/gpio/gpio-leds.txt
This means that we must extend the matches list passed to
of_platform_bus_probe() in arch/x86/platform/olpc/olpc_dt.c so that
the search goes deep enough into the tree to find the gpio-leds
element and create a device for it. Specifically we must add:
{ .compatible = pci },
{ .compatible = isa },
{ .compatible = via,vx855-gpio },
{ .compatible = gpio-leds },
This works, but it causes huge duplication of the whole pci and isa
trees in /sys/devices. These devices were already created because
arch/x86/kernel/devicetree.c unconditionally calls
of_platform_bus_probe() for pci and isa devices (see add_bus_probe()
and ce4100_ids), but not for vx855-gpio and gpio-leds.
Whats the best way to solve this?
Thanks,
Daniel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH] i2c: tegra: Fix compile when !CONFIG_OF
Grant Likely wrote at Wednesday, July 13, 2011 4:48 PM: On Thu, Jul 14, 2011 at 5:36 AM, Stephen Warren swar...@nvidia.com wrote: When !CONFIG_OF, linux/of.h doesn't prototype of_get_property(), which causes i2c-tegra.c to fail to compile. Make the references to this function conditional to solve this. Signed-off-by: Stephen Warren swar...@nvidia.com ... Acked-by: Grant Likely grant.lik...@secretlab.ca Ben, please can this patch be applied in time for 3.1? Currently, the linux-next and next-i2c tree won't compile on Tegra without CONFIG_OF enabled. Also, the other patch I posted titled i2c: Tegra: Add of_match_table is required for Tegra I2C Device Tree support to be useful. Can that go into 3.1 as well? Thanks very much! -- nvpublic ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ASoC: sgtl5000: add device tree probe support
It adds device tree probe support for sgtl5000 driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Zeng Zhaoming zhaoming.z...@freescale.com
Cc: Liam Girdwood l...@ti.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
---
.../bindings/sound/soc/codecs/fsl-sgtl5000.txt | 11 +++
sound/soc/codecs/sgtl5000.c|8
2 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt
diff --git
a/Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt
b/Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt
new file mode 100644
index 000..2c3cd41
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt
@@ -0,0 +1,11 @@
+* Freescale SGTL5000 Stereo Codec
+
+Required properties:
+- compatible : fsl,sgtl5000.
+
+Example:
+
+codec: sgtl5000@0a {
+ compatible = fsl,sgtl5000;
+ reg = 0x0a;
+};
diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index 76258f2..cf6eea8 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -20,6 +20,7 @@
#include linux/regulator/driver.h
#include linux/regulator/machine.h
#include linux/regulator/consumer.h
+#include linux/of_device.h
#include sound/core.h
#include sound/tlv.h
#include sound/pcm.h
@@ -1494,10 +1495,17 @@ static const struct i2c_device_id sgtl5000_id[] = {
MODULE_DEVICE_TABLE(i2c, sgtl5000_id);
+static const struct of_device_id sgtl5000_dt_ids[] = {
+ { .compatible = fsl,sgtl5000, },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(i2c, sgtl5000_dt_ids);
+
static struct i2c_driver sgtl5000_i2c_driver = {
.driver = {
.name = sgtl5000,
.owner = THIS_MODULE,
+ .of_match_table = sgtl5000_dt_ids,
},
.probe = sgtl5000_i2c_probe,
.remove = __devexit_p(sgtl5000_i2c_remove),
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC][PATCH] gpio: Add device tree support for exynos4
Exynos4 GPIO helper functions registers each bank of GPIO as a gpio chip.
For each gpio chip being registered, this patch finds a matching node
in device tree and attaches the node pointer to the gpio chip. The match
is based on the compatible property of the node.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
Each gpio controller is listed as below in the dts file.
gpa0: gpio-controller@1140 {
compatible = samsung,exynos4-gpio-gpa0,samsung,exynos4-gpio;
#gpio-cells = 2;
gpio-controller;
};
gpa1: gpio-controller@11400020 {
compatible = samsung,exynos4-gpio-gpa1,samsung,exynos4-gpio;
#gpio-cells = 2;
gpio-controller;
};
gpb: gpio-controller@11400040 {
compatible = samsung,exynos4-gpio-gpb,samsung,exynos4-gpio;
#gpio-cells = 2;
gpio-controller;
};
and many more (gpc, gpd, , gpx)
For each linux domain gpio chip registered by the exynos4 gpio helpers,
a matching device node is found from the device tree by matching the
compatible property.
drivers/gpio/gpio-exynos4.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-exynos4.c b/drivers/gpio/gpio-exynos4.c
index 9029835..c727bf1 100644
--- a/drivers/gpio/gpio-exynos4.c
+++ b/drivers/gpio/gpio-exynos4.c
@@ -14,6 +14,10 @@
#include linux/irq.h
#include linux/io.h
#include linux/gpio.h
+#ifdef CONFIG_OF
+#include linux/of.h
+#include linux/slab.h
+#endif
#include mach/map.h
@@ -321,6 +325,29 @@ static struct s3c_gpio_chip exynos4_gpio_part3_4bit[] = {
},
};
+#ifdef CONFIG_OF
+static __init void exynos4_gpiolib_attach_ofnode(struct gpio_chip *gc)
+{
+ const char exynos4_gpio_compat_base[] = samsung,exynos4-gpio-;
+ char *exynos4_gpio_compat;
+
+ exynos4_gpio_compat = kzalloc(strlen(exynos4_gpio_compat_base) +
+ strlen(gc-label), GFP_KERNEL);
+ if (!exynos4_gpio_compat)
+ return;
+
+ strcpy(exynos4_gpio_compat, exynos4_gpio_compat_base);
+ strcat(exynos4_gpio_compat, gc-label);
+ gc-of_node = of_find_compatible_node(NULL, NULL, exynos4_gpio_compat);
+ kfree(exynos4_gpio_compat);
+}
+#else
+static __init void exynos4_gpiolib_attach_ofnode(struct gpio_chip *chip)
+{
+ return;
+}
+#endif
+
static __init int exynos4_gpiolib_init(void)
{
struct s3c_gpio_chip *chip;
@@ -341,6 +368,7 @@ static __init int exynos4_gpiolib_init(void)
}
if (chip-base == NULL)
chip-base = S5P_VA_GPIO1 + (i) * 0x20;
+ exynos4_gpiolib_attach_ofnode(chip-chip);
}
samsung_gpiolib_add_4bit_chips(exynos4_gpio_part1_4bit, nr_chips);
@@ -358,6 +386,7 @@ static __init int exynos4_gpiolib_init(void)
}
if (chip-base == NULL)
chip-base = S5P_VA_GPIO2 + (i) * 0x20;
+ exynos4_gpiolib_attach_ofnode(chip-chip);
}
samsung_gpiolib_add_4bit_chips(exynos4_gpio_part2_4bit, nr_chips);
@@ -375,6 +404,7 @@ static __init int exynos4_gpiolib_init(void)
}
if (chip-base == NULL)
chip-base = S5P_VA_GPIO3 + (i) * 0x20;
+ exynos4_gpiolib_attach_ofnode(chip-chip);
}
samsung_gpiolib_add_4bit_chips(exynos4_gpio_part3_4bit, nr_chips);
--
1.6.6.rc2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Same parts of DT being probed twice
Daniel,
On 07/21/2011 09:46 AM, Daniel Drake wrote:
Hi,
We're working on enabling the HDD LED on the XO-1.5 laptop using
gpio-leds and its automatic interaction with the device tree. I have
it working locally, but there is something not quite right.
We have modified the device tree to add /pci/isa/gpios
gpios then has a child gpio-leds which has a child hdd as
described in Documentation/devicetree/bindings/gpio/gpio-leds.txt
This means that we must extend the matches list passed to
of_platform_bus_probe() in arch/x86/platform/olpc/olpc_dt.c so that
the search goes deep enough into the tree to find the gpio-leds
element and create a device for it. Specifically we must add:
{ .compatible = pci },
{ .compatible = isa },
{ .compatible = via,vx855-gpio },
{ .compatible = gpio-leds },
This works, but it causes huge duplication of the whole pci and isa
trees in /sys/devices. These devices were already created because
arch/x86/kernel/devicetree.c unconditionally calls
of_platform_bus_probe() for pci and isa devices (see add_bus_probe()
and ce4100_ids), but not for vx855-gpio and gpio-leds.
Whats the best way to solve this?
I think you want to move up the gpio-leds to top level of the dts. The
leds are part of your board not part of the gpio controller, so they
should be separate. On the other hand, i2c slaves are typically under
the controller node, so perhaps gpio controller drivers need to scan for
sub devices like leds.
Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3 v4] dt: tegra20: Add ehci overrides to Seaboard.
From: Andrew Chew ac...@nvidia.com
Seaboard has different values for some of the utmi properties.
Signed-off-by: Andrew Chew ac...@nvidia.com
Acked-by: Stephen Warren swar...@nvidia.com
Acked-by: Olof Johansson o...@lixom.net
---
arch/arm/boot/dts/tegra-seaboard.dts | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra-seaboard.dts
b/arch/arm/boot/dts/tegra-seaboard.dts
index 5a99b4c..adc000a 100644
--- a/arch/arm/boot/dts/tegra-seaboard.dts
+++ b/arch/arm/boot/dts/tegra-seaboard.dts
@@ -31,4 +31,21 @@
sdhci@c8000600 {
status = ok;
};
+
+ ehci@c500 {
+ power-down-on-bus-suspend;
+ nvidia,hssync-start-delay = 0 ;
+ nvidia,xcvr-setup = 15 ;
+ };
+
+ ehci@c5004000 {
+ power-down-on-bus-suspend;
+ phy-type = ulpi;
+ };
+
+ ehci@c5008000 {
+ power-down-on-bus-suspend;
+ nvidia,hssync-start-delay = 0 ;
+ nvidia,xcvr-setup = 8 ;
+ };
};
--
1.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3 v4] usb: tegra20-ehci: Add devicetree support.
From: Andrew Chew ac...@nvidia.com
Add code to try to get platform data information (register base, irq,
modes, various tuning parameters) from device tree, if not present in board
files.
Signed-off-by: Andrew Chew ac...@nvidia.com
Acked-by: Stephen Warren swar...@nvidia.com
---
Applied Olof Johansson's comments:
- Use direct assignment when copying default config structs.
- Use __devinitdata for static default config structs.
- Don't compile the default config structs if CONFIG_OF is disabled, to avoid
a warning.
.../devicetree/bindings/usb/tegra20-ehci.txt | 27 +++
drivers/usb/host/ehci-tegra.c | 189
2 files changed, 216 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/tegra20-ehci.txt
diff --git a/Documentation/devicetree/bindings/usb/tegra20-ehci.txt
b/Documentation/devicetree/bindings/usb/tegra20-ehci.txt
new file mode 100644
index 000..315ea6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/tegra20-ehci.txt
@@ -0,0 +1,27 @@
+NVIDIA Tegra20 SOC USB controllers
+
+The device node for a USB controller that is part of a Tegra20
+SOC is as described in the document Open Firmware Recommended
+Practice: Universal Serial Bus with the following modifications
+and additions:
+
+Required properties:
+ - compatible: Should be nvidia,tegra20-ehci.
+ - phy-type: Should be one of utmi or ulpi. Defaults to utmi.
+ - dr-mode: Should be one of peripheral, host, or otg. Defaults to host.
+ - power-down-on-bus-suspend: For host mode only. If present, then
+ the USB phy will power down when the host is suspended.
+
+Required properties for phy-type = utmi. These values are derived from
+characterization by system engineering.
+ - nvidia,hssync-start-delay: Defaults to 9.
+ - nvidia,idle-wait-delay: Defaults to 17.
+ - nvidia,elastic-limit: Defaults to 16.
+ - nvidia,term-range-adj: Defaults to 6.
+ - nvidia,xcvr-setup: Defaults to 9.
+ - nvidia,xcvr-lsfslew: Defaults to 2.
+ - nvidia,xcvr-lsrslew: Defaults to 2.
+
+Required properties for phy-type = ulpi:
+ - reset-gpio: The GPIO used to drive reset. Defaults to 169.
+ - clk: Defaults to cdev2.
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 02b2bfd..d7295eb 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -21,10 +21,34 @@
#include linux/platform_data/tegra_usb.h
#include linux/irq.h
#include linux/usb/otg.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/of_platform.h
+
#include mach/usb_phy.h
#define TEGRA_USB_DMA_ALIGN 32
+static u64 tegra_ehci_dmamask = DMA_BIT_MASK(TEGRA_USB_DMA_ALIGN);
+
+#if defined(CONFIG_OF)
+static struct tegra_utmip_config utmi_default __devinitdata = {
+ .hssync_start_delay = 9,
+ .idle_wait_delay = 17,
+ .elastic_limit = 16,
+ .term_range_adj = 6,
+ .xcvr_setup = 9,
+ .xcvr_lsfslew = 2,
+ .xcvr_lsrslew = 2,
+};
+
+static struct tegra_ulpi_config ulpi_default __devinitdata = {
+ .reset_gpio = 169,
+ .clk = cdev2,
+};
+#endif
+
struct tegra_ehci_hcd {
struct ehci_hcd *ehci;
struct tegra_usb_phy *phy;
@@ -574,9 +598,155 @@ static const struct hc_driver tegra_ehci_hc_driver = {
.port_handed_over = ehci_port_handed_over,
};
+#if defined(CONFIG_OF)
+static int tegra_ehci_parse_dt_node_utmi(struct device_node *dn,
+struct platform_device *pdev,
+struct tegra_ehci_platform_data *pdata)
+{
+ struct device *dev = pdev-dev;
+ struct tegra_utmip_config *phy_config;
+ u32 val;
+
+ phy_config = devm_kzalloc(dev, sizeof(struct tegra_utmip_config),
+ GFP_KERNEL);
+ if (!phy_config)
+ return -ENOMEM;
+
+ /* Copy default values. */
+ *phy_config = utmi_default;
+
+ /* Values can be overridden from their defaults. */
+ if (of_property_read_u32(dn, nvidia,hssync-start-delay, val) == 0)
+ phy_config-hssync_start_delay = val;
+
+ if (of_property_read_u32(dn, nvidia,elastic-limit, val) == 0)
+ phy_config-elastic_limit = val;
+
+ if (of_property_read_u32(dn, nvidia,idle-wait-delay, val) == 0)
+ phy_config-idle_wait_delay = val;
+
+ if (of_property_read_u32(dn, nvidia,term-range-adj, val) == 0)
+ phy_config-term_range_adj = val;
+
+ if (of_property_read_u32(dn, nvidia,xcvr-setup, val) == 0)
+ phy_config-xcvr_setup = val;
+
+ if (of_property_read_u32(dn, nvidia,xcvr-lsfslew, val) == 0)
+ phy_config-xcvr_lsfslew = val;
+
+ if (of_property_read_u32(dn, nvidia,xcvr-lsrslew, val) == 0)
+ phy_config-xcvr_lsrslew = val;
+
+ pdata-phy_config = phy_config;
+
+ return 0;
+}
+
+static int tegra_ehci_parse_dt_node_ulpi(struct
[PATCH 2/3 v4] dt: tegra20: Add ehci host controller nodes.
From: Andrew Chew ac...@nvidia.com
These values were derived from various headers in arch/arm/mach-tegra.
Signed-off-by: Andrew Chew ac...@nvidia.com
Acked-by: Stephen Warren swar...@nvidia.com
Acked-by: Olof Johansson o...@lixom.net
---
arch/arm/boot/dts/tegra20.dtsi | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 83fedf3..d51f887 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -160,5 +160,23 @@
interrupts = 63 ;
status = disabled;
};
+
+ ehci@c500 {
+ compatible = nvidia,tegra20-ehci;
+ reg = 0xc500 0x4000;
+ interrupts = 52 ;
+ };
+
+ ehci@c5004000 {
+ compatible = nvidia,tegra20-ehci;
+ reg = 0xc5004000 0x4000;
+ interrupts = 53 ;
+ };
+
+ ehci@c5008000 {
+ compatible = nvidia,tegra20-ehci;
+ reg = 0xc5008000 0x4000;
+ interrupts = 129 ;
+ };
};
--
1.7.6
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3 v4] usb: tegra20-ehci: Add devicetree support.
On Thu, Jul 21, 2011 at 2:17 PM, ac...@nvidia.com wrote: From: Andrew Chew ac...@nvidia.com Add code to try to get platform data information (register base, irq, modes, various tuning parameters) from device tree, if not present in board files. Signed-off-by: Andrew Chew ac...@nvidia.com Acked-by: Stephen Warren swar...@nvidia.com Acked-by: Olof Johansson o...@lixom.net -Olof ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 1/3 v4] usb: tegra20-ehci: Add devicetree support.
On 7/21/11 2:17 PM, Andrew Chew ac...@nvidia.com wrote: From: Andrew Chew ac...@nvidia.com Add code to try to get platform data information (register base, irq, modes, various tuning parameters) from device tree, if not present in board files. This patch no longer gets the register base or irq, just the modes and tuning parameters. - Dan Willemsen You're totally right, Dan. Grant, would you mind fixing the commit message, if nothing else comes up? Or would you prefer I send a new patchset out? I suppose the commit message should just read: Add code to try to get platform data information (modes, various tuning parameters) from device tree, if not present in board files. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RESEND v3 0/2] Add device tree probe support for tty/serial/imx
On Thu, Jul 07, 2011 at 01:20:18AM +0800, Shawn Guo wrote: The first patch removes the use of cpu_is_mx1(). The second patch adds device tree probe with a dependency on the following patch. http://article.gmane.org/gmane.linux.drivers.devicetree/6128 Changes with resend: * Fix typo * Change a few macros to inline functions Changes since v2: * Not use generic naming imx-uart, instead use specific soc name to show uart type compatibility (Sascha's suggestion) Changes since v1: * Address review comments given by Grant and Uwe Shawn Guo (2): serial/imx: get rid of the uses of cpu_is_mx1() serial/imx: add device tree probe support .../bindings/tty/serial/fsl-imx-uart.txt | 19 +++ arch/arm/mach-imx/clock-imx1.c |6 +- arch/arm/mach-imx/clock-imx21.c|8 +- arch/arm/mach-imx/clock-imx25.c| 11 +- arch/arm/mach-imx/clock-imx27.c| 13 +- arch/arm/mach-imx/clock-imx31.c| 11 +- arch/arm/mach-imx/clock-imx35.c|7 +- arch/arm/mach-mx5/clock-mx51-mx53.c| 18 ++- arch/arm/plat-mxc/devices/platform-imx-uart.c |7 +- drivers/tty/serial/imx.c | 167 +--- 10 files changed, 205 insertions(+), 62 deletions(-) To avoid conflict, will repost the series when Grant's devicetree/next and i.mx tree get merged on mainline in the coming merge window. Alan, hopefully, you can give your ack then, so that Sascha can pick it up. -- Regards, Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] Add device tree probe for i2c-imx driver
Hi Ben, Any comments, or it's been good for you to queue them for v3.1 window? Regards, Shawn On Fri, Jul 15, 2011 at 12:03:43AM +0800, Shawn Guo wrote: The first patch removes unused init/exit hooks from platform data, and the second one actually adds the actual device tree probe support. Shawn Guo (2): i2c/imx: remove init/exit hooks from platform data i2c/imx: add device tree probe support .../devicetree/bindings/i2c/fsl-imx-i2c.txt| 25 +++ arch/arm/plat-mxc/include/mach/i2c.h |4 -- drivers/i2c/busses/i2c-imx.c | 46 +-- 3 files changed, 47 insertions(+), 28 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC/PATCH 7/7] WIP: HACK/RFC: omap_device: begin to decouple platform_device from omap_device
On Thu, Jul 21, 2011 at 5:52 PM, Kevin Hilman khil...@ti.com wrote:
Rather than embedding a struct platform_device inside a struct
omap_device, decouple them, leaving only a pointer to the
platform_device inside the omap_device.
This patch uses devres to allocate and attach the omap_device to the
struct device, so finding an omap_device from a struct device means
using devres_find(), and the to_omap_device() helper function was
modified accordingly.
RFC/Hack alert:
Currently the driver core (drivers/base/dd.c) doesn't expect any
devres resources to exist before the driver's -probe() is called. In
this patch, I just comment out the warning, but we'll need to
understand why that limitation exists, and if it's a real limitation.
A first glance suggests that it's not really needed. If this is a
true limitation, we'll need to find some way other than devres to
attach an omap_device to a struct device.
The devres lifetime is scoped to binding a driver; it is added at
probe time and removed at release. For this use-case, it needs to be
scoped to the lifetime of the struct device. To make this work,
you'll need to add a flag to devres so that the driver core can
differentiate between driver-scoped and device-scoped lifetimes (which
I do think is the right thing to do). Without fixing this, the driver
core will remove all the devres when a driver gets unbound, or if a
.probe() hook fails, which completely breaks the driver model.
g.
On OMAP, we will need an omap_device attached to a struct device
before probe because device HW may be disabled in probe and drivers
are expected to use runtime PM in -probe() to activate the hardware
before access. Because the runtime PM API calls use omap_device (via
our PM domain layer), we need omap_device attached to a
platform_device before probe.
---
arch/arm/mach-omap2/opp.c | 2 +-
arch/arm/plat-omap/include/plat/omap_device.h | 4 +-
arch/arm/plat-omap/omap_device.c | 78
+++--
drivers/base/dd.c | 2 +-
4 files changed, 50 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index ab8b35b..9262a6b 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -69,7 +69,7 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
opp_def-hwmod_name, i);
return -EINVAL;
}
- dev = oh-od-pdev.dev;
+ dev = oh-od-pdev-dev;
r = opp_add(dev, opp_def-freq, opp_def-u_volt);
if (r) {
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 7a3ec4f..6bd4f6f 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -64,7 +64,7 @@ extern struct device omap_device_parent;
*
*/
struct omap_device {
- struct platform_device pdev;
+ struct platform_device *pdev;
struct omap_hwmod **hwmods;
struct omap_device_pm_latency *pm_lats;
u32 dev_wakeup_lat;
@@ -142,6 +142,6 @@ struct omap_device_pm_latency {
#define OMAP_DEVICE_LATENCY_AUTO_ADJUST BIT(1)
/* Get omap_device pointer from platform_device pointer */
-#define to_omap_device(x) container_of((x), struct omap_device, pdev)
+struct omap_device *to_omap_device(struct platform_device *pdev);
#endif
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index c420b94..52ce013 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -117,7 +117,7 @@ static int _omap_device_activate(struct omap_device *od,
u8 ignore_lat)
{
struct timespec a, b, c;
- dev_dbg(od-pdev.dev, omap_device: activating\n);
+ dev_dbg(od-pdev-dev, omap_device: activating\n);
while (od-pm_lat_level 0) {
struct omap_device_pm_latency *odpl;
@@ -141,7 +141,7 @@ static int _omap_device_activate(struct omap_device *od,
u8 ignore_lat)
c = timespec_sub(b, a);
act_lat = timespec_to_ns(c);
- dev_dbg(od-pdev.dev,
+ dev_dbg(od-pdev-dev,
omap_device: pm_lat %d: activate: elapsed time
%llu nsec\n, od-pm_lat_level, act_lat);
@@ -149,12 +149,12 @@ static int _omap_device_activate(struct omap_device
*od, u8 ignore_lat)
odpl-activate_lat_worst = act_lat;
if (odpl-flags OMAP_DEVICE_LATENCY_AUTO_ADJUST) {
odpl-activate_lat = act_lat;
- dev_warn(od-pdev.dev,
+ dev_warn(od-pdev-dev,
new worst case activate latency
Re: [PATCH v2 0/3] Add device tree probe support for imx fec driver
From: Shawn Guo shawn@freescale.com Date: Fri, 22 Jul 2011 10:08:19 +0800 David, I assume I can add your acks to all 3 patches, otherwise please let me know. Yes, you can. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
