Re: [PATCH 1/2] ARM: OMAP2+: Allow clock alias provision from device tree

[Roger Quadros]

On 02/11/2013 06:07 PM, Sascha Hauer wrote:
> On Mon, Feb 11, 2013 at 05:44:23PM +0200, Roger Quadros wrote:
>> Currently on OMAP, it is not possible to specify a clock consumer
>> to any of the OMAP generated clocks using the device tree. This can pose
>> a problem for external devices that run off an OMAP clock as we
>> can't reliably provide a reference to the clock in the device tree.
> 
> There is an established way of providing clocks in the devicetree using
> the clocks/clock-names properties. Wouldn't it be better using this
> for OMAP aswell?
> 
I agree with you, but I'm not sure when this migration will be done.
Rajendra/Santosh might know better.

regards,
-roger

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Devicetree node to turn off LCD when backlight is 'disabled'

[Alex Courbot]

On 02/11/2013 03:25 PM, Tony Prisk wrote:

I was just wondering if the following would be an acceptable way to turn
off an lcd backlight when the pwm-backlight driver is set to level 0.
The LCD backlight is 'powered' by the gpio.

leds {
compatible = "gpio-leds";
backlight {
label = "lcd-power";
gpios = <&gpio 0 0 0>;  /* bank pin active_low */
linux,default-trigger = "backlight";
default-state = "on";
};
};


This would work... for the most common case of a FB blank event (as 
gpio-leds will be notified of it and switch your GPIO on/off according 
to the kind of event). There are a few drawbacks however:


1) You will have no control over the order of your power sequence. 
pwm-backlight also uses FB notifications to switch the PWM on/off. Which 
one will happen first will depend on the registration order.


2) This will only work on FB blank events. For instance, if someone 
writes "0" into the "brightness" property of your backlight's sysfs 
node, no FB blank event will be emitted and your GPIO will remain on.


Also this solution works for the simple case where you control the 
backlight using only a GPIO. It would be good to support more complex 
cases as well (I have to handle a GPIO and a regulator, for instance).


The "correct" way of doing this would be to let the pwm-backlight driver 
(or even the backlight framework) control the power status of the 
backlight itself. You can do this using the platform callbacks of 
pwm-backlight, but this will require a custom panel. Another possibility 
would be to use the power sequence framework within the backlight 
drivers, but I need to rewrite it first.


So as an ad-hoc solution, what you propose would certainly work - 
however I think this is a good opportunity to try and solve this problem 
more globally. Maybe we can start discussing about Power Sequences 2.0. :)


Alex.

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v3] gpio: Add device driver for GRGPIO cores and support custom accessors with gpio-generic

[Andreas Larsson]

This driver supports GRGPIO gpio cores available in the GRLIB VHDL IP
core library from Aeroflex Gaisler.

This also adds support to gpio-generic for using custom accessor
functions. The grgpio driver uses this to use ioread32be and iowrite32be
for big endian register accesses.

Signed-off-by: Andreas Larsson 
---
 .../devicetree/bindings/gpio/gpio-grgpio.txt   |   29 +++
 drivers/gpio/Kconfig   |8 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-generic.c|   26 ++-
 drivers/gpio/gpio-grgpio.c |  255 
 5 files changed, 310 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
 create mode 100644 drivers/gpio/gpio-grgpio.c

diff --git a/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt 
b/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
new file mode 100644
index 000..36f456f
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
@@ -0,0 +1,29 @@
+Aeroflex Gaisler GRGPIO General Purpose I/O cores.
+
+The GRGPIO GPIO core is available in the GRLIB VHDL IP core library.
+
+Note: In the ordinary ordinary environment for the GRGPIO core, a Leon SPARC
+system, these properties are built from information in the AMBA plug&play.
+
+Required properties:
+
+- name : Should be "GAISLER_GPIO" or "01_01a"
+
+- reg : Address and length of the register set for the device
+
+- interrupts : Interrupt numbers for this device
+
+Optional properties:
+
+- base : The base gpio number for the core. A dynamic base is used if not
+   present
+
+- nbits : The number of gpio lines. If not present driver assumes 32 lines.
+
+- irqmap : An array with an index for each gpio line. An index is either a 
valid
+   index into the interrupts property array, or 0x that indicates
+   no irq for that line. Driver provides no interrupt support if not
+   present.
+
+For further information look in the documentation for the GLIB IP core library:
+http://www.gaisler.com/products/grlib/grip.pdf
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ab97eb8..5472778 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -309,6 +309,14 @@ config GPIO_LYNXPOINT
  driver for GPIO functionality on Intel Lynxpoint PCH chipset
  Requires ACPI device enumeration code to set up a platform device.
 
+config GPIO_GRGPIO
+   tristate "Aeroflex Gaisler GRGPIO support"
+   depends on OF
+   select GPIO_GENERIC
+   help
+ Select this to support Aeroflex Gaisler GRGPIO cores from the GRLIB
+ VHDL IP core library.
+
 comment "I2C GPIO expanders:"
 
 config GPIO_ARIZONA
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4398034..f3b49a2 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_ARCH_DAVINCI)+= gpio-davinci.o
 obj-$(CONFIG_GPIO_EM)  += gpio-em.o
 obj-$(CONFIG_GPIO_EP93XX)  += gpio-ep93xx.o
 obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
+obj-$(CONFIG_GPIO_GRGPIO)  += gpio-grgpio.o
 obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
 obj-$(CONFIG_GPIO_IT8761E) += gpio-it8761e.o
 obj-$(CONFIG_GPIO_JANZ_TTL)+= gpio-janz-ttl.o
diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
index 05fcc0f..f854799 100644
--- a/drivers/gpio/gpio-generic.c
+++ b/drivers/gpio/gpio-generic.c
@@ -251,24 +251,25 @@ static int bgpio_setup_accessors(struct device *dev,
 struct bgpio_chip *bgc,
 bool be)
 {
+   struct bgpio_chip def;
 
switch (bgc->bits) {
case 8:
-   bgc->read_reg   = bgpio_read8;
-   bgc->write_reg  = bgpio_write8;
+   def.read_reg= bgpio_read8;
+   def.write_reg   = bgpio_write8;
break;
case 16:
-   bgc->read_reg   = bgpio_read16;
-   bgc->write_reg  = bgpio_write16;
+   def.read_reg= bgpio_read16;
+   def.write_reg   = bgpio_write16;
break;
case 32:
-   bgc->read_reg   = bgpio_read32;
-   bgc->write_reg  = bgpio_write32;
+   def.read_reg= bgpio_read32;
+   def.write_reg   = bgpio_write32;
break;
 #if BITS_PER_LONG >= 64
case 64:
-   bgc->read_reg   = bgpio_read64;
-   bgc->write_reg  = bgpio_write64;
+   def.read_reg= bgpio_read64;
+   def.write_reg   = bgpio_write64;
break;
 #endif /* BITS_PER_LONG >= 64 */
default:
@@ -276,7 +277,14 @@ static int bgpio_setup_accessors(struct device *dev,
return -EINVAL;
}
 
-   bgc->pin2mask = be ? bgpio_pin2mask_be : bgpio_pin2mask;
+   def.pin2mask = be ? bgpio_pin2mask_be : bgpio_pin2mask;
+
+   if (!bgc->read

Re: Devicetree node to turn off LCD when backlight is 'disabled'

[Thierry Reding]

On Mon, Feb 11, 2013 at 07:25:05PM +1300, Tony Prisk wrote:
> I was just wondering if the following would be an acceptable way to turn
> off an lcd backlight when the pwm-backlight driver is set to level 0.
> The LCD backlight is 'powered' by the gpio.
> 
> leds {
>   compatible = "gpio-leds";
>   backlight {
>   label = "lcd-power";
>   gpios = <&gpio 0 0 0>;  /* bank pin active_low */
>   linux,default-trigger = "backlight";
>   default-state = "on";
>   };
> };
> 
> The method has been tested by an end-user and confirmed as working - I
> just wanted to check whether it is the 'accepted' way of doing it.

I don't quite see how this is related to pwm-backlight. Maybe you can
post a more complete example? Representing the backlight power as a GPIO
controlled LED seems somewhat kludgy.

That said, there is currently no "accepted" way to use a GPIO to control
the power to the backlight in pwm-backlight. There was some work by Alex
(Cc'ed) to integrate this using generic power-sequences, but there was
some pushback on that. Your best bet currently would seem to integrate
this with the CDF (Common Display Framework). Unfortunately that'd mean
you'd need to write a whole new driver to abstract the panel. Even in
CDF there are ongoing discussions about how to hook it up with the
backlight framework. I know this doesn't give you a solution right away
but I think it's the best way to represent the actual hardware and it
takes into account a number of other aspect about displays as well.

Thierry


pgpDyBG14ari0.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 1/4] of/pci: Provide support for parsing PCI DT ranges property

[Thierry Reding]

On Mon, Feb 11, 2013 at 01:43:03PM -0600, Rob Herring wrote:
> On 02/11/2013 02:22 AM, Thierry Reding wrote:
> > From: Andrew Murray 
> > 
> > DT bindings for PCI host bridges often use the ranges property to describe
> > memory and IO ranges - this binding tends to be the same across 
> > architectures
> > yet several parsing implementations exist, e.g. arch/mips/pci/pci.c,
> > arch/powerpc/kernel/pci-common.c, arch/sparc/kernel/pci.c and
> > arch/microblaze/pci/pci-common.c (clone of PPC). Some of these duplicate
> > functionality provided by drivers/of/address.c.
> > 
> > This patch provides a common iterator-based parser for the ranges property, 
> > it
> > is hoped this will reduce DT representation differences between 
> > architectures
> > and that architectures will migrate in part to this new parser.
> > 
> > It is also hoped (and the motativation for the patch) that this patch will
> > reduce duplication of code when writing host bridge drivers that are 
> > supported
> > by multiple architectures.
> > 
> > This patch provides struct resources from a device tree node, e.g.:
> > 
> > u32 *last = NULL;
> > struct resource res;
> > while ((last = of_pci_process_ranges(np, res, last))) {
> > //do something with res
> > }
> > 
> > Platforms with quirks can then do what they like with the resource or 
> > migrate
> > common quirk handling to the parser. In an ideal world drivers can just 
> > request
> > the obtained resources and pass them on (e.g. pci_add_resource_offset).
> > 
> > Signed-off-by: Andrew Murray 
> > Signed-off-by: Liviu Dudau 
> > Signed-off-by: Thierry Reding 
> > ---
> >  drivers/of/address.c   | 63 
> > ++
> >  include/linux/of_address.h |  9 +++
> >  2 files changed, 72 insertions(+)
> > 
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 04da786..f607008 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -13,6 +13,7 @@
> >  #define OF_CHECK_COUNTS(na, ns)(OF_CHECK_ADDR_COUNT(na) && (ns) > 0)
> >  
> >  static struct of_bus *of_match_bus(struct device_node *np);
> > +static struct of_bus *of_find_bus(const char *name);
> 
> Can you move this function up to avoid the forward declaration.

It needs to be defined after the of_busses structure, which is defined
below the CONFIG_PCI block where of_pci_process_ranges() is defined. I'd
have to move that one as well and add another #ifdef CONFIG_PCI section.
If you prefer that I can do that.

> > +static struct of_bus *of_find_bus(const char *name)
> > +{
> > +   unsigned int i;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(of_busses); i++)
> > +   if (strcmp(name, of_busses[i].name) == 0)
>   ^
> space needed.

I don't understand. Do you want the space to go between '.' and "name"?

Thierry


pgpkGlFQMJesX.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v3 3/3] ARM: davinci: da850: override mmc DT node device name

[Manjunathappa, Prakash]

Populate OF_DEV_AUXDATA with desired device name expected by
davinci_mmc driver. Without this clk_get of davinci_mmc DT driver
fails.

Signed-off-by: Manjunathappa, Prakash 
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: devicetree-discuss@lists.ozlabs.org
Cc: c...@laptop.org
Cc: Sekhar Nori 
---
Since v2:
Rebased on top of v3.9/dt-2 branch of linux_davinci and reordered this patch.
Since v1:
No Change.

 arch/arm/mach-davinci/da8xx-dt.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 5404e92..fc62240 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -40,6 +40,8 @@ static void __init da8xx_init_irq(void)
 struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "watchdog", NULL),
+   OF_DEV_AUXDATA("ti,davinci-mmc-da830", 0x01c4, "davinci_mmc.0",
+   NULL),
{}
 };
 
-- 
1.7.4.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v3 2/3] ARM: davinci: da850: add mmc DT entries

[Manjunathappa, Prakash]

Add DT entry for MMC. Also add entry for pinmux information.
Tested:
1) Without GPIO card detection and EDMA support as DT support for
   GPIO and EDMA are yet come.
2) By creating/deleting files and mounting/unmounting the partition.

Signed-off-by: Manjunathappa, Prakash 
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: devicetree-discuss@lists.ozlabs.org
Cc: c...@laptop.org
Cc: Sekhar Nori 
---
Since v2:
Remove properties specifying for highspeed card capability.
Since v1:
Removed bitfields for specifying the device capabilty and accomodate
controller revision in compatible field.

 arch/arm/boot/dts/da850-evm.dts |7 +++
 arch/arm/boot/dts/da850.dtsi|   14 ++
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index f712fb6..78c8e54 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -39,6 +39,13 @@
wdt: wdt@1c21000 {
status = "okay";
};
+   mmc0: mmc@1c4 {
+   max-frequency = <5000>;
+   bus-width = <4>;
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc0_pins>;
+   };
};
nand_cs3@6200 {
status = "okay";
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 4b2262a..ebe7386 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -67,6 +67,15 @@
0x10 0x2200 0xff00
>;
};
+   mmc0_pins: pinmux_mmc_pins {
+   pinctrl-single,bits = <
+   /* MMCSD0_DAT[3] MMCSD0_DAT[2]
+* MMCSD0_DAT[1] MMCSD0_DAT[0]
+* MMCSD0_CMDMMCSD0_CLK
+*/
+   0x28 0x0022  0x00ff
+   >;
+   };
};
serial0: serial@1c42000 {
compatible = "ns16550a";
@@ -110,6 +119,11 @@
wdt: wdt@1c21000 {
compatible = "ti,davinci-wdt";
reg = <0x21000 0x1000>;
+   };
+   mmc0: mmc@1c4 {
+   compatible = "ti,davinci-mmc-da830";
+   reg = <0x4 0x1000>;
+   interrupts = <16>;
status = "disabled";
};
};
-- 
1.7.4.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v3 1/3] mmc: davinci_mmc: add DT support

[Manjunathappa, Prakash]

Adds device tree support for davinci_mmc. Also add binding documentation.
As of now in non-dma PIO mode and without GPIO card_detect/write_protect
option because of dependencies on EDMA and GPIO module DT support.

Signed-off-by: Manjunathappa, Prakash 
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: devicetree-discuss@lists.ozlabs.org
Cc: c...@laptop.org
Cc: Sekhar Nori 
Cc: mpor...@ti.com
---
Since v2:
Modified the default value for bus-width and removed the support for
highspeed card capabilties for now.
Since v1:
Modified DT parse function to take default values and accomodate controller
version in compatible field.

 .../devicetree/bindings/mmc/davinci_mmc.txt|   25 
 drivers/mmc/host/davinci_mmc.c |   65 +++-
 2 files changed, 88 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/davinci_mmc.txt

diff --git a/Documentation/devicetree/bindings/mmc/davinci_mmc.txt 
b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
new file mode 100644
index 000..247be0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
@@ -0,0 +1,25 @@
+* TI Highspeed MMC host controller for DaVinci
+
+The Highspeed MMC Host Controller on TI DaVinci family
+provides an interface for MMC, SD and SDIO types of memory cards.
+
+This file documents the properties used by the davinci_mmc driver.
+
+Required properties:
+- compatible:
+ Should be "ti,davinci-mmc-da830": for da830, da850, dm365
+ Should be "ti,davinci-mmc-dm355": for dm355, dm644x
+
+Optional properties:
+- bus-width: Number of data lines, can be <1>, <4>, or <8>, default <1>
+- max-frequency: Maximum operating clock frequency, default 25MHz.
+
+Example:
+   mmc0: mmc@1c4 {
+   compatible = "ti,davinci-mmc-da830",
+   reg = <0x4 0x1000>;
+   interrupts = <16>;
+   status = "okay";
+   bus-width = <4>;
+   max-frequency = <5000>;
+   };
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 27123f8..66ca6bf 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -34,6 +34,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -1157,16 +1159,74 @@ static void __init init_mmcsd_host(struct 
mmc_davinci_host *host)
mmc_davinci_reset_ctrl(host, 0);
 }
 
-static int __init davinci_mmcsd_probe(struct platform_device *pdev)
+static const struct of_device_id davinci_mmc_dt_ids[] = {
+   {
+   .compatible = "ti,davinci-mmc-dm355",
+   .data = (void *)MMC_CTLR_VERSION_1,
+   },
+   {
+   .compatible = "ti,davinci-mmc-da830",
+   .data = (void *)MMC_CTLR_VERSION_2,
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, davinci_mmc_dt_ids);
+
+static struct davinci_mmc_config
+   *mmc_parse_pdata(struct platform_device *pdev)
 {
+   struct device_node *np;
struct davinci_mmc_config *pdata = pdev->dev.platform_data;
+   const struct of_device_id *match =
+   of_match_device(of_match_ptr(davinci_mmc_dt_ids), &pdev->dev);
+   u32 data;
+
+   np = pdev->dev.of_node;
+   if (!np)
+   return pdata;
+
+   pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   dev_err(&pdev->dev, "Failed to allocate memory for struct 
davinci_mmc_config\n");
+   goto nodata;
+   }
+
+   if (match->data)
+   pdata->version = (u8)((int)match->data);
+
+   of_property_read_u32(np, "max-frequency", &pdata->max_freq);
+   if (!pdata->max_freq)
+   dev_info(&pdev->dev, "'max-frequency' property not specified, 
defaulting to 25MHz\n");
+
+   of_property_read_u32(np, "bus-width", &data);
+   switch (data) {
+   case 1:
+   case 4:
+   case 8:
+   pdata->wires = data;
+   break;
+   default:
+   pdata->wires = 1;
+   dev_info(&pdev->dev, "Unsupported buswidth, defaulting to 1 
bit\n");
+   }
+nodata:
+   return pdata;
+}
+
+static int __init davinci_mmcsd_probe(struct platform_device *pdev)
+{
+   struct davinci_mmc_config *pdata = NULL;
struct mmc_davinci_host *host = NULL;
struct mmc_host *mmc = NULL;
struct resource *r, *mem = NULL;
int ret = 0, irq = 0;
size_t mem_size;
 
-   /* REVISIT:  when we're fully converted, fail if pdata is NULL */
+   pdata = mmc_parse_pdata(pdev);
+   if (pdata == NULL) {
+   dev_err(&pdev->dev, "Can not get platform data\n");
+   return -ENOENT;
+   }
 
ret = -ENODEV;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1408,6 +1468,7 @@ static struct platform_driver davinci_mmcsd_driver = {
.name   = "davinci_m

[PATCH v3 0/3] Add DT support for davinci_mmc driver

[Manjunathappa, Prakash]

Patch set adds DT support for davinci_mmc driver and is
verified on da850-evm without card_detect/write_protect and
EDMA support.

This patch depends on below patches under review:
1) Patch "drivers/pinctrl: grab default handles from device core"
http://www.gossamer-threads.com/lists/linux/kernel/1664015?page=last
2) Patch "mmc: davinci: allow driver to work without DMA resource"
http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg18771.html

Applies on top of v3.9/dt-2 branch of linux_davinci tree:
git://gitorious.org/linux-davinci/linux-davinci.git

Since v2:
Modified the default value for bus-width and skipping the property 
specifications
for highspeed card capabilties for now. Re-ordered patch 2 and 3.
Since v1:
Modified the DT parse function to take default values, updated DT binding
documentation accordingly.

Manjunathappa, Prakash (3):
  mmc: davinci_mmc: add DT support
  ARM: davinci: da850: add mmc DT entries
  ARM: davinci: da850: override mmc DT node device name

 .../devicetree/bindings/mmc/davinci_mmc.txt|   25 
 arch/arm/boot/dts/da850-evm.dts|7 ++
 arch/arm/boot/dts/da850.dtsi   |   14 
 arch/arm/mach-davinci/da8xx-dt.c   |2 +
 drivers/mmc/host/davinci_mmc.c |   65 +++-
 5 files changed, 111 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/davinci_mmc.txt

-- 
1.7.4.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2 2/3] mmc: davinci_mmc: add DT support

[Sekhar Nori]

On 2/7/2013 1:27 PM, Manjunathappa, Prakash wrote:
> Adds device tree support for davinci_mmc. Also add binding documentation.
> Tested in non-dma PIO mode and without GPIO card_detect/write_protect
> option because of dependencies on EDMA and GPIO module DT support.
> 
> Signed-off-by: Manjunathappa, Prakash 
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> Cc: davinci-linux-open-sou...@linux.davincidsp.com
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: c...@laptop.org
> Cc: Sekhar Nori 
> Cc: mpor...@ti.com
> ---
> Since v1:
> Modified DT parse function to take default values and accomodate controller
> version in compatible field.
> 
>  .../devicetree/bindings/mmc/davinci_mmc.txt|   30 
>  drivers/mmc/host/davinci_mmc.c |   70 
> +++-
>  2 files changed, 99 insertions(+), 1 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mmc/davinci_mmc.txt
> 
> diff --git a/Documentation/devicetree/bindings/mmc/davinci_mmc.txt 
> b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
> new file mode 100644
> index 000..6717ab1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
> @@ -0,0 +1,30 @@
> +* TI Highspeed MMC host controller for DaVinci
> +
> +The Highspeed MMC Host Controller on TI DaVinci family
> +provides an interface for MMC, SD and SDIO types of memory cards.
> +
> +This file documents the properties used by the davinci_mmc driver.
> +
> +Required properties:
> +- compatible:
> + Should be "ti,davinci-mmc-da830": for da830, da850, dm365
> + Should be "ti,davinci-mmc-dm355": for dm355, dm644x
> +
> +Optional properties:
> +- bus-width: Number of data lines, can be <4>, or <8>, default <1>
> +- max-frequency: Maximum operating clock frequency, default 25MHz.
> +- mmc-cap-mmc-highspeed: Indicates support for MMC in high speed mode
> +- mmc-cap-sd-highspeed: Indicates support for SD in high speed mode
> +
> +Example:
> + mmc0: mmc@1c4 {
> + compatible = "ti,davinci-mmc-da830",
> + reg = <0x4 0x1000>;
> + interrupts = <16>;
> + status = "okay";
> + bus-width = <4>;
> + max-frequency = <5000>;
> + mmc-cap-sd-highspeed;
> + mmc-cap-mmc-highspeed;
> + };
> +
> diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
> index 27123f8..3f90316 100644
> --- a/drivers/mmc/host/davinci_mmc.c
> +++ b/drivers/mmc/host/davinci_mmc.c
> @@ -34,6 +34,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include 
>  
> @@ -1157,15 +1159,80 @@ static void __init init_mmcsd_host(struct 
> mmc_davinci_host *host)
>   mmc_davinci_reset_ctrl(host, 0);
>  }
>  
> -static int __init davinci_mmcsd_probe(struct platform_device *pdev)
> +static const struct of_device_id davinci_mmc_dt_ids[] = {
> + {
> + .compatible = "ti,davinci-mmc-dm355",
> + .data = (void *)MMC_CTLR_VERSION_1,
> + },
> + {
> + .compatible = "ti,davinci-mmc-da830",
> + .data = (void *)MMC_CTLR_VERSION_2,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, davinci_mmc_dt_ids);

If you are doing this why not also kill passing IP version through
platform data using a platform_device_id table? Look at what Afzal did
for drivers/rtc/rtc-omap.c

Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

RE: [PATCH v2 1/3] ARM: davinci: da850: override mmc DT node device name

[Manjunathappa, Prakash]

On Tue, Feb 12, 2013 at 11:16:21, Nori, Sekhar wrote:
> On 2/7/2013 1:27 PM, Manjunathappa, Prakash wrote:
> > Populate OF_DEV_AUXDATA with desired device name expected by
> > davinci_mmc driver. Without this clk_get of davinci_mmc DT driver
> > fails.
> 
> But there is no mmc DT support for DaVinci at this time. This patch
> should come after the driver DT support and .dts addition patches.
> 

Agreed, I will bring it up in the series.

> > diff --git a/arch/arm/mach-davinci/da8xx-dt.c 
> > b/arch/arm/mach-davinci/da8xx-dt.c
> > index 37c27af..3362ca4 100644
> > --- a/arch/arm/mach-davinci/da8xx-dt.c
> > +++ b/arch/arm/mach-davinci/da8xx-dt.c
> > @@ -39,9 +39,16 @@ static void __init da8xx_init_irq(void)
> >  
> >  #ifdef CONFIG_ARCH_DAVINCI_DA850
> >  
> > +static const struct of_dev_auxdata da8xx_auxdata[] __initconst = {
> > +   OF_DEV_AUXDATA("ti,davinci-mmc-da830", 0x01c4, "davinci_mmc.0",
> > +   NULL),
> > +   {},
> > +};
> > +
> >  static void __init da850_init_machine(void)
> >  {
> > -   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> > +   of_platform_populate(NULL, of_default_bus_match_table, da8xx_auxdata,
> > +   NULL);
> 
> This needs to be rebased on by v3.9/dt-2 branch. There are conflicts
> with the code already present.
> 

Yes, I will send it after rebasing on new branch.

Thanks,
Prakash

> Thanks,
> Sekhar
> 

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2 1/3] ARM: davinci: da850: override mmc DT node device name

[Sekhar Nori]

On 2/7/2013 1:27 PM, Manjunathappa, Prakash wrote:
> Populate OF_DEV_AUXDATA with desired device name expected by
> davinci_mmc driver. Without this clk_get of davinci_mmc DT driver
> fails.

But there is no mmc DT support for DaVinci at this time. This patch
should come after the driver DT support and .dts addition patches.

> diff --git a/arch/arm/mach-davinci/da8xx-dt.c 
> b/arch/arm/mach-davinci/da8xx-dt.c
> index 37c27af..3362ca4 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -39,9 +39,16 @@ static void __init da8xx_init_irq(void)
>  
>  #ifdef CONFIG_ARCH_DAVINCI_DA850
>  
> +static const struct of_dev_auxdata da8xx_auxdata[] __initconst = {
> + OF_DEV_AUXDATA("ti,davinci-mmc-da830", 0x01c4, "davinci_mmc.0",
> + NULL),
> + {},
> +};
> +
>  static void __init da850_init_machine(void)
>  {
> - of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> + of_platform_populate(NULL, of_default_bus_match_table, da8xx_auxdata,
> + NULL);

This needs to be rebased on by v3.9/dt-2 branch. There are conflicts
with the code already present.

Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 2/3] ASoC: add snd_soc_of_get_port_dai_name()

[Kuninori Morimoto]

Hi Stephen

> 2) Call an "of_xlate" function on that driver, passing it the "portspec"
> I mentioned above; the driver will interpret the portspec, maps it to
> the ASoC port name, and return it.
> 
> The DT binding for each audio component must define the list of valid
> port IDs, and the number of cells used to encode the value.
> 
> See for example the GPIO and PWM subsystem's of_xlate functions.

Hmm...
I guess this means struct snd_soc_dai_driver or similar has .of_xlate() 
callback ?
But, this simple-audio is "independent" from cpu/codec.

For example, basically, we can use this simple-audio for FSI-wm8903 matching.
But, this wm8903 is used on tegra too.
Then, FSI-wm8903 (which use simple-audio) needs .of_xlate on wm8903 driver to 
get interpreted port name,
but tegra-wm8903 don't need it.


Best regards
---
Kuninori Morimoto
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 3/3 v5] ASoC: simple-card: add Device Tree support

[Kuninori Morimoto]

Hi Stephen

> > +sound {
> > +   compatible = "simple-audio";
> ...
> > +   simple-audio,codec,dai = <&ak4648 0>;
> ...
> > +sh_fsi2: sh_fsi2@0xec23 {
> > +   compatible = "renesas,sh_fsi2";
> > +   reg = <0xec23 0x400>;
> > +   interrupt-parent = <&gic>;
> > +   interrupts = <0 146 0x4>;
> > +};
> 
> Note that the DT binding documentation for renesas,sh_fsi2 needs to define:
> 
> a) The value of the #sound-dai-cells property that's missing from the
> sh_fsi2 node.
> 
> b) The legal values for the "0" in the "simple-audio,codec,dai" property
> in the "sound" node above, and which DAI on the device each value
> represents.

Sorry, I couldn't understand this.
Do you mean like this ?

This example is assuming like this, and shows FSI-ak4642 sound

FSI port A -- ak4642
port B -- HDMI

sh_fsi2 has #sound-dai-cells, and ak4642 doesn't have it.
Does this solved a) ?

Do you mean sh_fsi2 needs something like "port-a = xxx" settings for b) ??

