[PATCH v2] net/smsc911x: add device tree probe support
It adds device tree probe support for smsc911x driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Steve Glendinning steve.glendinn...@smsc.com
Cc: David S. Miller da...@davemloft.net
---
Changes since v1:
* Instead of getting irq line from gpio number, it use irq domain
to keep platform_get_resource(IORESOURCE_IRQ) works for dt too.
* Use 'lan9115' the first model that smsc911x supports in the match
table
* Use reg-shift and reg-io-width which already used in of_serial for
shift and access size binding
Documentation/devicetree/bindings/net/smsc911x.txt | 38 +
drivers/net/smsc911x.c | 85 +---
2 files changed, 112 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/smsc911x.txt
diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt
b/Documentation/devicetree/bindings/net/smsc911x.txt
new file mode 100644
index 000..271c454
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc911x.txt
@@ -0,0 +1,38 @@
+* Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
+
+Required properties:
+- compatible : Should be smsc,lanmodel, smsc,lan9115
+- reg : Address and length of the io space for SMSC LAN
+- interrupts : Should contain SMSC LAN interrupt line
+- interrupt-parent : Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- phy-mode : String, operation mode of the PHY interface.
+ Supported values are: mii, gmii, sgmii, tbi, rmii,
+ rgmii, rgmii-id, rgmii-rxid, rgmii-txid, rtbi, smii.
+
+Optional properties:
+- reg-shift : Specify the quantity to shift the register offsets by
+- reg-io-width : Specify the size (in bytes) of the IO accesses that
+ should be performed on the device. Valid value for SMSC LAN is
+ 2 or 4. If it's omitted or invalid, the size would be 2.
+- smsc,irq-active-high : Indicates the IRQ polarity is active-low
+- smsc,irq-push-pull : Indicates the IRQ type is push-pull
+- smsc,force-internal-phy : Forces SMSC LAN controller to use
+ internal PHY
+- smsc,force-external-phy : Forces SMSC LAN controller to use
+ external PHY
+- smsc,save-mac-address : Indicates that mac address needs to be saved
+ before resetting the controller
+- local-mac-address : 6 bytes, mac address
+
+Examples:
+
+lan9220@f400 {
+ compatible = smsc,lan9220, smsc,lan9115;
+ reg = 0xf400 0x200;
+ phy-mode = mii;
+ interrupt-parent = gpio1;
+ interrupts = 31;
+ reg-io-width = 4;
+ smsc,irq-push-pull;
+};
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
index b9016a3..75c08a5 100644
--- a/drivers/net/smsc911x.c
+++ b/drivers/net/smsc911x.c
@@ -53,6 +53,10 @@
#include linux/phy.h
#include linux/smsc911x.h
#include linux/device.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_gpio.h
+#include linux/of_net.h
#include smsc911x.h
#define SMSC_CHIPNAME smsc911x
@@ -2095,8 +2099,58 @@ static const struct smsc911x_ops shifted_smsc911x_ops = {
.tx_writefifo = smsc911x_tx_writefifo_shift,
};
+#ifdef CONFIG_OF
+static int __devinit smsc911x_probe_config_dt(
+ struct smsc911x_platform_config *config,
+ struct device_node *np)
+{
+ const char *mac;
+ u32 width = 0;
+
+ if (!np)
+ return -ENODEV;
+
+ config-phy_interface = of_get_phy_mode(np);
+
+ mac = of_get_mac_address(np);
+ if (mac)
+ memcpy(config-mac, mac, ETH_ALEN);
+
+ of_property_read_u32(np, reg-shift, config-shift);
+
+ of_property_read_u32(np, reg-io-width, width);
+ if (width == 4)
+ config-flags |= SMSC911X_USE_32BIT;
+
+ if (of_get_property(np, smsc,irq-active-high, NULL))
+ config-irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH;
+
+ if (of_get_property(np, smsc,irq-push-pull, NULL))
+ config-irq_type = SMSC911X_IRQ_TYPE_PUSH_PULL;
+
+ if (of_get_property(np, smsc,force-internal-phy, NULL))
+ config-flags |= SMSC911X_FORCE_INTERNAL_PHY;
+
+ if (of_get_property(np, smsc,force-external-phy, NULL))
+ config-flags |= SMSC911X_FORCE_EXTERNAL_PHY;
+
+ if (of_get_property(np, smsc,save-mac-address, NULL))
+ config-flags |= SMSC911X_SAVE_MAC_ADDRESS;
+
+ return 0;
+}
+#else
+static inline int smsc911x_probe_config_dt(
+ struct smsc911x_platform_config *config,
+ struct device_node *np)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_OF */
+
static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
{
+ struct device_node *np = pdev-dev.of_node;
struct net_device *dev;
struct smsc911x_data *pdata;
struct smsc911x_platform_config *config = pdev-dev.platform_data;
@@
[PATCHv3] gpio-generic: add support for device tree probing
This patch adds support for gpio-generic controllers to be
instantiated from the device tree. The binding supports devices with
multiple banks.
v3:
- Remove extraneous of_node_{get,put}().
- Rename basic-mmio-gpio,reg-io-width to reg-io-width.
- Use vendor specific compatible values for now.
- Only add child banks, and allocate banks as an array.
- Remove bgpio_init_info() and populate bgpio_chip directly.
- Rename properties to gpio-generic,* to match the driver name.
v2:
- Added more detail to the binding.
- Added CONFIG_OF guards.
- Use regoffset-* properties for each register in each bank.
relative to the registers of the controller.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Anton Vorontsov cbouatmai...@gmail.com
Signed-off-by: Jamie Iles ja...@jamieiles.com
---
.../devicetree/bindings/gpio/gpio-generic.txt | 85 ++
drivers/gpio/gpio-generic.c| 174 ++--
2 files changed, 245 insertions(+), 14 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-generic.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-generic.txt
b/Documentation/devicetree/bindings/gpio/gpio-generic.txt
new file mode 100644
index 000..91c9441
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-generic.txt
@@ -0,0 +1,85 @@
+Generic MMIO GPIO controller
+
+This binding allows lots of common GPIO controllers to use a generic GPIO
+driver. The top level GPIO node describes the registers for the controller
+and high level properties such as endianness and register width. Each bank in
+the controller is represented as a child node.
+
+Required properties:
+- compatible : Must be one of:
+ - snps,dw-apb-gpio : Synopsys DesignWare APB GPIO controller
+- reg : The register window for the GPIO device. If the device has multiple
+ banks then this window should cover all of the banks.
+- gpio-generic,reg-io-width : The width of the registers in the controller
+ (in bytes).
+- #address-cells : should be set to 1.
+- #size-cells : should be set to 0. The addresses of the child nodes are the
+ bank numbers and the child nodes themselves represent the banks in the
+ controller.
+
+Optional properties:
+- gpio-generic,big-endian : the registers are in big-endian byte ordering.
+ If present then the first gpio in the controller occupies the MSB for
+ each register.
+
+Generic MMIO GPIO controller bank
+
+Required properties:
+- compatible : Must be one of:
+ - snps,dw-apb-gpio-bank : Synopsys DesignWare APB GPIO controller bank
+- gpio-controller : Marks the node as a GPIO controller.
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell encodes optional flags (currently unused).
+- gpio-generic,nr-gpio : The number of GPIO pins in the bank.
+- regoffset-dat : The offset from the beginning of the controller for the
+ dat register for this bank. This register is read to get the value of the
+ GPIO pins, and if there is no regoffset-set property then it is also used to
+ set the value of the pins.
+
+Optional properties:
+- regoffset-set : The offset from the beginning of the controller for the
+ set register for this bank. If present then the GPIO values are set
+ through this register (writing a 1 bit sets the GPIO high). If there is no
+ regoffset-clr property then writing a 0 bit to this register will set the
+ pin to a low value.
+- regoffset-clr : The offset from the beginning of the controller for the
+ clr register for this bank. Writing a 1 bit to this register will set the
+ GPIO to a low output value.
+- regoffset-dirout : The offset from the beginning of the controller for the
+ dirout register for this bank. Writing a 1 bit to this register sets the
+ pin to be an output pin, writing a zero sets the pin to be an input.
+- regoffset-dirin : The offset from the beginning of the controller for the
+ dirin register for this bank. Writing a 1 bit to this register sets the
+ pin to be an input pin, writing a zero sets the pin to be an output.
+
+Examples:
+
+gpio: gpio@2 {
+ compatible = snps,dw-apb-gpio;
+ reg = 0x2 0x1000;
+ #address-cells = 1;
+ #size-cells = 0;
+ gpio-generic,reg-io-width = 4;
+
+ banka: gpio-controller@0 {
+ compatible = snps,dw-apb-gpio;
+ gpio-controller;
+ #gpio-cells = 2;
+ gpio-generic,nr-gpio = 8;
+
+ regoffset-dat = 0x50;
+ regoffset-set = 0x00;
+ regoffset-dirout = 0x04;
+ };
+
+ bankb: gpio-controller@1 {
+ compatible = snps,dw-apb-gpio;
+ gpio-controller;
+ #gpio-cells = 2;
+ gpio-generic,nr-gpio = 16;
+
+ regoffset-dat = 0x54;
+ regoffset-set = 0x0c;
+ regoffset-dirout = 0x10;
+ };
+};
diff --git
[PATCHv2] mtd: gpio-nand: add device tree bindings
Add device tree bindings so that the gpio-nand driver may be
instantiated from the device tree. This also allows the partitions
to be specified in the device tree.
v2:
- add CONFIG_OF guards for non-dt platforms
- compatible becomes gpio-control-nand
- clarify some binding details
Cc: David Woodhouse dw...@infradead.org
Cc: Artem Bityutskiy dedeki...@gmail.com
Signed-off-by: Jamie Iles ja...@jamieiles.com
---
.../devicetree/bindings/mtd/gpio-control-nand.txt | 40
drivers/mtd/nand/gpio.c| 100 ++--
2 files changed, 132 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/gpio-control-nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/gpio-control-nand.txt
b/Documentation/devicetree/bindings/mtd/gpio-control-nand.txt
new file mode 100644
index 000..2dc52de
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpio-control-nand.txt
@@ -0,0 +1,40 @@
+GPIO assisted NAND flash
+
+The GPIO assisted NAND flash uses a memory mapped interface to
+read/write the NAND commands and data and GPIO pins for the control
+signals.
+
+Required properties:
+- compatible : gpio-control-nand
+- reg : should specify localbus chip select and size used for the chip. For
+ ARM platforms where a dummy read is needed to provide synchronisation with
+ regards to bus reordering, an optional second resource describes the
+ location to read from.
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+ representing partitions. In this case, both #address-cells and #size-cells
+ must be equal to 1.
+- gpios : specifies the gpio pins to control the NAND device. nwp is an
+ optional gpio and may be set to 0 if not present.
+
+Optional properties:
+- bank-width : Width (in bytes) of the device.
+- chip-delay : chip dependent delay for transferring data from array to
+ read registers (tR).
+
+Examples:
+
+gpio-nand@1,0 {
+ compatible = gpio-control-nand;
+ reg = 1 0x 0x1000;
+ #address-cells = 1;
+ #size-cells = 1;
+ gpios = banka 1 0 /* rdy */
+banka 2 0 /* nce */
+banka 3 0 /* ale */
+banka 4 0 /* cle */
+0 /* nwp */;
+
+ partition@0 {
+ ...
+ };
+};
diff --git a/drivers/mtd/nand/gpio.c b/drivers/mtd/nand/gpio.c
index 2c2060b..1373eab 100644
--- a/drivers/mtd/nand/gpio.c
+++ b/drivers/mtd/nand/gpio.c
@@ -27,6 +27,9 @@
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
#include linux/mtd/nand-gpio.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_gpio.h
struct gpiomtd {
void __iomem*io_sync;
@@ -221,14 +224,79 @@ static void __iomem *request_and_remap(struct resource
*res, size_t size,
return ptr;
}
+#ifdef CONFIG_OF
+static const struct of_device_id gpio_nand_id_table[] = {
+ { .compatible = gpio-control-nand },
+ {}
+};
+MODULE_DEVICE_TABLE(of, gpio_nand_id_table);
+
+static int gpio_nand_of_get_options(struct device *dev,
+ struct gpio_nand_platdata *plat)
+{
+ u32 width;
+
+ if (!of_property_read_u32(dev-of_node, bank-width, width)) {
+ if (width == 2) {
+ plat-options |= NAND_BUSWIDTH_16;
+ } else if (width != 1) {
+ dev_err(dev, invalid bank-width %u\n, width);
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+static void gpio_nand_of_get_gpio(struct device *dev,
+ struct gpio_nand_platdata *plat)
+{
+ plat-gpio_rdy = of_get_gpio(dev-of_node, 0);
+ plat-gpio_nce = of_get_gpio(dev-of_node, 1);
+ plat-gpio_ale = of_get_gpio(dev-of_node, 2);
+ plat-gpio_cle = of_get_gpio(dev-of_node, 3);
+ plat-gpio_nwp = of_get_gpio(dev-of_node, 4);
+}
+
+static void gpio_nand_of_get_chip_delay(struct device *dev,
+ struct gpio_nand_platdata *plat)
+{
+ u32 chip_delay;
+
+ if (!of_property_read_u32(dev-of_node, chip-delay, chip_delay))
+ plat-chip_delay = (int)chip_delay;
+}
+
+static int gpio_nand_of_get_config(struct device *dev,
+ struct gpio_nand_platdata *plat)
+{
+ int ret = gpio_nand_of_get_options(dev, plat);
+
+ if (ret 0)
+ return ret;
+
+ gpio_nand_of_get_gpio(dev, plat);
+ gpio_nand_of_get_chip_delay(dev, plat);
+
+ return 0;
+}
+#else /* CONFIG_OF */
+#define gpio_nand_id_table NULL
+static inline int gpio_nand_of_get_config(struct device *dev,
+ struct gpio_nand_platdata *plat)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_OF */
+
static int __devinit gpio_nand_probe(struct platform_device *dev)
{
struct gpiomtd *gpiomtd;
struct
Re: [RFC/PATCH 2/7] OMAP3: beagle: don't touch omap_device internals
On 08:31-20110728, Menon, Nishanth wrote:
On Thu, Jul 28, 2011 at 07:57, Cousson, Benoit b-cous...@ti.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 293fa6c..77d01a2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -142,6 +142,7 @@
#include powerdomain.h
#includeplat/clock.h
#includeplat/omap_hwmod.h
+#includeplat/omap_device.h
I'd rather put that code inside the omap_device.c instead of here.
The omap_device layer is on top of the omap_hwmod.
In order to minimize the dependencies from the low HW description layer to
the omap_device layer, you should maybe define a omap_device_from_hwmod()
function or something similar.
Thanks for the review. will check on this.
That being said, do we really need to get the device from the hwmod name?
Cannot we use the device name instead?
I do not know all the usecases, that why I'm asking.
mpu.0 , are the device names - which probably lets me walk the kernel
data structrues instead of omap database to get to the right device,
Vs using the common names like mpu make things a little easier to
deal with from driver perspective.
as an example, some of the dev_driver_string(dev):dev_name(dev) (in
bracket hwmod name) I collected from OMAP4 are:
platform:mpu.0 (mpu)
platform:l3_main_1.0 ('l3_main_1)
pvrsrvkm:pvrsrvkm.0 (gpu)
rpres:fdif.0 (fdif)
omap_hsi:omap_hsi.0 (hsi)
platform:iss.0 (iss)
etc..
I mean I have'nt been keeping track of the device tree discussions so
dont know if this function could be better done - but I think I agree
with the overall idea that instead of spawning off get_xyz_device() we
need to have some uniform approach to get to the device scaling
silicon - I hoped we could consider the hwmod database/what ever
replacing it to do that.
following are a couple of reference patches how this could be done
with omap_device
From f03490456e24f72ca5272303c95a6f0b212494d5 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Wed, 27 Jul 2011 15:02:32 -0500
Subject: [PATCH 1/2] OMAP: PM: omap_device: add omap_hwmod_name_get_odev
An API which translates a standard hwmod name to corresponding
omap_device is useful for drivers when they need to look up the
device associated with a hwmod name to map back into the device
structure pointers. These ideally should be used by drivers in
mach directory. Using a generic hwmod name like gpu instead of
the actual device name which could change in the future, allows
us to:
a) Could in effect help replace apis such as omap2_get_mpuss_device,
omap2_get_iva_device, omap2_get_l3_device, omap4_get_dsp_device,
etc..
b) Scale to more devices rather than be restricted to named functions
c) Simplify driver's platform_data from passing additional fields
all doing the same thing with different function pointer names
just for accessing a different device name.
Change-Id: Ib42d22b4a929982c87a79866e3d7dc6e41073a6c
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |1 +
arch/arm/plat-omap/omap_device.c | 32 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 70d31d0..7a3c046 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -102,6 +102,7 @@ int omap_device_register(struct omap_device *od);
int omap_early_device_register(struct omap_device *od);
void __iomem *omap_device_get_rt_va(struct omap_device *od);
+struct omap_device *omap_hwmod_name_get_odev(const char *oh_name);
/* OMAP PM interface */
int omap_device_align_pm_lat(struct platform_device *pdev,
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 92b4496..21df532 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -780,6 +780,38 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od)
return omap_hwmod_get_mpu_rt_va(od-hwmods[0]);
}
+/**
+ * omap_hwmod_name_get_odev() - convert a hwmod name to omap_device pointer
+ * @oh_name: name of the hwmod device
+ *
+ * returns back a struct omap_device * pointer associated with a hwmod
+ * device represented by a hwmod_name
+ */
+struct omap_device *omap_hwmod_name_get_odev(const char *oh_name)
+{
+ struct omap_hwmod *oh;
+
+ if (!oh_name) {
+ WARN(1, %s: no hwmod name!\n, __func__);
+ return ERR_PTR(-EINVAL);
+ }
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (IS_ERR_OR_NULL(oh)) {
+ WARN(1, %s: no hwmod for %s\n, __func__,
+ oh_name);
+ return ERR_PTR(oh ? PTR_ERR(oh) : -ENODEV);
+ }
+ if (IS_ERR_OR_NULL(oh-od)) {
+ WARN(1, %s: no omap_device for %s\n, __func__,
+
Re: [RFC/PATCH 2/7] OMAP3: beagle: don't touch omap_device internals
hi,
On Fri, Jul 29, 2011 at 08:49:34AM -0500, Nishanth Menon wrote:
From f03490456e24f72ca5272303c95a6f0b212494d5 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Wed, 27 Jul 2011 15:02:32 -0500
Subject: [PATCH 1/2] OMAP: PM: omap_device: add omap_hwmod_name_get_odev
An API which translates a standard hwmod name to corresponding
omap_device is useful for drivers when they need to look up the
device associated with a hwmod name to map back into the device
structure pointers. These ideally should be used by drivers in
mach directory. Using a generic hwmod name like gpu instead of
the actual device name which could change in the future, allows
us to:
a) Could in effect help replace apis such as omap2_get_mpuss_device,
omap2_get_iva_device, omap2_get_l3_device, omap4_get_dsp_device,
etc..
b) Scale to more devices rather than be restricted to named functions
c) Simplify driver's platform_data from passing additional fields
all doing the same thing with different function pointer names
just for accessing a different device name.
Change-Id: Ib42d22b4a929982c87a79866e3d7dc6e41073a6c
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |1 +
arch/arm/plat-omap/omap_device.c | 32
+
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 70d31d0..7a3c046 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -102,6 +102,7 @@ int omap_device_register(struct omap_device *od);
int omap_early_device_register(struct omap_device *od);
void __iomem *omap_device_get_rt_va(struct omap_device *od);
+struct omap_device *omap_hwmod_name_get_odev(const char *oh_name);
/* OMAP PM interface */
int omap_device_align_pm_lat(struct platform_device *pdev,
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 92b4496..21df532 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -780,6 +780,38 @@ void __iomem *omap_device_get_rt_va(struct omap_device
*od)
return omap_hwmod_get_mpu_rt_va(od-hwmods[0]);
}
+/**
+ * omap_hwmod_name_get_odev() - convert a hwmod name to omap_device pointer
+ * @oh_name: name of the hwmod device
+ *
+ * returns back a struct omap_device * pointer associated with a hwmod
+ * device represented by a hwmod_name
+ */
+struct omap_device *omap_hwmod_name_get_odev(const char *oh_name)
+{
+ struct omap_hwmod *oh;
+
+ if (!oh_name) {
+ WARN(1, %s: no hwmod name!\n, __func__);
+ return ERR_PTR(-EINVAL);
+ }
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (IS_ERR_OR_NULL(oh)) {
+ WARN(1, %s: no hwmod for %s\n, __func__,
+ oh_name);
+ return ERR_PTR(oh ? PTR_ERR(oh) : -ENODEV);
+ }
+ if (IS_ERR_OR_NULL(oh-od)) {
+ WARN(1, %s: no omap_device for %s\n, __func__,
+ oh_name);
+ return ERR_PTR(oh-od ? PTR_ERR(oh-od) : -ENODEV);
+ }
+
+ return oh-od;
+}
+EXPORT_SYMBOL(omap_hwmod_name_get_odev);
maybe EXPORT_SYMBOL_GPL() ?? Not sure we want non-GPL code to access
this ;-)
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] net/smsc911x: add device tree probe support
On Tue, Jul 26, 2011 at 09:30:26AM +0800, Shawn Guo wrote:
On Mon, Jul 25, 2011 at 09:16:40PM -0400, Nicolas Pitre wrote:
On Tue, 26 Jul 2011, Shawn Guo wrote:
On Mon, Jul 25, 2011 at 03:37:23PM -0600, Grant Likely wrote:
On Mon, Jul 25, 2011 at 05:44:00PM +0800, Shawn Guo wrote:
It adds device tree probe support for smsc911x driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Steve Glendinning steve.glendinn...@smsc.com
Cc: David S. Miller da...@davemloft.net
---
Documentation/devicetree/bindings/net/smsc.txt | 34 +++
drivers/net/smsc911x.c | 123
+++-
2 files changed, 132 insertions(+), 25 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/smsc.txt
diff --git a/Documentation/devicetree/bindings/net/smsc.txt
b/Documentation/devicetree/bindings/net/smsc.txt
new file mode 100644
index 000..1920695
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc.txt
@@ -0,0 +1,34 @@
+* Smart Mixed-Signal Connectivity (SMSC) LAN Controller
+
+Required properties:
+- compatible : Should be smsc,lanmodelsmsc,lan
Drop smsc,lan. That's far too generic.
The following devices are supported by the driver.
LAN9115, LAN9116, LAN9117, LAN9118
LAN9215, LAN9216, LAN9217, LAN9218
LAN9210, LAN9211
LAN9220, LAN9221
If we only keep specific model as the compatible, we will have a
long match table which is actually used nowhere to distinguish the
device.
So we need some level generic compatible to save the meaningless
long match table. What about:
static const struct of_device_id smsc_dt_ids[] = {
{ .compatible = smsc,lan9, },
{ /* sentinel */ }
};
Or:
static const struct of_device_id smsc_dt_ids[] = {
{ .compatible = smsc,lan91, },
{ .compatible = smsc,lan92, },
{ /* sentinel */ }
};
None of this unambiguously distinguish the devices supported by this
driver and the smc91x driver which supports LAN91C92, LAN91C94,
LAN91C95, LAN91C96, LAN91C100, LAN91C110.
So you suggest to make a long list to explicitly tell the device type
that the driver supports?
If newer devices are 100% backwards compatible with an older device,
then the newer device doesn't need to appear in this list because the
device node can claim compatibility.
If it isn't backwards compatible, then you do need an entry in this
list.
g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] net/smsc911x: add device tree probe support
On Fri, Jul 29, 2011 at 04:43:16PM +0800, Shawn Guo wrote:
It adds device tree probe support for smsc911x driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Steve Glendinning steve.glendinn...@smsc.com
Cc: David S. Miller da...@davemloft.net
Some comments below, and I asked a question on the older version about
the actual model name vs. compatible, but otherwise it looks right and
you can add my:
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
---
Changes since v1:
* Instead of getting irq line from gpio number, it use irq domain
to keep platform_get_resource(IORESOURCE_IRQ) works for dt too.
* Use 'lan9115' the first model that smsc911x supports in the match
table
* Use reg-shift and reg-io-width which already used in of_serial for
shift and access size binding
Documentation/devicetree/bindings/net/smsc911x.txt | 38 +
drivers/net/smsc911x.c | 85
+---
2 files changed, 112 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/smsc911x.txt
diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt
b/Documentation/devicetree/bindings/net/smsc911x.txt
new file mode 100644
index 000..271c454
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc911x.txt
@@ -0,0 +1,38 @@
+* Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
+
+Required properties:
+- compatible : Should be smsc,lanmodel, smsc,lan9115
+- reg : Address and length of the io space for SMSC LAN
+- interrupts : Should contain SMSC LAN interrupt line
+- interrupt-parent : Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- phy-mode : String, operation mode of the PHY interface.
+ Supported values are: mii, gmii, sgmii, tbi, rmii,
+ rgmii, rgmii-id, rgmii-rxid, rgmii-txid, rtbi, smii.
+
+Optional properties:
+- reg-shift : Specify the quantity to shift the register offsets by
+- reg-io-width : Specify the size (in bytes) of the IO accesses that
+ should be performed on the device. Valid value for SMSC LAN is
+ 2 or 4. If it's omitted or invalid, the size would be 2.
+- smsc,irq-active-high : Indicates the IRQ polarity is active-low
Which is it? Active high or active low? The property doesn't match
the description.
+- smsc,irq-push-pull : Indicates the IRQ type is push-pull
What exactly does push-pull mean here?
+- smsc,force-internal-phy : Forces SMSC LAN controller to use
+ internal PHY
+- smsc,force-external-phy : Forces SMSC LAN controller to use
+ external PHY
+- smsc,save-mac-address : Indicates that mac address needs to be saved
+ before resetting the controller
+- local-mac-address : 6 bytes, mac address
+
+Examples:
+
+lan9220@f400 {
+ compatible = smsc,lan9220, smsc,lan9115;
+ reg = 0xf400 0x200;
+ phy-mode = mii;
+ interrupt-parent = gpio1;
+ interrupts = 31;
+ reg-io-width = 4;
+ smsc,irq-push-pull;
+};
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
index b9016a3..75c08a5 100644
--- a/drivers/net/smsc911x.c
+++ b/drivers/net/smsc911x.c
@@ -53,6 +53,10 @@
#include linux/phy.h
#include linux/smsc911x.h
#include linux/device.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_gpio.h
+#include linux/of_net.h
#include smsc911x.h
#define SMSC_CHIPNAMEsmsc911x
@@ -2095,8 +2099,58 @@ static const struct smsc911x_ops shifted_smsc911x_ops
= {
.tx_writefifo = smsc911x_tx_writefifo_shift,
};
+#ifdef CONFIG_OF
+static int __devinit smsc911x_probe_config_dt(
+ struct smsc911x_platform_config *config,
+ struct device_node *np)
+{
+ const char *mac;
+ u32 width = 0;
+
+ if (!np)
+ return -ENODEV;
+
+ config-phy_interface = of_get_phy_mode(np);
+
+ mac = of_get_mac_address(np);
+ if (mac)
+ memcpy(config-mac, mac, ETH_ALEN);
+
+ of_property_read_u32(np, reg-shift, config-shift);
+
+ of_property_read_u32(np, reg-io-width, width);
+ if (width == 4)
+ config-flags |= SMSC911X_USE_32BIT;
+
+ if (of_get_property(np, smsc,irq-active-high, NULL))
+ config-irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH;
+
+ if (of_get_property(np, smsc,irq-push-pull, NULL))
+ config-irq_type = SMSC911X_IRQ_TYPE_PUSH_PULL;
+
+ if (of_get_property(np, smsc,force-internal-phy, NULL))
+ config-flags |= SMSC911X_FORCE_INTERNAL_PHY;
+
+ if (of_get_property(np, smsc,force-external-phy, NULL))
+ config-flags |= SMSC911X_FORCE_EXTERNAL_PHY;
+
+ if (of_get_property(np, smsc,save-mac-address, NULL))
+ config-flags |= SMSC911X_SAVE_MAC_ADDRESS;
+
+ return 0;
+}
+#else
+static inline int
Re: [PATCH] Input: mma8450: add device tree probe support
On Fri, Jul 29, 2011 at 10:38 AM, Shawn Guo shawn@freescale.com wrote:
Any comments?
Shawn,
Patch looks OK to me.
Regards,
Shawn
On Fri, Jul 22, 2011 at 12:25:51AM +0800, Shawn Guo wrote:
It adds device tree probe support for mma8450 driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Sammy He r62...@freescale.com
Cc: Eric Miao eric.m...@linaro.org
Cc: Dmitry Torokhov d...@mail.ru
---
.../devicetree/bindings/input/fsl-mma8450.txt | 11 +++
drivers/input/misc/mma8450.c | 8
2 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/fsl-mma8450.txt
diff --git a/Documentation/devicetree/bindings/input/fsl-mma8450.txt
b/Documentation/devicetree/bindings/input/fsl-mma8450.txt
new file mode 100644
index 000..a00c94c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/fsl-mma8450.txt
@@ -0,0 +1,11 @@
+* Freescale MMA8450 3-Axis Accelerometer
+
+Required properties:
+- compatible : fsl,mma8450.
+
+Example:
+
+accelerometer: mma8450@1c {
+ compatible = fsl,mma8450;
+ reg = 0x1c;
+};
diff --git a/drivers/input/misc/mma8450.c b/drivers/input/misc/mma8450.c
index 20f8f92..6c76cf7 100644
--- a/drivers/input/misc/mma8450.c
+++ b/drivers/input/misc/mma8450.c
@@ -24,6 +24,7 @@
#include linux/delay.h
#include linux/i2c.h
#include linux/input-polldev.h
+#include linux/of_device.h
#define MMA8450_DRV_NAME mma8450
@@ -229,10 +230,17 @@ static const struct i2c_device_id mma8450_id[] = {
};
MODULE_DEVICE_TABLE(i2c, mma8450_id);
+static const struct of_device_id mma8450_dt_ids[] = {
+ { .compatible = fsl,mma8450, },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(i2c, mma8450_dt_ids);
+
static struct i2c_driver mma8450_driver = {
.driver = {
.name = MMA8450_DRV_NAME,
.owner = THIS_MODULE,
+ .of_match_table = mma8450_dt_ids,
},
.probe = mma8450_probe,
.remove = __devexit_p(mma8450_remove),
--
1.7.4.1
___
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: [PATCH] net/smsc911x: add device tree probe support
On Fri, Jul 29, 2011 at 09:47:23AM -0600, Grant Likely wrote:
On Fri, Jul 29, 2011 at 10:36:26AM +0800, Shawn Guo wrote:
On Mon, Jul 25, 2011 at 10:28:05PM -0400, Nicolas Pitre wrote:
On Tue, 26 Jul 2011, Shawn Guo wrote:
On Mon, Jul 25, 2011 at 09:16:40PM -0400, Nicolas Pitre wrote:
On Tue, 26 Jul 2011, Shawn Guo wrote:
On Mon, Jul 25, 2011 at 03:37:23PM -0600, Grant Likely wrote:
On Mon, Jul 25, 2011 at 05:44:00PM +0800, Shawn Guo wrote:
It adds device tree probe support for smsc911x driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Steve Glendinning steve.glendinn...@smsc.com
Cc: David S. Miller da...@davemloft.net
---
Documentation/devicetree/bindings/net/smsc.txt | 34 +++
drivers/net/smsc911x.c | 123
+++-
2 files changed, 132 insertions(+), 25 deletions(-)
create mode 100644
Documentation/devicetree/bindings/net/smsc.txt
diff --git a/Documentation/devicetree/bindings/net/smsc.txt
b/Documentation/devicetree/bindings/net/smsc.txt
new file mode 100644
index 000..1920695
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc.txt
@@ -0,0 +1,34 @@
+* Smart Mixed-Signal Connectivity (SMSC) LAN Controller
+
+Required properties:
+- compatible : Should be smsc,lanmodelsmsc,lan
Drop smsc,lan. That's far too generic.
The following devices are supported by the driver.
LAN9115, LAN9116, LAN9117, LAN9118
LAN9215, LAN9216, LAN9217, LAN9218
LAN9210, LAN9211
LAN9220, LAN9221
If we only keep specific model as the compatible, we will have a
long match table which is actually used nowhere to distinguish the
device.
So we need some level generic compatible to save the meaningless
long match table. What about:
static const struct of_device_id smsc_dt_ids[] = {
{ .compatible = smsc,lan9, },
{ /* sentinel */ }
};
Or:
static const struct of_device_id smsc_dt_ids[] = {
{ .compatible = smsc,lan91, },
{ .compatible = smsc,lan92, },
{ /* sentinel */ }
};
None of this unambiguously distinguish the devices supported by this
driver and the smc91x driver which supports LAN91C92, LAN91C94,
LAN91C95, LAN91C96, LAN91C100, LAN91C110.
So you suggest to make a long list to explicitly tell the device type
that the driver supports?
I'm not suggesting anything. :-) I'm merely pointing out that the
above .compatible = smsc,lan9 or .compatible = smsc,lan91 are too
generic given that there is another driver with different devices to
which they could also apply.
Since I do not get any suggestion here, I'm going to follow the driver
name to use '911' as the model number. Please tell me if there is any
better one.
What is the manufacturer part name? lan9111 or lan91c11? The
manufacturer's documented part number is almost always preferred.
I just posted the v2 of the patch, and chose to use 'smsc,lan9115'
which is the first model supported in the driver. This is the same
approach I used with i.mx device bindings.
--
Regards,
Shawn
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ASoC: sgtl5000: add device tree probe support
On Fri, Jul 29, 2011 at 10:40:51AM +0800, Shawn Guo wrote:
On Tue, Jul 26, 2011 at 08:55:11PM +0100, Mark Brown wrote:
On Fri, Jul 22, 2011 at 12:28:51AM +0800, Shawn Guo wrote:
It adds device tree probe support for sgtl5000 driver.
Kind of waiting for the device tree people to comment on this...
Grant, please?
Acked-by: Grant Likely grant.lik...@secretlab.ca
Regards,
Shawn
.../bindings/sound/soc/codecs/fsl-sgtl5000.txt | 11 +++
I'd expect this can just be put directly under the sound directory.
+++ 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;
+};
This might get a tiny bit verbose... I wonder if it makes sense to have
some central file for devices with trivial bindings? But possibly more
trouble than it's worth.
___
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: [PATCH v2] net/smsc911x: add device tree probe support
On Fri, Jul 29, 2011 at 09:53:54AM -0600, Grant Likely wrote:
On Fri, Jul 29, 2011 at 04:43:16PM +0800, Shawn Guo wrote:
It adds device tree probe support for smsc911x driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Steve Glendinning steve.glendinn...@smsc.com
Cc: David S. Miller da...@davemloft.net
Some comments below, and I asked a question on the older version about
the actual model name vs. compatible, but otherwise it looks right and
you can add my:
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Thanks, Grant.
---
Changes since v1:
* Instead of getting irq line from gpio number, it use irq domain
to keep platform_get_resource(IORESOURCE_IRQ) works for dt too.
* Use 'lan9115' the first model that smsc911x supports in the match
table
* Use reg-shift and reg-io-width which already used in of_serial for
shift and access size binding
Documentation/devicetree/bindings/net/smsc911x.txt | 38 +
drivers/net/smsc911x.c | 85
+---
2 files changed, 112 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/smsc911x.txt
diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt
b/Documentation/devicetree/bindings/net/smsc911x.txt
new file mode 100644
index 000..271c454
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc911x.txt
@@ -0,0 +1,38 @@
+* Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
+
+Required properties:
+- compatible : Should be smsc,lanmodel, smsc,lan9115
+- reg : Address and length of the io space for SMSC LAN
+- interrupts : Should contain SMSC LAN interrupt line
+- interrupt-parent : Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- phy-mode : String, operation mode of the PHY interface.
+ Supported values are: mii, gmii, sgmii, tbi, rmii,
+ rgmii, rgmii-id, rgmii-rxid, rgmii-txid, rtbi, smii.
+
+Optional properties:
+- reg-shift : Specify the quantity to shift the register offsets by
+- reg-io-width : Specify the size (in bytes) of the IO accesses that
+ should be performed on the device. Valid value for SMSC LAN is
+ 2 or 4. If it's omitted or invalid, the size would be 2.
+- smsc,irq-active-high : Indicates the IRQ polarity is active-low
Which is it? Active high or active low? The property doesn't match
the description.
Sorry. The description is wrong.
+- smsc,irq-push-pull : Indicates the IRQ type is push-pull
What exactly does push-pull mean here?
I do not understand exactly. But I see the term used in driver was
originally from SMSC data sheet.
+- smsc,force-internal-phy : Forces SMSC LAN controller to use
+ internal PHY
+- smsc,force-external-phy : Forces SMSC LAN controller to use
+ external PHY
+- smsc,save-mac-address : Indicates that mac address needs to be saved
+ before resetting the controller
+- local-mac-address : 6 bytes, mac address
+
+Examples:
+
+lan9220@f400 {
+ compatible = smsc,lan9220, smsc,lan9115;
+ reg = 0xf400 0x200;
+ phy-mode = mii;
+ interrupt-parent = gpio1;
+ interrupts = 31;
+ reg-io-width = 4;
+ smsc,irq-push-pull;
+};
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
index b9016a3..75c08a5 100644
--- a/drivers/net/smsc911x.c
+++ b/drivers/net/smsc911x.c
@@ -53,6 +53,10 @@
#include linux/phy.h
#include linux/smsc911x.h
#include linux/device.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_gpio.h
+#include linux/of_net.h
#include smsc911x.h
#define SMSC_CHIPNAME smsc911x
@@ -2095,8 +2099,58 @@ static const struct smsc911x_ops
shifted_smsc911x_ops = {
.tx_writefifo = smsc911x_tx_writefifo_shift,
};
+#ifdef CONFIG_OF
+static int __devinit smsc911x_probe_config_dt(
+ struct smsc911x_platform_config *config,
+ struct device_node *np)
+{
+ const char *mac;
+ u32 width = 0;
+
+ if (!np)
+ return -ENODEV;
+
+ config-phy_interface = of_get_phy_mode(np);
+
+ mac = of_get_mac_address(np);
+ if (mac)
+ memcpy(config-mac, mac, ETH_ALEN);
+
+ of_property_read_u32(np, reg-shift, config-shift);
+
+ of_property_read_u32(np, reg-io-width, width);
+ if (width == 4)
+ config-flags |= SMSC911X_USE_32BIT;
+
+ if (of_get_property(np, smsc,irq-active-high, NULL))
+ config-irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH;
+
+ if (of_get_property(np, smsc,irq-push-pull, NULL))
+ config-irq_type = SMSC911X_IRQ_TYPE_PUSH_PULL;
+
+ if (of_get_property(np, smsc,force-internal-phy, NULL))
+ config-flags |= SMSC911X_FORCE_INTERNAL_PHY;
+
+ if
Re: [PATCH] net/smsc911x: add device tree probe support
On Sat, Jul 30, 2011 at 12:03:44AM +0800, Shawn Guo wrote: On Fri, Jul 29, 2011 at 09:47:23AM -0600, Grant Likely wrote: On Fri, Jul 29, 2011 at 10:36:26AM +0800, Shawn Guo wrote: Since I do not get any suggestion here, I'm going to follow the driver name to use '911' as the model number. Please tell me if there is any better one. What is the manufacturer part name? lan9111 or lan91c11? The manufacturer's documented part number is almost always preferred. I just posted the v2 of the patch, and chose to use 'smsc,lan9115' which is the first model supported in the driver. This is the same approach I used with i.mx device bindings. You haven't answered the question. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ASoC: sgtl5000: add device tree probe support
On Fri, Jul 22, 2011 at 12:28:51AM +0800, Shawn Guo wrote: It adds device tree probe support for sgtl5000 driver. Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/7] ARM: mmp: parse timer configuration from DT
On Thu, Jul 28, 2011 at 02:41:28PM +0800, Haojian Zhuang wrote:
Parse timer configuration from DT. Now we can merge pxa910_timer and
mmp2_timer into mmp_timer. Since most configuration between these two
timers are same. The difference is recorded in DT.
Signed-off-by: Haojian Zhuang haojian.zhu...@marvell.com
---
.../devicetree/bindings/arm/marvell/timer.txt | 24 +
arch/arm/mach-mmp/common.h |2 +
arch/arm/mach-mmp/time.c | 50
+++-
3 files changed, 75 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/marvell/timer.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell/timer.txt
b/Documentation/devicetree/bindings/arm/marvell/timer.txt
new file mode 100644
index 000..24a6f97
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/timer.txt
@@ -0,0 +1,24 @@
+* Timer Controller Binding for ARCH-MMP
+
+This binding specifies what properties must be available in device tree
+representation of an ARCH-MMP compliant timer controller.
+
+Required properties:
+
+ - compatible: Specifies the compatibility list of the timer controller.
+ The type shall be string and the value shall be
+ mrvl,pxa168-timer.
+
+ - mrvl,clk-conf: Specifies the address and value of timer
+ configuration register.
+ The type shall be prop-encoded-array. The first value indicates
+ the physical address of timer configuration register. The second
+ value indicates data should be written to timer configuration
+ register.
+
+* Example
+
+ mmp_timer: {
+ compatible = mrvl,pxa168-timer;
+ mrvl,clk-conf = 0xd434 0x33;
+ };
diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h
index 1c563c2..890c664 100644
--- a/arch/arm/mach-mmp/common.h
+++ b/arch/arm/mach-mmp/common.h
@@ -2,6 +2,8 @@
struct sys_timer;
+extern struct sys_timer mmp_timer;
+
extern void timer_init(int irq);
extern void __init icu_init_irq(void);
diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
index 99833b9..5a90b27 100644
--- a/arch/arm/mach-mmp/time.c
+++ b/arch/arm/mach-mmp/time.c
@@ -25,6 +25,8 @@
#include linux/io.h
#include linux/irq.h
+#include linux/of.h
+#include linux/of_irq.h
#include linux/sched.h
#include asm/sched_clock.h
@@ -150,7 +152,7 @@ static void __init timer_config(void)
__raw_writel(cer ~0x1, TIMERS_VIRT_BASE + TMR_CER); /* disable */
- ccr = (cpu_is_mmp2()) ? TMR_CCR_CS_0(0) : TMR_CCR_CS_0(3);
+ ccr = TMR_CCR_CS_0(0);
__raw_writel(ccr, TIMERS_VIRT_BASE + TMR_CCR);
/* free-running mode */
@@ -187,3 +189,49 @@ void __init timer_init(int irq)
clocksource_register_hz(cksrc, CLOCK_TICK_RATE);
clockevents_register_device(ckevt);
}
+
+#ifdef CONFIG_OF
+static void __init mmp_timer_init(void)
+{
+ struct device_node *np;
+ const __be32 *clk_offs;
+ void __iomem *conf;
+ unsigned int addr = 0, offs = 0;
+ int size, irq;
+
+ np = of_find_compatible_node(NULL, NULL, mrvl,pxa168-timer);
+
+ BUG_ON(!np);
+
+ of_node_get(np);
+ irq = irq_of_parse_and_map(np, 0);
+
+ clk_offs = of_get_property(np, mrvl,clk-conf, size);
+ if ((clk_offs == NULL) || (size != sizeof(int) * 2)) {
sizeof(u32)
I would recommend using of_property_read_u32_array() which does the
sanity checking for you.
+ pr_warn(mmp-timer: mrvl,clk-conf property is wrong\n);
+ goto out;
+ }
+ addr = be32_to_cpu(*clk_offs) PAGE_MASK;
+ offs = be32_to_cpu(*clk_offs) - addr;
+ conf = ioremap(addr, PAGE_SIZE);
base addresses should be in a 'reg' property. I would put the
register region into a 'reg' tuple so that of_iomap() works, and then
encode just the offset/config-value pair into mrvl,clk-conf.
+ if (conf == NULL) {
+ pr_warn(mmp-timer: failed on mapping 0x%x\n, (uint32_t)conf);
+ goto out;
+ }
+ /* reset and configure */
+ __raw_writel(APBC_APBCLK | APBC_RST, conf + offs);
+ __raw_writel(be32_to_cpu(*++clk_offs), conf + offs);
+ __raw_readl(conf + offs);
+ iounmap(conf);
+
+ timer_init(irq);
+ return;
+out:
+ of_node_put(np);
+ return;
+}
+
+struct sys_timer mmp_timer = {
+ .init = mmp_timer_init,
+};
+#endif
--
1.5.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/7] tty: serial: support device tree in pxa
On Thu, Jul 28, 2011 at 02:41:30PM +0800, Haojian Zhuang wrote:
Support both normal platform driver and device tree driver in serial pxa.
Signed-off-by: Haojian Zhuang haojian.zhu...@marvell.com
---
drivers/tty/serial/pxa.c | 51 -
1 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index 4302e6e..dadd201 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
@@ -36,6 +36,7 @@
#include linux/circ_buf.h
#include linux/delay.h
#include linux/interrupt.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/tty.h
#include linux/tty_flip.h
@@ -54,6 +55,8 @@ struct uart_pxa_port {
char*name;
};
+#define PXA_SERIAL_NR4
+
static inline unsigned int serial_in(struct uart_pxa_port *up, int offset)
{
offset = 2;
@@ -593,7 +596,7 @@ serial_pxa_type(struct uart_port *port)
return up-name;
}
-static struct uart_pxa_port *serial_pxa_ports[4];
+static struct uart_pxa_port *serial_pxa_ports[PXA_SERIAL_NR];
static struct uart_driver serial_pxa_reg;
#ifdef CONFIG_SERIAL_PXA_CONSOLE
@@ -765,7 +768,10 @@ static int serial_pxa_probe(struct platform_device *dev)
{
struct uart_pxa_port *sport;
struct resource *mmres, *irqres;
- int ret;
+ struct device_node *np = dev-dev.of_node;
+ char name[32];
+ unsigned int clk = 0, spd = 0;
+ int ret, i;
mmres = platform_get_resource(dev, IORESOURCE_MEM, 0);
irqres = platform_get_resource(dev, IORESOURCE_IRQ, 0);
@@ -776,11 +782,39 @@ static int serial_pxa_probe(struct platform_device *dev)
if (!sport)
return -ENOMEM;
+#ifdef CONFIG_OF
+ for (i = 0; i PXA_SERIAL_NR; i++) {
+ if (serial_pxa_ports[i] == NULL)
+ break;
+ }
+ if (i = PXA_SERIAL_NR) {
+ pr_warn(can't find pxa serial port\n);
+ return -ENODEV;
+ }
+
+ if (of_property_read_u32(np, clock-frequency, clk)) {
+ pr_warn(no clock-frequency property set\n);
+ return -ENODEV;
+ }
+ if (of_property_read_u32(np, current-speed, spd) == 0)
+ sport-port.custom_divisor = clk / (16 * spd);
+
+ sprintf(name, pxa2xx-uart.%d, i);
+ sport-clk = clk_get_sys(name, NULL);
+ if (IS_ERR(sport-clk)) {
+ ret = PTR_ERR(sport-clk);
+ goto err_free;
+ }
+ sport-port.uartclk = clk;
+#else
+ i = dev-id;
sport-clk = clk_get(dev-dev, NULL);
if (IS_ERR(sport-clk)) {
ret = PTR_ERR(sport-clk);
goto err_free;
}
+ sport-port.uartclk = clk_get_rate(sport-clk);
+#endif
This means a kernel build can either support DT or non-DT, but not
both. DT non-DT booting are full supported with the same kernel
image, so don't do it this way.
Instead, check for the presence of an of_node. If it is there, do the
DT parsing. If now, still support the old method.
sport-port.type = PORT_PXA;
sport-port.iotype = UPIO_MEM;
@@ -788,12 +822,11 @@ static int serial_pxa_probe(struct platform_device *dev)
sport-port.irq = irqres-start;
sport-port.fifosize = 64;
sport-port.ops = serial_pxa_pops;
- sport-port.line = dev-id;
+ sport-port.line = i;
sport-port.dev = dev-dev;
sport-port.flags = UPF_IOREMAP | UPF_BOOT_AUTOCONF;
- sport-port.uartclk = clk_get_rate(sport-clk);
- switch (dev-id) {
+ switch (i) {
case 0: sport-name = FFUART; break;
case 1: sport-name = BTUART; break;
case 2: sport-name = STUART; break;
@@ -809,7 +842,7 @@ static int serial_pxa_probe(struct platform_device *dev)
goto err_clk;
}
- serial_pxa_ports[dev-id] = sport;
+ serial_pxa_ports[i] = sport;
uart_add_one_port(serial_pxa_reg, sport-port);
platform_set_drvdata(dev, sport);
@@ -836,6 +869,11 @@ static int serial_pxa_remove(struct platform_device *dev)
return 0;
}
+static struct of_device_id __devinitdata of_serial_pxa_table[] = {
+ { .compatible = mrvl,pxa270-serial, .data = (void *)PORT_PXA, },
+ {},
+};
+
static struct platform_driver serial_pxa_driver = {
.probe = serial_pxa_probe,
.remove = serial_pxa_remove,
@@ -843,6 +881,7 @@ static struct platform_driver serial_pxa_driver = {
.driver = {
.name = pxa2xx-uart,
.owner = THIS_MODULE,
+ .of_match_table = of_serial_pxa_table,
#ifdef CONFIG_PM
.pm = serial_pxa_pm_ops,
#endif
--
1.5.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/7] tty: serial: support device tree in pxa
On Fri, Jul 29, 2011 at 10:45:39AM -0600, Grant Likely wrote:
On Thu, Jul 28, 2011 at 02:41:30PM +0800, Haojian Zhuang wrote:
+#ifdef CONFIG_OF
+ for (i = 0; i PXA_SERIAL_NR; i++) {
+ if (serial_pxa_ports[i] == NULL)
+ break;
+ }
+ if (i = PXA_SERIAL_NR) {
+ pr_warn(can't find pxa serial port\n);
+ return -ENODEV;
+ }
+
+ if (of_property_read_u32(np, clock-frequency, clk)) {
+ pr_warn(no clock-frequency property set\n);
+ return -ENODEV;
+ }
+ if (of_property_read_u32(np, current-speed, spd) == 0)
+ sport-port.custom_divisor = clk / (16 * spd);
+
+ sprintf(name, pxa2xx-uart.%d, i);
+ sport-clk = clk_get_sys(name, NULL);
+ if (IS_ERR(sport-clk)) {
+ ret = PTR_ERR(sport-clk);
+ goto err_free;
+ }
+ sport-port.uartclk = clk;
+#else
+ i = dev-id;
sport-clk = clk_get(dev-dev, NULL);
if (IS_ERR(sport-clk)) {
ret = PTR_ERR(sport-clk);
goto err_free;
}
+ sport-port.uartclk = clk_get_rate(sport-clk);
+#endif
This means a kernel build can either support DT or non-DT, but not
both. DT non-DT booting are full supported with the same kernel
image, so don't do it this way.
Instead, check for the presence of an of_node. If it is there, do the
DT parsing. If now, still support the old method.
Oh ffs, why is this DT stuff causing all the clk stuff to have to change.
And specifically why is stuff converting to use clk_get_sys().
clk_get_sys() is there to allow system devices to get their clocks.
It's not for general drivers to use.
Please, stop this madness.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3] gpio-generic: add support for device tree probing
On Fri, Jul 29, 2011 at 10:24:53AM -0600, Grant Likely wrote:
On Fri, Jul 29, 2011 at 11:45:01AM +0100, Jamie Iles wrote:
This patch adds support for gpio-generic controllers to be
instantiated from the device tree. The binding supports devices with
multiple banks.
v3:
- Remove extraneous of_node_{get,put}().
- Rename basic-mmio-gpio,reg-io-width to reg-io-width.
- Use vendor specific compatible values for now.
- Only add child banks, and allocate banks as an array.
- Remove bgpio_init_info() and populate bgpio_chip directly.
- Rename properties to gpio-generic,* to match the driver name.
v2:
- Added more detail to the binding.
- Added CONFIG_OF guards.
- Use regoffset-* properties for each register in each bank.
relative to the registers of the controller.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Anton Vorontsov cbouatmai...@gmail.com
Signed-off-by: Jamie Iles ja...@jamieiles.com
Hi Jamie,
Overall, I'm pretty happy with the direction this is going. Comments
below...
Thanks for reviewing it Grant. A few inliners.
Jamie
---
.../devicetree/bindings/gpio/gpio-generic.txt | 85 ++
drivers/gpio/gpio-generic.c| 174
++--
2 files changed, 245 insertions(+), 14 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-generic.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-generic.txt
b/Documentation/devicetree/bindings/gpio/gpio-generic.txt
new file mode 100644
index 000..91c9441
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-generic.txt
@@ -0,0 +1,85 @@
+Generic MMIO GPIO controller
+
+This binding allows lots of common GPIO controllers to use a generic GPIO
+driver. The top level GPIO node describes the registers for the controller
+and high level properties such as endianness and register width. Each
bank in
+the controller is represented as a child node.
+
+Required properties:
+- compatible : Must be one of:
+ - snps,dw-apb-gpio : Synopsys DesignWare APB GPIO controller
+- reg : The register window for the GPIO device. If the device has
multiple
+ banks then this window should cover all of the banks.
+- gpio-generic,reg-io-width : The width of the registers in the controller
+ (in bytes).
+- #address-cells : should be set to 1.
+- #size-cells : should be set to 0. The addresses of the child nodes are
the
+ bank numbers and the child nodes themselves represent the banks in the
+ controller.
There is no 'reg' or 'ranges' property documented for the child nodes.
#address-cells and #size-cells are only meaningful when needed to
interpret a reg or ranges prop.
OK.
+
+Optional properties:
+- gpio-generic,big-endian : the registers are in big-endian byte ordering.
+ If present then the first gpio in the controller occupies the MSB for
+ each register.
+
+Generic MMIO GPIO controller bank
+
+Required properties:
+- compatible : Must be one of:
+ - snps,dw-apb-gpio-bank : Synopsys DesignWare APB GPIO controller bank
I really do think that the compatible property can be dropped from the
child nodes... although thinking further. It doesn't have much value
for specifying the exact controller, but maybe it should be used to
specify the specific type of bank. Right now the generic code uses a
heuristic to figure out which set of accessor ops to use which strikes
me as rather fragile. I think it would be better to identify the
major types of gpio controllers and name them.
I did think of doing this originally but I felt it could get a bit too
unwieldy to describe all of the combinations (both in the compatible
string and parsing code). I guess in the driver we could have a list of
templates that have a mask of the required registers for a given
compatible string.
+- gpio-controller : Marks the node as a GPIO controller.
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell encodes optional flags (currently unused).
I'm not /opposed/ to this binding, but there is an issue that I think
is worth raising. From an engineer's perspective, multi-bank gpio
controllers are often documented as a single range of N gpios, even if
it is composed of M banks of x gpios (where N = M * x). This means
that the documentation will specify an 'N' value for a gpio pin, but
the device tree will be a set of 'x' values against sub nodes. I
think this will cause a lot of confusion.
and for controllers such as the Synopsys one, each bank may have a
different number of GPIO pins!
Perhaps the gpio-controller property and #gpio-cells should be part of
the parent node. The current Linux implementation doesn't easily
support doing it that way, but we can change the driver if it means a
better binding.
I'm not sure though. Thoughts?
Personally
Re: [PATCH v2 6/7] i2c: pxa: support i2c controller from DT
On Thu, Jul 28, 2011 at 02:41:32PM +0800, Haojian Zhuang wrote:
support i2c-pxa controller from DT.
Signed-off-by: Haojian Zhuang haojian.zhu...@marvell.com
---
drivers/i2c/busses/i2c-pxa.c | 51 +++--
1 files changed, 38 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index d603646..8c27733 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -29,6 +29,7 @@
#include linux/errno.h
#include linux/interrupt.h
#include linux/i2c-pxa.h
+#include linux/of_device.h
#include linux/of_i2c.h
#include linux/platform_device.h
#include linux/err.h
@@ -1044,15 +1045,31 @@ static const struct i2c_algorithm
i2c_pxa_pio_algorithm = {
.functionality = i2c_pxa_functionality,
};
+static const struct of_device_id pxa_i2c_of_match[] = {
+ { .compatible = mrvl,pxa255-i2c,.data = (void *)REGS_PXA2XX, },
+ { .compatible = mrvl,pxa300-pwri2c, .data = (void *)REGS_PXA3XX, },
+ {},
+};
+
static int i2c_pxa_probe(struct platform_device *dev)
{
+ struct device_node *np = dev-dev.of_node;
+ const struct of_device_id *match;
struct pxa_i2c *i2c;
- struct resource *res;
struct i2c_pxa_platform_data *plat = dev-dev.platform_data;
const struct platform_device_id *id = platform_get_device_id(dev);
- enum pxa_i2c_types i2c_type = id-driver_data;
- int ret;
- int irq;
+ enum pxa_i2c_types i2c_type;
+ struct resource *res;
+ int irq, ret;
+ static int idx = 0;
+
+ if (np) {
+ match = of_match_device(pxa_i2c_of_match, dev-dev);
+ if (match == NULL)
+ return -ENODEV;
+ i2c_type = (int)match-data;
+ } else
+ i2c_type = id-driver_data;
res = platform_get_resource(dev, IORESOURCE_MEM, 0);
irq = platform_get_irq(dev, 0);
@@ -1074,16 +1091,23 @@ static int i2c_pxa_probe(struct platform_device *dev)
spin_lock_init(i2c-lock);
init_waitqueue_head(i2c-wait);
- /*
- * If dev-id is negative we consider it as zero.
- * The reason to do so is to avoid sysfs names that only make
- * sense when there are multiple adapters.
- */
- i2c-adap.nr = dev-id;
- snprintf(i2c-adap.name, sizeof(i2c-adap.name), pxa_i2c-i2c.%u,
- i2c-adap.nr);
- i2c-clk = clk_get(dev-dev, NULL);
+ if (np) {
+ i2c-adap.nr = idx++;
Use this so that a bus number gets dynamically assigned:
i2c-adap.nr = -1;
+ snprintf(i2c-adap.name, sizeof(i2c-adap.name),
+ pxa2xx-i2c.%u, i2c-adap.nr);
+ i2c-clk = clk_get_sys(i2c-adap.name, NULL);
Missing i2c-adap.dev.of_node = dev-dev.of_node;
and after the bus is registered:
of_i2c_register_devices(i2c-adap);
+ } else {
+ /*
+ * If dev-id is negative we consider it as zero.
+ * The reason to do so is to avoid sysfs names that only make
+ * sense when there are multiple adapters.
+ */
+ i2c-adap.nr = dev-id;
+ snprintf(i2c-adap.name, sizeof(i2c-adap.name),
+ pxa_i2c-i2c.%u, i2c-adap.nr);
+ i2c-clk = clk_get(dev-dev, NULL);
+ }
if (IS_ERR(i2c-clk)) {
ret = PTR_ERR(i2c-clk);
goto eclk;
@@ -1234,6 +1258,7 @@ static struct platform_driver i2c_pxa_driver = {
.name = pxa2xx-i2c,
.owner = THIS_MODULE,
.pm = I2C_PXA_DEV_PM_OPS,
+ .of_match_table = pxa_i2c_of_match,
},
.id_table = i2c_pxa_id_table,
};
--
1.5.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/7] tty: serial: support device tree in pxa
On Fri, Jul 29, 2011 at 05:49:22PM +0100, Russell King - ARM Linux wrote:
On Fri, Jul 29, 2011 at 10:45:39AM -0600, Grant Likely wrote:
On Thu, Jul 28, 2011 at 02:41:30PM +0800, Haojian Zhuang wrote:
+#ifdef CONFIG_OF
+ for (i = 0; i PXA_SERIAL_NR; i++) {
+ if (serial_pxa_ports[i] == NULL)
+ break;
+ }
+ if (i = PXA_SERIAL_NR) {
+ pr_warn(can't find pxa serial port\n);
+ return -ENODEV;
+ }
+
+ if (of_property_read_u32(np, clock-frequency, clk)) {
+ pr_warn(no clock-frequency property set\n);
+ return -ENODEV;
+ }
+ if (of_property_read_u32(np, current-speed, spd) == 0)
+ sport-port.custom_divisor = clk / (16 * spd);
+
+ sprintf(name, pxa2xx-uart.%d, i);
+ sport-clk = clk_get_sys(name, NULL);
+ if (IS_ERR(sport-clk)) {
+ ret = PTR_ERR(sport-clk);
+ goto err_free;
+ }
+ sport-port.uartclk = clk;
+#else
+ i = dev-id;
sport-clk = clk_get(dev-dev, NULL);
if (IS_ERR(sport-clk)) {
ret = PTR_ERR(sport-clk);
goto err_free;
}
+ sport-port.uartclk = clk_get_rate(sport-clk);
+#endif
This means a kernel build can either support DT or non-DT, but not
both. DT non-DT booting are full supported with the same kernel
image, so don't do it this way.
Instead, check for the presence of an of_node. If it is there, do the
DT parsing. If now, still support the old method.
Oh ffs, why is this DT stuff causing all the clk stuff to have to change.
And specifically why is stuff converting to use clk_get_sys().
clk_get_sys() is there to allow system devices to get their clocks.
It's not for general drivers to use.
Please, stop this madness.
indeed.
g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 6/7] i2c: pxa: support i2c controller from DT
On Fri, Jul 29, 2011 at 10:52:22AM -0600, Grant Likely wrote:
On Thu, Jul 28, 2011 at 02:41:32PM +0800, Haojian Zhuang wrote:
- /*
-* If dev-id is negative we consider it as zero.
-* The reason to do so is to avoid sysfs names that only make
-* sense when there are multiple adapters.
-*/
- i2c-adap.nr = dev-id;
- snprintf(i2c-adap.name, sizeof(i2c-adap.name), pxa_i2c-i2c.%u,
-i2c-adap.nr);
- i2c-clk = clk_get(dev-dev, NULL);
+ if (np) {
+ i2c-adap.nr = idx++;
Use this so that a bus number gets dynamically assigned:
i2c-adap.nr = -1;
+ snprintf(i2c-adap.name, sizeof(i2c-adap.name),
+ pxa2xx-i2c.%u, i2c-adap.nr);
+ i2c-clk = clk_get_sys(i2c-adap.name, NULL);
Missing i2c-adap.dev.of_node = dev-dev.of_node;
And here we go again. Is it really the case that this DT stuff doesn't
have stable device names?
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] net/smsc911x: add device tree probe support
On Fri, Jul 29, 2011 at 10:26:29AM -0600, Grant Likely wrote: On Sat, Jul 30, 2011 at 12:03:44AM +0800, Shawn Guo wrote: On Fri, Jul 29, 2011 at 09:47:23AM -0600, Grant Likely wrote: On Fri, Jul 29, 2011 at 10:36:26AM +0800, Shawn Guo wrote: Since I do not get any suggestion here, I'm going to follow the driver name to use '911' as the model number. Please tell me if there is any better one. What is the manufacturer part name? lan9111 or lan91c11? The manufacturer's documented part number is almost always preferred. I just posted the v2 of the patch, and chose to use 'smsc,lan9115' which is the first model supported in the driver. This is the same approach I used with i.mx device bindings. You haven't answered the question. For 9115 example, the part number in data sheet is LAN9115. -- Regards, Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC/PATCH 2/7] OMAP3: beagle: don't touch omap_device internals
On Fri, Jul 29, 2011 at 09:05, Felipe Balbi ba...@ti.com wrote: +} +EXPORT_SYMBOL(omap_hwmod_name_get_odev); maybe EXPORT_SYMBOL_GPL() ?? Not sure we want non-GPL code to access this ;-) Sure.. but is this the way we want to go? if yes, I can post the series in a formal way to the list. Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC/PATCH 0/7] decouple platform_device from omap_device
G, Manjunath Kondaiah manj...@ti.com writes: On Wed, Jul 27, 2011 at 02:45:33PM -0700, Hilman, Kevin wrote: Hi Manjunath, On Wed, Jul 27, 2011 at 7:04 AM, G, Manjunath Kondaiah manj...@ti.com wrote: Kevin, On Thu, Jul 21, 2011 at 04:52:10PM -0700, Kevin Hilman wrote: Here's a first whack, proof-of-concept on how we could start to decouple the platform_device from an omap_device. The main RFC is in the last patch, and everything leading up to it are misc. omap_device cleanups that make the last patch cleaner and clearer. It's really the last patch that does the decoupling. This will be necessary if we're going to decouple the platform_device creation from the omap_device/omap_hwmod creation etc. This patch leaves them both done in omap_device_build(), but shows that they can be decoupled. Can you pls mention baseline used for these patches? I tried applying on latest mainline, v3.0 and git://git.pwsan.com/linux-2.6 prcm-devel-3.1 Oops, sorry. I forgot to mention it. Due to some misc. dependencies (mainly on Beagle board file), I've temporarily based it on the for-next branch of the arm-soc tree[1] since that has everything already queued for the next merge window. I also based it on the omap_device patch I posted which changes the pr_* prints to dev_*. For convenience, I've pushed this series to the 'wip/od-devres' branch of my tree[2]. Sorry for the confusion, Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc.git [2] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git This series results in boot crash. However, it boots fine without this series. I have not tried to debug but it looks like from boot log, the res structure has invalid entries in mmc probe. As mentioned by Grant in 7/7, the scope of devres is not lifetime hence it needs to be fixed. This limitation was also clearly described in the changelog of patch 7/7. However, I don't think that problem should cause a problem on boot, only a from the driver core (which, suprisingly, I don't see in your bootlog.) I suspect your crash is because you're not also testing with the MMC runtime PM series that is merging for v3.1. Kevin ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