sound {
compatible = "simple-audio";

simple-audio,card-name = "FSI2A-AK4648";
simple-audio,format = "left_j";
simple-audio,cpu,dai = <&sh_fsi2 0>;
simple-audio,codec,dai = <&ak4648>;
simple-audio,codec,bitclock-master;
simple-audio,codec,frame-master;
simple-audio,codec,system-clock-frequency = <11289600>;
};

&i2c0 {
ak4648: ak4648@0x12 {
compatible = "asahi-kasei,ak4648";
reg = <0x12>;
};
};

sh_fsi2: sh_fsi2@0xec23 {
#sound-dai-cells = <2>;
compatible = "renesas,sh_fsi2";
reg = <0xec23 0x400>;
interrupt-parent = <&gic>;
interrupts = <0 146 0x4>;
};


Best regards
---
Kuninori Morimoto
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Sound record on Devkit8000 with DT boot issue

[Anil Kumar]

Hi Peter,

On Mon, Feb 11, 2013 at 11:44 PM, Peter Ujfalusi  wrote:
> Hi,
>
> On 02/11/2013 06:58 PM, Anil Kumar wrote:
>>> Here you should have something like:
>>> ti,audio-routing =
>>> "Ext Spk", "PREDRIVEL",
>>> "Ext Spk", "PREDRIVER",
>>> "MAINMIC", "Main Mic",
>>> "Main Mic", "Mic Bias 1";
>>>
>>> So you connect the MicBias1 to Main Mic. When you start playback MicBias1 
>>> will
>>> be turned on for you.
>>
>> I tried with this routing (next-20130211 tag kernel). But it is not
>> working for me.
>> So i have gone through other board and found snd_soc_dapm_route for
>>
>> 1) zoom2.c
>>{"MAINMIC", NULL, "Mic Bias 1"},
>>{"Mic Bias 1", NULL, "Ext Mic"},

I was giving zoom2 reference from kernel 3.8-rc5.

>>
>> 2) omap3pandora.c
>> {"MAINMIC", NULL, "Mic Bias 1"},
>> {"Mic Bias 1", NULL, "Mic (internal)"},

same as above comment.

>>
>> But for omap-twl4030.c it is
>> {"MAINMIC", NULL, "Main Mic"},
>> {"Main Mic", NULL, "Mic Bias 1"},
>>
>>  It Should will be as ?
>> {"MAINMIC", NULL, "Mic Bias 1"},
>> {"Mic Bias 1", NULL, "Main Mic"},
>>
>> Because with this i am able to get audio on Devkit8000 as
>>  ti,audio-routing =
>> "Ext Spk", "PREDRIVEL",
>> "Ext Spk", "PREDRIVER",
>> "MAINMIC", "Mic Bias 1",
>> "Mic Bias 1", "Main Mic";
>
> In 3.9 this should not work...
>
> linux-next should not have zoom2 at least and I converted the machine drivers
> as well in regards to micbias handling:
> e04d6e5 ASoC: twl4030: Convert MICBIAS to SUPPLY widget
> 57d61b9 ASoC: OMAP: Remove obsolete machine drivers for Zoom2 and SDP3430

My board is not botting with linux-next ((next-20130211). So i have
taken omap-twl4030.c changes from next-20130211
and merged into 3.8-rc5 as it does have. But missed changes for
twl4030.c. With these all changes it is working for me now .
Sorry for noise.

I am really thanks for this.
Anil
[...]
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH V4] i2c: add bcm2835 driver

[Stephen Warren]

This implements a very basic I2C host driver for the BCM2835 SoC. Missing
features so far are:

* 10-bit addressing.
* DMA.

Reviewed-by: Grant Likely 
Signed-off-by: Stephen Warren 
---
v4:
* Convert FIFO fill/drain loops from for to while.
* Don't WARN_ON transfer timeout.
* Use regular request_irq not devm_request_irq.
* Use i2c_add_adapter not i2c_add_numbered_adapter.
v3:
* Return i2c_add_numbered_adapter() from probe() directly.
v2:
* Implemented clock divider configuration based on desired bus rate.
* Make use of module_platform_driver().
* Removed use of devinit.
---
 .../devicetree/bindings/i2c/brcm,bcm2835-i2c.txt   |   20 ++
 drivers/i2c/busses/Kconfig |   12 +
 drivers/i2c/busses/Makefile|1 +
 drivers/i2c/busses/i2c-bcm2835.c   |  342 
 4 files changed, 375 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
 create mode 100644 drivers/i2c/busses/i2c-bcm2835.c

diff --git a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt 
b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
new file mode 100644
index 000..e9de375
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
@@ -0,0 +1,20 @@
+Broadcom BCM2835 I2C controller
+
+Required properties:
+- compatible : Should be "brcm,bcm2835-i2c".
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks : The clock feeding the I2C controller.
+
+Recommended properties:
+- clock-frequency : desired I2C bus clock frequency in Hz.
+
+Example:
+
+i2c@20205000 {
+   compatible = "brcm,bcm2835-i2c";
+   reg = <0x7e205000 0x1000>;
+   interrupts = <2 21>;
+   clocks = <&clk_i2c>;
+   clock-frequency = <10>;
+};
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 8bb810e..3cc40ab 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -319,6 +319,18 @@ config I2C_AU1550
  This driver can also be built as a module.  If so, the module
  will be called i2c-au1550.
 
+config I2C_BCM2835
+   tristate "Broadcom BCM2835 I2C controller"
+   depends on ARCH_BCM2835
+   help
+ If you say yes to this option, support will be included for the
+ BCM2835 I2C controller.
+
+ If you don't know what to do here, say N.
+
+ This support is also available as a module.  If so, the module
+ will be called i2c-bcm2835.
+
 config I2C_BLACKFIN_TWI
tristate "Blackfin TWI I2C support"
depends on BLACKFIN
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 6181f3f..a52a891 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_I2C_POWERMAC)+= i2c-powermac.o
 # Embedded system I2C/SMBus host controller drivers
 obj-$(CONFIG_I2C_AT91) += i2c-at91.o
 obj-$(CONFIG_I2C_AU1550)   += i2c-au1550.o
+obj-$(CONFIG_I2C_BCM2835)  += i2c-bcm2835.o
 obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
 obj-$(CONFIG_I2C_CBUS_GPIO)+= i2c-cbus-gpio.o
 obj-$(CONFIG_I2C_CPM)  += i2c-cpm.o
diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
new file mode 100644
index 000..ea4b08f
--- /dev/null
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -0,0 +1,342 @@
+/*
+ * BCM2835 master mode driver
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BCM2835_I2C_C  0x0
+#define BCM2835_I2C_S  0x4
+#define BCM2835_I2C_DLEN   0x8
+#define BCM2835_I2C_A  0xc
+#define BCM2835_I2C_FIFO   0x10
+#define BCM2835_I2C_DIV0x14
+#define BCM2835_I2C_DEL0x18
+#define BCM2835_I2C_CLKT   0x1c
+
+#define BCM2835_I2C_C_READ BIT(0)
+#define BCM2835_I2C_C_CLEARBIT(4) /* bits 4 and 5 both clear */
+#define BCM2835_I2C_C_ST   BIT(7)
+#define BCM2835_I2C_C_INTD BIT(8)
+#define BCM2835_I2C_C_INTT BIT(9)
+#define BCM2835_I2C_C_INTR BIT(10)
+#define BCM2835_I2C_C_I2CENBIT(15)
+
+#define BCM2835_I2C_S_TA   BIT(0)
+#define BCM2835_I2C_S_DONE BIT(1)
+#define BCM2835_I2C_S_TXW  BIT(2)
+#define BCM2835_I2C_S_RXR  BIT(3)
+#define BCM2835_I2C_S_TXD  BIT(4)
+#define BCM2835_I2C_S_RXD  BIT(5)
+#define BCM2835_I2C_S_TXE  BIT(6)
+#define BCM2835_I2C_S_RXF  BIT(7)
+#define BCM2835_I2C_S_ERR  BIT(8)
+#define BCM2835

Re: [PATCH V3] i2c: add bcm2835 driver

[Stephen Warren]

On 02/11/2013 03:52 PM, Wolfram Sang wrote:
> Hi Stephen,
> 
> On Fri, Feb 08, 2013 at 08:52:58PM -0700, Stephen Warren wrote:
>> This implements a very basic I2C host driver for the BCM2835 SoC. Missing
>> features so far are:
>>
>> * 10-bit addressing.
>> * DMA.
...
>> +ret = wait_for_completion_timeout(&i2c_dev->completion,
>> +  BCM2835_I2C_TIMEOUT);
>> +bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_C, BCM2835_I2C_C_CLEAR);
>> +if (WARN_ON(ret == 0)) {
>> +dev_err(i2c_dev->dev, "i2c transfer timed out\n");
>> +return -ETIMEDOUT;
>> +}
> 
> I'd suggest to skip the WARN_ON. Timeout is the expected case when you
> want to read from an EEPROM which is just in the process of
> erasing/writing data from the previous command.

I copied that from Tegra. Should that driver be changed too?

>> +adap = &i2c_dev->adapter;
>> +i2c_set_adapdata(adap, i2c_dev);
>> +adap->owner = THIS_MODULE;
>> +adap->class = I2C_CLASS_HWMON;
> 
> Do you really need the class?

If I grep for I2C_CLASS_HWMON, I see a ton of hits. I think I'll keep it
unless you strongly object, since it seems typical.

I'll fix up the other points you mentioned.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Fwd:

[Belisko Marek]

http://www.prinzicase.com/qnyigp.php?s=ot

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 12/12] clocksource: samsung-time: Add Device Tree support

[Tomasz Figa]

Hi Mark,

Thanks for your comments. See my replies inline.

On Monday 11 of February 2013 11:00:56 Mark Rutland wrote:
> On Sun, Feb 10, 2013 at 01:20:23PM +, Tomasz Figa wrote:
> > This patch adds support for parsing all platform-specific data from
> > Device Tree and instantiation using clocksource_of_init to
> > samsung-time
> > clocksource driver.
> > 
> > Cc: devicetree-discuss@lists.ozlabs.org
> > Signed-off-by: Tomasz Figa 
> > ---
> > 
> >  .../devicetree/bindings/arm/samsung-timer.txt  |  32 +++
> >  drivers/clocksource/samsung-time.c | 102
> >  - 2 files changed, 131 insertions(+), 3
> >  deletions(-)
> >  create mode 100644
> >  Documentation/devicetree/bindings/arm/samsung-timer.txt> 
> > diff --git a/Documentation/devicetree/bindings/arm/samsung-timer.txt
> > b/Documentation/devicetree/bindings/arm/samsung-timer.txt new file
> > mode 100644
> > index 000..8eb7030
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/samsung-timer.txt
> > @@ -0,0 +1,32 @@
> > +* Samsung PWM timer
> > +
> > +Samsung SoCs contain PWM timer blocks which can be used for system
> > clock source +and clock event timers.
> > +
> > +Be aware that this configuration is supported only on uniprocessor
> > platforms. +For SMP SoCs, SMP-aware timers should be used, like MCT.
> > +
> > +Required properties:
> > +- compatible : should be one of following:
> > +samsung,s3c24xx-pwm-timer - for 16-bit timers present on S3C24xx
> > +samsung,s3c64xx-pwm-timer - for 32-bit timers present on S3C64xx
> > and newer +- reg: base address and size of register area
> > +- interrupts: interrupt list for all five PWM timers.
> 
> Is this a set of combined interrupts, or one per timer?

It is one per timer, however the node represents a single PWM timer block 
that contains several timers (usually 5).

> Which order are they in?
> 
> Assuming they're one per timer, in order, how about something like:
> 
> "- interrupts: one interrupt per timer, starting at timer 0".

Sounds fine to me. I will modify the description in next version.

> > +- samsung,source-timer: index of timer to be used as clocksource
> > +- samsung,event-timer: index of timer to be used as clock event
> 
> Is there any reason this needs to be specified in the dt?

Yes. On some SoCs selected channels of PWM block can be used as PWM 
outputs and so thsoe cannot be used for system timers. This property makes 
it possible to specify channels used as system timers on particular 
platform (board).

> Can the driver not just select two arbitrary timers from the hardware?

In most cases I could statically choose channel 3 and 4 as it was done 
before my patches on S3C24xx and S3C64xx. I can make those channels 
default if others are not specified in properties.

> > +
> > +Optional properties:
> > +- samsung,prescale: PWM prescaler divisor (from 1 to 256)
> 
> It might be better to have this named "samsung,prescale-divisor" to make
> it clear to the average reader that its a divisor value rather than a
> multiplier value.

Right.

> 
> > +- samsung,divisor: PWM main divider divisor (1, 2, 4, 8 or 16)
> > +
> > +Example:
> > +   timer@7f006000 {
> > +   compatible = "samsung,s3c64xx-pwm-timer";
> > +   reg = <0x7f006000 0x1000>;
> > +   interrupt-parent = <&vic0>;
> > +   interrupts = <23>, <24>, <25>, <27>, <28>;
> > +   samsung,source-timer = <4>;
> > +   samsung,event-timer = <3>;
> > +   samsung,prescale = <2>;
> > +   samsung,divisor = <1>;
> > +   };
> > diff --git a/drivers/clocksource/samsung-time.c
> > b/drivers/clocksource/samsung-time.c index 19a1c8a..63d2992 100644
> > --- a/drivers/clocksource/samsung-time.c
> > +++ b/drivers/clocksource/samsung-time.c
> > @@ -14,6 +14,9 @@
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > +#include 
> > +#include 
> > +#include 
> > 
> >  #include 
> >  #include 
> > 
> > @@ -479,9 +482,11 @@ static void __init samsung_timer_resources(void)
> > 
> > unsigned long source_id = timer_source.source_id;
> > char devname[15];
> > 
> > -   timer_base = ioremap_nocache(timer_variant.reg_base, SZ_4K);
> > -   if (!timer_base)
> > -   panic("failed to map timer registers");
> > +   if (!timer_base) {
> > +   timer_base = ioremap_nocache(timer_variant.reg_base, SZ_4K);
> > +   if (!timer_base)
> > +   panic("failed to map timer registers");
> > +   }
> 
> You map 4K here, but the binding didn't mention that 4K is always the
> expected size of the reg.

This is a compatibility mapping for legacy (non-DT) platforms that will be 
removed once all platforms get moved to DT.

> > timerclk = clk_get(NULL, "timers");
> > if (IS_ERR(timerclk))
> > 
> > @@ -514,8 +519,92 @@ static void __init samsung_timer_resources(void)
> > 
> > clk_enable(tin_source);
> >  
> >  }
> > 
> > +enum {
> > +   TYPE_S3C24XX,
> > +   TYPE_S3C64XX,
> > +};
> > +
> > +#ifdef C

Re: [PATCH] of: Fix locking when calling of_get_next_available_child()

[Stephen Warren]

On 02/11/2013 03:19 PM, Grant Likely wrote:
> of_get_next_available_child() obtains the devtree_lock and then calls
> of_device_is_available() which also attempts to claim the lock. This is
> obviously incorrect and causes a deadlock on boot. Fix issue by adding
> an variant of of_device_is_available() which doesn't obtain the lock.

This patch forgets to update __of_device_is_available() to call
__of_get_property() rather than of_get_property() and hence doesn't
actually solve the problem.

You might want to make __of_device_is_available() static too.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V3] i2c: add bcm2835 driver

[Wolfram Sang]

Hi Stephen,

On Fri, Feb 08, 2013 at 08:52:58PM -0700, Stephen Warren wrote:
> This implements a very basic I2C host driver for the BCM2835 SoC. Missing
> features so far are:
> 
> * 10-bit addressing.
> * DMA.
> 
> Reviewed-by: Grant Likely 
> Signed-off-by: Stephen Warren 
> ---

...

> +struct bcm2835_i2c_dev {
> + struct device *dev;
> + void __iomem *regs;
> + struct clk *clk;
> + struct i2c_adapter adapter;
> + struct completion completion;
> + u32 msg_err;
> + u8 *msg_buf;
> + size_t msg_buf_remaining;
> +};
> +
> +static inline void bcm2835_i2c_writel(struct bcm2835_i2c_dev *i2c_dev,
> +   u32 reg, u32 val)
> +{
> + writel(val, i2c_dev->regs + reg);
> +}
> +
> +static inline u32 bcm2835_i2c_readl(struct bcm2835_i2c_dev *i2c_dev, u32 reg)
> +{
> + return readl(i2c_dev->regs + reg);
> +}

Hmm, not sure if those functions add readability, but no need to change.

> +
> +static void bcm2835_fill_txfifo(struct bcm2835_i2c_dev *i2c_dev)
> +{
> + u32 val;
> +
> + for (;;) {
> + if (!i2c_dev->msg_buf_remaining)
> + return;
> + val = bcm2835_i2c_readl(i2c_dev, BCM2835_I2C_S);
> + if (!(val & BCM2835_I2C_S_TXD))
> + break;
> + bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_FIFO,
> +*i2c_dev->msg_buf);
> + i2c_dev->msg_buf++;
> + i2c_dev->msg_buf_remaining--;
> + }

while (i2c_dev->msg_buf_remaining) ...

?

> +}
> +
> +static void bcm2835_drain_rxfifo(struct bcm2835_i2c_dev *i2c_dev)
> +{
> + u32 val;
> +
> + for (;;) {
> + if (!i2c_dev->msg_buf_remaining)
> + return;
> + val = bcm2835_i2c_readl(i2c_dev, BCM2835_I2C_S);
> + if (!(val & BCM2835_I2C_S_RXD))
> + break;
> + *i2c_dev->msg_buf = bcm2835_i2c_readl(i2c_dev,
> +   BCM2835_I2C_FIFO);
> + i2c_dev->msg_buf++;
> + i2c_dev->msg_buf_remaining--;
> + }

ditto?

...

> + ret = wait_for_completion_timeout(&i2c_dev->completion,
> +   BCM2835_I2C_TIMEOUT);
> + bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_C, BCM2835_I2C_C_CLEAR);
> + if (WARN_ON(ret == 0)) {
> + dev_err(i2c_dev->dev, "i2c transfer timed out\n");
> + return -ETIMEDOUT;
> + }

I'd suggest to skip the WARN_ON. Timeout is the expected case when you
want to read from an EEPROM which is just in the process of
erasing/writing data from the previous command.

...

> + adap = &i2c_dev->adapter;
> + i2c_set_adapdata(adap, i2c_dev);
> + adap->owner = THIS_MODULE;
> + adap->class = I2C_CLASS_HWMON;

Do you really need the class?

> + strlcpy(adap->name, "bcm2835 I2C adapter", sizeof(adap->name));
> + adap->algo = &bcm2835_i2c_algo;
> + adap->dev.parent = &pdev->dev;
> + adap->nr = -1;

If you are using '-1' anyhow, you could skip setting it and simply call
i2c_add_adapter(). Or you can init it here to pdev->id. Whatever you
prefer.

> +
> + bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_C, 0);
> +
> + return i2c_add_numbered_adapter(adap);
> +}
> +
> +static int bcm2835_i2c_remove(struct platform_device *pdev)
> +{
> + struct bcm2835_i2c_dev *i2c_dev = platform_get_drvdata(pdev);
> +
> + i2c_del_adapter(&i2c_dev->adapter);

Is it guaranteed that interrupts cannot occur anymore? Otherwise OOPS
might happen, since the adapter is cleared here already but devm will
remove the interrupt only a little later.

Thanks,

   Wolfram

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH next v2] OF: convert devtree lock from rw_lock to raw spinlock

[Grant Likely]

On Mon, Feb 11, 2013 at 10:21 PM, Rob Herring  wrote:
> On 02/11/2013 04:18 PM, Grant Likely wrote:
>> On Mon, Feb 11, 2013 at 7:54 PM, Rob Herring  wrote:
>>> I found the problem. of_get_next_available_child ->
>>> of_device_is_available -> of_get_property -> of_get_property. An
>>> unlocked version of of_device_is_available is needed here.
>>
>> Oops, I had testbooted on a single core machine which would mask the
>> issue. I've crafted a fix and am posting it for review before I apply
>> it.
>>
>
> I'm in the process of applying Stephen's fix.

I didn't actually see Stephen's fix until just now, after I had
already written, posted and pushed out basically the same thing. :-)

g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] of: fix recursive locking in of_get_next_available_child()

[Grant Likely]

On Mon, 11 Feb 2013 14:15:32 -0700, Stephen Warren  
wrote:
> From: Stephen Warren 
> 
> of_get_next_available_child() acquires devtree_lock, then calls
> of_device_is_available() which calls of_get_property() which calls
> of_find_property() which tries to re-acquire devtree_lock, thus causing
> deadlock.
> 
> To avoid this, create a new __of_device_is_available() which calls
> __of_get_property() instead, which calls __of_find_property(), which
> does not take the lock,. Update of_get_next_available_child() to call
> the new __of_device_is_available() since it already owns the lock.
> 
> Signed-off-by: Stephen Warren 

Thanks for looking at this Stephen. I ended up applying my version of
this patch though just because it was more convenient to do so. It was
pretty much identical anyway.

g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] of: Fix locking when calling of_get_next_available_child()

[Grant Likely]

On Mon, Feb 11, 2013 at 10:27 PM, Rob Herring  wrote:
> On 02/11/2013 04:19 PM, Grant Likely wrote:
>> of_get_next_available_child() obtains the devtree_lock and then calls
>> of_device_is_available() which also attempts to claim the lock. This is
>> obviously incorrect and causes a deadlock on boot. Fix issue by adding
>> an variant of of_device_is_available() which doesn't obtain the lock.
>>
>> Cc: Stephen Warren 
>> Cc: Rob Herring 
>> Signed-off-by: Grant Likely 
>> ---
>>  drivers/of/base.c |   15 +--
>>  1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index e8d65af..4af74b7 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -297,7 +297,7 @@ EXPORT_SYMBOL(of_machine_is_compatible);
>>   *  Returns 1 if the status property is absent or set to "okay" or "ok",
>>   *  0 otherwise
>>   */
>> -int of_device_is_available(const struct device_node *device)
>> +int __of_device_is_available(const struct device_node *device)
>>  {
>>   const char *status;
>>   int statlen;
>> @@ -313,6 +313,17 @@ int of_device_is_available(const struct device_node 
>> *device)
>>
>>   return 0;
>>  }
>> +
>> +int of_device_is_available(const struct device_node *device)
>
> Stephen's version wins because he preserved the documentation. :)

Pish. He just cut and paste the documentation so now we have 2 copies.
My version wins because it is already in my tree. So ptfff!

:-)

g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] of: Fix locking when calling of_get_next_available_child()

[Rob Herring]

On 02/11/2013 04:19 PM, Grant Likely wrote:
> of_get_next_available_child() obtains the devtree_lock and then calls
> of_device_is_available() which also attempts to claim the lock. This is
> obviously incorrect and causes a deadlock on boot. Fix issue by adding
> an variant of of_device_is_available() which doesn't obtain the lock.
> 
> Cc: Stephen Warren 
> Cc: Rob Herring 
> Signed-off-by: Grant Likely 
> ---
>  drivers/of/base.c |   15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index e8d65af..4af74b7 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -297,7 +297,7 @@ EXPORT_SYMBOL(of_machine_is_compatible);
>   *  Returns 1 if the status property is absent or set to "okay" or "ok",
>   *  0 otherwise
>   */
> -int of_device_is_available(const struct device_node *device)
> +int __of_device_is_available(const struct device_node *device)
>  {
>   const char *status;
>   int statlen;
> @@ -313,6 +313,17 @@ int of_device_is_available(const struct device_node 
> *device)
>  
>   return 0;
>  }
> +
> +int of_device_is_available(const struct device_node *device)

Stephen's version wins because he preserved the documentation. :)

Rob

> +{
> + unsigned long flags;
> + int rc;
> +
> + raw_spin_lock_irqsave(&devtree_lock, flags);
> + rc = __of_device_is_available(device);
> + raw_spin_unlock_irqrestore(&devtree_lock, flags);
> + return rc;
> +}
>  EXPORT_SYMBOL(of_device_is_available);
>  
>  /**
> @@ -404,7 +415,7 @@ struct device_node *of_get_next_available_child(const 
> struct device_node *node,
>   raw_spin_lock(&devtree_lock);
>   next = prev ? prev->sibling : node->child;
>   for (; next; next = next->sibling) {
> - if (!of_device_is_available(next))
> + if (!__of_device_is_available(next))
>   continue;
>   if (of_node_get(next))
>   break;
> 

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH next v2] OF: convert devtree lock from rw_lock to raw spinlock

[Grant Likely]

On Mon, Feb 11, 2013 at 7:54 PM, Rob Herring  wrote:
> On 02/11/2013 01:29 PM, Stephen Warren wrote:
>> On 02/08/2013 04:09 PM, Rob Herring wrote:
>>> On 02/06/2013 02:30 PM, Paul Gortmaker wrote:
>>>> From: Thomas Gleixner 
>>>>
>>>> With the locking cleanup in place (from "OF: Fixup resursive
>>>> locking code paths"), we can now do the conversion from the
>>>> rw_lock to a raw spinlock as required for preempt-rt.
>>>>
>>>> The previous cleanup and this conversion were originally
>>>> separate since they predated when mainline got raw spinlock (in
>>>> commit c2f21ce2e31286a "locking: Implement new raw_spinlock").
>>>>
>>>> So, at that point in time, the cleanup was considered plausible
>>>> for mainline, but not this conversion.  In any case, we've kept
>>>> them separate as it makes for easier review and better bisection.
>>>>
>>>> Signed-off-by: Thomas Gleixner 
>>>> [PG: taken from preempt-rt, update subject & add a commit log]
>>>> Signed-off-by: Paul Gortmaker 
>>>> ---
>>>>
>>>> [v2: recent commit e81b329 ("powerpc+of: Add /proc device tree
>>>>  updating to of node add/remove") added two more instances of
>>>>  write_unlock that also needed converting to raw_spin_unlock.
>>>>  Retested (boot) on sbc8548, defconfig builds on arm/sparc; no
>>>>  new warnings observed.]
>>>>
>>>>  arch/sparc/kernel/prom_common.c |   4 +-
>>>>  drivers/of/base.c   | 100 
>>>> ++--
>>>>  include/linux/of.h  |   2 +-
>>>>  3 files changed, 59 insertions(+), 47 deletions(-)
>>>
>>> Applied.
>>
>> This commit is present in next-20130211, and causes a boot failure
>> (hang) early while booting on Tegra. Reverting just this one commit
>> solves the issue.
>>
>> I'll see if I can track down where the issue is. Given the commit
>> description, I assume there's some new recursive lock issue that snuck
>> in between the previous fix for them and this commit? Any hints welcome.
>>
>> One thing I wonder looking at the patch: Most paths use
>> raw_spin_lock_irqsave() but a few use just raw_spin_lock(). I wonder how
>> that decision was made?
>
> I found the problem. of_get_next_available_child ->
> of_device_is_available -> of_get_property -> of_get_property. An
> unlocked version of of_device_is_available is needed here.

Oops, I had testbooted on a single core machine which would mask the
issue. I've crafted a fix and am posting it for review before I apply
it.

g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH next v2] OF: convert devtree lock from rw_lock to raw spinlock

[Rob Herring]

On 02/11/2013 04:18 PM, Grant Likely wrote:
> On Mon, Feb 11, 2013 at 7:54 PM, Rob Herring  wrote:
>> On 02/11/2013 01:29 PM, Stephen Warren wrote:
>>> On 02/08/2013 04:09 PM, Rob Herring wrote:
>>>> On 02/06/2013 02:30 PM, Paul Gortmaker wrote:
>>>>> From: Thomas Gleixner 
>>>>>
>>>>> With the locking cleanup in place (from "OF: Fixup resursive
>>>>> locking code paths"), we can now do the conversion from the
>>>>> rw_lock to a raw spinlock as required for preempt-rt.
>>>>>
>>>>> The previous cleanup and this conversion were originally
>>>>> separate since they predated when mainline got raw spinlock (in
>>>>> commit c2f21ce2e31286a "locking: Implement new raw_spinlock").
>>>>>
>>>>> So, at that point in time, the cleanup was considered plausible
>>>>> for mainline, but not this conversion.  In any case, we've kept
>>>>> them separate as it makes for easier review and better bisection.
>>>>>
>>>>> Signed-off-by: Thomas Gleixner 
>>>>> [PG: taken from preempt-rt, update subject & add a commit log]
>>>>> Signed-off-by: Paul Gortmaker 
>>>>> ---
>>>>>
>>>>> [v2: recent commit e81b329 ("powerpc+of: Add /proc device tree
>>>>>  updating to of node add/remove") added two more instances of
>>>>>  write_unlock that also needed converting to raw_spin_unlock.
>>>>>  Retested (boot) on sbc8548, defconfig builds on arm/sparc; no
>>>>>  new warnings observed.]
>>>>>
>>>>>  arch/sparc/kernel/prom_common.c |   4 +-
>>>>>  drivers/of/base.c   | 100 
>>>>> ++--
>>>>>  include/linux/of.h  |   2 +-
>>>>>  3 files changed, 59 insertions(+), 47 deletions(-)
>>>>
>>>> Applied.
>>>
>>> This commit is present in next-20130211, and causes a boot failure
>>> (hang) early while booting on Tegra. Reverting just this one commit
>>> solves the issue.
>>>
>>> I'll see if I can track down where the issue is. Given the commit
>>> description, I assume there's some new recursive lock issue that snuck
>>> in between the previous fix for them and this commit? Any hints welcome.
>>>
>>> One thing I wonder looking at the patch: Most paths use
>>> raw_spin_lock_irqsave() but a few use just raw_spin_lock(). I wonder how
>>> that decision was made?
>>
>> I found the problem. of_get_next_available_child ->
>> of_device_is_available -> of_get_property -> of_get_property. An
>> unlocked version of of_device_is_available is needed here.
> 
> Oops, I had testbooted on a single core machine which would mask the
> issue. I've crafted a fix and am posting it for review before I apply
> it.
> 

I'm in the process of applying Stephen's fix.

Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH] of: Fix locking when calling of_get_next_available_child()

[Grant Likely]

of_get_next_available_child() obtains the devtree_lock and then calls
of_device_is_available() which also attempts to claim the lock. This is
obviously incorrect and causes a deadlock on boot. Fix issue by adding
an variant of of_device_is_available() which doesn't obtain the lock.

Cc: Stephen Warren 
Cc: Rob Herring 
Signed-off-by: Grant Likely 
---
 drivers/of/base.c |   15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index e8d65af..4af74b7 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -297,7 +297,7 @@ EXPORT_SYMBOL(of_machine_is_compatible);
  *  Returns 1 if the status property is absent or set to "okay" or "ok",
  *  0 otherwise
  */
-int of_device_is_available(const struct device_node *device)
+int __of_device_is_available(const struct device_node *device)
 {
const char *status;
int statlen;
@@ -313,6 +313,17 @@ int of_device_is_available(const struct device_node 
*device)
 
return 0;
 }
+
+int of_device_is_available(const struct device_node *device)
+{
+   unsigned long flags;
+   int rc;
+
+   raw_spin_lock_irqsave(&devtree_lock, flags);
+   rc = __of_device_is_available(device);
+   raw_spin_unlock_irqrestore(&devtree_lock, flags);
+   return rc;
+}
 EXPORT_SYMBOL(of_device_is_available);
 
 /**
@@ -404,7 +415,7 @@ struct device_node *of_get_next_available_child(const 
struct device_node *node,
raw_spin_lock(&devtree_lock);
next = prev ? prev->sibling : node->child;
for (; next; next = next->sibling) {
-   if (!of_device_is_available(next))
+   if (!__of_device_is_available(next))
continue;
if (of_node_get(next))
break;
-- 
1.7.10.4

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 2/2] powerpc/5200: Use the gpt* labels to simplify mpc5200 dts files

[Anatolij Gustschin]

On Fri,  8 Feb 2013 08:02:51 +
Grant Likely  wrote:

> The DTC labels feature allows a dts file to reference a node without
> having to reproduce the entire node hierarchy above it. We can use this
> to simplify the MPC5200 board dts files by referencing the gpt nodes by
> label.
> 
> Cc: Anatolij Gustschin 
> Signed-off-by: Grant Likely 
> ---
>  arch/powerpc/boot/dts/a3m071.dts|6 ++--
>  arch/powerpc/boot/dts/a4m072.dts|   27 --
>  arch/powerpc/boot/dts/cm5200.dts|6 ++--
>  arch/powerpc/boot/dts/digsy_mtc.dts |   14 ++
>  arch/powerpc/boot/dts/media5200.dts |6 ++--
>  arch/powerpc/boot/dts/motionpro.dts |   26 --
>  arch/powerpc/boot/dts/mucmc52.dts   |   48 
>  arch/powerpc/boot/dts/o2d.dtsi  |   25 +
>  arch/powerpc/boot/dts/pcm030.dts|   48 ++--
>  arch/powerpc/boot/dts/pcm032.dts|   45 ++
>  arch/powerpc/boot/dts/uc101.dts |   52 
> ++-
>  11 files changed, 69 insertions(+), 234 deletions(-)

Applied, thanks!

Anatolij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 1/2] powerpc/5200: Add Lite5200 on-board LEDs as devices

[Anatolij Gustschin]

On Fri,  8 Feb 2013 08:02:50 +
Grant Likely  wrote:

> The Lite5200 evaluation board has a number of debug LEDs that Linux
> doesn't know about yet. This change adds a gpio-leds stanza to the
> lite5200 device tree so that the correct driver can get hooked up.
> 
> Also, make use of the dtc labels feature to reduce the number of source
> lines required to add the gpio-controller property to the general
> purpose timer nodes. In addition, the required #gpio-cells properties
> are added to the common mpc5200b dtsi include file so that each board
> doesn't need to add them explicitly. This still doesn't enable gpio
> mode, 'gpio-controller' is required for that, but it means less work
> needs to be done by board ports.
> 
> Cc: Anatolij Gustschin 
> Signed-off-by: Grant Likely 
> ---
>  arch/powerpc/boot/dts/lite5200b.dts |   23 +++
>  arch/powerpc/boot/dts/mpc5200b.dtsi |   25 +
>  2 files changed, 36 insertions(+), 12 deletions(-)

Applied, thanks!

Anatolij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v4 02/10] s5p-fimc: Add device tree support for FIMC devices

[Stephen Warren]

On 02/09/2013 03:29 PM, Sylwester Nawrocki wrote:
> On 02/09/2013 01:32 AM, Stephen Warren wrote:
>> On 02/08/2013 05:05 PM, Sylwester Nawrocki wrote:
>>> On 02/09/2013 12:21 AM, Stephen Warren wrote:
 On 02/08/2013 04:16 PM, Sylwester Nawrocki wrote:
> On 02/07/2013 12:40 AM, Stephen Warren wrote:
>>> diff --git
>>> a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
>>> b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
>>
>>> +Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC)
>>> +--
 ...
>>> +For every fimc node a numbered alias should be present in the
>>> aliases node.
>>> +Aliases are of the form fimc, whereis an integer (0...N)
>>> specifying
>>> +the IP's instance index.
...
>>> Different compatible values might not work, when for example there
>>> are 3 IPs out of 4 of one type and the fourth one of another type.
>>> It wouldn't even by really different types, just quirks/little
>>> differences between them, e.g. no data path routed to one of other IPs.
>>
>> I was thinking of using feature-/quirk-oriented properties. For example,
>> if there's a port on 3 of the 4 devices to connect to some other IP
>> block, simply include a boolean property to indicate whether that port
>> is present. It would be in 3 of the nodes but not the 4th.
> 
> Yes, I could add several properties corresponding to all members of this
> [3] data structure. But still it is needed to clearly identify the IP
> block in a set of the hardware instances.

Why? What decisions will be made based on the identify of the IP block
instance that wouldn't be covered by DT properties that describe which
features/bugs/... the IP block instance has?

>>> Then to connect e.g. MIPI-CSIS.0 to FIMC.2 at run time an index of the
>>> MIPI-CSIS needs to be written to the FIMC.2 data input control register.
>>> Even though MIPI-CSIS.N are same in terms of hardware structure they
>>> still
>>> need to be distinguished as separate instances.
>>
>> Oh, so you're using the alias ID as the value to write into the FIMC.2
>> register for that. I'm not 100% familiar with aliases, but they seem
>> like a more user-oriented naming thing to me, whereas values for hooking
>> up intra-SoC routing are an unrelated namespace semantically, even if
>> the values happen to line up right now. Perhaps rather than a Boolean
>> property I mentioned above, use a custom property to indicate the ID
>> that the FIMC.2 object knows the MIPI-CSIS.0 object as? While this seems
> 
> That could be 'reg' property in the MIPI-CSIS.0 'port' subnode that
> links it to the image sensor node ([4], line 165). Because MIPI-CSIS IP
> blocks are immutably connected to the SoC camera physical MIPI CSI-2
> interfaces, and the physical camera ports have fixed assignment to the
> MIPI-CSIS devices..  This way we could drop alias ID for the MIPI-CSIS
> nodes. And their instance index that is required for the top level
> driver which exposes topology and the routing capabilities to user space
> could be restored from the reg property value by subtracting a fixed
> offset.

I suppose that would work. It feels a little indirect, and I think means
that the driver needs to go find some child node defining its end of
some link, then find the node representing the other end of the link,
then read properties out of that other node to find the value. That
seems a little unusual, but I guess it would work. I'm not sure of the
long-term implications of doing that kind of thing. You'd want to run
the idea past some DT maintainers/experts.

...
> I can see aliases used in bindings of multiple devices: uart, spi, sound
> interfaces, gpio, ... And all bindings seem to impose some rules on how
> their aliases are created.

Do you have specific examples? I really don't think the bindings should
be dictating the alias values.

>> After all, what happens in some later SoC where you have two different
>> types of module that feed into the common module, such that type A
>> sources have IDs 0..3 in the common module, and type B sources have IDs
>> 4..7 in the common module - you wouldn't want to require alias ISs 4..7
>> for the type B DT nodes.
> 
> There is no need to write alias ID directly into registers, and actually
> it doesn't really happen. But we need to know that, for example camera A
> is connected to physical MIPI CSI-2 channel 0 and to capture video with
> DMA engine of FIMC.2 we need to set FIMC.2 input register to link it to
> MIPI-CSIS 0.

OK, so the IDs are selecting which register to write, or which mux
settings to access. That's pretty much semantically the same thing.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 2/5] ARM: dts: exynos5250-arndale: Add PMIC node entry

[amit daniel kachhap]

The V2 of this patch is posted with comments suggested by Anil and
some missing LDO's.

Thanks,
Amit Daniel

On Wed, Feb 6, 2013 at 9:56 PM, Tushar Behera  wrote:
> On 02/07/2013 11:19 AM, Kumar, Anil wrote:
>> On Thu, Feb 07, 2013 at 10:45:26, Tushar Behera wrote:
>>> From: Amit Daniel Kachhap 
>>>
>>> Added S5M8767 PMIC DT nodes to Arndale board.
>>>
>>> Signed-off-by: Amit Daniel Kachhap 
>>> Signed-off-by: Sachin Kamat 
>>> Signed-off-by: Tushar Behera 
>>> ---
>>>  arch/arm/boot/dts/exynos5250-arndale.dts |  213 
>>> +-
>>>  1 files changed, 212 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
>>> b/arch/arm/boot/dts/exynos5250-arndale.dts
>>> index 9ce40df..b40a02f 100644
>>> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
>>> @@ -25,7 +25,218 @@
>>>  };
>>>
>>>  i2c@12C6 {
>>> -status = "disabled";
>>> +status = "okay";
>>
>> Is there any need to change status "okay" here as in dtsi file it is
>> by default okay ?
>>
>
> Right, there is no need for setting it as "okay" explicitly.
>
> --
> Tushar Behera
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH V2] ARM: dts: exynos5250-arndale: Add PMIC node entry

[Amit Daniel Kachhap]

Added S5M8767 PMIC DT nodes for Arndale board. Only the used
LDO's/BUCK are defined here. Also the nodes describe the default/reset
state LDO's and no power mangement tuning is implemented. The usage
desription can be found in s5m8767 device tree binding documentation.

Cc: Tushar Behera 
Signed-off-by: Amit Daniel Kachhap 
---
This patch is based on Samsung kernel maintainer's for-next tree.
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next

The s5m8767 DT support is already accepted by regulator's maintainer and is
present in the tree,
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Changes since V1:
* Removed un-necessary status field settings.
* Added entries for LDO's 22,23,25,26 and BUCK9  
 
 arch/arm/boot/dts/exynos5250-arndale.dts |  257 +-
 1 files changed, 256 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 63572f9..f50f09c 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -25,7 +25,262 @@
};
 
i2c@12C6 {
-   status = "disabled";
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-max-bus-freq = <2>;
+   samsung,i2c-slave-addr = <0x66>;
+   gpios = <&gpb3 0 2 3 0>,
+   <&gpb3 1 2 3 0>;
+
+   s5m8767_pmic@66 {
+   compatible = "samsung,s5m8767-pmic";
+   reg = <0x66>;
+
+   s5m8767,pmic-buck2-dvs-voltage = <130>;
+   s5m8767,pmic-buck3-dvs-voltage = <110>;
+   s5m8767,pmic-buck4-dvs-voltage = <120>;
+   s5m8767,pmic-buck-dvs-gpios = <&gpd1 0 1 0 0>,
+   <&gpd1 1 1 0 0>,
+   <&gpd1 2 1 0 0>;
+   s5m8767,pmic-buck-ds-gpios = <&gpx2 3 1 0 0>,
+   <&gpx2 4 1 0 0>,
+   <&gpx2 5 1 0 0>;
+   regulators {
+   ldo1_reg: LDO1 {
+   regulator-name = "VDD_ALIVE_1.0V";
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   regulator-always-on;
+   regulator-boot-on;
+   op_mode = <1>;
+   };
+
+   ldo2_reg: LDO2 {
+   regulator-name = "VDD_28IO_DP_1.35V";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-always-on;
+   regulator-boot-on;
+   op_mode = <1>;
+   };
+
+   ldo3_reg: LDO3 {
+   regulator-name = "VDD_COMMON1_1.8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   regulator-boot-on;
+   op_mode = <1>;
+   };
+
+   ldo4_reg: LDO4 {
+   regulator-name = "VDD_IOPERI_1.8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   op_mode = <1>;
+   };
+
+   ldo5_reg: LDO5 {
+   regulator-name = "VDD_EXT_1.8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   regulator-boot-on;
+   op_mode = <1>;
+   };
+
+   ldo6_reg: LDO6 {
+   regulator-name = "VDD_MPLL_1.1V";
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   regulator-always-on;
+   regulator-boot-on;
+   

[PATCH V2] ARM: dts: add minimal DT support for DevKit8000

[Anil Kumar]

DevKit8000 is a beagle board clone from Timll, sold by
armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D,
S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and
JTAG interface.

This patch adds the basic DT support for devkit8000. At this time, Information
of twl4030, MMC1, I2C1, leds and there pim mux information are added.

Signed-off-by: Anil Kumar 
Tested-by: Thomas Weber 
---

 -This patch is based on top of kernel 3.8-rc5.

 -Tested on Devkit8000.

For V2:

 -Change model name as "TimLL OMAP3 Devkit8000"
 -Change compatible as "timll,omap3-devkit8000"
 -Doing i2c1 pinmux default with pinctrl-single driver instead of i2c1
  driver probe time.

:100644 100644 5ebb44f... 22ebc76... M  arch/arm/boot/dts/Makefile
:00 100644 000... dc59272... A  arch/arm/boot/dts/omap3-devkit8000.dts
:100644 100644 53cb380b.. ccecb76... M  arch/arm/mach-omap2/board-generic.c
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/omap3-devkit8000.dts |  126 
 arch/arm/mach-omap2/board-generic.c|1 +
 3 files changed, 128 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5ebb44f..22ebc76 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -102,6 +102,7 @@ dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
imx28-tx28.dtb
 dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle.dtb \
+   omap3-devkit8000.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts 
b/arch/arm/boot/dts/omap3-devkit8000.dts
new file mode 100644
index 000..dc59272
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -0,0 +1,126 @@
+/*
+ * Author: Anil Kumar 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "omap3.dtsi"
+/ {
+   model = "TimLL OMAP3 Devkit8000";
+   compatible = "timll,omap3-devkit8000", "ti,omap3";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>;  /* 256 MB */
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&leds_pins>;
+
+   heartbeat {
+   label = "devkit8000::led1";
+   gpios = <&gpio6 26 0>;  /* 186 -> LED1 */
+   default-state = "on";
+   linux,default-trigger = "heartbeat";
+   };
+
+   mmc {
+   label = "devkit8000::led2";
+   gpios = <&gpio6 3 0>;   /* 163 -> LED2 */
+   default-state = "on";
+   linux,default-trigger = "none";
+   };
+
+   usr {
+   label = "devkit8000::led3";
+   gpios = <&gpio6 4 0>;   /* 164 -> LED3 */
+   default-state = "on";
+   linux,default-trigger = "usr";
+};
+
+   };
+};
+
+&omap3_pmx_core {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c1_pins>;
+
+   leds_pins: pinmux_led_pins {
+   pinctrl-single,pins = <
+   0x168 0x4   /* GPIO_163 */
+   0x16c 0x4   /* GPIO_164 */
+   0x1b0 0x4   /* GPIO_186 */
+
+   >;
+   };
+
+   i2c1_pins: pinmux_i2c1_pins {
+   pinctrl-single,pins = <
+   0x188 0x118 /* I2C1_SCL */
+   0x18c 0x118 /* I2C1_SDA */
+>;
+   };
+};
+
+&i2c1 {
+   clock-frequency = <260>;
+
+   twl: twl@48 {
+   reg = <0x48>;
+   interrupts = <7>;   /* SYS_NIRQ cascaded to intc */
+   interrupt-parent = <&intc>;
+   };
+};
+
+&i2c2 {
+   status = "disabled";
+};
+
+&i2c3 {
+   status = "disabled";
+};
+
+/include/ "twl4030.dtsi"
+
+&mmc1 {
+   vmmc-supply = <&vmmc1>;
+   vmmc_aux-supply = <&vsim>;
+   bus-width = <8>;
+};
+
+&mmc2 {
+   status = "disabled";
+};
+
+&mmc3 {
+   status = "disabled";
+};
+
+&wdt2 {
+   status = "disabled";
+};
+
+&mcbsp1 {
+   status = "disabled";
+};
+
+&mcbsp2 {
+   status = "disabled";
+};
+
+&mcbsp3 {
+   status = "disabled";
+};
+
+&mcbsp4 {
+   status = "disabled";
+};
+
+&mcbsp5 {
+   status = "disabled";
+};
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 53cb380..ccecb76 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -110,6 +110,7 @@ MACHINE_END
 
 static const char *omap3_gp_boards_compat[] __initdata = {
"ti,omap3-beagle",
+   "timll,omap3-d

Sound record on Devkit8000 with DT boot issue

[Anil Kumar]

Hi All,

I am working on Devkit8000 and adding DT support for that. I am trying
to add sound DT node support for this boards.
I have nearly done with this but facing issue on record. I do not have
much knowledge of twl4030 audio codec but with
small Hack[1] (as MainMic connected to the input jack)  i am able to
record sound on Devkit8000.
I do not know that MICBIAS1_EN can be enable by amixer commands.
Could you please help me to get out of this ?


1) Hack [1]

diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index 63b280b..6780681 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -1473,7 +1473,7 @@ static const struct snd_soc_dapm_widget
twl4030_dapm_widgets[] = {
SND_SOC_DAPM_SUPPLY("micbias2 select", TWL4030_REG_MICBIAS_CTL, 6, 0,
NULL, 0),

-   SND_SOC_DAPM_MICBIAS("Mic Bias 1", TWL4030_REG_MICBIAS_CTL, 0, 0),
+   SND_SOC_DAPM_MICBIAS("Mic Bias 1", TWL4030_REG_MICBIAS_CTL, 0, 1),
SND_SOC_DAPM_MICBIAS("Mic Bias 2", TWL4030_REG_MICBIAS_CTL, 1, 0),
SND_SOC_DAPM_MICBIAS("Headset Mic Bias", TWL4030_REG_MICBIAS_CTL, 2, 0),


2) Sound DT node patch for Devkit8000

diff --git a/arch/arm/boot/dts/omap3-
devkit8000.dts b/arch/arm/boot/dts/omap3-devkit8000.dts
index dc59272..5f3eec0 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -44,11 +44,22 @@
 };

};
+
+   sound {
+   compatible = "ti,omap-twl4030";
+   ti,model = "devkit8000";
+
+   ti,mcbsp = <&mcbsp2>;
+   ti,codec = <&twl_audio>;
+   };
 };

 &omap3_pmx_core {
pinctrl-names = "default";
-   pinctrl-0 = <&i2c1_pins>;
+   pinctrl-0 = <
+   &i2c1_pins
+   &mcbsp2_pins
+   >;

leds_pins: pinmux_led_pins {
pinctrl-single,pins = <
@@ -65,6 +76,21 @@
0x18c 0x118 /* I2C1_SDA */
 >;
};
+
+   mcbsp2_pins: pinmux_mcbsp2_pins {
+pinctrl-single,pins = <
+   /*
+* MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT,
+* MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT
+*/
+   0x10c 0x01000100
+   /*
+* MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT,
+* MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT
+*/
+   0x110 0x0100
+   >;
+   };
 };

 &i2c1 {
@@ -74,6 +100,14 @@
reg = <0x48>;
interrupts = <7>;   /* SYS_NIRQ cascaded to intc */
interrupt-parent = <&intc>;
+
+   twl_audio: audio {
+   compatible = "ti,twl4030-audio";
+   codec {
+   ti,ramp_delay_value = <3>;
+   ti,offset_cncl_path = <0x31>;
+   };
+   };
};
 };

3) Playback amixer commands
   amixer set 'PredriveR Mixer AudioR2' on
   amixer set 'PredriveL Mixer AudioL2' on
   amixer set PreDriv 100 unmute
   amixer set 'DAC2 Digital Fine' 100

Thanks,
Anil
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] drivers: net: Remove remaining alloc/OOM messages

[Vladimir Kondratiev]

On Thursday, February 07, 2013 01:46:27 PM Joe Perches wrote:
> alloc failures already get standardized OOM
> messages and a dump_stack.
> 
> For the affected mallocs around these OOM messages:
> 
> Converted kmallocs with multiplies to kmalloc_array.
> Converted a kmalloc/memcpy to kmemdup.
> Removed now unused stack variables.
> Removed unnecessary parentheses.
> Neatened alignment.
> 
> Signed-off-by: Joe Perches 
> 

For wil6210:

Acked--by: Vladimir Kondratiev 

Thanks, Vladimir
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] gpio: Add device driver for GRGPIO cores

[Anton Vorontsov]

On Mon, Feb 04, 2013 at 11:27:33AM +0100, Andreas Larsson wrote:
[...]
> >>2) The grgpio_to_irq function is very hardware specific, and there is of
> >>course no gpio_to_irq support in gpio-generic.
> >
> >Well, the idea about gpio-generic is to use the pieces you need
> >IIRC. You may override.
> 
> Ah, I see, bgpio_init is exported, so I might be able use that from
> my driver to get rid of some functions. There is support for BE I
> saw now. It seems broken to me (flips bits, not bytes), but that can
> be fixed.

No, it is not broken. :-) There is a BE-notation of GPIO numbering. BE/LE
issue is also valid for bits. Please don't "fix" this. :)

If you need to introduce byte endianness support in addition, that's fine.

Thanks,

Anton
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 3.9] Driver for 7-segment displays connected over GPIOs

[Pavel Machek]

Hi!

>  wrote:
> 
> > This patch series implements a simple driver for 7-segment displays
> > connected over GPIOs through a BCD encoder. The userspace interface of
> > the driver is very simple: just a "value" file in the sysfs directory
> > of the device, which can be written to (changes the value shown on the
> > 7-segment display) and read (gives the current value).
> 
> The ARM Integrator AP and CP base boards I have here have
> 7-segment displays as well. But it's not on GPIO but dedicated
> registers, so I could implement these as, e.g. LEDs.
> 
> But with this framework I'd just make a driver that pokes directly
> into the registers.
> 
> However as Russell points out, this needs to be thought through.
> I have a period on my display between the two characters, so
> how do we model that period?

Well, 7 segment display can be used for 0-9 A-F (very readable) and
0-9 a-z if you stretch stuff a bit, as done on TI chronos for
example... Would it make sense to simply display a string? Up to four
letters with up-to 4 '.' space characters...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2] media: rc: gpio-ir-recv: add support for device tree parsing

[Mauro Carvalho Chehab]

Em Sat, 09 Feb 2013 01:45:42 +0100
Sebastian Hesselbarth  escreveu:

> On 02/09/2013 01:03 AM, Mauro Carvalho Chehab wrote:
> > Em Fri,  8 Feb 2013 21:38:07 +0100
> > Sebastian Hesselbarth  escreveu:
> >
> >> This patch adds device tree parsing for gpio_ir_recv platform_data and
> >> the mandatory binding documentation. It basically follows what we already
> >> have for e.g. gpio_keys. All required device tree properties are OS
> >> independent but an optional property allow linux specific support for rc
> >> maps.
> >>
> >> There was a similar patch sent by Matus Ujhelyi but that discussion
> >> died after the first reviews.
> >>
> >> Signed-off-by: Sebastian Hesselbarth
> >> ---
> >> Changelog
> >>
> >> v1->v2:
> >> - get rid of ptr returned by _get_devtree_pdata()
> >> - check for of_node instead for NULL pdata
> >> - remove unneccessary double check for gpios property
> >> - remove unneccessary #ifdef CONFIG_OF around match table
> >>
> >> Cc: Grant Likely
> >> Cc: Rob Herring
> >> Cc: Rob Landley
> >> Cc: Mauro Carvalho Chehab
> >> Cc: Sebastian Hesselbarth
> >> Cc: Benoit Thebaudeau
> >> Cc: David Hardeman
> >> Cc: Trilok Soni
> >> Cc: Sylwester Nawrocki
> >> Cc: Matus Ujhelyi
> >> Cc: devicetree-discuss@lists.ozlabs.org
> >> Cc: linux-...@vger.kernel.org
> >> Cc: linux-ker...@vger.kernel.org
> >> Cc: linux-me...@vger.kernel.org
> >> ---
> >>   .../devicetree/bindings/media/gpio-ir-receiver.txt |   16 ++
> >>   drivers/media/rc/gpio-ir-recv.c|   57 
> >> 
> >>   2 files changed, 73 insertions(+)
> >>   create mode 100644 
> >> Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt 
> >> b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> >> new file mode 100644
> >> index 000..8589f30
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> >> @@ -0,0 +1,16 @@
> >> +Device-Tree bindings for GPIO IR receiver
> >> +
> >> +Required properties:
> >> +  - compatible = "gpio-ir-receiver";
> >> +  - gpios: OF device-tree gpio specification.
> >> +
> >> +Optional properties:
> >> +  - linux,rc-map-name: Linux specific remote control map name.
> >> +
> >> +Example node:
> >> +
> >> +  ir: ir-receiver {
> >> +  compatible = "gpio-ir-receiver";
> >> +  gpios =<&gpio0 19 1>;
> >> +  linux,rc-map-name = "rc-rc6-mce";
> >
> > Please change this to:
> > linux,rc-map-name = RC_MAP_RC6_MCE;
> >
> > (as defined at include/media/rc-map.h).
> 
> Mauro,
> 
> this is not possible in device tree bindings. Device tree properties
> can only carry numeric or string types (and some other stuff) but no
> OS specific enumerations. So using strings is the only option here.
> 
> > The idea of having those strings defined at the same header file is to:
> 
> Unfortunately, device tree blobs don't know about linux header files.
> 
> That leaves two options:
> - allow the user to supply a string of the map in his device tree description
>and risk that there may be a broken map name
> - remove linux,rc-map-name from DT binding and let the user configure in
>from user space (which is propably best choice anyway)
> 
> I tried both, DT supplied map name and ir-keytable from userspace
> both work fine.

IMO, the first option is better, e. g. letting the device tree have the
string there.

Regards,
Mauro
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v3 03/13] mmc: provide a standard MMC device-tree binding parser centrally

[Markus Pargmann]

On Wed, Feb 06, 2013 at 08:46:50PM +0100, Guennadi Liakhovetski wrote:
> + /* Parse Card Detection */
> + if (of_find_property(np, "non-removable", &len)) {
> + host->caps |= MMC_CAP_NONREMOVABLE;
> + } else {
> + bool explicit_inv_cd, gpio_inv_cd = false;
> +
> + explicit_inv_cd = !!of_find_property(np, "cd-inverted", &len);

You could use of_property_read_bool here

> + /* Parse Write Protection */
> + explicit_inv_wp = !!of_find_property(np, "wp-inverted", &len);

and here.

Markus

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2] media: rc: gpio-ir-recv: add support for device tree parsing

[Mauro Carvalho Chehab]

Em Fri,  8 Feb 2013 21:38:07 +0100
Sebastian Hesselbarth  escreveu:

> This patch adds device tree parsing for gpio_ir_recv platform_data and
> the mandatory binding documentation. It basically follows what we already
> have for e.g. gpio_keys. All required device tree properties are OS
> independent but an optional property allow linux specific support for rc
> maps.
> 
> There was a similar patch sent by Matus Ujhelyi but that discussion
> died after the first reviews.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Changelog
> 
> v1->v2:
> - get rid of ptr returned by _get_devtree_pdata()
> - check for of_node instead for NULL pdata
> - remove unneccessary double check for gpios property
> - remove unneccessary #ifdef CONFIG_OF around match table
> 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: Rob Landley 
> Cc: Mauro Carvalho Chehab 
> Cc: Sebastian Hesselbarth 
> Cc: Benoit Thebaudeau 
> Cc: David Hardeman 
> Cc: Trilok Soni 
> Cc: Sylwester Nawrocki 
> Cc: Matus Ujhelyi 
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> ---
>  .../devicetree/bindings/media/gpio-ir-receiver.txt |   16 ++
>  drivers/media/rc/gpio-ir-recv.c|   57 
> 
>  2 files changed, 73 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt 
> b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> new file mode 100644
> index 000..8589f30
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> @@ -0,0 +1,16 @@
> +Device-Tree bindings for GPIO IR receiver
> +
> +Required properties:
> + - compatible = "gpio-ir-receiver";
> + - gpios: OF device-tree gpio specification.
> +
> +Optional properties:
> + - linux,rc-map-name: Linux specific remote control map name.
> +
> +Example node:
> +
> + ir: ir-receiver {
> + compatible = "gpio-ir-receiver";
> + gpios = <&gpio0 19 1>;
> + linux,rc-map-name = "rc-rc6-mce";

Please change this to:
linux,rc-map-name = RC_MAP_RC6_MCE;

(as defined at include/media/rc-map.h).

The idea of having those strings defined at the same header file is to:

- make sure that the same keyboard is spelled at the same way on
all places;

- avoid people to duplicate IR keytables, using different names;

- help userspace to get the right table. In the future, the
plan is to remove all keytables from kernelspace, keeping there just the
name of the keytable. The existing userspace code (ir-keytables, part
of v4l-utils) use the keytable name to dynamically load the right table
in runtime and to switch the IR core to only handle the protocol that
it is associated with the loaded keytable.

Regards,
Mauro
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH RESEND] media: rc: gpio-ir-recv: add support for device tree parsing

[Mauro Carvalho Chehab]

Em Fri, 8 Feb 2013 19:12:31 +0100
Sebastian Hesselbarth  escreveu:

> On Fri, Feb 8, 2013 at 6:57 PM, Mauro Carvalho Chehab
>  wrote:
> > Em Wed, 06 Feb 2013 18:18:22 +0100
> > Sebastian Hesselbarth  escreveu:
> >> On 02/06/2013 02:48 PM, Sylwester Nawrocki wrote:
> >> > On 02/06/2013 09:03 AM, Sebastian Hesselbarth wrote:
> >> >> This patch adds device tree parsing for gpio_ir_recv platform_data and
> >> >> the mandatory binding documentation. It basically follows what we 
> >> >> already
> >> >> have for e.g. gpio_keys. All required device tree properties are OS
> >> >> independent but optional properties allow linux specific support for rc
> >> >> protocols and maps.
> >> >>
> >> >> There was a similar patch sent by Matus Ujhelyi but that discussion
> >> >> died after the first reviews.
> >> >>
> >> >> Signed-off-by: Sebastian Hesselbarth
> >> >> ---
> >> > ...
> >> >> diff --git 
> >> >> a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt 
> >> >> b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> >> >> new file mode 100644
> >> >> index 000..937760c
> >> >> --- /dev/null
> >> >> +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> >> >> @@ -0,0 +1,20 @@
> >> >> +Device-Tree bindings for GPIO IR receiver
> >> >> +
> >> >> +Required properties:
> >> >> +  - compatible = "gpio-ir-receiver";
> >> >> +  - gpios: OF device-tree gpio specification.
> >> >> +
> >> >> +Optional properties:
> >> >> +  - linux,allowed-rc-protocols: Linux specific u64 bitmask of allowed
> >> >> +  rc protocols.
> >> >
> >> > You likely need to specify in these bindings documentation which bit
> >> > corresponds to which RC protocol.
> >> >
> >> > I'm not very familiar with the RC internals, but why it has to be
> >> > specified statically in the device tree, when decoding seems to be
> >> > mostly software defined ? I might be missing something though..
> >>
> >> Sylwester,
> >>
> >> I am not familiar with RC internals either. Maybe somebody with more
> >> insight in media/rc can clarify the specific needs for the rc subsystem.
> >> I was just transferring the DT support approach taken by gpio_keys to
> >> gpio_ir_recv as I will be using it on mach-dove/cubox soon.
> >
> > The allowed rc protocol field are there for devices with hardware IR
> > support, where only a limited set of remote protocols can be decoded.
> >
> > For software decoders RC_BIT_ALL is the proper setup. Users of course
> > can change it via sysfs at runtime, or a software decoder may be
> > disabled at compilation time by not selecting its CONFIG_* var.
> 
> Mauro,
> 
> thanks for the clarification! So for v2 of the patch, you all agree on 
> removing
> linux,allowed-rc-protocols from device node properties?

Yes.
> 
> >> > Couldn't this be configured at run time, with all protocols allowed
> >> > as the default ?
> >>
> >> Actually, this is how the internal rc code works. If there is nothing
> >> defined for allowed_protocols it assumes that all protocols are supported.
> >> That is why above node properties are optional.
> >>
> >> About the binding documentation of allowed_protocols, rc_map, or the
> >> default behavior of current linux code, I don't think they will stay
> >> in-sync for long.
> >
> > Why not? The rc_map name is used either by Kernelspace or by Userspace,
> > in order to provide the IR keycode name that matches a given keytable.
> >
> > There's no plans to change it, even in the long term.
> 
> Actually, I wasn't referring to changing names or bitmasks but updating
> the binding documentation with new allowed protocols or supported map
> names.
> 
> For linux,rc-map-name property it should be enough to just write that it
> relates to linux rc subsystem rc_map name - how to actually
> set it to a useful name is documented in rc subsystem.

It should be one of the names that are there at include/media/rc-map.h.

> And if the
> property is not set at all, DT parsing in gpio_ir_recv assumes the
> subsystem (or gpio_ir_recv platform) default, IIRC "rc-none".

The right default should be "rc-empty", but please use the macro RC_MAP_EMPTY
instead.

> I'll respin a v2 without allowed-protocols property soon.
> 
> Sebastian


-- 

Cheers,
Mauro
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH RESEND] media: rc: gpio-ir-recv: add support for device tree parsing

[Mauro Carvalho Chehab]

Em Wed, 06 Feb 2013 18:18:22 +0100
Sebastian Hesselbarth  escreveu:

> On 02/06/2013 02:48 PM, Sylwester Nawrocki wrote:
> > On 02/06/2013 09:03 AM, Sebastian Hesselbarth wrote:
> >> This patch adds device tree parsing for gpio_ir_recv platform_data and
> >> the mandatory binding documentation. It basically follows what we already
> >> have for e.g. gpio_keys. All required device tree properties are OS
> >> independent but optional properties allow linux specific support for rc
> >> protocols and maps.
> >>
> >> There was a similar patch sent by Matus Ujhelyi but that discussion
> >> died after the first reviews.
> >>
> >> Signed-off-by: Sebastian Hesselbarth
> >> ---
> > ...
> >> diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt 
> >> b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> >> new file mode 100644
> >> index 000..937760c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> >> @@ -0,0 +1,20 @@
> >> +Device-Tree bindings for GPIO IR receiver
> >> +
> >> +Required properties:
> >> +  - compatible = "gpio-ir-receiver";
> >> +  - gpios: OF device-tree gpio specification.
> >> +
> >> +Optional properties:
> >> +  - linux,allowed-rc-protocols: Linux specific u64 bitmask of allowed
> >> +  rc protocols.
> >
> > You likely need to specify in these bindings documentation which bit
> > corresponds to which RC protocol.
> >
> > I'm not very familiar with the RC internals, but why it has to be
> > specified statically in the device tree, when decoding seems to be
> > mostly software defined ? I might be missing something though..
> 
> Sylwester,
> 
> I am not familiar with RC internals either. Maybe somebody with more
> insight in media/rc can clarify the specific needs for the rc subsystem.
> I was just transferring the DT support approach taken by gpio_keys to
> gpio_ir_recv as I will be using it on mach-dove/cubox soon.

The allowed rc protocol field are there for devices with hardware IR
support, where only a limited set of remote protocols can be decoded.

For software decoders RC_BIT_ALL is the proper setup. Users of course
can change it via sysfs at runtime, or a software decoder may be
disabled at compilation time by not selecting its CONFIG_* var.

> > Couldn't this be configured at run time, with all protocols allowed
> > as the default ?
> 
> Actually, this is how the internal rc code works. If there is nothing
> defined for allowed_protocols it assumes that all protocols are supported.
> That is why above node properties are optional.
> 
> About the binding documentation of allowed_protocols, rc_map, or the
> default behavior of current linux code, I don't think they will stay
> in-sync for long. 

Why not? The rc_map name is used either by Kernelspace or by Userspace,
in order to provide the IR keycode name that matches a given keytable.

There's no plans to change it, even in the long term.

Regards,
Mauro.

-- 

Cheers,
Mauro
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] drivers: net: Remove remaining alloc/OOM messages

[John W. Linville]

On Thu, Feb 07, 2013 at 01:46:27PM -0800, Joe Perches wrote:
> alloc failures already get standardized OOM
> messages and a dump_stack.
> 
> For the affected mallocs around these OOM messages:
> 
> Converted kmallocs with multiplies to kmalloc_array.
> Converted a kmalloc/memcpy to kmemdup.
> Removed now unused stack variables.
> Removed unnecessary parentheses.
> Neatened alignment.
> 
> Signed-off-by: Joe Perches 

No objection...

Acked-by: John W. Linville 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

RE: [PATCH] ARM: dts: add minimal DT support for DevKit8000

[AnilKumar]

Hi Mark,

Thanks for the review comments. Please find my comments inline.

On Thu, Feb 07, 2013 at 23:09:49, Mark Rutland wrote:
> Hello,
> 
> I have a couple of minor comments.
> 
> On Thu, Feb 07, 2013 at 02:11:37PM +, Anil Kumar wrote:
> > DevKit8000 is a beagle board clone from Timll, sold by armkits.com.
> > The DevKit8000 has RS232 serial port, LCD, DVI-D, S-Video, Ethernet, 
> > SD/MMC, keyboard, camera, SPI, I2C, USB and JTAG interface.
> >
> > This patch adds the basic DT support for devkit8000. At this time, 
> > Information of twl4030, MMC1, I2C1, leds and there pim mux 
> > information are
> added.
> >
> > Signed-off-by: Anil Kumar 
> > Tested-by: Thomas Weber 
> > ---
> >
> >  -This patch is based on top of kernel 3.8-rc5.
> >
> >  -Tested on Devkit8000.
> >
> 
> [...]
> 
> > diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
> > b/arch/arm/boot/dts/omap3-devkit8000.dts
> > new file mode 100644
> > index 000..9864fd7
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/omap3-devkit8000.dts
> > @@ -0,0 +1,125 @@
> > +/*
> > + * Anil Kumar 
> > + *
> > + * This program is free software; you can redistribute it and/or 
> > +modify
> > + * it under the terms of the GNU General Public License version 2 
> > +as
> > + * published by the Free Software Foundation.
> > + */
> > +/dts-v1/;
> > +
> > +/include/ "omap3.dtsi"
> > +/ {
> > +   model = "TI OMAP3 Devkit8000";
> 
> Should this not be "TimLL Devkit8000" ?

Hmm..  I think it will be better as  "TimLL OMAP3 Devkit8000"  as this board
is omap3 based.

> 
> > +   compatible = "ti,omap3-devkit8000", "ti,omap3";
> 
> "timll,devkit8000" ?

I think it will be better  as  "timll,omap3-devkit8000"  as this board is
omap3 based.
 
Thanks,
Anil
[...]



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Wifi basics documents

[sl reddy]

Thank you

I will start from here

Thanks & Regards

O S L Reddy
slredd...@gmail.com


On Fri, Feb 8, 2013 at 3:50 PM, Arend van Spriel  wrote:

> On 02/08/2013 10:53 AM, sl reddy wrote:
> > any successions will be helpful for me
>
> My *suggestion* would be:
>
> http://wireless.kernel.org/en/developers/Documentation
>
> For what it is worth, below is some terrible ascii art.
>
> Gr. AvS
>
> Fullmac model:
>
>  user-space (libnl)
>   |
> +--+  v
> | cfg80211 |--o nl80211 api
> +--+
>  ^
>  |
>  v
> +--+
> | fullmac  |--o netdev
> | driver   |
> +--+
>
> Softmac model:
>
>  user-space (libnl)
>   |
> +--+  v
> | cfg80211 |--o nl80211 api
> +--+
>  ^
>  |
>  v
> +--+
> | mac80211 |--o netdev
> +--+
>  ^
>  |
>  v
> +--+
> | softmac  |
> | driver   |
> +--+
>
>
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Wifi basics documents

[Arend van Spriel]

On 02/08/2013 10:53 AM, sl reddy wrote:
> any successions will be helpful for me

My *suggestion* would be:

http://wireless.kernel.org/en/developers/Documentation

For what it is worth, below is some terrible ascii art.

Gr. AvS

Fullmac model:

 user-space (libnl)
  |
+--+  v
| cfg80211 |--o nl80211 api
+--+
 ^
 |
 v
+--+
| fullmac  |--o netdev
| driver   |
+--+

Softmac model:

 user-space (libnl)
  |
+--+  v
| cfg80211 |--o nl80211 api
+--+
 ^
 |
 v
+--+
| mac80211 |--o netdev
+--+
 ^
 |
 v
+--+
| softmac  |
| driver   |
+--+


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Wifi basics documents

[sl reddy]

Hi


Thanks for reply i referred  that site (wireless.kernel.org) as you said
there is   lot of information
but i am bit confused in getting right information because i am not
interested much about hardware architecture as of now
I need clear picture of software architecture
but in the website there is lot of information so bit confused where to
start

any successions will be helpful for me


Thanks & Regards

O S L Reddy
slredd...@gmail.com


On Fri, Feb 8, 2013 at 2:04 PM, Arend van Spriel  wrote:

> On 02/08/2013 07:55 AM, Onteddu Slreddy wrote:
> > Hello All,
> >
> >
> > I recently joined this group the group.
> >
> > Can anybody suggest me places where I can get Documents which will
> explain
> > wifi  Architecture in brief i would like to know details like
> >
> > In Linux for embedded systems:
> > What is the software architecture for wifi
> > What are each folders in kernel/net and kernel/drivers/net refer
> to
> > What is wpa_supplicant how to know which version I have to use
> > How to get  familiar with words like nl802.11, mac802.11, wext,
> > copat-wireless, compatwireless-openmac
> > If I have to add a new chip driver what are the checklist points
> i
> > have to see
> >
> > My Quesitions may be basic kindly bare with me
> > If any body have self prepared documents that will be great help for me
>
> 802.11 is a IEEE standard that is freely available for download.
> Regarding Linux architecture and infrastructure there is a lot of
> information to be found on wireless.kernel.org.
>
> Regards,
> Arend
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Wifi basics documents

[Arend van Spriel]

On 02/08/2013 07:55 AM, Onteddu Slreddy wrote:
> Hello All,
> 
> 
> I recently joined this group the group.
> 
> Can anybody suggest me places where I can get Documents which will explain
> wifi  Architecture in brief i would like to know details like
> 
> In Linux for embedded systems:
> What is the software architecture for wifi
> What are each folders in kernel/net and kernel/drivers/net refer to
> What is wpa_supplicant how to know which version I have to use
> How to get  familiar with words like nl802.11, mac802.11, wext,
> copat-wireless, compatwireless-openmac
> If I have to add a new chip driver what are the checklist points i
> have to see
> 
> My Quesitions may be basic kindly bare with me
> If any body have self prepared documents that will be great help for me

802.11 is a IEEE standard that is freely available for download.
Regarding Linux architecture and infrastructure there is a lot of
information to be found on wireless.kernel.org.

Regards,
Arend



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v5] iio: Add OF support

[Jonathan Cameron]

On 07/02/13 17:09, Guenter Roeck wrote:

Provide bindings and parse OF data during initialization.

Signed-off-by: Guenter Roeck 

Looks fine to me.  Will give it a few more days to see what others
have to say.

Thanks Guenter

---
v5:
- Updated examples in bindings.
v4:
- Fixed wrong parameter to dummy of_iio_channel_get_by_name if CONFIG_OF is
   undefined, and wrong return value.
- Initialize indio_dev->of_node in iio_device_register if the calling driver
   neglected to do it.
v3:
- Cleaned up documentation (formatting, left-over clock references)
- Updated bindings description to permit sub-devices
- When searching for iio devices, use the pointer to the iio device type instead
   of strcmp. Rename iio_dev_type to iio_device_type (to match other device
   types) and make it global for that purpose. Check the OF node first, then the
   device type, as the node is less likely to match.
- Move the common code in of_iio_channel_get and of_iio_channel_get_all to
   __of_iio_channel_get.
- Return NULL from of_iio_channel_get_by_name if nothing is found, or
   an error if there is a problem with consistency or if the provider device is
   not yet available.
- In iio_channel_get, return if of_iio_channel_get_by_name() returns a channel
   or an error, and continue otherwise.
v2:
- Rebased to iio/togreg
- Documentation update per feedback
- Dropped io-channel-output-names from the bindings document. The property is
   not used in the code, and it is not entirely clear what it would be used for.
   If there is a need for it, we can add it back in later on.
- Don't export OF specific API calls
- For OF support, no longer depend on iio_map
- Add #ifdef CONFIG_OF where appropriate, and ensure that the code still builds
   if it is not selected.
- Change iio_channel_get to take device pointer as argument instead of device
   name. Retain old API as of_iio_channel_get_sys.
- iio_channel_get now works for both OF and non-OF configurations
- Use regulator to get vref for max1363 driver.

  .../devicetree/bindings/iio/iio-bindings.txt   |   97 +++
  drivers/iio/iio_core.h |1 +
  drivers/iio/industrialio-core.c|8 +-
  drivers/iio/inkern.c   |  171 
  4 files changed, 275 insertions(+), 2 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/iio/iio-bindings.txt

diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt 
b/Documentation/devicetree/bindings/iio/iio-bindings.txt
new file mode 100644
index 000..1182845
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
@@ -0,0 +1,97 @@
+This binding is a work-in-progress. It is derived from clock bindings,
+and based on suggestions from Lars-Peter Clausen [1].
+
+Sources of IIO channels can be represented by any node in the device
+tree. Those nodes are designated as IIO providers. IIO consumer
+nodes use a phandle and IIO specifier pair to connect IIO provider
+outputs to IIO inputs. Similar to the gpio specifiers, an IIO
+specifier is an array of one or more cells identifying the IIO
+output on a device. The length of an IIO specifier is defined by the
+value of a #io-channel-cells property in the IIO provider node.
+
+[1] http://marc.info/?l=linux-iio&m=135902119507483&w=2
+
+==IIO providers==
+
+Required properties:
+#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes
+  with a single IIO output and 1 for nodes with multiple
+  IIO outputs.
+
+Example for a simple configuration with no trigger:
+
+   adc: voltage-sensor@35 {
+   compatible = "maxim,max1139";
+   reg = <0x35>;
+   #io-channel-cells = <1>;
+   };
+
+Example for a configuration with trigger:
+
+   adc@35 {
+   compatible = "some-vendor,some-adc";
+   reg = <0x35>;
+
+   adc1: iio-device@0 {
+   #io-channel-cells = <1>;
+   /* other properties */
+   };
+   adc2: iio-device@1 {
+   #io-channel-cells = <1>;
+   /* other properties */
+   };
+   };
+
+==IIO consumers==
+
+Required properties:
+io-channels:   List of phandle and IIO specifier pairs, one pair
+   for each IIO input to the device. Note: if the
+   IIO provider specifies '0' for #io-channel-cells,
+   then only the phandle portion of the pair will appear.
+
+Optional properties:
+io-channel-names:
+   List of IIO input name strings sorted in the same
+   order as the io-channels property. Consumers drivers
+   will use io-channel-names to match IIO input names
+   with IIO specifiers.
+io-channel-ranges:
+   Empty property indicating that child nodes can inherit named
+   IIO channels from this node. Useful for bus no

Re: [PATCH] drivers: net: Remove remaining alloc/OOM messages

[Arend van Spriel]

On 02/07/2013 10:46 PM, Joe Perches wrote:
> alloc failures already get standardized OOM
> messages and a dump_stack.
> 
> For the affected mallocs around these OOM messages:
> 
> Converted kmallocs with multiplies to kmalloc_array.
> Converted a kmalloc/memcpy to kmemdup.
> Removed now unused stack variables.
> Removed unnecessary parentheses.
> Neatened alignment.

for brcm80211 driver files listed below:

Acked-by: Arend van Spriel 
> Signed-off-by: Joe Perches 
> ---
> Let me know if you want multiple small patches instead.
> 
>  drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c |  5 +--
>  drivers/net/wireless/brcm80211/brcmfmac/usb.c  |  7 ++--


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH] ARM: dts: add minimal DT support for DevKit8000

[Anil Kumar]

DevKit8000 is a beagle board clone from Timll, sold by
armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D,
S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and
JTAG interface.

This patch adds the basic DT support for devkit8000. At this time, Information
of twl4030, MMC1, I2C1, leds and there pim mux information are added.

Signed-off-by: Anil Kumar 
Tested-by: Thomas Weber 
---

 -This patch is based on top of kernel 3.8-rc5.

 -Tested on Devkit8000.

:100644 100644 5ebb44f... 22ebc76... M  arch/arm/boot/dts/Makefile
:00 100644 000... 9864fd7... A  arch/arm/boot/dts/omap3-devkit8000.dts
:100644 100644 53cb380b.. 6e2cef6... M  arch/arm/mach-omap2/board-generic.c
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/omap3-devkit8000.dts |  125 
 arch/arm/mach-omap2/board-generic.c|1 +
 3 files changed, 127 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5ebb44f..22ebc76 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -102,6 +102,7 @@ dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
imx28-tx28.dtb
 dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle.dtb \
+   omap3-devkit8000.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts 
b/arch/arm/boot/dts/omap3-devkit8000.dts
new file mode 100644
index 000..9864fd7
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -0,0 +1,125 @@
+/*
+ * Anil Kumar 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "omap3.dtsi"
+/ {
+   model = "TI OMAP3 Devkit8000";
+   compatible = "ti,omap3-devkit8000", "ti,omap3";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>;  /* 256 MB */
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&leds_pins>;
+
+   heartbeat {
+   label = "devkit8000::led1";
+   gpios = <&gpio6 26 0>;  /* 186 -> LED1 */
+   default-state = "on";
+   linux,default-trigger = "heartbeat";
+   };
+
+   mmc {
+   label = "devkit8000::led2";
+   gpios = <&gpio6 3 0>;   /* 163 -> LED2 */
+   default-state = "on";
+   linux,default-trigger = "none";
+   };
+
+   usr {
+   label = "devkit8000::led3";
+   gpios = <&gpio6 4 0>;   /* 164 -> LED3 */
+   default-state = "on";
+   linux,default-trigger = "usr";
+};
+
+   };
+};
+
+&omap3_pmx_core {
+   leds_pins: pinmux_led_pins {
+   pinctrl-single,pins = <
+   0x168 0x4   /* GPIO_163 */
+   0x16c 0x4   /* GPIO_164 */
+   0x1b0 0x4   /* GPIO_186 */
+
+   >;
+   };
+
+   i2c1_pins: pinmux_i2c1_pins {
+   pinctrl-single,pins = <
+   0x188 0x118 /* I2C1_SCL */
+   0x18c 0x118 /* I2C1_SDA */
+>;
+   };
+};
+
+&i2c1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c1_pins>;
+   clock-frequency = <260>;
+
+   twl: twl@48 {
+   reg = <0x48>;
+   interrupts = <7>;   /* SYS_NIRQ cascaded to intc */
+   interrupt-parent = <&intc>;
+   };
+};
+
+&i2c2 {
+   status = "disabled";
+};
+
+&i2c3 {
+   status = "disabled";
+};
+
+/include/ "twl4030.dtsi"
+
+&mmc1 {
+   vmmc-supply = <&vmmc1>;
+   vmmc_aux-supply = <&vsim>;
+   bus-width = <8>;
+};
+
+&mmc2 {
+   status = "disabled";
+};
+
+&mmc3 {
+   status = "disabled";
+};
+
+&wdt2 {
+   status = "disabled";
+};
+
+&mcbsp1 {
+   status = "disabled";
+};
+
+&mcbsp2 {
+   status = "disabled";
+};
+
+&mcbsp3 {
+   status = "disabled";
+};
+
+&mcbsp4 {
+   status = "disabled";
+};
+
+&mcbsp5 {
+   status = "disabled";
+};
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 53cb380..6e2cef6 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -110,6 +110,7 @@ MACHINE_END
 
 static const char *omap3_gp_boards_compat[] __initdata = {
"ti,omap3-beagle",
+   "ti,omap3-devkit8000",
NULL,
 };
 
-- 
1.7.0.4

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v4 2/2] iio: Add OF support

[Jonathan Cameron]

On 07/02/13 01:53, Guenter Roeck wrote:

On Wed, Feb 06, 2013 at 07:37:37PM +, Jonathan Cameron wrote:

On 02/06/2013 06:29 PM, Guenter Roeck wrote:

Provide bindings and parse OF data during initialization.

Signed-off-by: Guenter Roeck 

looks good to me.  Couple of little queries inline.


[ ... ]


+
+Example for a configuration with trigger:
+
+   adc@35 {
+   compatible = "maxim,max1139";
+   reg = <0x35>;
+
+   adc: iio-device {
+   #io-channel-cells = <1>;
+   };
+   trigger: iio-trigger {
+   #io-channel-cells = <1>;

Why would the trigger have channel-cells?
So far we don't have any device tree stuff for the triggers.


I thought about keeping the example and adding a note that trigger support is
not currently implemented, but a better idea is to replace it with a second iio
device. I'll do that unless someone objects.

adc@35 {
compatible = "some-vendor,some-adc";
reg = <0x35>;

adc1: iio-device@0 {
#io-channel-cells = <1>;
/* other properties */
};
adc2: iio-device@1 {
#io-channel-cells = <1>;
/* other properties */
};
};

Agreed.




+
+==Example==
+
+   adc: max1139@35 {
+   compatible = "maxim,max1139";
+   reg = <0x35>;
+   #io-channel-cells = <1>;
+   };
+
+   ...
+
+   iio_hwmon {
+   compatible = "iio-hwmon";
+   io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
+   <&adc 3>, <&adc 4>, <&adc 5>,
+   <&adc 6>, <&adc 7>, <&adc 8>,
+   <&adc 9>, <&adc 10>, <&adc 11>;
+   io-channel-names = "vcc", "vdd", "vref", "1.2V";

This example still seems a little odd. Why give one where there are
more channels than names?


I replaced the example with

iio_hwmon {
compatible = "iio-hwmon";
io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
<&adc 3>, <&adc 4>, <&adc 5>,
<&adc 6>, <&adc 7>, <&adc 8>,
<&adc 9>;
};

some_consumer {
compatible = "some-consumer";
io-channels = <&adc 10>, <&adc 11>;
io-channel-names = "adc1", "adc2";
};

Good as well. Much happier with these examples as they
won't cause any confusion.


Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 1/5] ARM: dts: exynos5250-arndale: Add node entry for gpio-buttons

[Girish KS]

On Wed, Feb 6, 2013 at 10:56 PM, Tushar Behera  wrote:
> On 02/07/2013 12:06 PM, Manish Badarkhe wrote:
>> Hi Tushar
>>
>> On Thu, Feb 7, 2013 at 11:56 AM, Tushar Behera  
>> wrote:
>>> On 02/07/2013 11:47 AM, Kumar, Anil wrote:
 On Thu, Feb 07, 2013 at 10:45:25, Tushar Behera wrote:
> Added GPIO buttons DT node to Arndale board file.
>
> Signed-off-by: Tushar Behera 
> Signed-off-by: Sachin Kamat 
> ---
> This series is based on for-next branch of Kukjin Kim's tree
> and added on top of the below patch:
> https://patchwork.kernel.org/patch/2042451/
> ---
>  arch/arm/boot/dts/exynos5250-arndale.dts |   48 
> ++
>  1 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index 63572f9..9ce40df 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -119,4 +119,52 @@
>  spi_2: spi@12d4 {
>  status = "disabled";
>  };
> +
> +gpio_keys {
> +compatible = "gpio-keys";
> +#address-cells = <1>;
> +#size-cells = <0>;

 Just want to understand why these properties are here?
 As these properties are for child dt node. But have not seen
 anyone is using here.

>>>
>>> That is how gpio_keys node entries are defined in other .dts files.
>>
>> I have gone through example for address-cells and size-cells in following 
>> link:
>> http://devicetree.org/mediawiki/index.php?title=Device_Tree_Usage&stable=1#CPU_addressing
>>
>> which indicates that these fields are for child "reg".
>> I think, here in child node there is no "reg". so there is no use
>> of address-cells and size-cells propeties.
>>
>
> Please check Documentation/devicetree/bindings/gpio/gpio_keys.txt
>
> And whether these properties are required or not, I will let device tree
> experts to comment on that.
>
> As such, currently all node entries for gpio_keys use these properties.
you can just verify by a simple test.
delete the 2 lines. address-cells and size cells.
this will have no affect.
now with these 2 lines deleted lines add a dummy reg property with
address and cell. dtb compiler will warn.
So I think what manish reffered is right.
There is also a reference of smdk4210 for kepads.
>
> --
> Tushar Behera
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 1/5] ARM: dts: exynos5250-arndale: Add node entry for gpio-buttons

[Manish Badarkhe]

Hi Tushar

On Thu, Feb 7, 2013 at 11:56 AM, Tushar Behera  wrote:
> On 02/07/2013 11:47 AM, Kumar, Anil wrote:
>> On Thu, Feb 07, 2013 at 10:45:25, Tushar Behera wrote:
>>> Added GPIO buttons DT node to Arndale board file.
>>>
>>> Signed-off-by: Tushar Behera 
>>> Signed-off-by: Sachin Kamat 
>>> ---
>>> This series is based on for-next branch of Kukjin Kim's tree
>>> and added on top of the below patch:
>>> https://patchwork.kernel.org/patch/2042451/
>>> ---
>>>  arch/arm/boot/dts/exynos5250-arndale.dts |   48 
>>> ++
>>>  1 files changed, 48 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
>>> b/arch/arm/boot/dts/exynos5250-arndale.dts
>>> index 63572f9..9ce40df 100644
>>> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
>>> @@ -119,4 +119,52 @@
>>>  spi_2: spi@12d4 {
>>>  status = "disabled";
>>>  };
>>> +
>>> +gpio_keys {
>>> +compatible = "gpio-keys";
>>> +#address-cells = <1>;
>>> +#size-cells = <0>;
>>
>> Just want to understand why these properties are here?
>> As these properties are for child dt node. But have not seen
>> anyone is using here.
>>
>
> That is how gpio_keys node entries are defined in other .dts files.

I have gone through example for address-cells and size-cells in following link:
http://devicetree.org/mediawiki/index.php?title=Device_Tree_Usage&stable=1#CPU_addressing

which indicates that these fields are for child "reg".
I think, here in child node there is no "reg". so there is no use
of address-cells and size-cells propeties.

Correct me if I am wrong here?

Thanks
Manish Badarkhe
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] net: sh_eth: Add support of device tree probe

[Nobuhiro Iwamatsu]

Hi,

On Thu, Feb 7, 2013 at 10:42 AM, Kuninori Morimoto
 wrote:
>
> Hi Iwamatsu-san
>
>> >> +Required properties:
>> >> +- compatible:   "renesas,sh-eth";
>> >> +- interrupt-parent: The phandle for the interrupt controller 
>> >> that
>> >> +services interrupts for this device.
>> >> +- reg:  Offset and length of the register set 
>> >> for the
>> >> +device.
>> >> +- interrupts:   Interrupt mapping for the sh_eth 
>> >> interrupt
>> >> +sources (vector id).
>> >> +- phy-mode:  String, operation mode of the PHY interface.
>> >> +- sh-eth,edmac-endian:  String, endian of sh_eth dmac.
>> >
>> > I believe endian is only little/big.
>> > It can be "bool" settings, not "string" ?
>> >
>>
>> If we use bool , we may use this as "sh-eth,edmac-endian-big" or
>> sh-eth,edmac-endian-little.
>> Or we define big-endian, and when using big-endian, we specify this.
>> Either way is okay.
>
> Sorry, if it means
>
> "we define big-endian as default settings,
> and user can select little-endian by using sh-eth,edmac-little-endian"
>
> then, it is nice.
> Then, it can be "Option" properties.

OK, I will update.

>
>> >> +- sh-eth,endian:String, endian of sh_eth dmac.
>> >
>> > Is this really used it in this driver ?
>> >
>>
>> Yes. In many cases, this uses little-endian, but user may specify
>> big-endian, I think.
>
> I meant that I could find "sh-eth,edmac-endian" operation,
> but, couldn't find "sh-eth,endian" operation on sh_eth_parse_dt()
> and on Example either.
>

OK,I will remove this sentence.

Thanks,
  Nobuhiro
-- 
Nobuhiro Iwamatsu
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] net: sh_eth: Add support of device tree probe

[Nobuhiro Iwamatsu]

Hi,

On Wed, Feb 6, 2013 at 5:36 PM, Kuninori Morimoto
 wrote:
>
> Hi Simon, Iwamatsu-san
>
>> +Required properties:
>> +- compatible:   "renesas,sh-eth";
>> +- interrupt-parent: The phandle for the interrupt controller 
>> that
>> +services interrupts for this device.
>> +- reg:  Offset and length of the register set for 
>> the
>> +device.
>> +- interrupts:   Interrupt mapping for the sh_eth interrupt
>> +sources (vector id).
>> +- phy-mode:  String, operation mode of the PHY interface.
>> +- sh-eth,edmac-endian:  String, endian of sh_eth dmac.
>
> I believe endian is only little/big.
> It can be "bool" settings, not "string" ?
>

If we use bool , we may use this as "sh-eth,edmac-endian-big" or
sh-eth,edmac-endian-little.
Or we define big-endian, and when using big-endian, we specify this.
Either way is okay.

>> +- sh-eth,endian:String, endian of sh_eth dmac.
>
> Is this really used it in this driver ?
>

Yes. In many cases, this uses little-endian, but user may specify
big-endian, I think.

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] net: sh_eth: Add support of device tree probe

[Nobuhiro Iwamatsu]

Hi,

On Wed, Feb 6, 2013 at 5:26 PM, Magnus Damm  wrote:
> Hey Simon, Iwamatsu-san,
>
> On Wed, Feb 6, 2013 at 11:00 AM, Simon Horman
>  wrote:
>> From: Nobuhiro Iwamatsu 
>>
>> This adds support of device tree probe for Renesas sh-ether driver.
>>
>> Signed-off-by: Nobuhiro Iwamatsu 
>
> Thanks for your work on this
>
>> +++ b/Documentation/devicetree/bindings/net/sh_ether.txt
>> @@ -0,0 +1,43 @@
>> +* Renesas Electronics SuperH EMAC
>> +
>> +This file provides information, what the device node
>> +for the sh_eth interface contains.
>> +
>> +Required properties:
>> +- compatible:   "renesas,sh-eth";
>> +- interrupt-parent: The phandle for the interrupt controller 
>> that
>> +services interrupts for this device.
>> +- reg:  Offset and length of the register set for 
>> the
>> +device.
>> +- interrupts:   Interrupt mapping for the sh_eth interrupt
>> +sources (vector id).
>> +- phy-mode:  String, operation mode of the PHY interface.
>> +- sh-eth,edmac-endian:  String, endian of sh_eth dmac.
>> +- sh-eth,register-type: String, register type of sh_eth.
>> +Please select "gigabit", "fast-sh4" or
>> +"fast-sh3-sh2".
>> +Please select "little" or "big".
>> +- sh-eth,endian:String, endian of sh_eth dmac.
>> +- sh-eth,phy-id:PHY id.
>> +
>> +Optional properties:
>> +- local-mac-address : 6 bytes, mac address
>
>
>> +- sh-eth,no-ether-link: set link control by software. When device 
>> does
>> +not support ether-link, set.
>> +- sh-etn,ether-link-active-low: set link check method.
>> +When detection of link is treated as 
>> active-low,
>> +set.
>> +- sh-etn,needs-init:Initialization flag.
>> +When initialize device in probing device, 
>> set.
>
> I believe there is a spelling mistake here with "sh-etn" instead of "sh-eth".

Thanks, I will fix this typo.

>
> Also, I am happy when DT is used to describe hardware information, but
> in the case of "needs-init" it more looks like software policy.

You are right. I will remove this flag from DT infomation.

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] net: sh_eth: Add support of device tree probe

[Nobuhiro Iwamatsu]

HI,

On Wed, Feb 6, 2013 at 4:30 PM, Denis Kirjanov  wrote:
> On 2/6/13, Simon Horman  wrote:
>> From: Nobuhiro Iwamatsu 
>>
>> This adds support of device tree probe for Renesas sh-ether driver.
>>
>> Signed-off-by: Nobuhiro Iwamatsu 
>>
>> ---
>>  Documentation/devicetree/bindings/net/sh_ether.txt |   43 ++
>>  drivers/net/ethernet/renesas/sh_eth.c  |  156
>> +---
>>  2 files changed, 177 insertions(+), 22 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/net/sh_ether.txt
>>
>> [Simon Horman]
>> I am re-posting this patch with devicetree-discuss@lists.ozlabs.org CCed
>> for review of the proposed device tree bindings.
>>
>> diff --git a/Documentation/devicetree/bindings/net/sh_ether.txt
>> b/Documentation/devicetree/bindings/net/sh_ether.txt
>> new file mode 100644
>> index 000..c11e45d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/sh_ether.txt
>> @@ -0,0 +1,43 @@
>> +* Renesas Electronics SuperH EMAC
>> +
>> +This file provides information, what the device node
>> +for the sh_eth interface contains.
>> +
>> +Required properties:
>> +- compatible:   "renesas,sh-eth";
>> +- interrupt-parent: The phandle for the interrupt controller
>> that
>> +services interrupts for this device.
>> +- reg:  Offset and length of the register set for
>> the
>> +device.
>> +- interrupts:   Interrupt mapping for the sh_eth interrupt
>> +sources (vector id).
>> +- phy-mode:  String, operation mode of the PHY interface.
>> +- sh-eth,edmac-endian:  String, endian of sh_eth dmac.
>> +- sh-eth,register-type: String, register type of sh_eth.
>> +Please select "gigabit", "fast-sh4" or
>> +"fast-sh3-sh2".
>> +Please select "little" or "big".
>> +- sh-eth,endian:String, endian of sh_eth dmac.
>> +- sh-eth,phy-id:PHY id.
>> +
>> +Optional properties:
>> +- local-mac-address : 6 bytes, mac address
>> +- sh-eth,no-ether-link: set link control by software. When device
>> does
>> +not support ether-link, set.
>> +- sh-etn,ether-link-active-low: set link check method.
>> +When detection of link is treated as
>> active-low,
>> +set.
>> +- sh-etn,needs-init:Initialization flag.
>> +When initialize device in probing device,
>> set.
>> +
>> +Example (armadillo800eva):
>> + sh-eth@e9a0 {
>> + compatible = "renesas,sh-eth";
>> + interrupt-parent = <&intca>;
>> + reg = <0xe9a0 0x800>, <0xe9a01800 0x800>;
>> + interrupts = <0x500>;
>> + phy-mode = "mii";
>> + sh-eth,edmac-endian = "little";
>> + sh-eth,register-type = "gigabit";
>> + sh-eth,phy-id = <0>;
>> + };
>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c
>> b/drivers/net/ethernet/renesas/sh_eth.c
>> index 3d70586..1f64848 100644
>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
>> @@ -31,6 +31,12 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -2347,26 +2353,120 @@ static const struct net_device_ops
>> sh_eth_netdev_ops = {
>>   .ndo_change_mtu = eth_change_mtu,
>>  };
>>
>> +#ifdef CONFIG_OF
>> +
>> +static int
>> +sh_eth_of_get_register_type(struct device_node *np)
>> +{
>> + const char *of_str;
>> + int ret = of_property_read_string(np, "sh-eth,register-type", &of_str);
>> + if (ret)
>> + return ret;
>> +
>> + if (of_str && !strcmp(of_str, "gigabit"))
>> + return SH_ETH_REG_GIGABIT;
>> + else if (of_str && !strcmp(of_str, "fast-sh4"))
>> + return SH_ETH_REG_FAST_SH4;
>> + else if (of_str && !strcmp(of_str, "fast-sh3-sh2"))
>> + return SH_ETH_REG_FAST_SH3_SH2;
>> + else
>> + return -EINVAL;
>> +}
>> +
>> +static struct sh_eth_plat_data *
>> +sh_eth_parse_dt(struct device *dev, struct net_device *ndev)
>> +{
>> + int ret;
>> + const char *of_str;
>> + struct device_node *np = dev->of_node;
>> + struct sh_eth_plat_data *pdata;
>> +
>> + pdata = devm_kzalloc(dev, sizeof(struct sh_eth_plat_data),
>> + GFP_KERNEL);
>> + if (!pdata) {
>> + dev_err(dev, "%s: failed to allocate config data\n", __func__);
>> + return NULL;
>> + }
>> +
>> + pdata->phy_interface = of_get_phy_mode(np);
>> +
>> + of_property_read_u32(np, "sh-eth,phy-id", &pdata->phy);
>> +
>> + of_property_read_string(np, "

Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Philippe Rétornaz]

Hi all !

Le 06/02/2013 14:30, Benoit Cousson a écrit :

Salut Florian,

On 02/04/2013 10:14 AM, Florian Vaussard wrote:

Hello Benoit,

On 01/24/2013 01:21 PM, Benoit Cousson wrote:

+ Peter who did the original PWM

Hi Florian,

On 01/23/2013 06:56 PM, Florian Vaussard wrote:

Hello Benoit,

This patchset adds some new DT supports to the Overo products.
The first patch converts the PMIC LEDB output to use the
pwm-leds, newly merged in your branch for_3.9/dts. The second
patch adds the audio support.


Excellent, that looks very good to me, but I'd like to get the
feedback from Peter before merging it.



So a patch is being merged to handle triggers in the case of pwm
leds [1]. When done, we will be able to add back the default
trigger. Do you want to wait on it to merge this series?


What kind of dependency do we have between these two series? I mean
what will happen if the DTS is merged before the pwm subsystem?

If that does not generate any regression / crash, then it is OK, if
not, we should take care of the order.


Florian is on holiday the next two weeks.

AFAIK if the PWM/leds subsystem patches are not merged before this one
then the kernel will panic if a trigger is used to change the led status.

Regards,

Philippe
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D

[김승우]

On 2013년 02월 06일 17:51, Inki Dae wrote:
> 
> 
>> -Original Message-
>> From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
>> Sent: Wednesday, February 06, 2013 5:03 PM
>> To: Inki Dae
>> Cc: linux-me...@vger.kernel.org; dri-de...@lists.freedesktop.org;
>> devicetree-discuss@lists.ozlabs.org; k.deb...@samsung.com;
>> s.nawro...@samsung.com; kgene@samsung.com; patc...@linaro.org; Ajay
>> Kumar
>> Subject: Re: [PATCH v2 2/2] drm/exynos: Add device tree based discovery
>> support for G2D
>>
>> On 6 February 2013 13:02, Inki Dae  wrote:
>>>
>>> Looks good to me but please add document for it.
>>
>> Yes. I will. I was planning to send the bindings document patch along
>> with the dt patches (adding node entries to dts files).
>> Sylwester had suggested adding this to
>> Documentation/devicetree/bindings/media/ which contains other media
>> IPs.
> 
> I think that it's better to go to gpu than media and we can divide Exynos
> IPs into the bellow categories,
> 
> Media : mfc
> GPU : g2d, g3d, fimc, gsc
> Video : fimd, hdmi, eDP, MIPI-DSI

Hm, here is another considering point. Some device can be used as one of
two sub-system. For example g2d can be used as V4L2 driver or DRM
driver. And more specific case, multiple fimc/gsc deivces can be
separately used as both drivers: two fimc devices are used as V4L2
driver and other devices are used as DRM driver.
Current discussion, without change of build configuration, device can be
only used as one driver.

So I want to discuss about how we can bind device and driver just with
dts configuration.

IMO, there are two options.

First, driver usage is set on configurable node.
g2d: g2d {
compatible = "samsung,exynos4212-g2d";
...
*subsystem = "v4l2"* or *subsystem = "drm"*
};
Node name and type is just an example to describe.
With this option, driver which is not matched with subsystem node should
return with fail during its probing.

Second, using dual compatible strings.
g2d: g2d {
*compatible = "samsung,exynos4212-v4l2-g2d"; or
compatible = "samsung,exynos4212-v4l2-g2d";*
...
};
String is just an example so don't mind if it is ugly. Actually, with
this option, compatible string has non HW information. But this option
does not need fail in probing.

I'm not sure these options are fit to DT concept. Please let me know if
anyone has idea.

Best Regards,
- Seung-Woo Kim

> 
> And I think that the device-tree describes hardware so possibly, all
> documents in .../bindings/drm/exynos/* should be moved to proper place also.
> Please give  me any opinions.
> 
> Thanks,
> Inki Dae
> 
>>
>>>
>>> To other guys,
>>> And is there anyone who know where this document should be added to?
>>> I'm not sure that the g2d document should be placed in
>>> Documentation/devicetree/bindings/gpu, media, drm/exynos or arm/exynos.
>> At
>>> least, this document should be shared with the g2d hw relevant drivers
>> such
>>> as v4l2 and drm. So is ".../bindings/gpu" proper place?
>>>
>>
>>
>> --
>> With warm regards,
>> Sachin
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

RE: [PATCH] arm: mvebu: Add SPI flash on Armada XP-GP board

[Lior Amsalem]

> From: Jason Cooper [mailto:ja...@lakedaemon.net]
> Sent: Tuesday, February 05, 2013 8:09 PM
> 
> On Tue, Feb 05, 2013 at 06:07:05PM +0100, Thomas Petazzoni wrote:
> > Of course, it doesn't make sense to have drivers for pluggable devices
> > like PCIe devices that are not soldered, USB devices and things like
> > that. But for all the rest, I would say it should be in the defconfig.
> 
> hmmm, so for the new devboard we should set CONFIG_RAM=n? ;-)

I think something like CONFIG_RAM=m suit better :)

> 
> thx,
> 
> Jason.

Regards,
Lior Amsalem

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] net: sh_eth: Add support of device tree probe

[Denis Kirjanov]

On 2/6/13, Simon Horman  wrote:
> From: Nobuhiro Iwamatsu 
>
> This adds support of device tree probe for Renesas sh-ether driver.
>
> Signed-off-by: Nobuhiro Iwamatsu 
>
> ---
>  Documentation/devicetree/bindings/net/sh_ether.txt |   43 ++
>  drivers/net/ethernet/renesas/sh_eth.c  |  156
> +---
>  2 files changed, 177 insertions(+), 22 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/sh_ether.txt
>
> [Simon Horman]
> I am re-posting this patch with devicetree-discuss@lists.ozlabs.org CCed
> for review of the proposed device tree bindings.
>
> diff --git a/Documentation/devicetree/bindings/net/sh_ether.txt
> b/Documentation/devicetree/bindings/net/sh_ether.txt
> new file mode 100644
> index 000..c11e45d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/sh_ether.txt
> @@ -0,0 +1,43 @@
> +* Renesas Electronics SuperH EMAC
> +
> +This file provides information, what the device node
> +for the sh_eth interface contains.
> +
> +Required properties:
> +- compatible:   "renesas,sh-eth";
> +- interrupt-parent: The phandle for the interrupt controller
> that
> +services interrupts for this device.
> +- reg:  Offset and length of the register set for
> the
> +device.
> +- interrupts:   Interrupt mapping for the sh_eth interrupt
> +sources (vector id).
> +- phy-mode:  String, operation mode of the PHY interface.
> +- sh-eth,edmac-endian:  String, endian of sh_eth dmac.
> +- sh-eth,register-type: String, register type of sh_eth.
> +Please select "gigabit", "fast-sh4" or
> +"fast-sh3-sh2".
> +Please select "little" or "big".
> +- sh-eth,endian:String, endian of sh_eth dmac.
> +- sh-eth,phy-id:PHY id.
> +
> +Optional properties:
> +- local-mac-address : 6 bytes, mac address
> +- sh-eth,no-ether-link: set link control by software. When device
> does
> +not support ether-link, set.
> +- sh-etn,ether-link-active-low: set link check method.
> +When detection of link is treated as
> active-low,
> +set.
> +- sh-etn,needs-init:Initialization flag.
> +When initialize device in probing device,
> set.
> +
> +Example (armadillo800eva):
> + sh-eth@e9a0 {
> + compatible = "renesas,sh-eth";
> + interrupt-parent = <&intca>;
> + reg = <0xe9a0 0x800>, <0xe9a01800 0x800>;
> + interrupts = <0x500>;
> + phy-mode = "mii";
> + sh-eth,edmac-endian = "little";
> + sh-eth,register-type = "gigabit";
> + sh-eth,phy-id = <0>;
> + };
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c
> b/drivers/net/ethernet/renesas/sh_eth.c
> index 3d70586..1f64848 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -31,6 +31,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2347,26 +2353,120 @@ static const struct net_device_ops
> sh_eth_netdev_ops = {
>   .ndo_change_mtu = eth_change_mtu,
>  };
>
> +#ifdef CONFIG_OF
> +
> +static int
> +sh_eth_of_get_register_type(struct device_node *np)
> +{
> + const char *of_str;
> + int ret = of_property_read_string(np, "sh-eth,register-type", &of_str);
> + if (ret)
> + return ret;
> +
> + if (of_str && !strcmp(of_str, "gigabit"))
> + return SH_ETH_REG_GIGABIT;
> + else if (of_str && !strcmp(of_str, "fast-sh4"))
> + return SH_ETH_REG_FAST_SH4;
> + else if (of_str && !strcmp(of_str, "fast-sh3-sh2"))
> + return SH_ETH_REG_FAST_SH3_SH2;
> + else
> + return -EINVAL;
> +}
> +
> +static struct sh_eth_plat_data *
> +sh_eth_parse_dt(struct device *dev, struct net_device *ndev)
> +{
> + int ret;
> + const char *of_str;
> + struct device_node *np = dev->of_node;
> + struct sh_eth_plat_data *pdata;
> +
> + pdata = devm_kzalloc(dev, sizeof(struct sh_eth_plat_data),
> + GFP_KERNEL);
> + if (!pdata) {
> + dev_err(dev, "%s: failed to allocate config data\n", __func__);
> + return NULL;
> + }
> +
> + pdata->phy_interface = of_get_phy_mode(np);
> +
> + of_property_read_u32(np, "sh-eth,phy-id", &pdata->phy);
> +
> + of_property_read_string(np, "sh-eth,edmac-endian", &of_str);
> + if (of_str && !strcmp(of_str, "little"))
> + pdata->edmac_endian = EDMAC_LITTLE_ENDIAN;
> + else if (of_str && !strcmp(of_str, "big"))
> +   

Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree

[김승우]

On 2013년 02월 06일 09:56, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren  wrote:
>> On 02/05/2013 05:37 PM, Sean Paul wrote:
>>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren  
>>> wrote:
 n 02/05/2013 04:42 PM, Sean Paul wrote:
> Use the compatible string in the device tree to determine which
> registers/functions to use in the HDMI driver. Also changes the
> references from v13 to 4210 and v14 to 4212 to reflect the IP
> block version instead of the HDMI version.

> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
> b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt

 Binding looks sane to me.

> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c

>  #ifdef CONFIG_OF
>  static struct of_device_id hdmi_match_types[] = {
>   {
> - .compatible = "samsung,exynos5-hdmi",
> - .data   = (void *)HDMI_TYPE14,
> + .compatible = "samsung,exynos4-hdmi",
>   }, {
>   /* end node */
>   }

 Why not fill in all the "base" compatible values there (I think you need
 this anyway so that DTs don't all have to be compatible with
 samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
 values, then ...

>>>
>>> At the moment, all DTs have to be compatible with exynos4-hdmi since
>>> it provides the base for the current driver. The driver uses 4210 and
>>> 4212 to differentiate between different register addresses and
>>> features, but most things are just exynos4-hdmi compatible.
>>
>> The DT nodes should include only the compatible values that the HW is
>> actually compatible with. If the HW isn't compatible with exynos4-hdmi,
>> that value shouldn't be in the compatible property, but instead whatever
>> the "base" value that the HW really is compatible with. The driver can
>> support multiple "base" compatible values from this table.
>>
> 
> All devices that use this driver are compatible, at some level, with
> exynos4-hdmi, so I think its usage is correct here.
> 
> @@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device 
> *pdev)

> +
> + if (of_device_is_compatible(dev->of_node, 
> "samsung,exynos4210-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS4210;
> + if (of_device_is_compatible(dev->of_node, 
> "samsung,exynos4212-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS4212;
> + if (of_device_is_compatible(dev->of_node, 
> "samsung,exynos5250-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS5250;

 Instead of that, do roughly:

 match = of_match_device(hdmi_match_types, &pdev->dev);
 if (match)
 hdata->version |= (int)match->data;

 That way, it's all table-based. Any future additions to
 hdmi_match_types[] won't require another if statement to be added to
 probe().
>>>
>>> I don't think it's that easy. of_match_device returns the first match
>>> from the device table, so I'd still need to iterate through the
>>> matches. I could still break this out into a table, but I don't think
>>> of_match_device is the right way to probe it.
>>
>> You shouldn't have to iterate over multiple matches. of_match_device()
>> is supposed to return the match for the first entry in the compatible
>> property, then if there was no match, move on to looking at the next
>> entry in the compatible property, etc. In practice, I think it's still
>> not implemented quite correctly for this, but you can make it work by
>> putting the newest compatible value first in the match table.
> 
> I think the only way that works is if you hardcode the compatible
> versions in the driver, like this:
> 
> static struct of_device_id hdmi_match_types[] = {
> {
> .compatible = "samsung,exynos5250-hdmi",
> .data = (void *)(HDMI_VER_EXYNOS5250 | HDMI_VER_EXYNOS4212);
> }, {
> .compatible = "samsung,exynos4212-hdmi",
> .data = (void *)HDMI_VER_EXYNOS4212;
> }, {
> .compatible = "samsung,exynos4210-hdmi",
> .data = (void *)HDMI_VER_EXYNOS4210;
> }, {
> /* end node */
> }
> };

Actually, I can't understand why there is HDMI_VER_EXYNOS5250 because it
is not used anywhere in your patch. I'm not sure I missed something from
your v2 patch thread, but to me, just hdmi version or hdmi ip version
can be used as data field of struct of_device_id as like your v2 patch
set. and then of_match_device() can be used without | in data field.

If I have missed some point from v2 thread, please let me know.

Best Regards,
- Seung-Woo Kim

> 
> In that case, it eliminates the benefit of using device tree to
> determine the compatible bits. I hope I'm just being thick and missing
> something.
> 
> Sean
> 

Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree

[Joonyoung Shim]

On 02/06/2013 09:56 AM, Sean Paul wrote:

On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren  wrote:

On 02/05/2013 05:37 PM, Sean Paul wrote:

On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren  wrote:

n 02/05/2013 04:42 PM, Sean Paul wrote:

Use the compatible string in the device tree to determine which
registers/functions to use in the HDMI driver. Also changes the
references from v13 to 4210 and v14 to 4212 to reflect the IP
block version instead of the HDMI version.
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt

Binding looks sane to me.


diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
  #ifdef CONFIG_OF
  static struct of_device_id hdmi_match_types[] = {
   {
- .compatible = "samsung,exynos5-hdmi",
- .data   = (void *)HDMI_TYPE14,
+ .compatible = "samsung,exynos4-hdmi",
   }, {
   /* end node */
   }

Why not fill in all the "base" compatible values there (I think you need
this anyway so that DTs don't all have to be compatible with
samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
values, then ...


At the moment, all DTs have to be compatible with exynos4-hdmi since
it provides the base for the current driver. The driver uses 4210 and
4212 to differentiate between different register addresses and
features, but most things are just exynos4-hdmi compatible.

The DT nodes should include only the compatible values that the HW is
actually compatible with. If the HW isn't compatible with exynos4-hdmi,
that value shouldn't be in the compatible property, but instead whatever
the "base" value that the HW really is compatible with. The driver can
support multiple "base" compatible values from this table.


All devices that use this driver are compatible, at some level, with
exynos4-hdmi, so I think its usage is correct here.


@@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device *pdev)
+
+ if (of_device_is_compatible(dev->of_node, "samsung,exynos4210-hdmi"))
+ hdata->version |= HDMI_VER_EXYNOS4210;
+ if (of_device_is_compatible(dev->of_node, "samsung,exynos4212-hdmi"))
+ hdata->version |= HDMI_VER_EXYNOS4212;
+ if (of_device_is_compatible(dev->of_node, "samsung,exynos5250-hdmi"))
+ hdata->version |= HDMI_VER_EXYNOS5250;


But this way can make unnecessary combinations, e.g. exynos4210-hdmi + 
exynos5250-hdmi.



Instead of that, do roughly:

 match = of_match_device(hdmi_match_types, &pdev->dev);
 if (match)
 hdata->version |= (int)match->data;

That way, it's all table-based. Any future additions to
hdmi_match_types[] won't require another if statement to be added to
probe().

I don't think it's that easy. of_match_device returns the first match
from the device table, so I'd still need to iterate through the
matches. I could still break this out into a table, but I don't think
of_match_device is the right way to probe it.

You shouldn't have to iterate over multiple matches. of_match_device()
is supposed to return the match for the first entry in the compatible
property, then if there was no match, move on to looking at the next
entry in the compatible property, etc. In practice, I think it's still
not implemented quite correctly for this, but you can make it work by
putting the newest compatible value first in the match table.

I think the only way that works is if you hardcode the compatible
versions in the driver, like this:

static struct of_device_id hdmi_match_types[] = {
 {
 .compatible = "samsung,exynos5250-hdmi",
 .data = (void *)(HDMI_VER_EXYNOS5250 | HDMI_VER_EXYNOS4212);
 }, {
 .compatible = "samsung,exynos4212-hdmi",
 .data = (void *)HDMI_VER_EXYNOS4212;
 }, {
 .compatible = "samsung,exynos4210-hdmi",
 .data = (void *)HDMI_VER_EXYNOS4210;
 }, {
 /* end node */
 }
};


I think this makes driver more clearly. We just see device tables and we 
can know device uses which version.




In that case, it eliminates the benefit of using device tree to
determine the compatible bits. I hope I'm just being thick and missing
something.

Sean
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D

[Joonyoung Shim]

On 02/05/2013 12:03 PM, Inki Dae wrote:
> 2013/2/4 Sachin Kamat :
>> On 1 February 2013 18:28, Inki Dae  wrote:
>>>
>>>
>>>
>>> 2013. 2. 1. 오후 8:52 Inki Dae  작성:
>>>

> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sachin Kamat
> Sent: Friday, February 01, 2013 8:40 PM
> To: Inki Dae
> Cc: Sylwester Nawrocki; Kukjin Kim; Sylwester Nawrocki; linux-
> me...@vger.kernel.org; dri-de...@lists.freedesktop.org; devicetree-
> disc...@lists.ozlabs.org; patc...@linaro.org
> Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery
> support for G2D
>
> On 1 February 2013 17:02, Inki Dae  wrote:
>> How about using like below?
>>Compatible = ""samsung,exynos4x12-fimg-2d" /* for Exynos4212,
>> Exynos4412  */
>> It looks odd to use "samsung,exynos4212-fimg-2d" saying that this ip is
> for
>> exynos4212 and exynos4412.
> AFAIK, compatible strings are not supposed to have any wildcard
 characters.
> Compatible string should suggest the first SoC that contained this IP.
> Hence IMO 4212 is OK.
>
>>> Oops, one more thing. AFAIK Exynos4210 also has fimg-2d ip. In this case, 
>>> we should use "samsung,exynos4210-fimg-2d" as comparible string and add it 
>>> to exynos4210.dtsi?
>> Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same
>> comptible string will be used for this one too.
>>
>>> And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. If it's 
>>> different, we might need to add ip version property or compatible string to 
>>> each dtsi file to identify the ip version.
>> AFAIK, they both have the same IP (v4.1).
>>
> Ok, let's use the below,
>
> For exynos4210 SoC,
> compatible = "samsung,exynos4210-g2d"
>
> For exynos4x12 SoCs,
> compatible = "samsung,exynos4212-g2d"
>
> For exynos5250, 5410 (In case of Exynos5440, I'm not sure that the SoC
> has same ip)
> compatible = "samsung,exynos5250-g2d"
>
> To other guys,
> The device tree is used by not only v4l2 side but also drm side so we
> should reach an arrangement. So please give me ack if you agree to my
> opinion. Otherwise please, give me your opinions.

I like this compatible, also we can use rule like this to HDMI of
drm/exynos.

>
> Thanks,
> Inki Dae
>
>
>>> Sorry but give me your opinions.
>>>
>>> Thanks,
>>> Inki Dae
>>>
>>>
 Got it. Please post it again.

> --
> With warm regards,
> Sachin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>> --
>> With warm regards,
>> Sachin
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v8 3/4] media: coda: use genalloc API

[javier Martin]

Hi Philipp,
thank you for preserving compatibility for platform data.

For the coda sources:

Acked-By: Javier Martin 

On 4 February 2013 12:32, Philipp Zabel  wrote:
> This patch depends on "genalloc: add devres support, allow to find
> a managed pool by device", which provides the of_get_named_gen_pool
> and dev_get_gen_pool functions.
>
> Signed-off-by: Philipp Zabel 
> ---
> Changes since v7:
>  - In the platform data case, retrieve gen_pool by device instead of
>by physical address. The information about the SRAM pool can't be
>provided via memory resource, so add a platform data struct that
>contains a pointer to the SRAM device.
>  - Add device tree binding documentation.
> ---
>  Documentation/devicetree/bindings/media/coda.txt |   30 +++
>  drivers/media/platform/Kconfig   |1 -
>  drivers/media/platform/coda.c|   45 
> +++---
>  include/linux/platform_data/coda.h   |   18 +
>  4 files changed, 79 insertions(+), 15 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/media/coda.txt
>  create mode 100644 include/linux/platform_data/coda.h
>
> diff --git a/Documentation/devicetree/bindings/media/coda.txt 
> b/Documentation/devicetree/bindings/media/coda.txt
> new file mode 100644
> index 000..2865d04
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/coda.txt
> @@ -0,0 +1,30 @@
> +Chips&Media Coda multi-standard codec IP
> +
> +
> +Coda codec IPs are present in i.MX SoCs in various versions,
> +called VPU (Video Processing Unit).
> +
> +Required properties:
> +- compatible : should be "fsl,-src" for i.MX SoCs:
> +  (a) "fsl,imx27-vpu" for CodaDx6 present in i.MX27
> +  (b) "fsl,imx53-vpu" for CODA7541 present in i.MX53
> +  (c) "fsl,imx6q-vpu" for CODA960 present in i.MX6q
> +- reg: should be register base and length as documented in the
> +  SoC reference manual
> +- interrupts : Should contain the VPU interrupt. For CODA960,
> +  a second interrupt is needed for the MJPEG unit.
> +- clocks : Should contain the ahb and per clocks, in the order
> +  determined by the clock-names property.
> +- clock-names : Should be "ahb", "per"
> +- iram : phandle pointing to the SRAM device node
> +
> +Example:
> +
> +vpu: vpu@63ff4000 {
> +   compatible = "fsl,imx53-vpu";
> +   reg = <0x63ff4000 0x1000>;
> +   interrupts = <9>;
> +   clocks = <&clks 63>, <&clks 63>;
> +   clock-names = "ahb", "per";
> +   iram = <&ocram>;
> +};
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 05d7b63..bbf83c1 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -145,7 +145,6 @@ config VIDEO_CODA
> depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
> select VIDEOBUF2_DMA_CONTIG
> select V4L2_MEM2MEM_DEV
> -   select IRAM_ALLOC if SOC_IMX53
> ---help---
>Coda is a range of video codec IPs that supports
>H.264, MPEG-4, and other video formats.
> diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
> index 20827ba..b931c2a 100644
> --- a/drivers/media/platform/coda.c
> +++ b/drivers/media/platform/coda.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -23,7 +24,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include 
>  #include 
> @@ -43,6 +44,7 @@
>  #define CODA7_WORK_BUF_SIZE(512 * 1024 + CODA_FMO_BUF_SIZE * 8 * 1024)
>  #define CODA_PARA_BUF_SIZE (10 * 1024)
>  #define CODA_ISRAM_SIZE(2048 * 2)
> +#define CODADX6_IRAM_SIZE  0xb000
>  #define CODA7_IRAM_SIZE0x14000 /* 81920 bytes */
>
>  #define CODA_MAX_FRAMEBUFFERS  2
> @@ -128,7 +130,10 @@ struct coda_dev {
>
> struct coda_aux_buf codebuf;
> struct coda_aux_buf workbuf;
> +   struct gen_pool *iram_pool;
> +   long unsigned int   iram_vaddr;
> long unsigned int   iram_paddr;
> +   unsigned long   iram_size;
>
> spinlock_t  irqlock;
> struct mutexdev_mutex;
> @@ -1926,6 +1931,9 @@ static int coda_probe(struct platform_device *pdev)
> const struct of_device_id *of_id =
> of_match_device(of_match_ptr(coda_dt_ids), 
> &pdev->dev);
> const struct platform_device_id *pdev_id;
> +   struct coda_platform_data *pdata = pdev->dev.platform_data;
> +   struct device_node *np = pdev->dev.of_node;
> +   struct gen_pool *pool;
> struct coda_dev *dev;
> struct resource *res;
> int ret, irq;
> @@ -1988,6 +1996,16 @@ static int coda_probe(struct platform_device *pdev)
> return -ENOENT;
> }
>
> +   /* Get IRAM pool from device tree or platform data */
> +   pool = of_get_named_gen_pool(np, "iram", 0);
> +  

Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D

[김승우]

Hi Inki,

On 2013년 02월 05일 12:03, Inki Dae wrote:
> 2013/2/4 Sachin Kamat :
>> On 1 February 2013 18:28, Inki Dae  wrote:
>>>
>>>
>>>
>>>
>>> 2013. 2. 1. 오후 8:52 Inki Dae  작성:
>>>


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Sachin Kamat
> Sent: Friday, February 01, 2013 8:40 PM
> To: Inki Dae
> Cc: Sylwester Nawrocki; Kukjin Kim; Sylwester Nawrocki; linux-
> me...@vger.kernel.org; dri-de...@lists.freedesktop.org; devicetree-
> disc...@lists.ozlabs.org; patc...@linaro.org
> Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery
> support for G2D
>
> On 1 February 2013 17:02, Inki Dae  wrote:
>>
>> How about using like below?
>>Compatible = ""samsung,exynos4x12-fimg-2d" /* for Exynos4212,
>> Exynos4412  */
>> It looks odd to use "samsung,exynos4212-fimg-2d" saying that this ip is
> for
>> exynos4212 and exynos4412.
>
> AFAIK, compatible strings are not supposed to have any wildcard
 characters.
> Compatible string should suggest the first SoC that contained this IP.
> Hence IMO 4212 is OK.
>
>>>
>>> Oops, one more thing. AFAIK Exynos4210 also has fimg-2d ip. In this case, 
>>> we should use "samsung,exynos4210-fimg-2d" as comparible string and add it 
>>> to exynos4210.dtsi?
>>
>> Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same
>> comptible string will be used for this one too.
>>
>>> And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. If it's 
>>> different, we might need to add ip version property or compatible string to 
>>> each dtsi file to identify the ip version.
>>
>> AFAIK, they both have the same IP (v4.1).
>>
> 
> Ok, let's use the below,
> 
> For exynos4210 SoC,
> compatible = "samsung,exynos4210-g2d"
> 
> For exynos4x12 SoCs,
> compatible = "samsung,exynos4212-g2d"
> 
> For exynos5250, 5410 (In case of Exynos5440, I'm not sure that the SoC
> has same ip)
> compatible = "samsung,exynos5250-g2d"
> 
> To other guys,
> The device tree is used by not only v4l2 side but also drm side so we
> should reach an arrangement. So please give me ack if you agree to my
> opinion. Otherwise please, give me your opinions.

This seems good to me.

Best Regards,
- Seung-Woo Kim

> 
> Thanks,
> Inki Dae
> 
> 
>>>
>>> Sorry but give me your opinions.
>>>
>>> Thanks,
>>> Inki Dae
>>>
>>>

 Got it. Please post it again.

>
> --
> With warm regards,
> Sachin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>>
>> --
>> With warm regards,
>> Sachin
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Seung-Woo Kim
Samsung Software R&D Center
--

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 1/2] iio: Update iio_channel_get API to use consumer device pointer as argument

[Chanwoo Choi]

On 02/05/2013 05:26 AM, Guenter Roeck wrote:

For iio_channel_get to work with OF based configurations, it needs the
consumer device pointer instead of the consumer device name as argument.

Signed-off-by: Guenter Roeck 
---
  drivers/extcon/extcon-adc-jack.c|3 +--
  drivers/iio/inkern.c|   11 ++-
  drivers/power/generic-adc-battery.c |4 ++--
  drivers/power/lp8788-charger.c  |8 
  include/linux/iio/consumer.h|5 +++--
  5 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index eda2a1a..d0233cd 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -135,8 +135,7 @@ static int adc_jack_probe(struct platform_device *pdev)
;
data->num_conditions = i;
  
-	data->chan = iio_channel_get(dev_name(&pdev->dev),

-   pdata->consumer_channel);
+   data->chan = iio_channel_get(&pdev->dev, pdata->consumer_channel);
if (IS_ERR(data->chan)) {
err = PTR_ERR(data->chan);
goto out;
diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index c42aba6..b289915 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -93,7 +93,8 @@ static const struct iio_chan_spec

Ack for drivers/extcon .

Acked-by: Chanwoo Choi 

Thanks,
Chanwoo Choi

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

RE: [PATCH] ARM: dts: specify all the per-cpu interrupts of arch timer for exynos5440

[kgene]

Santosh Shilimkar wrote:
> 
> Benoit,
> 
> On Thursday 24 January 2013 06:46 PM, Marc Zyngier wrote:
> > Hi Benoit,
> >
> > On 24/01/13 12:42, Benoit Cousson wrote:
> >> Hi Santosh,
> >>
> >> On 01/23/2013 11:55 AM, Santosh Shilimkar wrote:
> >>> Looping Marc, Benoit
> >>>
> >>> On Wednesday 23 January 2013 04:06 PM, Mark Rutland wrote:
>  On Tue, Jan 22, 2013 at 10:05:18PM +, Kukjin Kim wrote:
> > Mark Rutland wrote:
> >>
> > + devicetree-discuss, Grant Likely, Rob Herring and Tony Lindgren
> >
> >> On Tue, Jan 22, 2013 at 01:41:27AM +, Kukjin Kim wrote:
> >>> From: Thomas Abraham 
> >>>
> >>> Need to be changed requirements in the 'cpus' node for
> exynos5440
> >>> to specify all the per-cpu interrupts of arch timer.
> >>
> >> The node(s) for the arch timer should not be in the cpus/cpu@N
> nodes.
> >> Instead, there should be one node (in the root of the tree).
> >>
> > Well, I don't think so. As per my understanding, the local timers
are
> > attached to every ARM cores (cpus) and it generates certain
interrupt
> > to the
> > GIC. So the correct representation for this in device tree is to
> > include the
> > interrupts in the cpu nodes in dts file. Your comments  refer to a
> > limitation in the Linux kernel implementation of the arch_timer and
it
> > should not result in representing the hardware details incorrectly
in
> > the
> > dts file.
> 
>  I disagree. The "correct representation" is whatever the devicetree
>  binding
>  documentation describes. It does not describe placing timer nodes in
>  the cpu
>  nodes.
> 
> >>> This seems to be exact same topic what is getting discussed here [1]
> >>> Technically DT is suppose to represent how the hardware is rather than
> >>> how the bindings are done.
> >>>
> >>> But as Marc pointed out, the approach taken currently is to not
> >>> duplicate the banked information. The thread [1] isn't concluded
> >>> yet but looks like we might want to avoid duplicating the information
> >>> considering, more of such duplication needs to follow. e.g gic i/f
> >>>
> >>> Am still waiting on what Benoit has to say ?
> >>
> >> I agree with you :-)
> >>
> >> I'm not sure the binding was properly done to reflect the HW
accurately.
> >>
> >> A local timer for my point of view should be located in the cpu node
> >> like a L1 cache. Or at least referenced in each cpu by a phandle.
> >>
> >> What was the rational to put it in the root?
> >
> > The rational was to follow what we already do for most (all?) banked
> > resources. We already have TWD, GIC and PMU that have a root node,
> > avoiding duplicated resources. I think consistency is an important thing
> > to have.
> >
> > If we decide to move everything into CPU nodes and duplicate all the
> > banked resources, fine. But that has impacts that reach far beyond the
> > simple case of the timer.
> >
> > In particular, good luck with the GIC distributor interface, where the
> > 32 first interrupts are per CPU. This would also mandate a redesign of
> > the way we specify a PPI, as the CPU mask in the third field doesn't
> > mean a thing anymore.
> >
> > If you insist on having a phandle to a timer node, fine by me.
> >
> Can you please comment on it so that we can conclude this thread ?
> I would like to update my patches and hence the push.
> 
Hmm...it's time to decide for now.

Let me add timer node for ARM arch timer at this moment. Then if any change
is required, will do it later.

If any objection, let me know. If not, I will queue following patch for
v3.9.

Thanks.

- Kukjin

-8<--8<-
-

From: Kukjin Kim 
Subject: [PATCH] ARM: dts: re-organized cpu node for exynos5440

This patch adds timer node and re-organizes cpu node for exynos5440.

Acked-by: Thomas Abraham 
Signed-off-by: Kukjin Kim 
---
 arch/arm/boot/dts/exynos5440.dtsi |   37
+
 1 file changed, 17 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 1e7a2b0..5c5a699 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -24,40 +24,37 @@
};
 
cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
cpu@0 {
compatible = "arm,cortex-a15";
-   timer {
-   compatible = "arm,armv7-timer";
-   interrupts = <1 13 0xf08>;
-   clock-frequency = <100>;
-   };
+   reg = <0>;
};
cpu@1 {
compatible = "arm,cortex-a15";
-   timer {
-   compatible = "arm,armv7-timer";
-   interrupts = <1 14 0xf

Re: [PATCH 1/2] iio: Update iio_channel_get API to use consumer device pointer as argument

[Anton Vorontsov]

On Mon, Feb 04, 2013 at 12:26:05PM -0800, Guenter Roeck wrote:
> For iio_channel_get to work with OF based configurations, it needs the
> consumer device pointer instead of the consumer device name as argument.
> 
> Signed-off-by: Guenter Roeck 
> ---
>  drivers/extcon/extcon-adc-jack.c|3 +--
>  drivers/iio/inkern.c|   11 ++-
>  drivers/power/generic-adc-battery.c |4 ++--
>  drivers/power/lp8788-charger.c  |8 
>  include/linux/iio/consumer.h|5 +++--
>  5 files changed, 20 insertions(+), 11 deletions(-)

Looks OK to me, Ack for drivers/power part.

Thanks.
Anton
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 6/6] Documentation: add docs for max8925 dt

[Haojian Zhuang]

From: Qing Xu 

add docs for dt of max8925-mfd, max8925-backlight, and
max8925-battery

Signed-off-by: Qing Xu 
Signed-off-by: Haojian Zhuang 
---
 Documentation/devicetree/bindings/mfd/max8925.txt  |   64 
 .../bindings/power_supply/max8925_batter.txt   |   18 ++
 .../bindings/video/backlight/max8925-backlight.txt |   10 +++
 3 files changed, 92 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/max8925.txt
 create mode 100644 
Documentation/devicetree/bindings/power_supply/max8925_batter.txt
 create mode 100644 
Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt

diff --git a/Documentation/devicetree/bindings/mfd/max8925.txt 
b/Documentation/devicetree/bindings/mfd/max8925.txt
new file mode 100644
index 000..4f0dc66
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max8925.txt
@@ -0,0 +1,64 @@
+* Maxim max8925 Power Management IC
+
+Required parent device properties:
+- compatible : "maxim,max8925"
+- reg : the I2C slave address for the max8925 chip
+- interrupts : IRQ line for the max8925 chip
+- interrupt-controller: describes the max8925 as an interrupt
+  controller (has its own domain)
+- #interrupt-cells : should be 1.
+   - The cell is the max8925 local IRQ number
+
+Optional parent device properties:
+- maxim,tsc-irq: there are 2 IRQ lines for max8925, one is indicated in
+  interrupts property, the other is indicated here.
+
+max8925 consists of a large and varied group of sub-devices:
+
+Device  Supply NamesDescription
+--  ---
+max8925-onkey  :   : On key
+max8925-rtc:   : RTC
+max8925-regulator  :   : Regulators
+max8925-backlight  :   : Backlight
+max8925-touch  :   : Touchscreen
+max8925-power  :   : Charger
+
+Example:
+
+   pmic: max8925@3c {
+   compatible = "maxim,max8925";
+   reg = <0x3c>;
+   interrupts = <1>;
+   interrupt-parent = <&intcmux4>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   maxim,tsc-irq = <0>;
+
+   regulators {
+   SDV1 {
+   regulator-min-microvolt = <637500>;
+   regulator-max-microvolt = <1425000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   LDO1 {
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <390>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   };
+   backlight {
+   maxim,max8925-dual-string = <0>;
+   };
+   charger {
+   batt-detect = <0>;
+   topoff-threshold = <1>;
+   fast-charge = <7>;
+   no-temp-support = <0>;
+   no-insert-detect = <0>;
+   };
+   };
diff --git a/Documentation/devicetree/bindings/power_supply/max8925_batter.txt 
b/Documentation/devicetree/bindings/power_supply/max8925_batter.txt
new file mode 100644
index 000..d7e3e0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/max8925_batter.txt
@@ -0,0 +1,18 @@
+max8925-battery bindings
+
+
+Optional properties :
+ - batt-detect: whether support battery detect
+ - topoff-threshold: set charging current in topoff mode
+ - fast-charge: set charging current in fast mode
+ - no-temp-support: whether support temperature protection detect
+ - no-insert-detect: whether support insert detect
+
+Example:
+   charger {
+   batt-detect = <0>;
+   topoff-threshold = <1>;
+   fast-charge = <7>;
+   no-temp-support = <0>;
+   no-insert-detect = <0>;
+   };
diff --git 
a/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt 
b/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
new file mode 100644
index 000..b4cffda
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
@@ -0,0 +1,10 @@
+88pm860x-backlight bindings
+
+Optional properties:
+  - maxim,max8925-dual-string: whether support dual string
+
+Example:
+
+   backlights {
+   maxim,max8925-dual-string = <0>;
+   };
-- 
1.7.10.4

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 5/6] mfd: max8925: add dts

[Haojian Zhuang]

From: Qing Xu 

Add max8925 dts support into mmp2 brownstone platform

Signed-off-by: Qing Xu 
Signed-off-by: Haojian Zhuang 
---
 arch/arm/boot/dts/mmp2-brownstone.dts |  158 +
 arch/arm/boot/dts/mmp2.dtsi   |4 +-
 2 files changed, 161 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/mmp2-brownstone.dts 
b/arch/arm/boot/dts/mmp2-brownstone.dts
index c9b4f27..7f70a39 100644
--- a/arch/arm/boot/dts/mmp2-brownstone.dts
+++ b/arch/arm/boot/dts/mmp2-brownstone.dts
@@ -29,6 +29,164 @@
};
twsi1: i2c@d4011000 {
status = "okay";
+   pmic: max8925@3c {
+   compatible = "maxium,max8925";
+   reg = <0x3c>;
+   interrupts = <1>;
+   interrupt-parent = <&intcmux4>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   maxim,tsc-irq = <0>;
+
+   regulators {
+   SDV1 {
+   regulator-min-microvolt 
= <637500>;
+   regulator-max-microvolt 
= <1425000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   SDV2 {
+   regulator-min-microvolt 
= <65>;
+   regulator-max-microvolt 
= <2225000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   SDV3 {
+   regulator-min-microvolt 
= <75>;
+   regulator-max-microvolt 
= <390>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   LDO1 {
+   regulator-min-microvolt 
= <75>;
+   regulator-max-microvolt 
= <390>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   LDO2 {
+   regulator-min-microvolt 
= <65>;
+   regulator-max-microvolt 
= <225>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   LDO3 {
+   regulator-min-microvolt 
= <65>;
+   regulator-max-microvolt 
= <225>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   LDO4 {
+   regulator-min-microvolt 
= <75>;
+   regulator-max-microvolt 
= <390>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   LDO5 {
+   regulator-min-microvolt 
= <75>;
+   regulator-max-microvolt 
= <390>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   LDO6 {
+   regulator-min-microvolt 
= <75>;
+   regulator-max-microvolt 

[PATCH 4/6] mfd: max8925: support dt for backlight

[Haojian Zhuang]

From: Qing Xu 

Add device tree support in max8925 backlight.

Signed-off-by: Qing Xu 
Signed-off-by: Haojian Zhuang 
---
 drivers/video/backlight/max8925_bl.c |   31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/video/backlight/max8925_bl.c 
b/drivers/video/backlight/max8925_bl.c
index 2c9bce0..5ca11b0 100644
--- a/drivers/video/backlight/max8925_bl.c
+++ b/drivers/video/backlight/max8925_bl.c
@@ -101,6 +101,29 @@ static const struct backlight_ops max8925_backlight_ops = {
.get_brightness = max8925_backlight_get_brightness,
 };
 
+#ifdef CONFIG_OF
+static int max8925_backlight_dt_init(struct platform_device *pdev,
+ struct max8925_backlight_pdata *pdata)
+{
+   struct device_node *nproot = pdev->dev.parent->of_node, *np;
+   int dual_string;
+
+   if (!nproot)
+   return -ENODEV;
+   np = of_find_node_by_name(nproot, "backlight");
+   if (!np) {
+   dev_err(&pdev->dev, "failed to find backlight node\n");
+   return -ENODEV;
+   }
+
+   of_property_read_u32(np, "maxim,max8925-dual-string", &dual_string);
+   pdata->dual_string = dual_string;
+   return 0;
+}
+#else
+#define max8925_backlight_dt_init(x, y)(-1)
+#endif
+
 static int max8925_backlight_probe(struct platform_device *pdev)
 {
struct max8925_chip *chip = dev_get_drvdata(pdev->dev.parent);
@@ -147,6 +170,13 @@ static int max8925_backlight_probe(struct platform_device 
*pdev)
platform_set_drvdata(pdev, bl);
 
value = 0;
+   if (pdev->dev.parent->of_node && !pdata) {
+   pdata = devm_kzalloc(&pdev->dev,
+sizeof(struct max8925_backlight_pdata),
+GFP_KERNEL);
+   max8925_backlight_dt_init(pdev, pdata);
+   }
+
if (pdata) {
if (pdata->lxw_scl)
value |= (1 << 7);
@@ -158,7 +188,6 @@ static int max8925_backlight_probe(struct platform_device 
*pdev)
ret = max8925_set_bits(chip->i2c, data->reg_mode_cntl, 0xfe, value);
if (ret < 0)
goto out_brt;
-
backlight_update_status(bl);
return 0;
 out_brt:
-- 
1.7.10.4

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 3/6] mfd: max8925: fix onkey driver irq base

[Haojian Zhuang]

From: Qing Xu 

update onkey driver's irq base, it should get from max8925,
but not save in a private value

Signed-off-by: Qing Xu 
Acked-by: Dmitry Torokhov 
---
 drivers/input/misc/max8925_onkey.c |3 ---
 drivers/mfd/max8925-core.c |2 +-
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/input/misc/max8925_onkey.c 
b/drivers/input/misc/max8925_onkey.c
index 369a39d..f9179b2 100644
--- a/drivers/input/misc/max8925_onkey.c
+++ b/drivers/input/misc/max8925_onkey.c
@@ -100,9 +100,6 @@ static int max8925_onkey_probe(struct platform_device *pdev)
input->dev.parent = &pdev->dev;
input_set_capability(input, EV_KEY, KEY_POWER);
 
-   irq[0] += chip->irq_base;
-   irq[1] += chip->irq_base;
-
error = request_threaded_irq(irq[0], NULL, max8925_onkey_handler,
 IRQF_ONESHOT, "onkey-down", info);
if (error < 0) {
diff --git a/drivers/mfd/max8925-core.c b/drivers/mfd/max8925-core.c
index d7abbb3..f0cc402 100644
--- a/drivers/mfd/max8925-core.c
+++ b/drivers/mfd/max8925-core.c
@@ -867,7 +867,7 @@ int max8925_device_init(struct max8925_chip *chip,
 
ret = mfd_add_devices(chip->dev, 0, &onkey_devs[0],
  ARRAY_SIZE(onkey_devs),
- NULL, 0, NULL);
+ NULL, chip->irq_base, NULL);
if (ret < 0) {
dev_err(chip->dev, "Failed to add onkey subdev\n");
goto out_dev;
-- 
1.7.10.4

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 2/6] mfd: max8925: fix mfd device register failure

[Haojian Zhuang]

From: Qing Xu 

we encounter rtc/power/touch driver registry failure, root cause
it is resources confilict in insert_resouce, solved by changing
mfd_add_devices 5th parameter to NULL

Signed-off-by: Qing Xu 
---
 drivers/mfd/max8925-core.c |   22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/mfd/max8925-core.c b/drivers/mfd/max8925-core.c
index 0ad8d9a..d7abbb3 100644
--- a/drivers/mfd/max8925-core.c
+++ b/drivers/mfd/max8925-core.c
@@ -859,7 +859,7 @@ int max8925_device_init(struct max8925_chip *chip,
 
ret = mfd_add_devices(chip->dev, 0, &rtc_devs[0],
  ARRAY_SIZE(rtc_devs),
- &rtc_resources[0], chip->irq_base, NULL);
+ NULL, chip->irq_base, NULL);
if (ret < 0) {
dev_err(chip->dev, "Failed to add rtc subdev\n");
goto out;
@@ -867,7 +867,7 @@ int max8925_device_init(struct max8925_chip *chip,
 
ret = mfd_add_devices(chip->dev, 0, &onkey_devs[0],
  ARRAY_SIZE(onkey_devs),
- &onkey_resources[0], 0, NULL);
+ NULL, 0, NULL);
if (ret < 0) {
dev_err(chip->dev, "Failed to add onkey subdev\n");
goto out_dev;
@@ -886,21 +886,19 @@ int max8925_device_init(struct max8925_chip *chip,
goto out_dev;
}
 
-   if (pdata && pdata->power) {
-   ret = mfd_add_devices(chip->dev, 0, &power_devs[0],
- ARRAY_SIZE(power_devs),
- &power_supply_resources[0], 0, NULL);
-   if (ret < 0) {
-   dev_err(chip->dev,
-   "Failed to add power supply subdev\n");
-   goto out_dev;
-   }
+   ret = mfd_add_devices(chip->dev, 0, &power_devs[0],
+ ARRAY_SIZE(power_devs),
+ NULL, 0, NULL);
+   if (ret < 0) {
+   dev_err(chip->dev,
+   "Failed to add power supply subdev, err = %d\n", ret);
+   goto out_dev;
}
 
if (pdata && pdata->touch) {
ret = mfd_add_devices(chip->dev, 0, &touch_devs[0],
  ARRAY_SIZE(touch_devs),
- &touch_resources[0], 0, NULL);
+ NULL, chip->tsc_irq, NULL);
if (ret < 0) {
dev_err(chip->dev, "Failed to add touch subdev\n");
goto out_dev;
-- 
1.7.10.4

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 1/6] mfd: max8925: add irqdomain for dt

[Haojian Zhuang]

From: Qing Xu 

Add irqdomains for max8925's main irq, wrap irq register operations
into irqdomain's map func. it is necessary for dt support.

Also, add dt support for max8925 driver.

Signed-off-by: Qing Xu 
Signed-off-by: Haojian Zhuang 
---
 drivers/mfd/max8925-core.c  |   73 +--
 drivers/mfd/max8925-i2c.c   |   36 +++--
 include/linux/mfd/max8925.h |3 +-
 3 files changed, 78 insertions(+), 34 deletions(-)

diff --git a/drivers/mfd/max8925-core.c b/drivers/mfd/max8925-core.c
index e32466e..0ad8d9a 100644
--- a/drivers/mfd/max8925-core.c
+++ b/drivers/mfd/max8925-core.c
@@ -14,10 +14,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 static struct resource bk_resources[] = {
{ 0x84, 0x84, "mode control", IORESOURCE_REG, },
@@ -639,17 +642,33 @@ static struct irq_chip max8925_irq_chip = {
.irq_disable= max8925_irq_disable,
 };
 
+static int max8925_irq_domain_map(struct irq_domain *d, unsigned int virq,
+irq_hw_number_t hw)
+{
+   irq_set_chip_data(virq, d->host_data);
+   irq_set_chip_and_handler(virq, &max8925_irq_chip, handle_edge_irq);
+   irq_set_nested_thread(virq, 1);
+#ifdef CONFIG_ARM
+   set_irq_flags(virq, IRQF_VALID);
+#else
+   irq_set_noprobe(virq);
+#endif
+   return 0;
+}
+
+static struct irq_domain_ops max8925_irq_domain_ops = {
+   .map= max8925_irq_domain_map,
+   .xlate  = irq_domain_xlate_onetwocell,
+};
+
+
 static int max8925_irq_init(struct max8925_chip *chip, int irq,
struct max8925_platform_data *pdata)
 {
unsigned long flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT;
-   int i, ret;
-   int __irq;
+   int ret;
+   struct device_node *node = chip->dev->of_node;
 
-   if (!pdata || !pdata->irq_base) {
-   dev_warn(chip->dev, "No interrupt support on IRQ base\n");
-   return -EINVAL;
-   }
/* clear all interrupts */
max8925_reg_read(chip->i2c, MAX8925_CHG_IRQ1);
max8925_reg_read(chip->i2c, MAX8925_CHG_IRQ2);
@@ -667,35 +686,30 @@ static int max8925_irq_init(struct max8925_chip *chip, 
int irq,
max8925_reg_write(chip->rtc, MAX8925_RTC_IRQ_MASK, 0xff);
 
mutex_init(&chip->irq_lock);
-   chip->core_irq = irq;
-   chip->irq_base = pdata->irq_base;
-
-   /* register with genirq */
-   for (i = 0; i < ARRAY_SIZE(max8925_irqs); i++) {
-   __irq = i + chip->irq_base;
-   irq_set_chip_data(__irq, chip);
-   irq_set_chip_and_handler(__irq, &max8925_irq_chip,
-handle_edge_irq);
-   irq_set_nested_thread(__irq, 1);
-#ifdef CONFIG_ARM
-   set_irq_flags(__irq, IRQF_VALID);
-#else
-   irq_set_noprobe(__irq);
-#endif
-   }
-   if (!irq) {
-   dev_warn(chip->dev, "No interrupt support on core IRQ\n");
-   goto tsc_irq;
+   chip->irq_base = irq_alloc_descs(-1, 0, MAX8925_NR_IRQS, 0);
+   if (chip->irq_base < 0) {
+   dev_err(chip->dev, "Failed to allocate interrupts, ret:%d\n",
+   chip->irq_base);
+   return -EBUSY;
}
 
+   irq_domain_add_legacy(node, MAX8925_NR_IRQS, chip->irq_base, 0,
+ &max8925_irq_domain_ops, chip);
+
+   /* request irq handler for pmic main irq*/
+   chip->core_irq = irq;
+   if (!chip->core_irq)
+   return -EBUSY;
ret = request_threaded_irq(irq, NULL, max8925_irq, flags | IRQF_ONESHOT,
   "max8925", chip);
if (ret) {
dev_err(chip->dev, "Failed to request core IRQ: %d\n", ret);
chip->core_irq = 0;
+   return -EBUSY;
}
 
-tsc_irq:
+   /* request irq handler for pmic tsc irq*/
+
/* mask TSC interrupt */
max8925_reg_write(chip->adc, MAX8925_TSC_IRQ_MASK, 0x0f);
 
@@ -704,7 +718,6 @@ tsc_irq:
return 0;
}
chip->tsc_irq = pdata->tsc_irq;
-
ret = request_threaded_irq(chip->tsc_irq, NULL, max8925_tsc_irq,
   flags | IRQF_ONESHOT, "max8925-tsc", chip);
if (ret) {
@@ -875,11 +888,11 @@ int max8925_device_init(struct max8925_chip *chip,
 
if (pdata && pdata->power) {
ret = mfd_add_devices(chip->dev, 0, &power_devs[0],
-   ARRAY_SIZE(power_devs),
+ ARRAY_SIZE(power_devs),
  &power_supply_resources[0], 0, NULL);
if (ret < 0) {
-   dev_err(chip->dev, "Failed to add power supply "
-   "subdev\n");
+   dev_err(chip->dev,
+   "Failed to add power supply sub

Re: [PATCH 3/3 v5] ASoC: simple-card: add Device Tree support

[Stephen Warren]

On 02/06/2013 05:55 PM, Kuninori Morimoto wrote:
> Support for loading the simple-card module via devicetree.
> It requests cpu/codec information for probing.


> +Simple-Card:
> +
> +Required properties:
> +
> + [prefix] means cpu/codec here
> +
> +- compatible : "simple-audio"
> +- simple-audio,card-name : simple-audio card name
> +- simple-audio,format: see below

> +- simple-audio,[prefix],dai  : phandle and port for CPU/CODEC
> +- simple-audio,[prefix],frame-master : frame master
> +- simple-audio,[prefix],bitclock-master  : bitclock master
> +
> +Optional properties:
> +
> +- simple-audio,system-clock-frequency: system clock rate if 
> it is connected to both CPU/CODEC
> +- simple-audio,bitclock-inversion: bit clock inversion for both 
> CPU/CODEC
> +- simple-audio,frame-inversion   : frame inversion for 
> both CPU/CODEC
> +
> +- simple-audio,[prefix],bitclock-inversion   : if CPU/CODEC needs clock 
> inversion
> +- simple-audio,[prefix],frame-inversion  : if CPU/CODEC needs 
> frame inversion
> +- simple-audio,[prefix],system-clock-frequency   : system clock rate for 
> each CPU/CODEC

I know Mark had a preference to store DAI-specific data in sub-nodes
rather than using this "[prefix]" thing... If that doesn't end up
happening though, rather than "[prefix],", I think it'd be more typical
to use "[prefix]-" since I've never seen a DT property name with two
","; "-" is typically used as the word separator in DT property names.

> +sound {
> + compatible = "simple-audio";
...
> + simple-audio,codec,dai = <&ak4648 0>;
...
> +sh_fsi2: sh_fsi2@0xec23 {
> + compatible = "renesas,sh_fsi2";
> + reg = <0xec23 0x400>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 146 0x4>;
> +};

Note that the DT binding documentation for renesas,sh_fsi2 needs to define:

a) The value of the #sound-dai-cells property that's missing from the
sh_fsi2 node.

b) The legal values for the "0" in the "simple-audio,codec,dai" property
in the "sound" node above, and which DAI on the device each value
represents.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V4 3/4] input: keyboard: tegra: add support for rows/cols configuration from dt

[Grant Likely]

On Sun, 6 Jan 2013 16:44:59 +0530, Laxman Dewangan  wrote:
> The NVIDIA's Tegra KBC has maximum 24 pins to make matrix keypad.
> Any pin can be configured as row or column. The maximum column pin
> can be 8 and maximum row pin can be 16.
> 
> Remove the assumption that all first 16 pins will be used as row
> and remaining as columns and Add the property for configuring pins
> to either row or column from DT. Update the devicetree binding
> document accordingly.
> 
> Signed-off-by: Laxman Dewangan 
> ---
> Changes from V1:
> - renames the rows and pins property array.
> - nit cleanups.
> Changes from V2/V3:
>  None
> 
>  .../bindings/input/nvidia,tegra20-kbc.txt  |   22 ++
>  drivers/input/keyboard/tegra-kbc.c |   74 
> +++-
>  2 files changed, 79 insertions(+), 17 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt 
> b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
> index 72683be..2995fae 100644
> --- a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
> +++ b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
> @@ -1,7 +1,18 @@
>  * Tegra keyboard controller
> +The key controller has maximum 24 pins to make matrix keypad. Any pin
> +can be configured as row or column. The maximum column pin can be 8
> +and maximum row pins can be 16 for Tegra20/Tegra30.
>  
>  Required properties:
>  - compatible: "nvidia,tegra20-kbc"
> +- reg: Register base address of KBC.
> +- interrupts: Interrupt number for the KBC.
> +- nvidia,kbc-row-pins: The KBC pins which are configured as row. This is an
> +  array of pin numbers which is used as rows.
> +- nvidia,kbc-col-pins: The KBC pins which are configured as column. This is 
> an
> +  array of pin numbers which is used as column.
> +- linux,keymap: The keymap for keys as described in the binding document
> +  devicetree/bindings/input/matrix-keymap.txt.

For the binding:
Acked-by: Grant Likely 
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 2/3] ASoC: add snd_soc_of_get_port_dai_name()

[Stephen Warren]

On 02/05/2013 03:11 AM, Kuninori Morimoto wrote:
> This patch adds snd_soc_of_get_port_dai_name() to get
> dai name from device_node and port number.

> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c

> +const char *snd_soc_of_get_port_dai_name(struct device_node *of_node, int 
> port)

OK, that function prototype seems like /almost/ the right kind of thing
to be doing.

"int port" should be "const struct of_phandle_args *portspec", since the
port ID could be encoded into device tree with more than one cell, and
the cells are uint32_t not int.

> +{
> + struct snd_soc_dai *dai;
> + int i = 0;
> +
> + list_for_each_entry(dai, &dai_list, list) {
> + if (dai->dev->of_node == of_node) {
> + if (port == i)
> + return dai->name;

Is this the reason for the previous patch? This is horribly wrong. The
only way this could work is with internal knowledge of how ASoC works,
yet the device tree must be written in a completely OS-/driver-agnostic
fashion, purely describing hardware.

This function should be implemented as follows:

1) Find the driver for dai->dev

2) Call an "of_xlate" function on that driver, passing it the "portspec"
I mentioned above; the driver will interpret the portspec, maps it to
the ASoC port name, and return it.

The DT binding for each audio component must define the list of valid
port IDs, and the number of cells used to encode the value.

See for example the GPIO and PWM subsystem's of_xlate functions.

> +
> + i++;
> + }
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(snd_soc_of_get_port_dai_name);

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2] gpio: mcp23s08: convert driver to DT

[Grant Likely]

On Mon, 11 Feb 2013 12:52:42 +0100, Lars Poeschel  
wrote:
> From: Lars Poeschel 
> 
> This converts the mcp23s08 driver to be able to be used with device
> tree.
> Explicitly allow -1 as a legal value for the
> mcp23s08_platform_data->base. This is the special value lets the
> kernel choose a valid global gpio base number.
> There is a "mcp,chips" device tree property, that correspond to the
> chips member of the struct mcp23s08_platform_data. It can be used for
> multiple mcp23s08/mc23s17 on the same spi chipselect.
> 
> Signed-off-by: Lars Poeschel 
> ---
> v2:
> - squashed booth patches together
> - fixed build warning, when CONFIG_OF is not defined
> - use of_match_ptr macro for of_match_table
> 
>  .../devicetree/bindings/gpio/gpio-mcp23s08.txt |   36 
>  drivers/gpio/gpio-mcp23s08.c   |   95 
> ++--
>  include/linux/spi/mcp23s08.h   |1 +
>  3 files changed, 126 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
> new file mode 100644
> index 000..17eb669
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
> @@ -0,0 +1,36 @@
> +Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for
> +8-/16-bit I/O expander with serial interface (I2C/SPI)
> +
> +Required properties:
> +- compatible : Should be
> +- "mcp,mcp23s08" for  8 GPIO SPI version
> +- "mcp,mcp23s17" for 16 GPIO SPI version
> +- "mcp,mcp23008" for  8 GPIO I2C version or
> +- "mcp,mcp23017" for 16 GPIO I2C version of the chip
> +- #gpio-cells : Should be two.
> +  - first cell is the pin number
> +  - second cell is used to specify optional parameters (currently unused)
> +- gpio-controller : Marks the device node as a GPIO controller.
> +- reg : For an address on its bus
> +
> +Optional device specific properties:
> +- mcp,chips : This is a table with 2 columns and up to 8 entries. The first 
> column
> + is a is_present flag, that makes only sense for SPI chips. Multiple
> + chips can share the same chipselect. This flag can be 0 or 1 depending
> + if there is a chip at this address or not.
> + The second column is written to the GPPU register, selecting a 100k
> + pullup resistor or not. Setting a 1 is activating the pullup.
> + For I2C chips only the first line in this table is used. Further chips
> + are registered at different addresses at the I2C bus.

Since these are two separate things, I would put them into separate
properties. Perhaps something like:
 - mcp,spi-present-mask = < mask >; /* one bit per chip */
 - mcp,pullup-enable-mask = < enable-value ... >;

However, is the pullup selection per-gpio line? If so, then why not
encode it into the flags field of the gpio specifier?

> +
> +Example:
> +gpiom1: gpio@20 {
> +compatible = "mcp,mcp23017";
> +gpio-controller;
> +#gpio-cells = <2>;
> +reg = <0x20>;
> + chips = <
> + /* is_present  pullups */
> + 1   0x07/* chip address 0 */
> + >;
> +};
> diff --git a/drivers/gpio/gpio-mcp23s08.c b/drivers/gpio/gpio-mcp23s08.c
> index 3cea0ea..ad08a5a 100644
> --- a/drivers/gpio/gpio-mcp23s08.c
> +++ b/drivers/gpio/gpio-mcp23s08.c
> @@ -12,6 +12,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /**
>   * MCP types supported by driver
> @@ -473,17 +475,88 @@ fail:
>  
>  /*--*/
>  
> +#ifdef CONFIG_OF
> +static struct of_device_id mcp23s08_of_match[] = {
> +#ifdef CONFIG_SPI_MASTER
> + {
> + .compatible = "mcp,mcp23s08",
> + },
> + {
> + .compatible = "mcp,mcp23s17",
> + },
> +#endif
> +#if IS_ENABLED(CONFIG_I2C)
> + {
> + .compatible = "mcp,mcp23008",
> + },
> + {
> + .compatible = "mcp,mcp23017",
> + },
> +#endif
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, mcp23s08_of_match);

I don't think this is actually what you want. You should use separate
match tables; one for I2C and one for SPI.

> +
> +static struct mcp23s08_platform_data *
> + of_get_mcp23s08_pdata(struct device *dev)
> +{
> + struct mcp23s08_platform_data *pdata;
> + struct device_node *np = dev->of_node;
> + u32 chips[sizeof(pdata->chip)];
> + int ret, i, j;
> +
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return NULL;
> +
> + pdata->base = -1;
> +
> + for (i = ARRAY_SIZE(pdata->chip) * MCP23S08_CHIP_INFO_MEMBERS;
> + i > 0; i -= MCP23S08_CHIP_INFO_MEMBERS) {
> + ret = of_property_read_u32_array(np, "mcp,chips", chips, i);
> + if (ret == -EOVERFLOW)
> + continue;
> + break;
> + }
> 

Re: [PATCH 1/3] ASoC: use list_add_tail() instead of list_add() for platform/codec/dai list

[Stephen Warren]

On 02/05/2013 03:11 AM, Kuninori Morimoto wrote:
> Current ASoC is using list_add() in order to add new list to
> platform/codec/dai list.
> But it breaks added list's order.
> This patch use list_add_tail() instead of list_add() to solve this issue.

Do these lists have a defined order, such that changing the order does
actually /break/ something?

I'm just curious what the motivation for this patch is really; is it
just cosmetic?
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH] of: fix recursive locking in of_get_next_available_child()

[Stephen Warren]

From: Stephen Warren 

of_get_next_available_child() acquires devtree_lock, then calls
of_device_is_available() which calls of_get_property() which calls
of_find_property() which tries to re-acquire devtree_lock, thus causing
deadlock.

To avoid this, create a new __of_device_is_available() which calls
__of_get_property() instead, which calls __of_find_property(), which
does not take the lock,. Update of_get_next_available_child() to call
the new __of_device_is_available() since it already owns the lock.

Signed-off-by: Stephen Warren 
---
 drivers/of/base.c |   30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index e8d65af..f7a87ce 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -290,19 +290,19 @@ int of_machine_is_compatible(const char *compat)
 EXPORT_SYMBOL(of_machine_is_compatible);
 
 /**
- *  of_device_is_available - check if a device is available for use
+ *  __of_device_is_available - check if a device is available for use
  *
- *  @device: Node to check for availability
+ *  @device: Node to check for availability, with locks already held
  *
  *  Returns 1 if the status property is absent or set to "okay" or "ok",
  *  0 otherwise
  */
-int of_device_is_available(const struct device_node *device)
+static int __of_device_is_available(const struct device_node *device)
 {
const char *status;
int statlen;
 
-   status = of_get_property(device, "status", &statlen);
+   status = __of_get_property(device, "status", &statlen);
if (status == NULL)
return 1;
 
@@ -313,6 +313,26 @@ int of_device_is_available(const struct device_node 
*device)
 
return 0;
 }
+
+/**
+ *  of_device_is_available - check if a device is available for use
+ *
+ *  @device: Node to check for availability
+ *
+ *  Returns 1 if the status property is absent or set to "okay" or "ok",
+ *  0 otherwise
+ */
+int of_device_is_available(const struct device_node *device)
+{
+   unsigned long flags;
+   int res;
+
+   raw_spin_lock_irqsave(&devtree_lock, flags);
+   res = __of_device_is_available(device);
+   raw_spin_unlock_irqrestore(&devtree_lock, flags);
+   return res;
+
+}
 EXPORT_SYMBOL(of_device_is_available);
 
 /**
@@ -404,7 +424,7 @@ struct device_node *of_get_next_available_child(const 
struct device_node *node,
raw_spin_lock(&devtree_lock);
next = prev ? prev->sibling : node->child;
for (; next; next = next->sibling) {
-   if (!of_device_is_available(next))
+   if (!__of_device_is_available(next))
continue;
if (of_node_get(next))
break;
-- 
1.7.10.4

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH next v2] OF: convert devtree lock from rw_lock to raw spinlock

[Rob Herring]

On 02/11/2013 01:29 PM, Stephen Warren wrote:
> On 02/08/2013 04:09 PM, Rob Herring wrote:
>> On 02/06/2013 02:30 PM, Paul Gortmaker wrote:
>>> From: Thomas Gleixner 
>>>
>>> With the locking cleanup in place (from "OF: Fixup resursive
>>> locking code paths"), we can now do the conversion from the
>>> rw_lock to a raw spinlock as required for preempt-rt.
>>>
>>> The previous cleanup and this conversion were originally
>>> separate since they predated when mainline got raw spinlock (in
>>> commit c2f21ce2e31286a "locking: Implement new raw_spinlock").
>>>
>>> So, at that point in time, the cleanup was considered plausible
>>> for mainline, but not this conversion.  In any case, we've kept
>>> them separate as it makes for easier review and better bisection.
>>>
>>> Signed-off-by: Thomas Gleixner 
>>> [PG: taken from preempt-rt, update subject & add a commit log]
>>> Signed-off-by: Paul Gortmaker 
>>> ---
>>>
>>> [v2: recent commit e81b329 ("powerpc+of: Add /proc device tree
>>>  updating to of node add/remove") added two more instances of
>>>  write_unlock that also needed converting to raw_spin_unlock.
>>>  Retested (boot) on sbc8548, defconfig builds on arm/sparc; no
>>>  new warnings observed.]
>>>
>>>  arch/sparc/kernel/prom_common.c |   4 +-
>>>  drivers/of/base.c   | 100 
>>> ++--
>>>  include/linux/of.h  |   2 +-
>>>  3 files changed, 59 insertions(+), 47 deletions(-)
>>
>> Applied.
> 
> This commit is present in next-20130211, and causes a boot failure
> (hang) early while booting on Tegra. Reverting just this one commit
> solves the issue.
> 
> I'll see if I can track down where the issue is. Given the commit
> description, I assume there's some new recursive lock issue that snuck
> in between the previous fix for them and this commit? Any hints welcome.
> 
> One thing I wonder looking at the patch: Most paths use
> raw_spin_lock_irqsave() but a few use just raw_spin_lock(). I wonder how
> that decision was made?

I found the problem. of_get_next_available_child ->
of_device_is_available -> of_get_property -> of_get_property. An
unlocked version of of_device_is_available is needed here.

Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 1/4] of/pci: Provide support for parsing PCI DT ranges property

[Rob Herring]

On 02/11/2013 02:22 AM, Thierry Reding wrote:
> From: Andrew Murray 
> 
> DT bindings for PCI host bridges often use the ranges property to describe
> memory and IO ranges - this binding tends to be the same across architectures
> yet several parsing implementations exist, e.g. arch/mips/pci/pci.c,
> arch/powerpc/kernel/pci-common.c, arch/sparc/kernel/pci.c and
> arch/microblaze/pci/pci-common.c (clone of PPC). Some of these duplicate
> functionality provided by drivers/of/address.c.
> 
> This patch provides a common iterator-based parser for the ranges property, it
> is hoped this will reduce DT representation differences between architectures
> and that architectures will migrate in part to this new parser.
> 
> It is also hoped (and the motativation for the patch) that this patch will
> reduce duplication of code when writing host bridge drivers that are supported
> by multiple architectures.
> 
> This patch provides struct resources from a device tree node, e.g.:
> 
>   u32 *last = NULL;
>   struct resource res;
>   while ((last = of_pci_process_ranges(np, res, last))) {
>   //do something with res
>   }
> 
> Platforms with quirks can then do what they like with the resource or migrate
> common quirk handling to the parser. In an ideal world drivers can just 
> request
> the obtained resources and pass them on (e.g. pci_add_resource_offset).
> 
> Signed-off-by: Andrew Murray 
> Signed-off-by: Liviu Dudau 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/of/address.c   | 63 
> ++
>  include/linux/of_address.h |  9 +++
>  2 files changed, 72 insertions(+)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 04da786..f607008 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -13,6 +13,7 @@
>  #define OF_CHECK_COUNTS(na, ns)  (OF_CHECK_ADDR_COUNT(na) && (ns) > 0)
>  
>  static struct of_bus *of_match_bus(struct device_node *np);
> +static struct of_bus *of_find_bus(const char *name);

Can you move this function up to avoid the forward declaration.

>  static int __of_address_to_resource(struct device_node *dev,
>   const __be32 *addrp, u64 size, unsigned int flags,
>   const char *name, struct resource *r);
> @@ -227,6 +228,57 @@ int of_pci_address_to_resource(struct device_node *dev, 
> int bar,
>   return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
>  }
>  EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> +
> +const __be32 *of_pci_process_ranges(struct device_node *node,
> + struct resource *res, const __be32 *from)
> +{
> + const __be32 *start, *end;
> + int na, ns, np, pna;
> + int rlen;
> + struct of_bus *bus;
> +
> + WARN_ON(!res);
> +
> + bus = of_find_bus("pci");
> + bus->count_cells(node, &na, &ns);
> + if (!OF_CHECK_COUNTS(na, ns)) {
> + pr_err("Bad cell count for %s\n", node->full_name);
> + return NULL;
> + }
> +
> + pna = of_n_addr_cells(node);
> + np = pna + na + ns;
> +
> + start = of_get_property(node, "ranges", &rlen);
> + if (start == NULL)
> + return NULL;
> +
> + end = start + rlen / sizeof(__be32);
> +
> + if (!from)
> + from = start;
> +
> + while (from + np <= end) {
> + u64 cpu_addr, size;
> +
> + cpu_addr = of_translate_address(node, from + na);
> + size = of_read_number(from + na + pna, ns);
> + res->flags = bus->get_flags(from);
> + from += np;
> +
> + if (cpu_addr == OF_BAD_ADDR || size == 0)
> + continue;
> +
> + res->name = node->full_name;
> + res->start = cpu_addr;
> + res->end = res->start + size - 1;
> + res->parent = res->child = res->sibling = NULL;
> + return from;
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_process_ranges);
>  #endif /* CONFIG_PCI */
>  
>  /*
> @@ -337,6 +389,17 @@ static struct of_bus *of_match_bus(struct device_node 
> *np)
>   return NULL;
>  }
>  
> +static struct of_bus *of_find_bus(const char *name)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(of_busses); i++)
> + if (strcmp(name, of_busses[i].name) == 0)
  ^
space needed.

> + return &of_busses[i];
> +
> + return NULL;
> +}
> +
>  static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>   struct of_bus *pbus, __be32 *addr,
>   int na, int ns, int pna, const char *rprop)
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 0506eb5..751e889 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -27,6 +27,8 @@ static inline unsigned long pci_address_to_pio(phys_addr_t 
> addr) { return -1; }
>  #de

Re: [PATCH next v2] OF: convert devtree lock from rw_lock to raw spinlock

[Stephen Warren]

On 02/08/2013 04:09 PM, Rob Herring wrote:
> On 02/06/2013 02:30 PM, Paul Gortmaker wrote:
>> From: Thomas Gleixner 
>>
>> With the locking cleanup in place (from "OF: Fixup resursive
>> locking code paths"), we can now do the conversion from the
>> rw_lock to a raw spinlock as required for preempt-rt.
>>
>> The previous cleanup and this conversion were originally
>> separate since they predated when mainline got raw spinlock (in
>> commit c2f21ce2e31286a "locking: Implement new raw_spinlock").
>>
>> So, at that point in time, the cleanup was considered plausible
>> for mainline, but not this conversion.  In any case, we've kept
>> them separate as it makes for easier review and better bisection.
>>
>> Signed-off-by: Thomas Gleixner 
>> [PG: taken from preempt-rt, update subject & add a commit log]
>> Signed-off-by: Paul Gortmaker 
>> ---
>>
>> [v2: recent commit e81b329 ("powerpc+of: Add /proc device tree
>>  updating to of node add/remove") added two more instances of
>>  write_unlock that also needed converting to raw_spin_unlock.
>>  Retested (boot) on sbc8548, defconfig builds on arm/sparc; no
>>  new warnings observed.]
>>
>>  arch/sparc/kernel/prom_common.c |   4 +-
>>  drivers/of/base.c   | 100 
>> ++--
>>  include/linux/of.h  |   2 +-
>>  3 files changed, 59 insertions(+), 47 deletions(-)
> 
> Applied.

This commit is present in next-20130211, and causes a boot failure
(hang) early while booting on Tegra. Reverting just this one commit
solves the issue.

I'll see if I can track down where the issue is. Given the commit
description, I assume there's some new recursive lock issue that snuck
in between the previous fix for them and this commit? Any hints welcome.

One thing I wonder looking at the patch: Most paths use
raw_spin_lock_irqsave() but a few use just raw_spin_lock(). I wonder how
that decision was made?
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V8] kbuild: create a rule to run the pre-processor on *.dts files

[Stephen Warren]

On 02/08/2013 08:45 AM, Grant Likely wrote:
> On Tue,  5 Feb 2013 12:06:28 -0700, Stephen Warren  
> wrote:
>> Create cmd_dtc_cpp to run the C pre-processor on *.dts file before
>> passing them to dtc for final compilation. This allows the use of #define
>> and #include within the .dts file.
...
> I've applied this and was going to push it out, but I've just thought of
> a problem that could be a show stopper. ...

Grant, I notice this showed up in next-20130211 as:

22435f3 kbuild: create a rule to run the pre-processor on *.dts files

Was that intentional? I assumed you wanted me to rework this before
you'd apply it, rather than sending an incremental patch.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Sound record on Devkit8000 with DT boot issue

[Anil Kumar]

Hi Peter,

Thanks for helping me. please see my comment inline

On Mon, Feb 11, 2013 at 6:47 PM, Peter Ujfalusi  wrote:
> On 02/10/2013 04:21 PM, Anil Kumar wrote:
>> Hi All,
>>
>> I am working on Devkit8000 and adding DT support for that. I am trying
>> to add sound DT node support for this boards.
>> I have nearly done with this but facing issue on record. I do not have
>> much knowledge of twl4030 audio codec but with
>> small Hack[1] (as MainMic connected to the input jack)  i am able to
>> record sound on Devkit8000.
>> I do not know that MICBIAS1_EN can be enable by amixer commands.
>> Could you please help me to get out of this ?
>
> You need to pass the routing information via DT for Devkit8000. This is not
> done for the BeagleBoard since it works without it (no need for MICBIAS for
> example)
>
>>
>>
>> 1) Hack [1]
>>
>> diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
>> index 63b280b..6780681 100644
>> --- a/sound/soc/codecs/twl4030.c
>> +++ b/sound/soc/codecs/twl4030.c
>> @@ -1473,7 +1473,7 @@ static const struct snd_soc_dapm_widget
>> twl4030_dapm_widgets[] = {
>> SND_SOC_DAPM_SUPPLY("micbias2 select", TWL4030_REG_MICBIAS_CTL, 6, 0,
>> NULL, 0),
>>
>> -   SND_SOC_DAPM_MICBIAS("Mic Bias 1", TWL4030_REG_MICBIAS_CTL, 0, 0),
>> +   SND_SOC_DAPM_MICBIAS("Mic Bias 1", TWL4030_REG_MICBIAS_CTL, 0, 1),
>
> Yes, this is HACK and it is wrong at the same time.

Agree

>
>> SND_SOC_DAPM_MICBIAS("Mic Bias 2", TWL4030_REG_MICBIAS_CTL, 1, 0),
>> SND_SOC_DAPM_MICBIAS("Headset Mic Bias", TWL4030_REG_MICBIAS_CTL, 2, 
>> 0),
>>
>>
>> 2) Sound DT node patch for Devkit8000
>>
>> diff --git a/arch/arm/boot/dts/omap3-
>> devkit8000.dts b/arch/arm/boot/dts/omap3-devkit8000.dts
>> index dc59272..5f3eec0 100644
>> --- a/arch/arm/boot/dts/omap3-devkit8000.dts
>> +++ b/arch/arm/boot/dts/omap3-devkit8000.dts
>> @@ -44,11 +44,22 @@
>>  };
>>
>> };
>> +
>> +   sound {
>> +   compatible = "ti,omap-twl4030";
>> +   ti,model = "devkit8000";
>> +
>> +   ti,mcbsp = <&mcbsp2>;
>> +   ti,codec = <&twl_audio>;
>
> Here you should have something like:
> ti,audio-routing =
> "Ext Spk", "PREDRIVEL",
> "Ext Spk", "PREDRIVER",
> "MAINMIC", "Main Mic",
> "Main Mic", "Mic Bias 1";
>
> So you connect the MicBias1 to Main Mic. When you start playback MicBias1 will
> be turned on for you.

I tried with this routing (next-20130211 tag kernel). But it is not
working for me.
So i have gone through other board and found snd_soc_dapm_route for

1) zoom2.c
   {"MAINMIC", NULL, "Mic Bias 1"},
   {"Mic Bias 1", NULL, "Ext Mic"},

2) omap3pandora.c
{"MAINMIC", NULL, "Mic Bias 1"},
{"Mic Bias 1", NULL, "Mic (internal)"},

But for omap-twl4030.c it is
{"MAINMIC", NULL, "Main Mic"},
{"Main Mic", NULL, "Mic Bias 1"},

 It Should will be as ?
{"MAINMIC", NULL, "Mic Bias 1"},
{"Mic Bias 1", NULL, "Main Mic"},

Because with this i am able to get audio on Devkit8000 as
 ti,audio-routing =
"Ext Spk", "PREDRIVEL",
"Ext Spk", "PREDRIVER",
"MAINMIC", "Mic Bias 1",
"Mic Bias 1", "Main Mic";

Sorry if i am saying nonsense.

Thanks,
Anil
[...]
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v8 2/4] misc: Generic on-chip SRAM allocation driver

[Philipp Zabel]

Hi Grant,

Am Freitag, den 08.02.2013, 20:16 + schrieb Grant Likely:
> On Mon,  4 Feb 2013 12:32:16 +0100, Philipp Zabel  
> wrote:
> > This driver requests and remaps a memory region as configured in the
> > device tree. It serves memory from this region via the genalloc API.
> > It optionally enables the SRAM clock.
> > 
> > Other drivers can retrieve the genalloc pool from a phandle pointing
> > to this drivers' device node in the device tree.
> > 
> > The allocation granularity is hard-coded to 32 bytes for now,
> > to make the SRAM driver useful for the 6502 remoteproc driver.
> > There is overhead for bigger SRAMs, where only a much coarser
> > allocation granularity is needed: At 32 bytes minimum allocation
> > size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations.
> > 
> > Signed-off-by: Philipp Zabel 
> > Reviewed-by: Shawn Guo 
> > ---
> > Changes since v7:
> >  - Removed obsolete __devinit/__devexit/__devexit_p
> > ---
> >  Documentation/devicetree/bindings/misc/sram.txt |   17 
> >  drivers/misc/Kconfig|9 ++
> >  drivers/misc/Makefile   |1 +
> >  drivers/misc/sram.c |  121 
> > +++
> >  4 files changed, 148 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/misc/sram.txt
> >  create mode 100644 drivers/misc/sram.c
> > 
> > diff --git a/Documentation/devicetree/bindings/misc/sram.txt 
> > b/Documentation/devicetree/bindings/misc/sram.txt
> > new file mode 100644
> > index 000..b64136c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/sram.txt
> > @@ -0,0 +1,17 @@
> > +Generic on-chip SRAM
> > +
> > +Simple IO memory regions to be managed by the genalloc API.
> > +
> > +Required properties:
> > +
> > +- compatible : sram
> 
> I'm a little concerned that 'sram' is just too generic for a compatible
> value and we may end up needing a blacklist of systems where the sram
> device should not be driven with this driver. If you can think of
> a more descriptive name here then I would use it.

various SoC vendors call this (variations of) "on-chip" or "internal"
SRAM/memory. "on-chip-sram" or "internal-sram" are still plenty generic,
though. How about "mmio-sram", as opposed to an SRAM that needs more
than the simple mmio region handled by this driver?

An alternative would be to use the vendor specific names and grow a
compatible list in the driver ("fsl,ocram", "ti,ocm", ...).

> However, I'm not worried about it enough to nak it and the rest of the
> series looks fine.
> 
> Acked-by: Grant Likely 

Thank you.

regards
Philipp

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Sound record on Devkit8000 with DT boot issue

[Peter Ujfalusi]

Hi,

On 02/11/2013 06:58 PM, Anil Kumar wrote:
>> Here you should have something like:
>> ti,audio-routing =
>> "Ext Spk", "PREDRIVEL",
>> "Ext Spk", "PREDRIVER",
>> "MAINMIC", "Main Mic",
>> "Main Mic", "Mic Bias 1";
>>
>> So you connect the MicBias1 to Main Mic. When you start playback MicBias1 
>> will
>> be turned on for you.
> 
> I tried with this routing (next-20130211 tag kernel). But it is not
> working for me.
> So i have gone through other board and found snd_soc_dapm_route for
> 
> 1) zoom2.c
>{"MAINMIC", NULL, "Mic Bias 1"},
>{"Mic Bias 1", NULL, "Ext Mic"},
> 
> 2) omap3pandora.c
> {"MAINMIC", NULL, "Mic Bias 1"},
> {"Mic Bias 1", NULL, "Mic (internal)"},
> 
> But for omap-twl4030.c it is
> {"MAINMIC", NULL, "Main Mic"},
> {"Main Mic", NULL, "Mic Bias 1"},
> 
>  It Should will be as ?
> {"MAINMIC", NULL, "Mic Bias 1"},
> {"Mic Bias 1", NULL, "Main Mic"},
> 
> Because with this i am able to get audio on Devkit8000 as
>  ti,audio-routing =
> "Ext Spk", "PREDRIVEL",
> "Ext Spk", "PREDRIVER",
> "MAINMIC", "Mic Bias 1",
> "Mic Bias 1", "Main Mic";

In 3.9 this should not work...

linux-next should not have zoom2 at least and I converted the machine drivers
as well in regards to micbias handling:
e04d6e5 ASoC: twl4030: Convert MICBIAS to SUPPLY widget
57d61b9 ASoC: OMAP: Remove obsolete machine drivers for Zoom2 and SDP3430

-- 
Péter
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 0/3] omap_hsmmc DT DMA Client support

[Chris Ball]

Hi Matt,

On Fri, Feb 01 2013, Matt Porter wrote:
> This series adds DT DMA Engine Client support to the omap_hsmmc.
> It leverages the generic DMA OF helpers in -next and the
> dma_request_slave_channel_compat() wrapper introduced in the
> AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms
> booting via DT. These platforms include omap2/3/4/5 and am33xx.
>
> These patches were split out from the v5 version of the AM33XX DMA
> series and split from the EDMA-specific omap_hsmmc changes.

Thanks, pushed to mmc-next for 3.9.

- Chris.
-- 
Chris Ball  
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 1/2] ARM: OMAP2+: Allow clock alias provision from device tree

[Sascha Hauer]

On Mon, Feb 11, 2013 at 05:44:23PM +0200, Roger Quadros wrote:
> Currently on OMAP, it is not possible to specify a clock consumer
> to any of the OMAP generated clocks using the device tree. This can pose
> a problem for external devices that run off an OMAP clock as we
> can't reliably provide a reference to the clock in the device tree.

There is an established way of providing clocks in the devicetree using
the clocks/clock-names properties. Wouldn't it be better using this
for OMAP aswell?

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 1/2] ARM: OMAP2+: Allow clock alias provision from device tree

[Felipe Balbi]

Hi,

On Mon, Feb 11, 2013 at 05:44:23PM +0200, Roger Quadros wrote:
> @@ -36,12 +39,76 @@ static struct of_device_id omap_dt_match_table[] 
> __initdata = {
>   { }
>  };
>  
> +static int __init omap_create_clk_alias(struct device_node *np)

if the rest of the folks agree with the aproach, looks like most of this
can be made a bit more generic ;-)


-- 
balbi


signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 2/2] ARM: dts: omap4-panda: Add clock alias for USB PHY

[Roger Quadros]

On Panda, the USB Host PHY is clocked by FREF3_CLK (auxclk3_ck) pin
of the OMAP. Provide this information in the device tree.

CC: Russell King 
CC: Rajendra Nayak 
CC: Santosh Shilimkar 

Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/omap4-panda.dts |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index d6e59c7..a7d66cc 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -86,6 +86,13 @@
reset-supply = <&hsusb1_reset>;
vcc-supply = <&hsusb1_power>;
};
+
+   /* hsusb1_phy is clocked by FREF_CLK3 i.e. auxclk3 */
+   clock_alias {
+   clock-name = "auxclk3_ck";
+   clock-alias = "main_clk";
+   device = <&hsusb1_phy>;
+   };
 };
 
 &omap4_pmx_core {
-- 
1.7.4.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 1/2] ARM: OMAP2+: Allow clock alias provision from device tree

[Roger Quadros]

Currently on OMAP, it is not possible to specify a clock consumer
to any of the OMAP generated clocks using the device tree. This can pose
a problem for external devices that run off an OMAP clock as we
can't reliably provide a reference to the clock in the device tree.

This patch allows device trees to provide a node that contains the
clock identifier, clock alias and the device phandle. The board
initialization code then creates a clock alias to this clock id,
and associates it with the device whose phandle was supplied.

Discussion
http://www.spinics.net/lists/linux-omap/msg86241.html

CC: Russell King 
CC: Rajendra Nayak 
CC: Santosh Shilimkar 

Signed-off-by: Roger Quadros 
---
 .../devicetree/bindings/clock/ti-clock-alias.txt   |   26 
 arch/arm/mach-omap2/board-generic.c|   67 
 2 files changed, 93 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/ti-clock-alias.txt

diff --git a/Documentation/devicetree/bindings/clock/ti-clock-alias.txt 
b/Documentation/devicetree/bindings/clock/ti-clock-alias.txt
new file mode 100644
index 000..87ef4c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti-clock-alias.txt
@@ -0,0 +1,26 @@
+* Clock alias provision for TI OMAP2+ boards
+
+This binding allows the board's device tree file to specify a clock name,
+device phandle and clock alias so that that clock can be associated
+to the device with the alias.
+
+This is required in cases where an external device is clocked by an
+OMAP generated clock and needs to be assocated to it.
+
+NOTE: The node's name should be clock_alias
+
+Required properties
+- clock-name: The clock identifier string. Should be one of the
+  clock ids defined in OMAP common clock data.
+- clock-alias: A string specifying the alias that must be created to the clock.
+- device: A phandle to the device this clock should be associated to.
+
+e.g. On the OMAP4 Panda board, the USB PHY device is clocked by the
+FREF_CLK3 (auxclk3_ck) from the OMAP. The PHY driver expexts the clock to
+be named "main_clk". This binding can be provided like so
+
+clock_alias {
+   clock-name = "auxclk3_ck";
+   clock-alias = "main_clk";
+   device = <&hsusb1_phy>;
+};
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 53cb380b..a4b8813 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -36,12 +39,76 @@ static struct of_device_id omap_dt_match_table[] __initdata 
= {
{ }
 };
 
+static int __init omap_create_clk_alias(struct device_node *np)
+{
+   int ret = 0;
+   const char *s, *alias;
+   char *clk_id;
+   struct device_node *dev_np;
+   struct platform_device *pdev;
+
+   of_property_read_string(np, "clock-name", &s);
+   if (!s) {
+   pr_err("%s: couldn't find clock-name property in node %s\n",
+   __func__, np->name);
+   return -ENODEV;
+   }
+
+   clk_id = kstrdup(s, GFP_KERNEL);
+   if (!clk_id)
+   return -ENOMEM;
+
+   dev_np = of_parse_phandle(np, "device", 0);
+   if (!dev_np) {
+   pr_err("%s: couldn't find device phandle for \'%s\'\n",
+   __func__, clk_id);
+   ret = -ENODEV;
+   goto exit;
+   }
+
+   pdev = of_find_device_by_node(dev_np);
+   if (!pdev) {
+   pr_err("%s: couldn't find device for clock \'%s\'\n",
+   __func__, clk_id);
+   ret = -ENODEV;
+   goto exit;
+   }
+
+   ret = of_property_read_string(np, "clock-alias", &alias);
+   if (ret) {
+   pr_err("%s: couldn't find alias for clock \'%s\'\n",
+   __func__, clk_id);
+   ret = -ENODEV;
+   goto exit;
+   }
+
+   ret = clk_add_alias(alias, dev_name(&pdev->dev), clk_id, NULL);
+   if (ret) {
+   pr_err("%s: couldn't add alias \'%s\' to clock \'%s\'\n",
+   __func__, alias, clk_id);
+   ret = -ENODEV;
+   goto exit;
+   }
+
+exit:
+   kfree(clk_id);
+   return ret;
+}
+
 static void __init omap_generic_init(void)
 {
+   struct device_node *np;
+
omap_sdrc_init(NULL, NULL);
 
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
 
+   /* create clock aliases based on 'clock_alias' nodes */
+   for_each_node_by_name(np, "clock_alias") {
+   omap_create_clk_alias(np);
+   of_node_put(np);
+   }
+
/*
 * HACK: call display setup code for selected boards to enable omapdss.
 * This will be removed when omapdss supports DT.
-- 
1.7.4.1

___
devicetree-dis

Re: [PATCH RFC 2/7] net: smsc911x: add pinctrl support

[Javier Martinez Canillas]

On Mon, Feb 11, 2013 at 3:23 PM, Linus Walleij  wrote:
> On Sat, Feb 9, 2013 at 9:44 PM, Javier Martinez Canillas
>  wrote:
>
>> If no pinctrl is available just report a warning since
>> it may not needed in some cases (e.g: non-DT kernels).
>>
>> Signed-off-by: Javier Martinez Canillas 
> (...)
>> +   struct pinctrl *pinctrl;
> (...)
>> +   pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
>> +   if (IS_ERR(pinctrl)) {
>> +   retval = PTR_ERR(pinctrl);
>> +   if (retval == -EPROBE_DEFER)
>> +   goto out_0;
>> +
>> +   dev_warn(&pdev->dev, "No pinctrl provided\n");
>> +   }
>
> NACK.
>
> This will be handled from the device core after the v3.9 merge
> window.
>
> See:
> http://marc.info/?l=linux-kernel&m=135887740715083&w=2
>

Great, I also wondered why it couldn't be part of the device core
since we basically duplicate this in all the DT aware drivers and
pinctrl was not used anywhere after setting to its default state.

This is a nice improvement.

> Yours,
> Linus Walleij
> --

Thanks a lot and best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH RFC 2/7] net: smsc911x: add pinctrl support

[Linus Walleij]

On Sat, Feb 9, 2013 at 9:44 PM, Javier Martinez Canillas
 wrote:

> If no pinctrl is available just report a warning since
> it may not needed in some cases (e.g: non-DT kernels).
>
> Signed-off-by: Javier Martinez Canillas 
(...)
> +   struct pinctrl *pinctrl;
(...)
> +   pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> +   if (IS_ERR(pinctrl)) {
> +   retval = PTR_ERR(pinctrl);
> +   if (retval == -EPROBE_DEFER)
> +   goto out_0;
> +
> +   dev_warn(&pdev->dev, "No pinctrl provided\n");
> +   }

NACK.

This will be handled from the device core after the v3.9 merge
window.

See:
http://marc.info/?l=linux-kernel&m=135887740715083&w=2

Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Sound record on Devkit8000 with DT boot issue

[Peter Ujfalusi]

On 02/10/2013 04:21 PM, Anil Kumar wrote:
> Hi All,
> 
> I am working on Devkit8000 and adding DT support for that. I am trying
> to add sound DT node support for this boards.
> I have nearly done with this but facing issue on record. I do not have
> much knowledge of twl4030 audio codec but with
> small Hack[1] (as MainMic connected to the input jack)  i am able to
> record sound on Devkit8000.
> I do not know that MICBIAS1_EN can be enable by amixer commands.
> Could you please help me to get out of this ?

You need to pass the routing information via DT for Devkit8000. This is not
done for the BeagleBoard since it works without it (no need for MICBIAS for
example)

> 
> 
> 1) Hack [1]
> 
> diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
> index 63b280b..6780681 100644
> --- a/sound/soc/codecs/twl4030.c
> +++ b/sound/soc/codecs/twl4030.c
> @@ -1473,7 +1473,7 @@ static const struct snd_soc_dapm_widget
> twl4030_dapm_widgets[] = {
> SND_SOC_DAPM_SUPPLY("micbias2 select", TWL4030_REG_MICBIAS_CTL, 6, 0,
> NULL, 0),
> 
> -   SND_SOC_DAPM_MICBIAS("Mic Bias 1", TWL4030_REG_MICBIAS_CTL, 0, 0),
> +   SND_SOC_DAPM_MICBIAS("Mic Bias 1", TWL4030_REG_MICBIAS_CTL, 0, 1),

Yes, this is HACK and it is wrong at the same time.

> SND_SOC_DAPM_MICBIAS("Mic Bias 2", TWL4030_REG_MICBIAS_CTL, 1, 0),
> SND_SOC_DAPM_MICBIAS("Headset Mic Bias", TWL4030_REG_MICBIAS_CTL, 2, 
> 0),
> 
> 
> 2) Sound DT node patch for Devkit8000
> 
> diff --git a/arch/arm/boot/dts/omap3-
> devkit8000.dts b/arch/arm/boot/dts/omap3-devkit8000.dts
> index dc59272..5f3eec0 100644
> --- a/arch/arm/boot/dts/omap3-devkit8000.dts
> +++ b/arch/arm/boot/dts/omap3-devkit8000.dts
> @@ -44,11 +44,22 @@
>  };
> 
> };
> +
> +   sound {
> +   compatible = "ti,omap-twl4030";
> +   ti,model = "devkit8000";
> +
> +   ti,mcbsp = <&mcbsp2>;
> +   ti,codec = <&twl_audio>;

Here you should have something like:
ti,audio-routing =
"Ext Spk", "PREDRIVEL",
"Ext Spk", "PREDRIVER",
"MAINMIC", "Main Mic",
"Main Mic", "Mic Bias 1";

So you connect the MicBias1 to Main Mic. When you start playback MicBias1 will
be turned on for you.

> +   };
>  };
> 
>  &omap3_pmx_core {
> pinctrl-names = "default";
> -   pinctrl-0 = <&i2c1_pins>;
> +   pinctrl-0 = <
> +   &i2c1_pins
> +   &mcbsp2_pins
> +   >;
> 
> leds_pins: pinmux_led_pins {
> pinctrl-single,pins = <
> @@ -65,6 +76,21 @@
> 0x18c 0x118 /* I2C1_SDA */
>  >;
> };
> +
> +   mcbsp2_pins: pinmux_mcbsp2_pins {
> +pinctrl-single,pins = <
> +   /*
> +* MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT,
> +* MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT
> +*/
> +   0x10c 0x01000100
> +   /*
> +* MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT,
> +* MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT
> +*/
> +   0x110 0x0100
> +   >;
> +   };
>  };
> 
>  &i2c1 {
> @@ -74,6 +100,14 @@
> reg = <0x48>;
> interrupts = <7>;   /* SYS_NIRQ cascaded to intc */
> interrupt-parent = <&intc>;
> +
> +   twl_audio: audio {
> +   compatible = "ti,twl4030-audio";
> +   codec {
> +   ti,ramp_delay_value = <3>;
> +   ti,offset_cncl_path = <0x31>;
> +   };
> +   };
> };
>  };
> 
> 3) Playback amixer commands
>amixer set 'PredriveR Mixer AudioR2' on
>amixer set 'PredriveL Mixer AudioL2' on
>amixer set PreDriv 100 unmute
>amixer set 'DAC2 Digital Fine' 100
> 
> Thanks,
> Anil
> 


-- 
Péter
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v2] gpio: mcp23s08: convert driver to DT

[Lars Poeschel]

From: Lars Poeschel 

This converts the mcp23s08 driver to be able to be used with device
tree.
Explicitly allow -1 as a legal value for the
mcp23s08_platform_data->base. This is the special value lets the
kernel choose a valid global gpio base number.
There is a "mcp,chips" device tree property, that correspond to the
chips member of the struct mcp23s08_platform_data. It can be used for
multiple mcp23s08/mc23s17 on the same spi chipselect.

Signed-off-by: Lars Poeschel 
---
v2:
- squashed booth patches together
- fixed build warning, when CONFIG_OF is not defined
- use of_match_ptr macro for of_match_table

 .../devicetree/bindings/gpio/gpio-mcp23s08.txt |   36 
 drivers/gpio/gpio-mcp23s08.c   |   95 ++--
 include/linux/spi/mcp23s08.h   |1 +
 3 files changed, 126 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt 
b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
new file mode 100644
index 000..17eb669
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
@@ -0,0 +1,36 @@
+Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for
+8-/16-bit I/O expander with serial interface (I2C/SPI)
+
+Required properties:
+- compatible : Should be
+- "mcp,mcp23s08" for  8 GPIO SPI version
+- "mcp,mcp23s17" for 16 GPIO SPI version
+- "mcp,mcp23008" for  8 GPIO I2C version or
+- "mcp,mcp23017" for 16 GPIO I2C version of the chip
+- #gpio-cells : Should be two.
+  - first cell is the pin number
+  - second cell is used to specify optional parameters (currently unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+- reg : For an address on its bus
+
+Optional device specific properties:
+- mcp,chips : This is a table with 2 columns and up to 8 entries. The first 
column
+   is a is_present flag, that makes only sense for SPI chips. Multiple
+   chips can share the same chipselect. This flag can be 0 or 1 depending
+   if there is a chip at this address or not.
+   The second column is written to the GPPU register, selecting a 100k
+   pullup resistor or not. Setting a 1 is activating the pullup.
+   For I2C chips only the first line in this table is used. Further chips
+   are registered at different addresses at the I2C bus.
+
+Example:
+gpiom1: gpio@20 {
+compatible = "mcp,mcp23017";
+gpio-controller;
+#gpio-cells = <2>;
+reg = <0x20>;
+   chips = <
+   /* is_present  pullups */
+   1   0x07/* chip address 0 */
+   >;
+};
diff --git a/drivers/gpio/gpio-mcp23s08.c b/drivers/gpio/gpio-mcp23s08.c
index 3cea0ea..ad08a5a 100644
--- a/drivers/gpio/gpio-mcp23s08.c
+++ b/drivers/gpio/gpio-mcp23s08.c
@@ -12,6 +12,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /**
  * MCP types supported by driver
@@ -473,17 +475,88 @@ fail:
 
 /*--*/
 
+#ifdef CONFIG_OF
+static struct of_device_id mcp23s08_of_match[] = {
+#ifdef CONFIG_SPI_MASTER
+   {
+   .compatible = "mcp,mcp23s08",
+   },
+   {
+   .compatible = "mcp,mcp23s17",
+   },
+#endif
+#if IS_ENABLED(CONFIG_I2C)
+   {
+   .compatible = "mcp,mcp23008",
+   },
+   {
+   .compatible = "mcp,mcp23017",
+   },
+#endif
+   { },
+};
+MODULE_DEVICE_TABLE(of, mcp23s08_of_match);
+
+static struct mcp23s08_platform_data *
+   of_get_mcp23s08_pdata(struct device *dev)
+{
+   struct mcp23s08_platform_data *pdata;
+   struct device_node *np = dev->of_node;
+   u32 chips[sizeof(pdata->chip)];
+   int ret, i, j;
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   pdata->base = -1;
+
+   for (i = ARRAY_SIZE(pdata->chip) * MCP23S08_CHIP_INFO_MEMBERS;
+   i > 0; i -= MCP23S08_CHIP_INFO_MEMBERS) {
+   ret = of_property_read_u32_array(np, "mcp,chips", chips, i);
+   if (ret == -EOVERFLOW)
+   continue;
+   break;
+   }
+   if (!ret) {
+   for (j = 0; j < i / MCP23S08_CHIP_INFO_MEMBERS ; j++) {
+   pdata->chip[j].is_present =
+   chips[j * MCP23S08_CHIP_INFO_MEMBERS];
+   pdata->chip[j].pullups =
+   chips[j * MCP23S08_CHIP_INFO_MEMBERS + 1];
+   }
+   }
+
+   return pdata;
+}
+#else
+static struct mcp23s08_platform_data *
+   of_get_mcp23s08_pdata(struct device *dev)
+{
+   return NULL;
+}
+#endif /* CONFIG_OF */
+
+
 #if IS_ENABLED(CONFIG_I2C)
 
 static int mcp230xx_probe(struct i2c_client *client,
const struct i2c_de

Re: [PATCH] cpuidle: kirkwood: Move out of mach directory, add DT.

[Grant Likely]

On Sun, 10 Feb 2013 19:58:12 +0100, Andrew Lunn  wrote:
> > > +* QNAP Power Off
> > > +
> > > +QNAP NAS devices have a microcontroller controlling the main power
> > > +supply. This microcontroller is connected to UART1 of the Kirkwood and
> > > +Orion5x SoCs. Sending the charactor 'A', at 19200 baud, tells the
> > > +microcontroller to turn the power off. This driver adds a handler to
> > > +pm_power_off which is called to turn the power off.
> > > +
> > > +Required Properties:
> > > +- compatibile: Should be "qnap,power-off"
> > 
> > It would do well to have the model number embedded into this compatible
> > string since it is unlikely that every single QNAP device will use the
> > same controller interface.
> 
> Hi Grant
> 
> All QNAP devices known to mainline use this same controller interface.
> 
> So that would be ts109, ts209, ts409, ts119, ts219, ts419, plus a few
> other models which we don't differentiate, like ts219P and ts219P+.
> 
> Any suggestions what to use in the compatible string?

for the ts109: compatible = "qnap,ts109-poweroff";
for the others: compatible = "qnap,ts[model]-poweroff", "qnap,ts109-poweroff";

That is the usual way things are done. The newer model claims
compatibility with the older. Some have also tried to use a 'generic'
value for claiming compatibility (ie. "qnap,tsxxx-poweroff") but I don't
recommend that because generic values aren't 'anchored' to any real
piece of hardware.

Instead 'qnap,ts109-poweroff' is used as the 'generic' version with the
advantage that when new hardware appears that doesn't conform you simply
drop the string for the older version.

It is also recommended to also include the specific model number simply
as a mechanism to test for quirks if ever needed... not critical though
for system level devices since the top level system model property can
also be used for that.

g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss