date:20130401

On Thu, Mar 21, 2013 at 4:39 AM, Vinod Koul vinod.k...@intel.com wrote:
 On Tue, Mar 05, 2013 at 02:55:31PM +0530, Padmavathi Venna wrote:
 This patch register the dma controller with generic dma helpers only
 in DT case. This also adds some extra error handling in the driver.

 Signed-off-by: Padmavathi Venna padm...@samsung.com
 Reported-by: Sachin Kamat sachin.ka...@linaro.org

What's the status on this? It is needed for 3.9 to fix pl330 on highbank.

Rob

 ---

 Based on Vinod Koul next branch.

 Changes since V1:
   - return silently when of_dma_controller_register fails, as
 suggested by Arnd.

  drivers/dma/pl330.c |   38 +++---
  1 files changed, 27 insertions(+), 11 deletions(-)

 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index 7181531..5dbc594 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -2882,7 +2882,7 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)
  {
   struct dma_pl330_platdata *pdat;
   struct dma_pl330_dmac *pdmac;
 - struct dma_pl330_chan *pch;
 + struct dma_pl330_chan *pch, *_p;
   struct pl330_info *pi;
   struct dma_device *pd;
   struct resource *res;
 @@ -2984,7 +2984,16 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)
   ret = dma_async_device_register(pd);
   if (ret) {
   dev_err(adev-dev, unable to register DMAC\n);
 - goto probe_err2;
 + goto probe_err3;
 + }
 +
 + if (adev-dev.of_node) {
 + ret = of_dma_controller_register(adev-dev.of_node,
 +  of_dma_pl330_xlate, pdmac);
 + if (ret) {
 + dev_err(adev-dev,
 + unable to register DMA to the generic DT DMA 
 helpers\n);
 Indent?
 + }
   }

   dev_info(adev-dev,
 @@ -2995,16 +3004,21 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)
   pi-pcfg.data_bus_width / 8, pi-pcfg.num_chan,
   pi-pcfg.num_peri, pi-pcfg.num_events);

 - ret = of_dma_controller_register(adev-dev.of_node,
 -  of_dma_pl330_xlate, pdmac);
 - if (ret) {
 - dev_err(adev-dev,
 - unable to register DMA to the generic DT DMA helpers\n);
 - goto probe_err2;
 - }
 -
   return 0;
 +probe_err3:
 + amba_set_drvdata(adev, NULL);

 + /* Idle the DMAC */
 + list_for_each_entry_safe(pch, _p, pdmac-ddma.channels,
 + chan.device_node) {
 +
 + /* Remove the channel */
 + list_del(pch-chan.device_node);
 +
 + /* Flush the channel */
 + pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
 + pl330_free_chan_resources(pch-chan);
 free_chan for error handling in probe?

 + }
  probe_err2:
   pl330_del(pi);
  probe_err1:
 @@ -3023,8 +3037,10 @@ static int pl330_remove(struct amba_device *adev)
   if (!pdmac)
   return 0;

 - of_dma_controller_free(adev-dev.of_node);
 + if (adev-dev.of_node)
 + of_dma_controller_free(adev-dev.of_node);

 + dma_async_device_unregister(pdmac-ddma);
   amba_set_drvdata(adev, NULL);

   /* Idle the DMAC */
 --
 1.7.4.4

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

Re: [PATCH -next] spi: remove unused variable in tegra_slink_read_rx_fifo_to_client_rxbuf()

2013-04-01 Thread Mark Brown

On Wed, Mar 13, 2013 at 09:29:12PM +0800, Wei Yongjun wrote:
 From: Wei Yongjun yongjun_...@trendmicro.com.cn
 
 The variable bits_per_word is initialized but never used
 otherwise, so remove the unused variable.

Applied, thanks.


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

Re: drm/tilcdc: LCD panels clocks initialization and earlier backlight initialization

2013-04-01 Thread Rob Clark

On Mon, Apr 1, 2013 at 7:31 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:

 -Original Message-
 From: devicetree-discuss [mailto:devicetree-discuss-
 bounces+hvaibhav=ti@lists.ozlabs.org] On Behalf Of Michal Bachraty
 Sent: Thursday, March 28, 2013 11:02 PM
 To: dri-de...@lists.freedesktop.org; devicetree-
 disc...@lists.ozlabs.org
 Cc: robdcl...@gmail.com; k...@dominion.thruhere.net
 Subject: drm/tilcdc: LCD panels clocks initialization and earlier
 backlight initialization

 Hi,

 I'm trying to use tilcdc driver for KWH050TG08 LCD panel connected to
 AM335x
 processor (3.9 rc1 kernel). I have prepared DT bindings for that
 (listed
 bellow). I see fb0 device but I have no clocks going from cpu to LCD.
 My
 clocks for LCD seems not properly to be set ...

 virt_2500_ck   1   12500
 sys_clkin_ck8   19   2500
dpll_disp_ck 0   12500
   dpll_disp_m2_ck   0   12500
  lcd_gclk   0   12500

 and tilcdc_crtc is not called. I also set lcd_gclk to 300MHz, but I got
 same
 result. The question is there any way how to properly set clocks for
 LCD?

 Not sure  about the LCDC DRM driver, but I just tested clk_set_rate()
 For lcdc_gclk clock and it is working for me. I could able to set
 300MHz freq on my BeagleBone platform, with below code -

fwiw, tilcdc drm driver won't set clocks until you do modeset, as it
is setting them based on the requested pixel clock.  As opposed to
setting it once at boot time.

Michal, you may want to add 'drm.debug=7' in your bootargs, and send
the bootlog.  That should set some light about whether it is even
trying to modeset but failing, or some other issue.

BR,
-R

 diff --git a/arch/arm/mach-omap2/board-generic.c 
 b/arch/arm/mach-omap2/board-generic.c
 index e54a480..443fb26 100644
 --- a/arch/arm/mach-omap2/board-generic.c
 +++ b/arch/arm/mach-omap2/board-generic.c
 @@ -11,6 +11,7 @@
   * it under the terms of the GNU General Public License version 2 as
   * published by the Free Software Foundation.
   */
 +#include linux/clk-private.h
  #include linux/io.h
  #include linux/of_irq.h
  #include linux/of_platform.h
 @@ -37,6 +38,8 @@ static struct of_device_id omap_dt_match_table[] __initdata 
 = {

  static void __init omap_generic_init(void)
  {
 +   struct clk *clk;
 +
 omap_sdrc_init(NULL, NULL);

 of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
 @@ -49,6 +52,15 @@ static void __init omap_generic_init(void)
 omap4_panda_display_init_of();
 else if (of_machine_is_compatible(ti,omap4-sdp))
 omap_4430sdp_display_init_of();
 +
 +   clk = clk_get(NULL, lcd_gclk);
 +   if (IS_ERR(clk))
 +   printk(Can not get lcd_gclk clock\n);
 +
 +   printk(%s:%d gclk_rate - %lu\n, __func__, __LINE__, 
 clk_get_rate(clk));
 +   clk_set_rate(clk, 3);
 +   printk(%s:%d clk_rate - %lu\n, __func__, __LINE__, 
 clk_get_rate(clk));
 +   clk_put(clk);
  }

  #ifdef CONFIG_SOC_OMAP2420

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

[PATCH v10 0/3] Add DRM FIMD DT support for Exynos4 DT Machines

This patch series adds support for DRM FIMD DT for Exynos4 DT Machines,
specifically for Exynos4412 SoC.

changes since v9:
- dropped the patch ARM: dts: Add lcd pinctrl node entries for 
EXYNOS4412 SoC
as the gpios in the newly added nodes lcd_en and lcd_sync in this 
patch 
were already PULLed high by existing lcd_clk node.
- addressed comments from Sylwester Nawrocki 
sylvester.nawro...@gmail.com
and Thomas Abraham thomas.abra...@linaro.org

changes since v8:
- addressed comments to add missing documentation for clock and 
clock-names
properties as pointed out by Sachin Kamat sachin.ka...@linaro.org

changes since v7:
- rebased to kgene's for-next
- Migrated to Common Clock Framework
- removed the patch ARM: dts: Add FIMD AUXDATA node entry for exynos4 
DT,
as migration to Common Clock Framework will NOT need this.
- addressed the comments raised by Sachin Kamat 
sachin.ka...@linaro.org

changes since v6:
- addressed comments and added interrupt-names = fifo, vsync, 
lcd_sys
in exynos4.dtsi and re-ordered the interrupt numbering to match the 
order in
interrupt combiner IP as suggested by Sylwester Nawrocki 
sylvester.nawro...@gmail.com.

changes since v5:
- renamed the fimd binding documentation file name as 
samsung-fimd.txt,
since it not only talks about exynos display controller but also about
previous samsung display controllers.
- rephrased an abmigious statement about the interrupt combiner in the
fimd binding documentation as pointed out by 
Sachin Kamat sachin.ka...@linaro.org

changes since v4:
- moved the fimd binding documentation to 
Documentation/devicetree/bindings/video/
as suggested by Sylwester Nawrocki sylvester.nawro...@gmail.com

- added more fimd compatiblity strings in fimd documentation as
discussed at  https://patchwork.kernel.org/patch/2144861/ with
Sylwester Nawrocki sylvester.nawro...@gmail.com and
Tomasz Figa tomasz.f...@gmail.com

- modified compatible string for exynos4 fimd as exynos4210-fimd
exynos5 fimd as exynos5250-fimd to stick to the rule that compatible
value should be named after first specific SoC model in which this
particular IP version was included as discussed at
https://patchwork.kernel.org/patch/2144861/

- documented more about the interrupt combiner and their order as 
suggested by Sylwester Nawrocki sylvester.nawro...@gmail.com

changes since v3:
- rebased on

http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=shortlog;h=refs/heads/for-next-next

changes since v2:
- added alias to 'fimd@11c0' node
(reported by: Rahul Sharma r.sh.o...@gmail.com)
- removed 'lcd0_data' node as there was already a similar node 
lcd_data24
(reported by: Jingoo Han jg1@samsung.com
- replaced spaces with tabs in display-timing node

changes since v1:
- added new patch to add FIMD DT binding Documentation
- removed patch enabling SAMSUNG_DEV_BACKLIGHT and SAMSUNG_DEV_PMW 
for mach-exynos4 DT
- added 'status' property to fimd DT node

Is based on branch kgene's for-next
https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next

Vikas Sajjan (3):
  ARM: dts: Add FIMD node to exynos4
  ARM: dts: Add FIMD node and display timing node to
exynos4412-origen.dts
  ARM: dts: Add FIMD DT binding Documentation

 .../devicetree/bindings/video/samsung-fimd.txt |   65 
 arch/arm/boot/dts/exynos4.dtsi |   12 
 arch/arm/boot/dts/exynos4412-origen.dts|   21 +++
 3 files changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/samsung-fimd.txt

-- 
1.7.9.5

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

[PATCH v10 1/3] ARM: dts: Add FIMD node to exynos4

This patch adds a common FIMD device node for all Exynos4 SoCs.

Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
 arch/arm/boot/dts/exynos4.dtsi |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 9ac47d5..59e6730 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -356,4 +356,16 @@
#dma-requests = 1;
};
};
+
+   fimd: fimd@11c0 {
+   compatible = samsung,exynos4210-fimd;
+   interrupt-parent = combiner;
+   reg = 0x11c0 0x2;
+   interrupt-names = fifo, vsync, lcd_sys;
+   interrupts = 11 0, 11 1, 11 2;
+   clocks = clock 140, clock 283;
+   clock-names = sclk_fimd, fimd;
+   samsung,power-domain = pd_lcd0;
+   status = disabled;
+   };
 };
-- 
1.7.9.5

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

[PATCH v10 2/3] ARM: dts: Add FIMD node and display timing node to exynos4412-origen.dts

This patch adds FIMD related nodes for the Origen Quad board.

Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
 arch/arm/boot/dts/exynos4412-origen.dts |   21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-origen.dts 
b/arch/arm/boot/dts/exynos4412-origen.dts
index a5478bd..cb0c507 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -70,6 +70,27 @@
status = okay;
};
 
+   fimd@11c0 {
+   pinctrl-0 = lcd_clk lcd_data24 pwm1_out;
+   pinctrl-names = default;
+   status = okay;
+   };
+
+   display-timings {
+   native-mode = timing0;
+   timing0: timing@0 {
+   clock-frequency = 5;
+   hactive = 1024;
+   vactive = 600;
+   hfront-porch = 64;
+   hback-porch = 16;
+   hsync-len = 48;
+   vback-porch = 64;
+   vfront-porch = 16;
+   vsync-len = 3;
+   };
+   };
+
serial@1380 {
status = okay;
};
-- 
1.7.9.5

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

[PATCH v10 3/3] ARM: dts: Add FIMD DT binding Documentation

Add DT binding documentation for the FIMD IP block found in Samsung SoCs.

Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
 .../devicetree/bindings/video/samsung-fimd.txt |   65 
 1 file changed, 65 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/samsung-fimd.txt

diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt 
b/Documentation/devicetree/bindings/video/samsung-fimd.txt
new file mode 100644
index 000..1984dbb
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -0,0 +1,65 @@
+Device-Tree bindings for Samsung SoC display controller (FIMD)
+
+FIMD (Fully Interactive Mobile Display) is the Display Controller for the
+Samsung series of SoCs which transfers the image data from a video memory 
buffer
+to an external LCD interface.
+
+Required properties:
+- compatible: value should be one of the following
+   samsung,s3c2443-fimd; /* for S3C24XX SoCs */
+   samsung,s3c6400-fimd; /* for S3C64XX SoCs */
+   samsung,s5p6440-fimd; /* for S5P64X0 SoCs */
+   samsung,s5pc100-fimd; /* for S5PC100 SoC  */
+   samsung,s5pv210-fimd; /* for S5PV210 SoC */
+   samsung,exynos4210-fimd; /* for Exynos4 SoCs */
+   samsung,exynos5250-fimd; /* for Exynos5 SoCs */
+
+- reg: physical base address of the FIMD and length of memory mapped region
+
+- interrupt-parent: should be the phandle of the fimd controller's
+   parent interrupt controller.
+
+- interrupts: should contain a list of all FIMD IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+   lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names properties.
+
+- clock-names: List of clock names sorted in the same order as the clocks
+   property. Must contain sclk_fimd and fimd.
+
+Optional Properties:
+- samsung,power-domain: a phandle to FIMD power domain node
+
+Example:
+
+SoC specific DT entry:
+
+   fimd@11c0 {
+   compatible = samsung,exynos4210-fimd;
+   interrupt-parent = combiner;
+   reg = 0x11c0 0x2;
+   interrupt-names = fifo, vsync, lcd_sys;
+   interrupts = 11 0, 11 1, 11 2;
+   clocks = clock 140, clock 283;
+   clock-names = sclk_fimd, fimd;
+   samsung,power-domain = pd_lcd0;
+   status = disabled;
+   };
+
+Board specific DT entry:
+
+   fimd@11c0 {
+   pinctrl-0 = lcd_clk lcd_data24 pwm1_out;
+   pinctrl-names = default;
+   status = okay;
+   };
-- 
1.7.9.5

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

Re: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two

2013-04-01 Thread Christoph Fritz

Hi Javier

On Sat, 2013-03-30 at 14:18 +0100, Javier Martinez Canillas wrote:
 A call to gpio_request() to enable the GPIO bank is needed before
 using a GPIO as an IRQ source, otherwise accesses to the GPIO bank
 registers fails making the kernel to hang.

Yes, that is exactly my problem here. I'm using the GPIO as an IRQ
source.

 Jon's (added as cc)gpio/omap: warn if bank is not enabled on setting
 irq type patch [1] fixes the issue by warning and returning -EINVAL.
 
 This patch will make the kernel to boot but the call to request_irq()
 will fail of course. For now, the only solution is to call
 gpio_request() before request_irq() in your platform code or device
 driver. There is an on going discussion about what's the better way to
 address this but we still haven't found a good solution to this
 problem, you can see the last email for this discussion here [2]
 
 Also, even when calling gpio_request() before request_irq() this won't
 work. When specifying the trigger/level flags on the second cell for
 an GPIO-IRQ, this is not set on the IORESOURCE_IRQ struct resource.
 The IRQ flag is set on of_irq_to_resource() but it just does:
 
 r-flags = IORESOURCE_IRQ;
 
 and then the call stack is irq_to_parse_and_map() -
 irq_set_irq_type() -  __irq_set_trigger() - chip-irq_set_type() -
 (drivers/gpio/gpio-omap.c) gpio_irq_type().
 
 So, even when gpio_irq_type() receive the correct flags, this are not
 returned neither stored on the flags member of the IORESOURCE_IRQ
 struct resource that passed to the drivers in their struct
 platform_device.

As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
to enable GPIO banks. I now geht this:

  [0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040: 0x00ff
  [0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010: 0x0007
  [0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000: 0x0007

And it works for me. _But_ when I do enable regulator twl4030
(CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:

[2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x00ff
[2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
[2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x

And the IRQ source for the network chip (smsc911x) is disabled :-(

Do you have any idea how to (quick) fix this?

 Thanks
  -- Christoph

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

Re: [PATCH V3 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

2013-04-01 Thread Jon Hunter

Vinod,

On 03/20/2013 11:36 AM, Tony Lindgren wrote:
 * Jon Hunter jon-hun...@ti.com [130319 09:08]:
 Vinod, Tony, Benoit,

 On 02/26/2013 12:27 PM, Jon Hunter wrote:
 If the device-tree blob is present during boot, then register the SDMA
 controller with the device-tree DMA driver so that we can use device-tree
 to look-up DMA client information.

 Signed-off-by: Jon Hunter jon-hun...@ti.com
 Reviewed-by: Felipe Balbi ba...@ti.com
 Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
 Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/dma.c |4 
  drivers/dma/omap-dma.c|   38 --
  2 files changed, 40 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
 index dab9fc0..49fd0d5 100644
 --- a/arch/arm/mach-omap2/dma.c
 +++ b/arch/arm/mach-omap2/dma.c
 @@ -28,6 +28,7 @@
  #include linux/init.h
  #include linux/device.h
  #include linux/dma-mapping.h
 +#include linux/of.h
  #include linux/omap-dma.h
  
  #include soc.h
 @@ -304,6 +305,9 @@ static int __init omap2_system_dma_init(void)
 if (res)
 return res;
  
 +   if (of_have_populated_dt())
 +   return res;
 +
 pdev = platform_device_register_full(omap_dma_dev_info);
 if (IS_ERR(pdev))
 return PTR_ERR(pdev);
 
 AFAIK we don't currently have anything else touching this file..
 
 diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
 index c4b4fd2..2ea3d7e 100644
 --- a/drivers/dma/omap-dma.c
 +++ b/drivers/dma/omap-dma.c
 @@ -16,6 +16,8 @@
  #include linux/platform_device.h
  #include linux/slab.h
  #include linux/spinlock.h
 +#include linux/of_dma.h
 +#include linux/of_device.h
  
  #include virt-dma.h
  
 @@ -67,6 +69,10 @@ static const unsigned es_bytes[] = {
 [OMAP_DMA_DATA_TYPE_S32] = 4,
  };
  
 +static struct of_dma_filter_info omap_dma_info = {
 +   .filter_fn = omap_dma_filter_fn,
 +};
 +
  static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
  {
 return container_of(d, struct omap_dmadev, ddev);
 @@ -621,8 +627,22 @@ static int omap_dma_probe(struct platform_device *pdev)
 pr_warn(OMAP-DMA: failed to register slave DMA engine device: 
 %d\n,
 rc);
 omap_dma_free(od);
 -   } else {
 -   platform_set_drvdata(pdev, od);
 +   return rc;
 +   }
 +
 +   platform_set_drvdata(pdev, od);
 +
 +   if (pdev-dev.of_node) {
 +   omap_dma_info.dma_cap = od-ddev.cap_mask;
 +
 +   /* Device-tree DMA controller registration */
 +   rc = of_dma_controller_register(pdev-dev.of_node,
 +   of_dma_simple_xlate, omap_dma_info);
 +   if (rc) {
 +   pr_warn(OMAP-DMA: failed to register DMA 
 controller\n);
 +   dma_async_device_unregister(od-ddev);
 +   omap_dma_free(od);
 +   }
 }
  
 dev_info(pdev-dev, OMAP DMA engine driver\n);
 @@ -634,18 +654,32 @@ static int omap_dma_remove(struct platform_device 
 *pdev)
  {
 struct omap_dmadev *od = platform_get_drvdata(pdev);
  
 +   if (pdev-dev.of_node)
 +   of_dma_controller_free(pdev-dev.of_node);
 +
 dma_async_device_unregister(od-ddev);
 omap_dma_free(od);
  
 return 0;
  }
  
 +static const struct of_device_id omap_dma_match[] = {
 +   { .compatible = ti,omap2420-sdma, },
 +   { .compatible = ti,omap2430-sdma, },
 +   { .compatible = ti,omap3430-sdma, },
 +   { .compatible = ti,omap3630-sdma, },
 +   { .compatible = ti,omap4430-sdma, },
 +   {},
 +};
 +MODULE_DEVICE_TABLE(of, omap_dma_match);
 +
  static struct platform_driver omap_dma_driver = {
 .probe  = omap_dma_probe,
 .remove = omap_dma_remove,
 .driver = {
 .name = omap-dma-engine,
 .owner = THIS_MODULE,
 +   .of_match_table = of_match_ptr(omap_dma_match),
 },
  };

 Who's tree does it make most sense for this patch to go through?

 Benoit has queued up patch 1/2 and so I am not sure if this should go
 via Benoit tree to Tony or directly via Vinod's tree. What are your
 thoughts?
 
 OK
  
 It would be great if this could make v3.10.
 
 I suggest Vinod/Grant/Linus W queue this patch:
 
 Acked-by: Tony Lindgren t...@atomide.com

Can you take this patch with Tony's ACK? Let me know if you want me to
resend with the ACK.

Cheers
Jon

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

[PATCH] of_net.h: Provide dummy functions if OF_NET is not configured

2013-04-01 Thread Guenter Roeck

of_get_mac_address() and of_get_phy_mode() are only provided if OF_NET
is configured. While most callers check for the define, not all do, and those
who do require #ifdef around the code. For those who don't, the missing check
can result in errors such as

arch/powerpc/sysdev/tsi108_dev.c:107:3: error: implicit declaration of
function 'of_get_mac_address' [-Werror=implicit-function-declaration]
arch/powerpc/sysdev/mv64x60_dev.c:253:2: error: implicit declaration of
function 'of_get_mac_address' [-Werror=implicit-function-declaration]

Provide dummy function declarations if OF_NET is not configured. This is safe
because all callers do check the return values. If desired, at least some of
the #ifdefs in the code can subsequently be removed.

Cc: David Daney david.da...@cavium.com
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
 include/linux/of_net.h |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/of_net.h b/include/linux/of_net.h
index f474641..61bf53b 100644
--- a/include/linux/of_net.h
+++ b/include/linux/of_net.h
@@ -11,6 +11,16 @@
 #include linux/of.h
 extern const int of_get_phy_mode(struct device_node *np);
 extern const void *of_get_mac_address(struct device_node *np);
+#else
+static inline const int of_get_phy_mode(struct device_node *np)
+{
+   return -ENODEV;
+}
+
+static inline const void *of_get_mac_address(struct device_node *np)
+{
+   return NULL;
+}
 #endif
 
 #endif /* __LINUX_OF_NET_H */
-- 
1.7.9.7

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

Re: [PATCH v10 2/3] ARM: dts: Add FIMD node and display timing node to exynos4412-origen.dts

2013-04-01 Thread Sylwester Nawrocki


On 04/01/2013 04:22 PM, Vikas Sajjan wrote:

This patch adds FIMD related nodes for the Origen Quad board.

Signed-off-by: Vikas Sajjanvikas.saj...@linaro.org
---
  arch/arm/boot/dts/exynos4412-origen.dts |   21 +
  1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-origen.dts 
b/arch/arm/boot/dts/exynos4412-origen.dts
index a5478bd..cb0c507 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -70,6 +70,27 @@
status = okay;
};

+   fimd@11c0 {
+   pinctrl-0 =lcd_clklcd_data24pwm1_out;
+   pinctrl-names = default;
+   status = okay;
+   };
+
+   display-timings {
+   native-mode =timing0;
+   timing0: timing@0 {


I think you could leave out '@0' part, since there is only one node.
And if you decide to keep it, then this node should contain 'reg'
property AFAICT.

Otherwise the series looks good to me. With the above issue addressed
feel free to add

Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com


+   clock-frequency =5;
+   hactive =1024;
+   vactive =600;
+   hfront-porch =64;
+   hback-porch =16;
+   hsync-len =48;
+   vback-porch =64;
+   vfront-porch =16;
+   vsync-len =3;
+   };
+   };
+
serial@1380 {
status = okay;
};


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

Re: [PATCH] of_net.h: Provide dummy functions if OF_NET is not configured

On 04/01/2013 01:19 PM, Guenter Roeck wrote:
 of_get_mac_address() and of_get_phy_mode() are only provided if OF_NET
 is configured. While most callers check for the define, not all do, and those
 who do require #ifdef around the code. For those who don't, the missing check
 can result in errors such as

How about removing the ifdef from those callers?

Rob

 
 arch/powerpc/sysdev/tsi108_dev.c:107:3: error: implicit declaration of
   function 'of_get_mac_address' [-Werror=implicit-function-declaration]
 arch/powerpc/sysdev/mv64x60_dev.c:253:2: error: implicit declaration of
   function 'of_get_mac_address' [-Werror=implicit-function-declaration]
 
 Provide dummy function declarations if OF_NET is not configured. This is safe
 because all callers do check the return values. If desired, at least some of
 the #ifdefs in the code can subsequently be removed.
 
 Cc: David Daney david.da...@cavium.com
 Signed-off-by: Guenter Roeck li...@roeck-us.net
 ---
  include/linux/of_net.h |   10 ++
  1 file changed, 10 insertions(+)
 
 diff --git a/include/linux/of_net.h b/include/linux/of_net.h
 index f474641..61bf53b 100644
 --- a/include/linux/of_net.h
 +++ b/include/linux/of_net.h
 @@ -11,6 +11,16 @@
  #include linux/of.h
  extern const int of_get_phy_mode(struct device_node *np);
  extern const void *of_get_mac_address(struct device_node *np);
 +#else
 +static inline const int of_get_phy_mode(struct device_node *np)
 +{
 + return -ENODEV;
 +}
 +
 +static inline const void *of_get_mac_address(struct device_node *np)
 +{
 + return NULL;
 +}
  #endif
  
  #endif /* __LINUX_OF_NET_H */
 

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

Re: [PATCH V2] DMA: PL330: Add check if device tree compatible

2013-04-01 Thread Vinod Koul

On Mon, Apr 01, 2013 at 08:13:31AM -0500, Rob Herring wrote:
 On Thu, Mar 21, 2013 at 4:39 AM, Vinod Koul vinod.k...@intel.com wrote:
  On Tue, Mar 05, 2013 at 02:55:31PM +0530, Padmavathi Venna wrote:
  This patch register the dma controller with generic dma helpers only
  in DT case. This also adds some extra error handling in the driver.
 
  Signed-off-by: Padmavathi Venna padm...@samsung.com
  Reported-by: Sachin Kamat sachin.ka...@linaro.org
 
 What's the status on this? It is needed for 3.9 to fix pl330 on highbank.
Well the status is that submitter has been rude. I had few questions and
comments on this patch and they are yet to be addressed.

--
~Vinod
 
 Rob
 
  ---
 
  Based on Vinod Koul next branch.
 
  Changes since V1:
- return silently when of_dma_controller_register fails, as
  suggested by Arnd.
 
   drivers/dma/pl330.c |   38 +++---
   1 files changed, 27 insertions(+), 11 deletions(-)
 
  diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
  index 7181531..5dbc594 100644
  --- a/drivers/dma/pl330.c
  +++ b/drivers/dma/pl330.c
  @@ -2882,7 +2882,7 @@ pl330_probe(struct amba_device *adev, const struct 
  amba_id *id)
   {
struct dma_pl330_platdata *pdat;
struct dma_pl330_dmac *pdmac;
  - struct dma_pl330_chan *pch;
  + struct dma_pl330_chan *pch, *_p;
struct pl330_info *pi;
struct dma_device *pd;
struct resource *res;
  @@ -2984,7 +2984,16 @@ pl330_probe(struct amba_device *adev, const struct 
  amba_id *id)
ret = dma_async_device_register(pd);
if (ret) {
dev_err(adev-dev, unable to register DMAC\n);
  - goto probe_err2;
  + goto probe_err3;
  + }
  +
  + if (adev-dev.of_node) {
  + ret = of_dma_controller_register(adev-dev.of_node,
  +  of_dma_pl330_xlate, pdmac);
  + if (ret) {
  + dev_err(adev-dev,
  + unable to register DMA to the generic DT DMA 
  helpers\n);
  Indent?
  + }
}
 
dev_info(adev-dev,
  @@ -2995,16 +3004,21 @@ pl330_probe(struct amba_device *adev, const struct 
  amba_id *id)
pi-pcfg.data_bus_width / 8, pi-pcfg.num_chan,
pi-pcfg.num_peri, pi-pcfg.num_events);
 
  - ret = of_dma_controller_register(adev-dev.of_node,
  -  of_dma_pl330_xlate, pdmac);
  - if (ret) {
  - dev_err(adev-dev,
  - unable to register DMA to the generic DT DMA helpers\n);
  - goto probe_err2;
  - }
  -
return 0;
  +probe_err3:
  + amba_set_drvdata(adev, NULL);
 
  + /* Idle the DMAC */
  + list_for_each_entry_safe(pch, _p, pdmac-ddma.channels,
  + chan.device_node) {
  +
  + /* Remove the channel */
  + list_del(pch-chan.device_node);
  +
  + /* Flush the channel */
  + pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
  + pl330_free_chan_resources(pch-chan);
  free_chan for error handling in probe?
 
  + }
   probe_err2:
pl330_del(pi);
   probe_err1:
  @@ -3023,8 +3037,10 @@ static int pl330_remove(struct amba_device *adev)
if (!pdmac)
return 0;
 
  - of_dma_controller_free(adev-dev.of_node);
  + if (adev-dev.of_node)
  + of_dma_controller_free(adev-dev.of_node);
 
  + dma_async_device_unregister(pdmac-ddma);
amba_set_drvdata(adev, NULL);
 
/* Idle the DMAC */
  --
  1.7.4.4
 
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V3 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

2013-04-01 Thread Vinod Koul

On Mon, Apr 01, 2013 at 12:48:26PM -0500, Jon Hunter wrote:
 Vinod,
 
 On 03/20/2013 11:36 AM, Tony Lindgren wrote:
  * Jon Hunter jon-hun...@ti.com [130319 09:08]:
  Vinod, Tony, Benoit,
 
  On 02/26/2013 12:27 PM, Jon Hunter wrote:
  If the device-tree blob is present during boot, then register the SDMA
  controller with the device-tree DMA driver so that we can use device-tree
  to look-up DMA client information.
 
  Signed-off-by: Jon Hunter jon-hun...@ti.com
  Reviewed-by: Felipe Balbi ba...@ti.com
  Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
  Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
  ---
   arch/arm/mach-omap2/dma.c |4 
   drivers/dma/omap-dma.c|   38 --
   2 files changed, 40 insertions(+), 2 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
  index dab9fc0..49fd0d5 100644
  --- a/arch/arm/mach-omap2/dma.c
  +++ b/arch/arm/mach-omap2/dma.c
  @@ -28,6 +28,7 @@
   #include linux/init.h
   #include linux/device.h
   #include linux/dma-mapping.h
  +#include linux/of.h
   #include linux/omap-dma.h
   
   #include soc.h
  @@ -304,6 +305,9 @@ static int __init omap2_system_dma_init(void)
if (res)
return res;
   
  + if (of_have_populated_dt())
  + return res;
  +
pdev = platform_device_register_full(omap_dma_dev_info);
if (IS_ERR(pdev))
return PTR_ERR(pdev);
  
  AFAIK we don't currently have anything else touching this file..
  
  diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
  index c4b4fd2..2ea3d7e 100644
  --- a/drivers/dma/omap-dma.c
  +++ b/drivers/dma/omap-dma.c
  @@ -16,6 +16,8 @@
   #include linux/platform_device.h
   #include linux/slab.h
   #include linux/spinlock.h
  +#include linux/of_dma.h
  +#include linux/of_device.h
   
   #include virt-dma.h
   
  @@ -67,6 +69,10 @@ static const unsigned es_bytes[] = {
[OMAP_DMA_DATA_TYPE_S32] = 4,
   };
   
  +static struct of_dma_filter_info omap_dma_info = {
  + .filter_fn = omap_dma_filter_fn,
  +};
  +
   static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
   {
return container_of(d, struct omap_dmadev, ddev);
  @@ -621,8 +627,22 @@ static int omap_dma_probe(struct platform_device 
  *pdev)
pr_warn(OMAP-DMA: failed to register slave DMA engine device: 
  %d\n,
rc);
omap_dma_free(od);
  - } else {
  - platform_set_drvdata(pdev, od);
  + return rc;
  + }
  +
  + platform_set_drvdata(pdev, od);
  +
  + if (pdev-dev.of_node) {
  + omap_dma_info.dma_cap = od-ddev.cap_mask;
  +
  + /* Device-tree DMA controller registration */
  + rc = of_dma_controller_register(pdev-dev.of_node,
  + of_dma_simple_xlate, omap_dma_info);
  + if (rc) {
  + pr_warn(OMAP-DMA: failed to register DMA 
  controller\n);
  + dma_async_device_unregister(od-ddev);
  + omap_dma_free(od);
  + }
}
   
dev_info(pdev-dev, OMAP DMA engine driver\n);
  @@ -634,18 +654,32 @@ static int omap_dma_remove(struct platform_device 
  *pdev)
   {
struct omap_dmadev *od = platform_get_drvdata(pdev);
   
  + if (pdev-dev.of_node)
  + of_dma_controller_free(pdev-dev.of_node);
  +
dma_async_device_unregister(od-ddev);
omap_dma_free(od);
   
return 0;
   }
   
  +static const struct of_device_id omap_dma_match[] = {
  + { .compatible = ti,omap2420-sdma, },
  + { .compatible = ti,omap2430-sdma, },
  + { .compatible = ti,omap3430-sdma, },
  + { .compatible = ti,omap3630-sdma, },
  + { .compatible = ti,omap4430-sdma, },
  + {},
  +};
  +MODULE_DEVICE_TABLE(of, omap_dma_match);
  +
   static struct platform_driver omap_dma_driver = {
.probe  = omap_dma_probe,
.remove = omap_dma_remove,
.driver = {
.name = omap-dma-engine,
.owner = THIS_MODULE,
  + .of_match_table = of_match_ptr(omap_dma_match),
},
   };
 
  Who's tree does it make most sense for this patch to go through?
 
  Benoit has queued up patch 1/2 and so I am not sure if this should go
  via Benoit tree to Tony or directly via Vinod's tree. What are your
  thoughts?
  
  OK
   
  It would be great if this could make v3.10.
  
  I suggest Vinod/Grant/Linus W queue this patch:
  
  Acked-by: Tony Lindgren t...@atomide.com
 
 Can you take this patch with Tony's ACK? Let me know if you want me to
 resend with the ACK.
ahhh due to my vcation/travel looks like this one was skipped, I have
applied it now should show up in linus's tree during next merg window

Sorry for delay

~Vinod
 
 Cheers
 Jon
 
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] of_net.h: Provide dummy functions if OF_NET is not configured

2013-04-01 Thread Guenter Roeck

On Mon, Apr 01, 2013 at 01:44:24PM -0500, Rob Herring wrote:
 On 04/01/2013 01:19 PM, Guenter Roeck wrote:
  of_get_mac_address() and of_get_phy_mode() are only provided if OF_NET
  is configured. While most callers check for the define, not all do, and 
  those
  who do require #ifdef around the code. For those who don't, the missing 
  check
  can result in errors such as
 
 How about removing the ifdef from those callers?
 
That would be the next step, after/if this one is accepted.
If not, it doesn't make sense to waste my time.

Thanks,
Guenter

 Rob
 
  
  arch/powerpc/sysdev/tsi108_dev.c:107:3: error: implicit declaration of
  function 'of_get_mac_address' [-Werror=implicit-function-declaration]
  arch/powerpc/sysdev/mv64x60_dev.c:253:2: error: implicit declaration of
  function 'of_get_mac_address' [-Werror=implicit-function-declaration]
  
  Provide dummy function declarations if OF_NET is not configured. This is 
  safe
  because all callers do check the return values. If desired, at least some of
  the #ifdefs in the code can subsequently be removed.
  
  Cc: David Daney david.da...@cavium.com
  Signed-off-by: Guenter Roeck li...@roeck-us.net
  ---
   include/linux/of_net.h |   10 ++
   1 file changed, 10 insertions(+)
  
  diff --git a/include/linux/of_net.h b/include/linux/of_net.h
  index f474641..61bf53b 100644
  --- a/include/linux/of_net.h
  +++ b/include/linux/of_net.h
  @@ -11,6 +11,16 @@
   #include linux/of.h
   extern const int of_get_phy_mode(struct device_node *np);
   extern const void *of_get_mac_address(struct device_node *np);
  +#else
  +static inline const int of_get_phy_mode(struct device_node *np)
  +{
  +   return -ENODEV;
  +}
  +
  +static inline const void *of_get_mac_address(struct device_node *np)
  +{
  +   return NULL;
  +}
   #endif
   
   #endif /* __LINUX_OF_NET_H */
  
 
 
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] of_net.h: Provide dummy functions if OF_NET is not configured

On 04/01/2013 02:01 PM, Guenter Roeck wrote:
 On Mon, Apr 01, 2013 at 01:44:24PM -0500, Rob Herring wrote:
 On 04/01/2013 01:19 PM, Guenter Roeck wrote:
 of_get_mac_address() and of_get_phy_mode() are only provided if OF_NET
 is configured. While most callers check for the define, not all do, and 
 those
 who do require #ifdef around the code. For those who don't, the missing 
 check
 can result in errors such as

 How about removing the ifdef from those callers?

 That would be the next step, after/if this one is accepted.
 If not, it doesn't make sense to waste my time.

Assuming that is done:

Acked-by: Rob Herring rob.herr...@calxeda.com

Presumably with the follow-on patches, this can go in thru the net tree.

Rob

 Thanks,
 Guenter
 
 Rob


 arch/powerpc/sysdev/tsi108_dev.c:107:3: error: implicit declaration of
 function 'of_get_mac_address' [-Werror=implicit-function-declaration]
 arch/powerpc/sysdev/mv64x60_dev.c:253:2: error: implicit declaration of
 function 'of_get_mac_address' [-Werror=implicit-function-declaration]

 Provide dummy function declarations if OF_NET is not configured. This is 
 safe
 because all callers do check the return values. If desired, at least some of
 the #ifdefs in the code can subsequently be removed.

 Cc: David Daney david.da...@cavium.com
 Signed-off-by: Guenter Roeck li...@roeck-us.net
 ---
  include/linux/of_net.h |   10 ++
  1 file changed, 10 insertions(+)

 diff --git a/include/linux/of_net.h b/include/linux/of_net.h
 index f474641..61bf53b 100644
 --- a/include/linux/of_net.h
 +++ b/include/linux/of_net.h
 @@ -11,6 +11,16 @@
  #include linux/of.h
  extern const int of_get_phy_mode(struct device_node *np);
  extern const void *of_get_mac_address(struct device_node *np);
 +#else
 +static inline const int of_get_phy_mode(struct device_node *np)
 +{
 +   return -ENODEV;
 +}
 +
 +static inline const void *of_get_mac_address(struct device_node *np)
 +{
 +   return NULL;
 +}
  #endif
  
  #endif /* __LINUX_OF_NET_H */




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

Re: [PATCH v4 1/6] drivers: phy: add generic PHY framework

2013-04-01 Thread Sylwester Nawrocki


Just couple minor comments...

On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:

The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.

PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
poweron, shutdown.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy and the documentation for
dt binding is can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---

[...]

+/**
+ * phy_put - release the PHY


nit: According to kernel-doc documentation function names should have
parentheses appended to the name. So it would need to be

+ * phy_put() - release the PHY

in this case and it applies to multiple places elsewhere in this patch.


+ * @phy: the phy returned by phy_get()
+ *
+ * Releases a refcount the caller received from phy_get().
+ */
+void phy_put(struct phy *phy)
+{
+   if (phy) {
+   module_put(phy-ops-owner);
+   put_device(phy-dev);
+   }
+}
+EXPORT_SYMBOL_GPL(phy_put);

[...]

+/**
+ * devm_of_phy_get_byname - lookup and obtain a reference to a phy by name
+ * @dev: device that requests this phy
+ * @string - the phy name as given in the dt data


s/ -/:


+ *
+ * Calls devm_of_phy_get (which associates the device with the phy using devres
+ * on successful phy get) and passes on the return value of devm_of_phy_get.
+ */
+struct phy *devm_of_phy_get_byname(struct device *dev, const char *string)
+{
+   int index;
+
+   if (!dev-of_node) {
+   dev_dbg(dev, device does not have a device node entry\n);
+   return ERR_PTR(-EINVAL);
+   }
+
+   index = of_property_match_string(dev-of_node, phy-names, string);
+
+   return devm_of_phy_get(dev, index);
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_get_byname);
+
+/**
+ * phy_get - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy.  The caller is responsible for
+ * calling phy_put() to release that count.
+ */
+struct phy *phy_get(struct device *dev, int index)
+{
+   struct phy *phy = NULL;


Unneeded initialization.


+   phy = phy_lookup(dev, index);
+   if (IS_ERR(phy)) {
+   dev_err(dev, unable to find phy\n);
+   goto err0;


Wouldn't it be better to just do:

return phy;

+   }
+
+   if (!try_module_get(phy-ops-owner)) {
+   phy = ERR_PTR(-EPROBE_DEFER);


and
return ERR_PTR(-EPROBE_DEFER);


+   goto err0;


and to drop this goto and the label below ?


+   }
+
+   get_device(phy-dev);
+
+err0:
+   return phy;
+}
+EXPORT_SYMBOL_GPL(phy_get);



diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
new file mode 100644
index 000..0cb2298
--- /dev/null
+++ b/include/linux/phy/phy.h
@@ -0,0 +1,237 @@
+/*
+ * phy.h -- generic phy header file

[...]

+#ifndef __DRIVERS_PHY_H
+#define __DRIVERS_PHY_H
+
+#includelinux/err.h
+#includelinux/of.h
+
+struct phy


I think you also need to add either

#include linux/device.h

or

struct device;

struct device * is used further in this file.


+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @suspend: suspending the phy
+ * @resume: resuming the phy



+ * @poweron: powering on the phy
+ * @shutdown: shutting down the phy


Could these be named power_on/power_off ? Looks a bit more symmetric
to me that way.


+ * @owner: the module owner containing the ops
+ */
+struct phy_ops {
+   int (*init)(struct phy *phy);
+   int (*exit)(struct phy *phy);
+   int (*suspend)(struct phy *phy);
+   int (*resume)(struct phy *phy);
+   int (*poweron)(struct phy *phy);
+   int (*shutdown)(struct phy *phy);
+   struct module *owner;
+};


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

Re: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two

2013-04-01 Thread Javier Martinez Canillas

On Mon, Apr 1, 2013 at 6:41 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
 Hi Javier

 On Sat, 2013-03-30 at 14:18 +0100, Javier Martinez Canillas wrote:
 A call to gpio_request() to enable the GPIO bank is needed before
 using a GPIO as an IRQ source, otherwise accesses to the GPIO bank
 registers fails making the kernel to hang.

 Yes, that is exactly my problem here. I'm using the GPIO as an IRQ
 source.

 Jon's (added as cc)gpio/omap: warn if bank is not enabled on setting
 irq type patch [1] fixes the issue by warning and returning -EINVAL.

 This patch will make the kernel to boot but the call to request_irq()
 will fail of course. For now, the only solution is to call
 gpio_request() before request_irq() in your platform code or device
 driver. There is an on going discussion about what's the better way to
 address this but we still haven't found a good solution to this
 problem, you can see the last email for this discussion here [2]

 Also, even when calling gpio_request() before request_irq() this won't
 work. When specifying the trigger/level flags on the second cell for
 an GPIO-IRQ, this is not set on the IORESOURCE_IRQ struct resource.
 The IRQ flag is set on of_irq_to_resource() but it just does:

 r-flags = IORESOURCE_IRQ;

 and then the call stack is irq_to_parse_and_map() -
 irq_set_irq_type() -  __irq_set_trigger() - chip-irq_set_type() -
 (drivers/gpio/gpio-omap.c) gpio_irq_type().

 So, even when gpio_irq_type() receive the correct flags, this are not
 returned neither stored on the flags member of the IORESOURCE_IRQ
 struct resource that passed to the drivers in their struct
 platform_device.

 As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
 to enable GPIO banks. I now geht this:

  [0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040: 0x00ff
  [0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010: 0x0007
  [0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000: 0x0007

 And it works for me. _But_ when I do enable regulator twl4030
 (CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:

 [2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x00ff
 [2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
 [2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x

 And the IRQ source for the network chip (smsc911x) is disabled :-(

 Do you have any idea how to (quick) fix this?


A quick hack is to call gpio_request() explicitly before calling to
irq_set_type() is made.
I've this patch just to make it work until we find a clean solution:

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 90c15ee..d594e1d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -14,6 +14,7 @@
  */
 #undef DEBUG

+#include linux/gpio.h
 #include linux/irq.h
 #include linux/kernel.h
 #include linux/init.h
@@ -1528,6 +1529,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}

+   ret = gpio_request_one(176, GPIOF_IN, smsc911x irq);
+   if (ret) {
+   pr_err(Failed to request IRQ GPIO%d\n, 176);
+   return ret;
+   }
+
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
if (ret  0) {

This solves the issue of the non-initialized GPIO bank before that
makes the kernel to hang. Since I've to configure the IRQ polarity as
active low level-sensitive on my board and the flags are not set by
the IRQ core, I've another ugly hack that forces this:

diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc
index da5cc9a..27e46f9 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2390,6 +2390,9 @@ static int smsc911x_drv_probe(struct
platform_device *pdev)
pdata = netdev_priv(dev);
dev-irq = irq_res-start;
-irq_flags = irq_res-flags  IRQF_TRIGGER_MASK;
+   irq_flags = IRQF_TRIGGER_LOW;
pdata-ioaddr = ioremap_nocache(res-start, res_size);

pdata-dev = dev;

  Thanks
   -- Christoph


I hope to find some time this week to work on this and at least find a
solution for the second issue (IORESOURCE_IRQ struct resource flags
not being set).

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

How to represent negative values for device tree property

2013-04-01 Thread David Collins

Hi,

I am working on a thermal driver which needs to be able to read a
temperature threshold from a device tree property.  The hardware supports
thresholds in the range -204.8 to +204.7 C in 0.1 C steps.  I have found,
as I am sure others have as well, that dtc treats a '-' before an integer
in a dtsi file as a syntax error.  Therefore, I need some artificial way
to represent negative numbers in device tree.  Here are the possibilities
that I have thought of so far:

1. Use a second integer to specify the sign of the threshold:
 2 mC -- 0 2
-2 mC -- 1 2
2. Use a string instead of an integer to specify the threshold and
   then convert it to an integer in the driver software:
 2 mC -- 2
-2 mC -- -2
3. Use units of millikelvin instead of millicelcius.  0 mC == 273150 mK
 2 mC -- 293150
-2 mC -- 253150
4. Use an arbitrary offset e.g. 0 mC == 100
 2 mC -- 102
-2 mC -- 98
5. Use the unsigned 32-bit representation for 2’s-compliment
   signed 32-bit integer
 2 mC -- 2
-2 mC -- 0xb1e0 or 4294947296

Which of these options would you recommend using?  Is there any better way
to handle negative values that I haven’t listed?  What is the best general
case solution for specifying negative numbers in device tree?

Thanks,
David

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] of: Add missing node iteration stubs for disabled CONFIG_OF

On 03/09/2013 02:15 PM, Tomasz Figa wrote:
 This patch moves several for_each macros out of the #ifdef CONFIG_OF
 block and adds inline stubs for functions used by these macros, compiled
 conditionally when CONFIG_OF is not enabled.
 
 This eliminates the need to explicitly check for CONFIG_OF in driver
 code using mentioned functions and macros.

Do you have some users of this?

Rob

 
 Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
 ---
  include/linux/of.h | 92 
 +-
  1 file changed, 63 insertions(+), 29 deletions(-)
 
 diff --git a/include/linux/of.h b/include/linux/of.h
 index a0f1292..7a736b8 100644
 --- a/include/linux/of.h
 +++ b/include/linux/of.h
 @@ -86,6 +86,31 @@ static inline struct device_node *of_node_get(struct 
 device_node *node)
  static inline void of_node_put(struct device_node *node) { }
  #endif /* !CONFIG_OF_DYNAMIC */
  
 +#define for_each_node_by_name(dn, name) \
 + for (dn = of_find_node_by_name(NULL, name); dn; \
 +  dn = of_find_node_by_name(dn, name))
 +#define for_each_node_by_type(dn, type) \
 + for (dn = of_find_node_by_type(NULL, type); dn; \
 +  dn = of_find_node_by_type(dn, type))
 +#define for_each_compatible_node(dn, type, compatible) \
 + for (dn = of_find_compatible_node(NULL, type, compatible); dn; \
 +  dn = of_find_compatible_node(dn, type, compatible))
 +#define for_each_matching_node(dn, matches) \
 + for (dn = of_find_matching_node(NULL, matches); dn; \
 +  dn = of_find_matching_node(dn, matches))
 +#define for_each_matching_node_and_match(dn, matches, match) \
 + for (dn = of_find_matching_node_and_match(NULL, matches, match); \
 +  dn; dn = of_find_matching_node_and_match(dn, matches, match))
 +#define for_each_child_of_node(parent, child) \
 + for (child = of_get_next_child(parent, NULL); child != NULL; \
 +  child = of_get_next_child(parent, child))
 +#define for_each_available_child_of_node(parent, child) \
 + for (child = of_get_next_available_child(parent, NULL); child != NULL; \
 +  child = of_get_next_available_child(parent, child))
 +#define for_each_node_with_property(dn, prop_name) \
 + for (dn = of_find_node_with_property(NULL, prop_name); dn; \
 +  dn = of_find_node_with_property(dn, prop_name))
 +
  #ifdef CONFIG_OF
  
  /* Pointer for first entry in chain of all nodes. */
 @@ -167,19 +192,10 @@ static inline const char *of_node_full_name(const 
 struct device_node *np)
  
  extern struct device_node *of_find_node_by_name(struct device_node *from,
   const char *name);
 -#define for_each_node_by_name(dn, name) \
 - for (dn = of_find_node_by_name(NULL, name); dn; \
 -  dn = of_find_node_by_name(dn, name))
  extern struct device_node *of_find_node_by_type(struct device_node *from,
   const char *type);
 -#define for_each_node_by_type(dn, type) \
 - for (dn = of_find_node_by_type(NULL, type); dn; \
 -  dn = of_find_node_by_type(dn, type))
  extern struct device_node *of_find_compatible_node(struct device_node *from,
   const char *type, const char *compat);
 -#define for_each_compatible_node(dn, type, compatible) \
 - for (dn = of_find_compatible_node(NULL, type, compatible); dn; \
 -  dn = of_find_compatible_node(dn, type, compatible))
  extern struct device_node *of_find_matching_node_and_match(
   struct device_node *from,
   const struct of_device_id *matches,
 @@ -190,12 +206,6 @@ static inline struct device_node *of_find_matching_node(
  {
   return of_find_matching_node_and_match(from, matches, NULL);
  }
 -#define for_each_matching_node(dn, matches) \
 - for (dn = of_find_matching_node(NULL, matches); dn; \
 -  dn = of_find_matching_node(dn, matches))
 -#define for_each_matching_node_and_match(dn, matches, match) \
 - for (dn = of_find_matching_node_and_match(NULL, matches, match); \
 -  dn; dn = of_find_matching_node_and_match(dn, matches, match))
  extern struct device_node *of_find_node_by_path(const char *path);
  extern struct device_node *of_find_node_by_phandle(phandle handle);
  extern struct device_node *of_get_parent(const struct device_node *node);
 @@ -207,14 +217,6 @@ extern struct device_node *of_get_next_available_child(
  
  extern struct device_node *of_get_child_by_name(const struct device_node 
 *node,
   const char *name);
 -#define for_each_child_of_node(parent, child) \
 - for (child = of_get_next_child(parent, NULL); child != NULL; \
 -  child = of_get_next_child(parent, child))
 -
 -#define for_each_available_child_of_node(parent, child) \
 - for (child = of_get_next_available_child(parent, NULL); child != NULL; \
 -  child = of_get_next_available_child(parent, child))
 -
  static inline int of_get_child_count(const struct device_node *np)
  {
   struct device_node *child;
 @@ -228,10 +230,6 @@ static inline int

Re: [PATCH 0/3] add devicetree bindings for rtc-m48t86

On 01/04/13 08:56, Alexander Clouter wrote:
 Currently there are two users of rtc-m48t86 (mach-ep93xx/ts72xx.c and
 mach-orion5x/ts78xx-setup.c) and both just use {read,write}b against
 a memory mapped region.  As I am devicetree'ing the TS-7800, this
 driver needs converting and thats what this patchset does.
 
 The patch does the following:
  * remove platform specific ops hooks, moving ioremap'ing and
   everything into the driver
  * utilises named resources to indicate index/data ranges
  * moves the RTC detection routine from ts78xx-setup.c into rtc-m48t86.c
  * and, of course, enable devicetree hooks and include documentation
 
 Awkward step, the first patch breaks both boards, the two following
 patches fix them.  Happy to re-work this if folks give me a pointer
 on how to do this in an acceptable way.

Sorry, that's no good. It breaks things like git bisect.

 
 My vote is to break fast, fix fast, spend the time writing other code :)

The patch series will need to be reworked so that there is no
build/runtime breakage between any of the patches. I'll have a read
through and see if I can suggest something.

~Ryan


 Signed-off-by: Alexander Clouter a...@digriz.org.uk
 
 Alexander Clouter (3):
   rtc: rtc-m48t86: add devicetree bindings
   arm: orion5x: fixup ts78xx to be able to use the rtc-m48t86 again.
   arm: ep93xx: fixup ts72xx to be able to use the rtc-m48t86 again.
 
  .../devicetree/bindings/rtc/rtc-m48t86.txt |   17 ++
  arch/arm/mach-ep93xx/ts72xx.c  |   29 +--
  arch/arm/mach-orion5x/ts78xx-setup.c   |   79 ++
  drivers/rtc/rtc-m48t86.c   |  254 
 +++-
  include/linux/m48t86.h |   16 --
  5 files changed, 239 insertions(+), 156 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
  delete mode 100644 include/linux/m48t86.h
 

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

[PATCH V2 0/3] Add DT Binding for Power-Supply power-supplies property

This series defines a common way for devicetree initialized
power_supplies to define their relationships between chargers and
supplicants.

This series adds a supplied_from array to complement the supplied_to
array and to allow supplies to define the list of supplies which
supply them.

Then once this property is supported, we can use a new property for
devicetree to define the relationships between nodes, and read in this
property to generate the supplied_from list.

With this logic in place, all drivers need to do to add support for
this mechanism, is to store their device tree node in the power_supply
struct. They should also handle EPROBE_DEFER properly.

Changes since:
v2:
 - Changed __power_supply_is_supplied_by to a boolean function and
   corrected return paths around it
 - took loop invariant tests out of loops
 - Fixed multiline comment style
 - fixed up return paths around power_supplies_check_supplies

RFC v2:
 - Changed to official Patch set rather than RFC
 - defined supplied_from char ** array rather than complicated
   struct device_node related array

RFC v1:
 - Inverted the logic so that supplies (batteries) contain a list of
   the supplies (chargers) which supply them.

Rhyland Klein (3):
  power_supply: Define Binding for power-supplies
  power: power_supply: Add core support for supplied_from
  power: power_supply_core: Add support for supplied_from

 .../bindings/power_supply/power_supply.txt |   23 +++
 drivers/power/power_supply_core.c  |  187 ++--
 include/linux/power_supply.h   |6 +
 3 files changed, 203 insertions(+), 13 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power_supply/power_supply.txt

-- 
1.7.9.5

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

[PATCH V2 1/3] power_supply: Define Binding for power-supplies

This property is meant to be used in device nodes which represent
power_supply devices that wish to provide a list of supplies which
provide them power, such as a battery listing its chargers.

Signed-off-by: Rhyland Klein rkl...@nvidia.com
---
v2:
 - no changes

v1:
 - changed from RFC v2 - patch v1
 - made poropery plural as it can be a list
 - update example with plural  changed once charger address

v2 (RFC):
 - changed property to power-supply which should be contained in the
   battery rather than the charger. Also updated example to match

 .../bindings/power_supply/power_supply.txt |   23 
 1 file changed, 23 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power_supply/power_supply.txt

diff --git a/Documentation/devicetree/bindings/power_supply/power_supply.txt 
b/Documentation/devicetree/bindings/power_supply/power_supply.txt
new file mode 100644
index 000..8391bfa
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/power_supply.txt
@@ -0,0 +1,23 @@
+Power Supply Core Support
+
+Optional Properties:
+ - power-supplies : This property is added to a supply in order to list the
+   devices which supply it power, referenced by their phandles.
+
+Example:
+
+   usb-charger: power@e {
+   compatible = some,usb-charger;
+   ...
+   };
+
+   ac-charger: power@c {
+   compatible = some,ac-charger;
+   ...
+   };
+
+   battery@b {
+   compatible = some,battery;
+   ...
+   power-supplies = usb-charger, ac-charger;
+   };
-- 
1.7.9.5

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

[PATCH V2 2/3] power: power_supply: Add core support for supplied_from

This patch adds support for supplies to register a list of char *'s
which represent the list of supplies which supply them. This is the
opposite as the supplied_to list.

This change maintains support for supplied_to until all drivers which
make use of it already are converted.

Signed-off-by: Rhyland Klein rkl...@nvidia.com
---
v2:
 - changed __power_supply_is_supplied_by to a boolean function
 - fixed up return paths with correct return values
 - moved loop invariant checks outside of loops

v1:
 - changed from RFC v2 - patch v1
 - removed list logic and instead added supplied_from char ** array and
   num_supplies field

v2 (RFC):
 - changed from struct device_node * contained in suppliers to a list
   stored in the supplies.
 - changed logic for the is_supplied_by check to handle the entire loop
   as the array structure is difference between the 2 paths.

 drivers/power/power_supply_core.c |   47 +++--
 include/linux/power_supply.h  |3 +++
 2 files changed, 37 insertions(+), 13 deletions(-)

diff --git a/drivers/power/power_supply_core.c 
b/drivers/power/power_supply_core.c
index 5deac43..d843cc9 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -26,17 +26,42 @@ EXPORT_SYMBOL_GPL(power_supply_class);
 
 static struct device_type power_supply_dev_type;
 
+static bool __power_supply_is_supplied_by(struct power_supply *supplier,
+struct power_supply *supply)
+{
+   int i;
+
+   if (!supply-supplied_from  !supplier-supplied_to)
+   return false;
+
+   /* Support both supplied_to and supplied_from modes */
+   if (supply-supplied_from) {
+   if (!supplier-name)
+   return false;
+   for (i = 0; i  supply-num_supplies; i++)
+   if (!strcmp(supplier-name, supply-supplied_from[i]))
+   return true;
+   } else {
+   if (!supply-name)
+   return false;
+   for (i = 0; i  supplier-num_supplicants; i++)
+   if (!strcmp(supplier-supplied_to[i], supply-name))
+   return true;
+   }
+
+   return false;
+}
+
 static int __power_supply_changed_work(struct device *dev, void *data)
 {
struct power_supply *psy = (struct power_supply *)data;
struct power_supply *pst = dev_get_drvdata(dev);
-   int i;
 
-   for (i = 0; i  psy-num_supplicants; i++)
-   if (!strcmp(psy-supplied_to[i], pst-name)) {
-   if (pst-external_power_changed)
-   pst-external_power_changed(pst);
-   }
+   if (__power_supply_is_supplied_by(psy, pst)) {
+   if (pst-external_power_changed)
+   pst-external_power_changed(pst);
+   }
+
return 0;
 }
 
@@ -68,17 +93,13 @@ static int __power_supply_am_i_supplied(struct device *dev, 
void *data)
union power_supply_propval ret = {0,};
struct power_supply *psy = (struct power_supply *)data;
struct power_supply *epsy = dev_get_drvdata(dev);
-   int i;
 
-   for (i = 0; i  epsy-num_supplicants; i++) {
-   if (!strcmp(epsy-supplied_to[i], psy-name)) {
-   if (epsy-get_property(epsy,
- POWER_SUPPLY_PROP_ONLINE, ret))
-   continue;
+   if (__power_supply_is_supplied_by(epsy, psy))
+   if (!epsy-get_property(epsy, POWER_SUPPLY_PROP_ONLINE, ret)) {
if (ret.intval)
return ret.intval;
}
-   }
+
return 0;
 }
 
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 002a99f..c1cbd5e 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -171,6 +171,9 @@ struct power_supply {
char **supplied_to;
size_t num_supplicants;
 
+   char **supplied_from;
+   size_t num_supplies;
+
int (*get_property)(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val);
-- 
1.7.9.5

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

[PATCH V2 3/3] power: power_supply_core: Add support for supplied_from

Adding support for supplied_from char * array. This is meant to store the
list of suppliers for a given supply, i.e. chargers for a battery. This
list can be populated through devicetree readily as well as passed
directly from the driver.

Signed-off-by: Rhyland Klein rkl...@nvidia.com
---
v2:
 - fixed multiline comment style
 - fixed usage of ret to inside loop and directly return result of
   power_supply_populate_supplied_from

v1:
 - Changed from RFC v2 - patch v1
 - removed list logic, added logic to first verify all supplies are
   present and defer probe until they are.
 - after all devices are registered, populate the char ** supplied_from
   array which simulates the case of dt not being used.
 - added of_node element to struct power_supply

v2 (RFC):
  - Simplified and renamed the logic to parse dt for the charger list.
  - Tied the dt parsing directly to power_supply_register to make fewer
changes required for converting existing chargers/supplies.

 drivers/power/power_supply_core.c |  140 +
 include/linux/power_supply.h  |3 +
 2 files changed, 143 insertions(+)

diff --git a/drivers/power/power_supply_core.c 
b/drivers/power/power_supply_core.c
index d843cc9..5e84321 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -88,6 +88,139 @@ void power_supply_changed(struct power_supply *psy)
 }
 EXPORT_SYMBOL_GPL(power_supply_changed);
 
+#ifdef CONFIG_OF
+#include linux/of.h
+
+static int __power_supply_populate_supplied_from(struct device *dev,
+void *data)
+{
+   struct power_supply *psy = (struct power_supply *)data;
+   struct power_supply *epsy = dev_get_drvdata(dev);
+   struct device_node *np;
+   int i = 0;
+
+   do {
+   np = of_parse_phandle(psy-of_node, power-supplies, i++);
+   if (!np)
+   continue;
+
+   if (np == epsy-of_node) {
+   dev_info(psy-dev, %s: Found supply : %s\n,
+   psy-name, epsy-name);
+   psy-supplied_from[i-1] = (char *)epsy-name;
+   psy-num_supplies++;
+   break;
+   }
+   } while (np);
+
+   return 0;
+}
+
+int power_supply_populate_supplied_from(struct power_supply *psy)
+{
+   int error;
+
+   error = class_for_each_device(power_supply_class, NULL, psy,
+ __power_supply_populate_supplied_from);
+
+   dev_dbg(psy-dev, %s %d\n, __func__, error);
+
+   return error;
+}
+
+static int  __power_supply_find_supply_from_node(struct device *dev,
+void *data)
+{
+   struct device_node *np = (struct device_node *)data;
+   struct power_supply *epsy = dev_get_drvdata(dev);
+
+   /* return error breaks out of class_for_each_device loop */
+   if (epsy-of_node == np)
+   return -EINVAL;
+
+   return 0;
+}
+
+int power_supply_find_supply_from_node(struct device_node *supply_node)
+{
+   int error;
+   struct device *dev;
+   struct class_dev_iter iter;
+
+   /*
+* Use iterator to see if any other device is registered.
+* This is required since class_for_each_device returns 0
+* if there are no devices registered.
+*/
+   class_dev_iter_init(iter, power_supply_class, NULL, NULL);
+   dev = class_dev_iter_next(iter);
+
+   if (!dev)
+   return -EPROBE_DEFER;
+
+   /*
+* We have to treat the return value as inverted, because if
+* we return error on not found, then it won't continue looking.
+* So we trick it by returning error on success to stop looking
+* once the matching device is found.
+*/
+   error = class_for_each_device(power_supply_class, NULL, supply_node,
+  __power_supply_find_supply_from_node);
+
+   return error ? 0 : -EPROBE_DEFER;
+}
+
+int power_supply_check_supplies(struct power_supply *psy)
+{
+   struct device_node *np;
+   int cnt = 0;
+
+   /* If there is already a list honor it */
+   if (psy-supplied_from  psy-num_supplies  0)
+   return 0;
+
+   /* No device node found, nothing to do */
+   if (!psy-of_node)
+   return 0;
+
+   do {
+   int ret;
+
+   np = of_parse_phandle(psy-of_node, power-supplies, cnt++);
+   if (!np)
+   continue;
+
+   ret = power_supply_find_supply_from_node(np);
+   if (ret) {
+   dev_dbg(psy-dev, Failed to find supply, defer!\n);
+   return -EPROBE_DEFER;
+   }
+   } while (np);
+
+   /* All supplies found, allocate char ** array for filling */
+   psy-supplied_from = devm_kzalloc(psy-dev, sizeof(psy-supplied_from),
+

Re: How to represent negative values for device tree property

2013-04-01 Thread Stephen Warren

On 04/01/2013 03:08 PM, David Collins wrote:
 Hi,
 
 I am working on a thermal driver which needs to be able to read a
 temperature threshold from a device tree property.  The hardware supports
 thresholds in the range -204.8 to +204.7 C in 0.1 C steps.  I have found,
 as I am sure others have as well, that dtc treats a '-' before an integer
 in a dtsi file as a syntax error.  Therefore, I need some artificial way
 to represent negative numbers in device tree.  Here are the possibilities
 that I have thought of so far:

Doesn't the very latest dtc, which contains integer expression support,
allow unary -? I thought that code had been imported into the kernel
(goes and checks) yes it has. What's the error you're seeing;
over/underflow or syntax?

That said, DT cells are supposed to be u32 not s32, so perhaps this
isn't unexpected.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 0/3] add devicetree bindings for rtc-m48t86

On Tue, Apr 02, 2013 at 08:44:10AM +1100, Ryan Mallon wrote:

On 01/04/13 08:56, Alexander Clouter wrote:

Currently there are two users of rtc-m48t86 (mach-ep93xx/ts72xx.c and
mach-orion5x/ts78xx-setup.c) and both just use {read,write}b against
a memory mapped region. As I am devicetree'ing the TS-7800, this
driver needs converting and thats what this patchset does.

The patch does the following:
* remove platform specific ops hooks, moving ioremap'ing and
everything into the driver
* utilises named resources to indicate index/data ranges
* moves the RTC detection routine from ts78xx-setup.c into rtc-m48t86.c
* and, of course, enable devicetree hooks and include documentation

Awkward step, the first patch breaks both boards, the two following
patches fix them. Happy to re-work this if folks give me a pointer
on how to do this in an acceptable way.

Sorry, that's no good. It breaks things like git bisect.

Bah :)

My vote is to break fast, fix fast, spend the time writing other code :)

The patch series will need to be reworked so that there is no
build/runtime breakage between any of the patches. I'll have a read
through and see if I can suggest something.

I am currently working through a new patchset now. It maintains the original {write,read}byte
ops but if not defined, and the required named resources are present, it moves to using driver
side mem mapped regions and what not...

'watch this space'

Cheers

--
Alexander Clouter
.sigmonster says: Deflector shields just came on, Captain.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 1/3] rtc: rtc-m48t86: add devicetree bindings

On 01/04/13 08:56, Alexander Clouter wrote:
 This patch allows rtc-m48t86 to be used via devicetree.
 
 Signed-off-by: Alexander Clouter a...@digriz.org.uk
 ---
  .../devicetree/bindings/rtc/rtc-m48t86.txt |   17 ++
  drivers/rtc/rtc-m48t86.c   |  254 
 +++-
  include/linux/m48t86.h |   16 --
  3 files changed, 213 insertions(+), 74 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
  delete mode 100644 include/linux/m48t86.h

Some comments below.

 diff --git a/Documentation/devicetree/bindings/rtc/rtc-m48t86.txt 
 b/Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
 new file mode 100644
 index 000..1336c98
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
 @@ -0,0 +1,17 @@
 +ST M48T86 / Dallas DS12887 RTC driver
 +
 +Required properties:
 +- compatible: rtc-m48t86
 +- reg: array of two address ranges of the RTC index and data registers
 +- reg-names: must have rtc_index and rtc_data present
 +
 +Example:
 +
 +rtc@808 {
 + #address-cells = 1;
 + #size-cells = 1;
 + compatible = rtc-m48t86;
 + reg =   0x808 0x04,
 + 0x80c 0x04;
 + reg-names = rtc_index, rtc_data;
 +};
 diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
 index 2ffbcac..47e9fd1 100644
 --- a/drivers/rtc/rtc-m48t86.c
 +++ b/drivers/rtc/rtc-m48t86.c
 @@ -16,8 +16,10 @@
  #include linux/module.h
  #include linux/rtc.h
  #include linux/platform_device.h
 -#include linux/m48t86.h
  #include linux/bcd.h
 +#include linux/of.h
 +#include linux/slab.h
 +#include linux/io.h
  
  #define M48T86_REG_SEC   0x00
  #define M48T86_REG_SECALRM   0x01
 @@ -41,40 +43,61 @@
  
  #define DRV_VERSION 0.1
  
 +struct m48t86_rtc_private_data {
 + void __iomem*io_index;
 + void __iomem*io_data;
 +
 + struct rtc_device   *rtc;
 +};
 +
 +static unsigned char m48t86_rtc_readbyte(
 + struct m48t86_rtc_private_data *priv,
 + unsigned long addr)

Line breaks like this are a bit ugly. Breaking after the return type
would be better. You can shorten this by changing 'unsigned char' to
'u8', and 'm48t86_rtc_private_data' to something like 'm48t86_priv'. Why
is addr unsigned long if you are passing it to writeb?

 +{
 + writeb(addr, priv-io_index);
 + return readb(priv-io_data);
 +}
 +
 +static void m48t86_rtc_writebyte(
 + struct m48t86_rtc_private_data *priv,
 + unsigned char value, unsigned long addr)
 +{
 + writeb(addr, priv-io_index);
 + writeb(value, priv-io_data);
 +}
  
  static int m48t86_rtc_read_time(struct device *dev, struct rtc_time *tm)
  {
   unsigned char reg;
 - struct platform_device *pdev = to_platform_device(dev);
 - struct m48t86_ops *ops = pdev-dev.platform_data;
 + struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
  
 - reg = ops-readbyte(M48T86_REG_B);
 + reg = m48t86_rtc_readbyte(priv, M48T86_REG_B);
  
   if (reg  M48T86_REG_B_DM) {
   /* data (binary) mode */
 - tm-tm_sec  = ops-readbyte(M48T86_REG_SEC);
 - tm-tm_min  = ops-readbyte(M48T86_REG_MIN);
 - tm-tm_hour = ops-readbyte(M48T86_REG_HOUR)  0x3F;
 - tm-tm_mday = ops-readbyte(M48T86_REG_DOM);
 + tm-tm_sec  = m48t86_rtc_readbyte(priv, M48T86_REG_SEC);
 + tm-tm_min  = m48t86_rtc_readbyte(priv, M48T86_REG_MIN);
 + tm-tm_hour = m48t86_rtc_readbyte(priv, M48T86_REG_HOUR)  
 0x3F;
 + tm-tm_mday = m48t86_rtc_readbyte(priv, M48T86_REG_DOM);
   /* tm_mon is 0-11 */
 - tm-tm_mon  = ops-readbyte(M48T86_REG_MONTH) - 1;
 - tm-tm_year = ops-readbyte(M48T86_REG_YEAR) + 100;
 - tm-tm_wday = ops-readbyte(M48T86_REG_DOW);
 + tm-tm_mon  = m48t86_rtc_readbyte(priv, M48T86_REG_MONTH) - 
 1;
 + tm-tm_year = m48t86_rtc_readbyte(priv, M48T86_REG_YEAR) + 
 100;
 + tm-tm_wday = m48t86_rtc_readbyte(priv, M48T86_REG_DOW);
   } else {
   /* bcd mode */
 - tm-tm_sec  = bcd2bin(ops-readbyte(M48T86_REG_SEC));
 - tm-tm_min  = bcd2bin(ops-readbyte(M48T86_REG_MIN));
 - tm-tm_hour = bcd2bin(ops-readbyte(M48T86_REG_HOUR)  
 0x3F);
 - tm-tm_mday = bcd2bin(ops-readbyte(M48T86_REG_DOM));
 + tm-tm_sec  = bcd2bin(m48t86_rtc_readbyte(priv, 
 M48T86_REG_SEC));
 + tm-tm_min  = bcd2bin(m48t86_rtc_readbyte(priv, 
 M48T86_REG_MIN));
 + tm-tm_hour = bcd2bin(m48t86_rtc_readbyte(priv, 
 M48T86_REG_HOUR)  0x3F);
 + tm-tm_mday = bcd2bin(m48t86_rtc_readbyte(priv, 
 M48T86_REG_DOM));
   /* tm_mon is 0-11 */
 - tm-tm_mon  = bcd2bin(ops-readbyte(M48T86_REG_MONTH)) - 1;

Re: [PATCH 0/3] add devicetree bindings for rtc-m48t86

On 02/04/13 08:44, Ryan Mallon wrote:
 On 01/04/13 08:56, Alexander Clouter wrote:
 Currently there are two users of rtc-m48t86 (mach-ep93xx/ts72xx.c and
 mach-orion5x/ts78xx-setup.c) and both just use {read,write}b against
 a memory mapped region.  As I am devicetree'ing the TS-7800, this
 driver needs converting and thats what this patchset does.

 The patch does the following:
  * remove platform specific ops hooks, moving ioremap'ing and
  everything into the driver
  * utilises named resources to indicate index/data ranges
  * moves the RTC detection routine from ts78xx-setup.c into rtc-m48t86.c
  * and, of course, enable devicetree hooks and include documentation

 Awkward step, the first patch breaks both boards, the two following
 patches fix them.  Happy to re-work this if folks give me a pointer
 on how to do this in an acceptable way.
 
 Sorry, that's no good. It breaks things like git bisect.
 

 My vote is to break fast, fix fast, spend the time writing other code :)
 
 The patch series will need to be reworked so that there is no
 build/runtime breakage between any of the patches. I'll have a read
 through and see if I can suggest something.

So looking through the patches, you are going to need to modify the rtc
driver and the platform code in the same patch at least once since you
are changing the interface. You could break the patches down like this:

1) Move the rtc detection from the orion5x board to the rtc driver.
   This adds the detection support for the ep93xx board also.

2) Replace the board read/write ops structure with ioremapped regions.

3) Add the device tree bindings to the rtc driver.

The first two patches could be combined, but will touch both the rtc
driver and the platform code, and do the prep work needed for adding the
dt bindings. The third patch can then stand on its own, and more clearly
just adds the dt bindings.

~Ryan

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

Re: [PATCH v4 1/6] drivers: phy: add generic PHY framework

2013-04-01 Thread Sylwester Nawrocki


On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..35696b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,76 @@
+This document explains only the dt data binding. For general information about
+PHY subsystem refer Documentation/phy.txt
+
+PHY device node
+===
+
+Optional Properties:
+#phy-cells:Number of cells in a PHY specifier;  The meaning of all those
+   cells is defined by the binding for the phy node. However
+   in-order to return the correct PHY, the PHY susbsystem
+   requires the first cell always refers to the port.
+
+This property is optional because it is needed only for the case where a
+single IP implements multiple PHYs.
+
+For example:
+
+phys: phy {
+compatible = xxx;
+reg1 =...;
+reg2 =...;
+reg3 =...;
+.
+.
+#phy-cells =1;
+.
+.
+};
+
+That node describes an IP block that implements 3 different PHYs. In order to
+differentiate between these 3 PHYs, an additonal specifier should be given
+while trying to get a reference to it. (The PHY subsystem assumes the
+specifier is port id).
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+
+Optional properties:
+phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phys* phandle
+
+example1:
+phys: phy {
+compatible = xxx;
+reg =...;
+.
+.
+phys =usb2_phy,usb3_phy;
+phy-names = usb2phy, usb3phy;
+.
+.
+};
+This node represents a controller that uses two PHYs one for usb2 and one for
+usb3. The controller driver can get the appropriate PHY either by using
+devm_of_phy_get/of_phy_get by passing the correct index or by using
+of_phy_get_byname/devm_of_phy_get_byname by passing the names given in
+*phy-names*.
+
+example2:
+phys: phy {
+compatible = xxx;
+reg =...;
+.
+.
+phys =phys 1;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs which is defined
+previously. Note that the phy handle has an additional specifier 1 to
+differentiate between the three PHYs. For this case, the controller driver
+should use of_phy_get_with_args/devm_of_phy_get_with_args.


This means a PHY user needs to know indexes at the PHY driver ?

I have been thinking of using this for an IP which has 4 video PHYs: 2 MIPI
CSI-2 and 2 MIPI DSI. The IP has just 2 registers, each of which is shared
between one MIPI CSI-2 DPHY and one MIPI DSI DPHY. So I thought about 
creating
a single device node for this IP and using 4 indexes for the PHYs, e.g. 
0...3.

Then users of each PHY type would use only indexes 0..1 (to select their
corresponding port).

However I fail to see how this could now be represented in the bindings.

I assume struct phy::type could be used to differentiate between CSI-2 
and DSI.

And struct phy::port could be used to select specific CSI-2 or DSI channel
(0, 1). Ideally the phy users should not care about index of a PHY at 
the PHY

device tree node. E.g. there are 2 MIPI CSI-2 receivers and each has only
one PHY assigned to it. I'm just wondering how the binding should look like,
so a PHY could be associated with a receiver automatically by the phy-core,
e.g.

/* DPHY IP node */
video-phy {
  reg = 0x1000 8;
};

/* MIPI DSI nodes */
dsi_0 {
 phys = video-phy 0;
};

dsi_1 {
 phys = video-phy 1;
};

/* MIPI CSI-2 nodes */
csi_0 {
 phys = video-phy 2;
};

csi_1 {
 phys = video-phy 3;
};

I'm not sure if it is not an overkill to use this the PHY framework with
a device which has only 2 registers. Perhaps something less heavy could
be designed for it. However, if the PHY framework is commonly used there
should be no issue wrt enabling the whole big infrastructure for a simple
device like this.


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

Re: [PATCH 0/3] add devicetree bindings for rtc-m48t86

2013-04-01 Thread Jason Cooper

On Tue, Apr 02, 2013 at 09:12:02AM +1100, Ryan Mallon wrote:
 On 02/04/13 08:44, Ryan Mallon wrote:
  On 01/04/13 08:56, Alexander Clouter wrote:
  Currently there are two users of rtc-m48t86 (mach-ep93xx/ts72xx.c and
  mach-orion5x/ts78xx-setup.c) and both just use {read,write}b against
  a memory mapped region.  As I am devicetree'ing the TS-7800, this
  driver needs converting and thats what this patchset does.
 
  The patch does the following:
   * remove platform specific ops hooks, moving ioremap'ing and
 everything into the driver
   * utilises named resources to indicate index/data ranges
   * moves the RTC detection routine from ts78xx-setup.c into rtc-m48t86.c
   * and, of course, enable devicetree hooks and include documentation
 
  Awkward step, the first patch breaks both boards, the two following
  patches fix them.  Happy to re-work this if folks give me a pointer
  on how to do this in an acceptable way.
  
  Sorry, that's no good. It breaks things like git bisect.
  
 
  My vote is to break fast, fix fast, spend the time writing other code :)
  
  The patch series will need to be reworked so that there is no
  build/runtime breakage between any of the patches. I'll have a read
  through and see if I can suggest something.
 
 So looking through the patches, you are going to need to modify the rtc
 driver and the platform code in the same patch at least once since you
 are changing the interface. You could break the patches down like this:
 
 1) Move the rtc detection from the orion5x board to the rtc driver.
This adds the detection support for the ep93xx board also.
 
 2) Replace the board read/write ops structure with ioremapped regions.
 
 3) Add the device tree bindings to the rtc driver.
 
 The first two patches could be combined, but will touch both the rtc
 driver and the platform code, and do the prep work needed for adding the
 dt bindings. 

Please keep me and Andrew Lunn in the Cc: and once we see the final
series, I'll ack the platform changes for going though the rtc tree.
It's best to keep this series together, and the changes to the platform
code should be pretty isolated from other changes we are doing.

thx,

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

Re: [PATCH v4 1/6] drivers: phy: add generic PHY framework

2013-04-01 Thread Stephen Warren

On 04/01/2013 04:27 PM, Sylwester Nawrocki wrote:
 On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
 diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt

 +example2:
 +phys: phy {
 +compatible = xxx;
 +reg =...;
 +.
 +.
 +phys =phys 1;
 +.
 +.
 +};
 +
 +This node represents a controller that uses one of the PHYs which is defined
 +previously. Note that the phy handle has an additional specifier 1 to
 +differentiate between the three PHYs. For this case, the controller driver
 +should use of_phy_get_with_args/devm_of_phy_get_with_args.
 
 This means a PHY user needs to know indexes at the PHY driver ?

The client node's DT has to specify which of the provider's PHYs it
references, yes. Presumably the device driver for the client node knows
absolutely nothing about this.

 I have been thinking of using this for an IP which has 4 video PHYs: 2 MIPI
 CSI-2 and 2 MIPI DSI. The IP has just 2 registers, each of which is shared
 between one MIPI CSI-2 DPHY and one MIPI DSI DPHY. So I thought about creating
 a single device node for this IP and using 4 indexes for the PHYs, e.g. 0...3.

That sounds right.

 Then users of each PHY type would use only indexes 0..1 (to select their
 corresponding port).

I don't follow that. If the provider exports PHYs 0..3, then the client
nodes would refer to PHYS 0..3 not 0..1.

 However I fail to see how this could now be represented in the bindings.

Exactly like the example you gave below, I would expect.

 I assume struct phy::type could be used to differentiate between CSI-2 and 
 DSI.
 And struct phy::port could be used to select specific CSI-2 or DSI channel
 (0, 1). Ideally the phy users should not care about index of a PHY at the PHY
 device tree node. E.g. there are 2 MIPI CSI-2 receivers and each has only
 one PHY assigned to it. I'm just wondering how the binding should look like,
 so a PHY could be associated with a receiver automatically by the phy-core,
 e.g.

Details such as phy::type and phy::port sounds like internal driver
implementation details which would have no effect on the bindings.

 /* DPHY IP node */
 video-phy {
   reg = 0x1000 8;
 };
 
 /* MIPI DSI nodes */
 dsi_0 {
  phys = video-phy 0;
 };
 
 dsi_1 {
  phys = video-phy 1;
 };
 
 /* MIPI CSI-2 nodes */
 csi_0 {
  phys = video-phy 2;
 };
 
 csi_1 {
  phys = video-phy 3;
 };

That looks correct to me.

 I'm not sure if it is not an overkill to use this the PHY framework with
 a device which has only 2 registers. Perhaps something less heavy could
 be designed for it. However, if the PHY framework is commonly used there
 should be no issue wrt enabling the whole big infrastructure for a simple
 device like this.

I don't think the number of registers should really makes any
difference; the whole point of the PHY framework is to decouple to
providers and consumers, so doing anything custom for special cases
would completely destroy the ability of the PHY framework to do that.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 1/6] rtc: rtc-m48t86: move m48t86.h to platform_data

The header for the rtc-m48t86 platform-data should be in
include/linux/platform_data.

Signed-off-by: Alexander Clouter a...@digriz.org.uk
---
 arch/arm/mach-ep93xx/ts72xx.c  |2 +-
 arch/arm/mach-orion5x/ts78xx-setup.c   |2 +-
 drivers/rtc/rtc-m48t86.c   |2 +-
 include/linux/{m48t86.h = platform_data/rtc-m48t86.h} |0
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename include/linux/{m48t86.h = platform_data/rtc-m48t86.h} (100%)

diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 61f4b5d..a278639 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -16,7 +16,7 @@
 #include linux/init.h
 #include linux/platform_device.h
 #include linux/io.h
-#include linux/m48t86.h
+#include linux/platform_data/rtc-m48t86.h
 #include linux/mtd/nand.h
 #include linux/mtd/partitions.h
 
diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c 
b/arch/arm/mach-orion5x/ts78xx-setup.c
index e960855..ffe3603 100644
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion5x/ts78xx-setup.c
@@ -16,7 +16,7 @@
 #include linux/platform_device.h
 #include linux/mv643xx_eth.h
 #include linux/ata_platform.h
-#include linux/m48t86.h
+#include linux/platform_data/rtc-m48t86.h
 #include linux/mtd/nand.h
 #include linux/mtd/partitions.h
 #include linux/timeriomem-rng.h
diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
index 2ffbcac..25e0116 100644
--- a/drivers/rtc/rtc-m48t86.c
+++ b/drivers/rtc/rtc-m48t86.c
@@ -16,7 +16,7 @@
 #include linux/module.h
 #include linux/rtc.h
 #include linux/platform_device.h
-#include linux/m48t86.h
+#include linux/platform_data/rtc-m48t86.h
 #include linux/bcd.h
 
 #define M48T86_REG_SEC 0x00
diff --git a/include/linux/m48t86.h b/include/linux/platform_data/rtc-m48t86.h
similarity index 100%
rename from include/linux/m48t86.h
rename to include/linux/platform_data/rtc-m48t86.h
-- 
1.7.10.4

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

[PATCHv2 0/6] add devicetree bindings for rtc-m48t86

Currently there are two users of rtc-m48t86 (mach-ep93xx/ts72xx.c and
mach-orion5x/ts78xx-setup.c) and both just use {read,write}b against
a memory mapped region.  As I am devicetree'ing the TS-7800, this
driver needs converting and thats what this patchset does.

The patch does the following:
 * moves m48t86.h to include/linux/platform_data/rtc-m48t86.h
 * adds a new additional interface to rtc-m48t86 via named
resources that move the ioremap and {read,write}byte
functionality into the driver (usable by ts7[28]xx)
 * moves the RTC detection routine from ts78xx-setup.c into rtc-m48t86.c
 * converts both ts7[28]xx to use the new interface
 * enable devicetree hooks and include documentation

Alexander Clouter (6):
  rtc: rtc-m48t86: move m48t86.h to platform_data
  rtc: rtc-m48t86: add hooks to support driver side memory mapping
  rtc: rtc-m48t86: add detect method for RTC
  arm: orion5x: move ts78xx to use rtc-m48t86 driver side memory
interface
  arm: ep93xx: move ts72xx to use rtc-m48t86 driver side memory
interface
  rtc: rtc-m48t86: add devicetree bindings

 .../devicetree/bindings/rtc/rtc-m48t86.txt |   17 ++
 arch/arm/mach-ep93xx/ts72xx.c  |   38 +--
 arch/arm/mach-orion5x/ts78xx-setup.c   |   78 ++
 drivers/rtc/rtc-m48t86.c   |  285 
 .../linux/{m48t86.h = platform_data/rtc-m48t86.h} |0
 5 files changed, 267 insertions(+), 151 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
 rename include/linux/{m48t86.h = platform_data/rtc-m48t86.h} (100%)

-- 
1.7.10.4

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

[PATCH 2/6] rtc: rtc-m48t86: add hooks to support driver side memory mapping

If platform_data is not defined (as before), then named memory io
ranges need to be defined (rtc_index and rtc_data).  The driver
then maps those regions and uses them as the RTC index and data
addresses.

Does compile with the following warnings, I cannot see the codepath
affected myself:

drivers/rtc/rtc-m48t86.c: In function ‘m48t86_rtc_probe’:
drivers/rtc/rtc-m48t86.c:180: warning: ‘res_index’ may be used uninitialized in 
this function
drivers/rtc/rtc-m48t86.c:180: warning: ‘res_data’ may be used uninitialized in 
this function


Signed-off-by: Alexander Clouter a...@digriz.org.uk
---
 drivers/rtc/rtc-m48t86.c |  230 ++
 1 file changed, 173 insertions(+), 57 deletions(-)

diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
index 25e0116..6f99e64 100644
--- a/drivers/rtc/rtc-m48t86.c
+++ b/drivers/rtc/rtc-m48t86.c
@@ -18,6 +18,8 @@
 #include linux/platform_device.h
 #include linux/platform_data/rtc-m48t86.h
 #include linux/bcd.h
+#include linux/slab.h
+#include linux/io.h
 
 #define M48T86_REG_SEC 0x00
 #define M48T86_REG_SECALRM 0x01
@@ -41,40 +43,71 @@
 
 #define DRV_VERSION 0.1
 
+struct m48t86_rtc_private_data {
+   void __iomem*io_index;
+   void __iomem*io_data;
+
+   struct rtc_device   *rtc;
+   struct m48t86_ops   *ops;
+};
+
+static void m48t86_rtc_writebyte(struct device *dev,
+   unsigned char value, unsigned long addr)
+{
+   struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
+
+   if (priv-ops) {
+   priv-ops-writebyte(value, addr);
+   return;
+   }
+
+   writeb(addr, priv-io_index);
+   writeb(value, priv-io_data);
+}
+
+static unsigned char m48t86_rtc_readbyte(struct device *dev,
+   unsigned long addr)
+{
+   struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
+
+   if (priv-ops)
+   return priv-ops-readbyte(addr);
+
+   writeb(addr, priv-io_index);
+   return readb(priv-io_data);
+}
 
 static int m48t86_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
unsigned char reg;
-   struct platform_device *pdev = to_platform_device(dev);
-   struct m48t86_ops *ops = pdev-dev.platform_data;
 
-   reg = ops-readbyte(M48T86_REG_B);
+   reg = m48t86_rtc_readbyte(dev, M48T86_REG_B);
 
if (reg  M48T86_REG_B_DM) {
/* data (binary) mode */
-   tm-tm_sec  = ops-readbyte(M48T86_REG_SEC);
-   tm-tm_min  = ops-readbyte(M48T86_REG_MIN);
-   tm-tm_hour = ops-readbyte(M48T86_REG_HOUR)  0x3F;
-   tm-tm_mday = ops-readbyte(M48T86_REG_DOM);
+   tm-tm_sec  = m48t86_rtc_readbyte(dev, M48T86_REG_SEC);
+   tm-tm_min  = m48t86_rtc_readbyte(dev, M48T86_REG_MIN);
+   tm-tm_hour = m48t86_rtc_readbyte(dev, M48T86_REG_HOUR)  
0x3F;
+   tm-tm_mday = m48t86_rtc_readbyte(dev, M48T86_REG_DOM);
/* tm_mon is 0-11 */
-   tm-tm_mon  = ops-readbyte(M48T86_REG_MONTH) - 1;
-   tm-tm_year = ops-readbyte(M48T86_REG_YEAR) + 100;
-   tm-tm_wday = ops-readbyte(M48T86_REG_DOW);
+   tm-tm_mon  = m48t86_rtc_readbyte(dev, M48T86_REG_MONTH) - 
1;
+   tm-tm_year = m48t86_rtc_readbyte(dev, M48T86_REG_YEAR) + 
100;
+   tm-tm_wday = m48t86_rtc_readbyte(dev, M48T86_REG_DOW);
} else {
/* bcd mode */
-   tm-tm_sec  = bcd2bin(ops-readbyte(M48T86_REG_SEC));
-   tm-tm_min  = bcd2bin(ops-readbyte(M48T86_REG_MIN));
-   tm-tm_hour = bcd2bin(ops-readbyte(M48T86_REG_HOUR)  
0x3F);
-   tm-tm_mday = bcd2bin(ops-readbyte(M48T86_REG_DOM));
+   tm-tm_sec  = bcd2bin(m48t86_rtc_readbyte(dev, 
M48T86_REG_SEC));
+   tm-tm_min  = bcd2bin(m48t86_rtc_readbyte(dev, 
M48T86_REG_MIN));
+   tm-tm_hour = bcd2bin(m48t86_rtc_readbyte(dev, 
M48T86_REG_HOUR)  0x3F);
+   tm-tm_mday = bcd2bin(m48t86_rtc_readbyte(dev, 
M48T86_REG_DOM));
/* tm_mon is 0-11 */
-   tm-tm_mon  = bcd2bin(ops-readbyte(M48T86_REG_MONTH)) - 1;
-   tm-tm_year = bcd2bin(ops-readbyte(M48T86_REG_YEAR)) + 100;
-   tm-tm_wday = bcd2bin(ops-readbyte(M48T86_REG_DOW));
+   tm-tm_mon  = bcd2bin(m48t86_rtc_readbyte(dev, 
M48T86_REG_MONTH)) - 1;
+   tm-tm_year = bcd2bin(m48t86_rtc_readbyte(dev, 
M48T86_REG_YEAR)) + 100;
+   tm-tm_wday = bcd2bin(m48t86_rtc_readbyte(dev, 
M48T86_REG_DOW));
}
 
/* correct the hour if the clock is in 12h mode */
if (!(reg  M48T86_REG_B_H24))
-   if (ops-readbyte(M48T86_REG_HOUR)  0x80)
+   if (m48t86_rtc_readbyte(dev, M48T86_REG_HOUR)

[PATCH 3/6] rtc: rtc-m48t86: add detect method for RTC

The m48t86 has 114 bytes of user space available, so we can use this
space to detect for the presence of the RTC.

Signed-off-by: Alexander Clouter a...@digriz.org.uk
---
 drivers/rtc/rtc-m48t86.c |   43 +++
 1 file changed, 43 insertions(+)

diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
index 6f99e64..b8edf73 100644
--- a/drivers/rtc/rtc-m48t86.c
+++ b/drivers/rtc/rtc-m48t86.c
@@ -173,6 +173,41 @@ static const struct rtc_class_ops m48t86_rtc_ops = {
.proc   = m48t86_rtc_proc,
 };
 
+/*
+ * The RTC chip has 114 bytes upper bytes that can be used as user storage
+ * space which we can use to test if the chip is present; for example it is
+ * an optional feature and not all boards will have it present.
+ *
+ * I've used the method Technologic Systems use in their rtc7800.c example
+ * for the detection.
+ *
+ * TODO: track down a guinea pig without an RTC to see if we can work out a
+ * better RTC detection routine
+ */
+static int m48t86_rtc_detect(struct device *dev)
+{
+   unsigned char tmp_rtc0, tmp_rtc1;
+
+   tmp_rtc0 = m48t86_rtc_readbyte(dev, 126);
+   tmp_rtc1 = m48t86_rtc_readbyte(dev, 127);
+
+   m48t86_rtc_writebyte(dev, 0x00, 126);
+   m48t86_rtc_writebyte(dev, 0x55, 127);
+   if (m48t86_rtc_readbyte(dev, 127) == 0x55) {
+   m48t86_rtc_writebyte(dev, 0xaa, 127);
+   if (m48t86_rtc_readbyte(dev, 127) == 0xaa
+m48t86_rtc_readbyte(dev, 126) == 0x00) {
+   m48t86_rtc_writebyte(dev, tmp_rtc0, 126);
+   m48t86_rtc_writebyte(dev, tmp_rtc1, 127);
+
+   return 0;
+   }
+   }
+
+   dev_info(dev, RTC not found\n);
+   return -ENODEV;
+}
+
 static int m48t86_rtc_probe(struct platform_device *pdev)
 {
unsigned char reg;
@@ -232,6 +267,14 @@ static int m48t86_rtc_probe(struct platform_device *pdev)
} else
priv-ops = pdev-dev.platform_data;
 
+   err = m48t86_rtc_detect(pdev-dev);
+   if (err) {
+   if (!pdev-dev.platform_data)
+   goto out_io_data;
+   else
+   goto out_free;
+   }
+
priv-rtc = rtc_device_register(m48t86,
pdev-dev, m48t86_rtc_ops, THIS_MODULE);
if (IS_ERR(priv-rtc)) {
-- 
1.7.10.4

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

[PATCH 4/6] arm: orion5x: move ts78xx to use rtc-m48t86 driver side memory interface

Remove platform_data hooks into rtc-m48t86 and use named resource regions.

Signed-off-by: Alexander Clouter a...@digriz.org.uk
---
 arch/arm/mach-orion5x/ts78xx-setup.c |   78 --
 1 file changed, 17 insertions(+), 61 deletions(-)

diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c 
b/arch/arm/mach-orion5x/ts78xx-setup.c
index ffe3603..613216f 100644
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion5x/ts78xx-setup.c
@@ -16,7 +16,6 @@
 #include linux/platform_device.h
 #include linux/mv643xx_eth.h
 #include linux/ata_platform.h
-#include linux/platform_data/rtc-m48t86.h
 #include linux/mtd/nand.h
 #include linux/mtd/partitions.h
 #include linux/timeriomem-rng.h
@@ -80,78 +79,35 @@ static struct mv_sata_platform_data ts78xx_sata_data = {
 /*
  * RTC M48T86 - nicked^Wborrowed from arch/arm/mach-ep93xx/ts72xx.c
  /
-#define TS_RTC_CTRL(TS78XX_FPGA_REGS_VIRT_BASE + 0x808)
-#define TS_RTC_DATA(TS78XX_FPGA_REGS_VIRT_BASE + 0x80c)
+#define TS_RTC_INDEX   (TS78XX_FPGA_REGS_PHYS_BASE + 0x808)
+#define TS_RTC_DATA(TS78XX_FPGA_REGS_PHYS_BASE + 0x80c)
 
-static unsigned char ts78xx_ts_rtc_readbyte(unsigned long addr)
-{
-   writeb(addr, TS_RTC_CTRL);
-   return readb(TS_RTC_DATA);
-}
-
-static void ts78xx_ts_rtc_writebyte(unsigned char value, unsigned long addr)
-{
-   writeb(addr, TS_RTC_CTRL);
-   writeb(value, TS_RTC_DATA);
-}
-
-static struct m48t86_ops ts78xx_ts_rtc_ops = {
-   .readbyte   = ts78xx_ts_rtc_readbyte,
-   .writebyte  = ts78xx_ts_rtc_writebyte,
+static struct resource ts78xx_ts_rtc_resource[] = {
+   DEFINE_RES_NAMED(TS_RTC_INDEX, 4, rtc_index, IORESOURCE_MEM),
+   DEFINE_RES_NAMED(TS_RTC_DATA, 4, rtc_data, IORESOURCE_MEM),
 };
 
 static struct platform_device ts78xx_ts_rtc_device = {
.name   = rtc-m48t86,
.id = -1,
-   .dev= {
-   .platform_data  = ts78xx_ts_rtc_ops,
-   },
-   .num_resources  = 0,
+   .resource   = ts78xx_ts_rtc_resource,
+   .num_resources  = ARRAY_SIZE(ts78xx_ts_rtc_resource),
 };
 
-/*
- * TS uses some of the user storage space on the RTC chip so see if it is
- * present; as it's an optional feature at purchase time and not all boards
- * will have it present
- *
- * I've used the method TS use in their rtc7800.c example for the detection
- *
- * TODO: track down a guinea pig without an RTC to see if we can work out a
- * better RTC detection routine
- */
 static int ts78xx_ts_rtc_load(void)
 {
int rc;
-   unsigned char tmp_rtc0, tmp_rtc1;
-
-   tmp_rtc0 = ts78xx_ts_rtc_readbyte(126);
-   tmp_rtc1 = ts78xx_ts_rtc_readbyte(127);
-
-   ts78xx_ts_rtc_writebyte(0x00, 126);
-   ts78xx_ts_rtc_writebyte(0x55, 127);
-   if (ts78xx_ts_rtc_readbyte(127) == 0x55) {
-   ts78xx_ts_rtc_writebyte(0xaa, 127);
-   if (ts78xx_ts_rtc_readbyte(127) == 0xaa
-ts78xx_ts_rtc_readbyte(126) == 0x00) {
-   ts78xx_ts_rtc_writebyte(tmp_rtc0, 126);
-   ts78xx_ts_rtc_writebyte(tmp_rtc1, 127);
-
-   if (ts78xx_fpga.supports.ts_rtc.init == 0) {
-   rc = 
platform_device_register(ts78xx_ts_rtc_device);
-   if (!rc)
-   ts78xx_fpga.supports.ts_rtc.init = 1;
-   } else
-   rc = platform_device_add(ts78xx_ts_rtc_device);
-
-   if (rc)
-   pr_info(RTC could not be registered: %d\n,
-   rc);
-   return rc;
-   }
-   }
 
-   pr_info(RTC not found\n);
-   return -ENODEV;
+   if (ts78xx_fpga.supports.ts_rtc.init == 0) {
+   rc = platform_device_register(ts78xx_ts_rtc_device);
+   if (!rc)
+   ts78xx_fpga.supports.ts_rtc.init = 1;
+   } else
+   rc = platform_device_add(ts78xx_ts_rtc_device);
+
+   if (rc)
+   pr_info(RTC could not be registered: %d\n, rc);
+   return rc;
 };
 
 static void ts78xx_ts_rtc_unload(void)
-- 
1.7.10.4

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

[PATCH 5/6] arm: ep93xx: move ts72xx to use rtc-m48t86 driver side memory interface

Remove platform_data hooks into rtc-m48t86 and use named resource regions.

Signed-off-by: Alexander Clouter a...@digriz.org.uk
---
 arch/arm/mach-ep93xx/ts72xx.c |   38 +++---
 1 file changed, 7 insertions(+), 31 deletions(-)

diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index a278639..baadffd 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -16,7 +16,6 @@
 #include linux/init.h
 #include linux/platform_device.h
 #include linux/io.h
-#include linux/platform_data/rtc-m48t86.h
 #include linux/mtd/nand.h
 #include linux/mtd/partitions.h
 
@@ -45,16 +44,6 @@ static struct map_desc ts72xx_io_desc[] __initdata = {
.pfn= __phys_to_pfn(TS72XX_OPTIONS2_PHYS_BASE),
.length = TS72XX_OPTIONS2_SIZE,
.type   = MT_DEVICE,
-   }, {
-   .virtual= (unsigned long)TS72XX_RTC_INDEX_VIRT_BASE,
-   .pfn= __phys_to_pfn(TS72XX_RTC_INDEX_PHYS_BASE),
-   .length = TS72XX_RTC_INDEX_SIZE,
-   .type   = MT_DEVICE,
-   }, {
-   .virtual= (unsigned long)TS72XX_RTC_DATA_VIRT_BASE,
-   .pfn= __phys_to_pfn(TS72XX_RTC_DATA_PHYS_BASE),
-   .length = TS72XX_RTC_DATA_SIZE,
-   .type   = MT_DEVICE,
}
 };
 
@@ -179,31 +168,18 @@ static void __init ts72xx_register_flash(void)
}
 }
 
-
-static unsigned char ts72xx_rtc_readbyte(unsigned long addr)
-{
-   __raw_writeb(addr, TS72XX_RTC_INDEX_VIRT_BASE);
-   return __raw_readb(TS72XX_RTC_DATA_VIRT_BASE);
-}
-
-static void ts72xx_rtc_writebyte(unsigned char value, unsigned long addr)
-{
-   __raw_writeb(addr, TS72XX_RTC_INDEX_VIRT_BASE);
-   __raw_writeb(value, TS72XX_RTC_DATA_VIRT_BASE);
-}
-
-static struct m48t86_ops ts72xx_rtc_ops = {
-   .readbyte   = ts72xx_rtc_readbyte,
-   .writebyte  = ts72xx_rtc_writebyte,
+static struct resource ts72xx_rtc_resource[] = {
+   DEFINE_RES_NAMED(TS72XX_RTC_INDEX_PHYS_BASE, 4,
+   rtc_index, IORESOURCE_MEM),
+   DEFINE_RES_NAMED(TS72XX_RTC_DATA_PHYS_BASE, 4,
+   rtc_data, IORESOURCE_MEM),
 };
 
 static struct platform_device ts72xx_rtc_device = {
.name   = rtc-m48t86,
.id = -1,
-   .dev= {
-   .platform_data  = ts72xx_rtc_ops,
-   },
-   .num_resources  = 0,
+   .resource   = ts72xx_rtc_resource,
+   .num_resources  = ARRAY_SIZE(ts72xx_rtc_resource),
 };
 
 static struct resource ts72xx_wdt_resources[] = {
-- 
1.7.10.4

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

[PATCH 6/6] rtc: rtc-m48t86: add devicetree bindings

Add devicetree bindings (and documentation) for rtc-m48t86.

Signed-off-by: Alexander Clouter a...@digriz.org.uk
---
 Documentation/devicetree/bindings/rtc/rtc-m48t86.txt |   17 +
 drivers/rtc/rtc-m48t86.c |   12 ++--
 2 files changed, 27 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-m48t86.txt

diff --git a/Documentation/devicetree/bindings/rtc/rtc-m48t86.txt 
b/Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
new file mode 100644
index 000..375ea56
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-m48t86.txt
@@ -0,0 +1,17 @@
+RTC support for the rtc-m48t86 driver
+
+Required properties:
+- compatible : rtc-m48t86
+- reg : Array of base physical addresses for the RTC control and data
+- reg-names : must have rtc_index and rtc_data
+
+Example:
+
+rtc@808 {
+   #address-cells = 1;
+   #size-cells = 1;
+   compatible = rtc-m48t86;
+   reg =   0x808 0x04,
+   0x80c 0x04;
+   reg-names = rtc_index, rtc_data;
+};
diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
index b8edf73..9395126 100644
--- a/drivers/rtc/rtc-m48t86.c
+++ b/drivers/rtc/rtc-m48t86.c
@@ -20,6 +20,7 @@
 #include linux/bcd.h
 #include linux/slab.h
 #include linux/io.h
+#include linux/of.h
 
 #define M48T86_REG_SEC 0x00
 #define M48T86_REG_SECALRM 0x01
@@ -335,10 +336,17 @@ static int m48t86_rtc_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct of_device_id m48t86_rtc_match[] = {
+   { .compatible = rtc-m48t86 },
+   {},
+};
+MODULE_DEVICE_TABLE(of, m48t86_rtc_match);
+
 static struct platform_driver m48t86_rtc_platform_driver = {
.driver = {
-   .name   = rtc-m48t86,
-   .owner  = THIS_MODULE,
+   .name   = rtc-m48t86,
+   .owner  = THIS_MODULE,
+   .of_match_table = m48t86_rtc_match,
},
.probe  = m48t86_rtc_probe,
.remove = m48t86_rtc_remove,
-- 
1.7.10.4

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

Re: [PATCH 2/6] rtc: rtc-m48t86: add hooks to support driver side memory mapping

On 02/04/13 10:22, Alexander Clouter wrote:
 If platform_data is not defined (as before), then named memory io
 ranges need to be defined (rtc_index and rtc_data).  The driver
 then maps those regions and uses them as the RTC index and data
 addresses.
 
 Does compile with the following warnings, I cannot see the codepath
 affected myself:
 
 drivers/rtc/rtc-m48t86.c: In function ‘m48t86_rtc_probe’:
 drivers/rtc/rtc-m48t86.c:180: warning: ‘res_index’ may be used uninitialized 
 in this function
 drivers/rtc/rtc-m48t86.c:180: warning: ‘res_data’ may be used uninitialized 
 in this function

It is caused by the exit paths. If pdev-dev.platform_data is set, the
res_index and res_data are never initialised, but in the error case you
still for rtc_device_register you jump to out_io_data, which will then
dereference res_index/res_data. You need to make the exit paths
conditional on pdev-dev.platform_data (or init res_index/data to NULL
and make the release_mem_regions conditional on that).

~Ryan

 
 
 Signed-off-by: Alexander Clouter a...@digriz.org.uk
 ---
  drivers/rtc/rtc-m48t86.c |  230 
 ++
  1 file changed, 173 insertions(+), 57 deletions(-)
 
 diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
 index 25e0116..6f99e64 100644
 --- a/drivers/rtc/rtc-m48t86.c
 +++ b/drivers/rtc/rtc-m48t86.c
 @@ -18,6 +18,8 @@
  #include linux/platform_device.h
  #include linux/platform_data/rtc-m48t86.h
  #include linux/bcd.h
 +#include linux/slab.h
 +#include linux/io.h
  
  #define M48T86_REG_SEC   0x00
  #define M48T86_REG_SECALRM   0x01
 @@ -41,40 +43,71 @@
  
  #define DRV_VERSION 0.1
  
 +struct m48t86_rtc_private_data {
 + void __iomem*io_index;
 + void __iomem*io_data;
 +
 + struct rtc_device   *rtc;
 + struct m48t86_ops   *ops;
 +};
 +
 +static void m48t86_rtc_writebyte(struct device *dev,
 + unsigned char value, unsigned long addr)
 +{
 + struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
 +
 + if (priv-ops) {
 + priv-ops-writebyte(value, addr);
 + return;
 + }
 +
 + writeb(addr, priv-io_index);
 + writeb(value, priv-io_data);
 +}
 +
 +static unsigned char m48t86_rtc_readbyte(struct device *dev,
 + unsigned long addr)
 +{
 + struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
 +
 + if (priv-ops)
 + return priv-ops-readbyte(addr);
 +
 + writeb(addr, priv-io_index);
 + return readb(priv-io_data);
 +}
  
  static int m48t86_rtc_read_time(struct device *dev, struct rtc_time *tm)
  {
   unsigned char reg;
 - struct platform_device *pdev = to_platform_device(dev);
 - struct m48t86_ops *ops = pdev-dev.platform_data;
  
 - reg = ops-readbyte(M48T86_REG_B);
 + reg = m48t86_rtc_readbyte(dev, M48T86_REG_B);
  
   if (reg  M48T86_REG_B_DM) {
   /* data (binary) mode */
 - tm-tm_sec  = ops-readbyte(M48T86_REG_SEC);
 - tm-tm_min  = ops-readbyte(M48T86_REG_MIN);
 - tm-tm_hour = ops-readbyte(M48T86_REG_HOUR)  0x3F;
 - tm-tm_mday = ops-readbyte(M48T86_REG_DOM);
 + tm-tm_sec  = m48t86_rtc_readbyte(dev, M48T86_REG_SEC);
 + tm-tm_min  = m48t86_rtc_readbyte(dev, M48T86_REG_MIN);
 + tm-tm_hour = m48t86_rtc_readbyte(dev, M48T86_REG_HOUR)  
 0x3F;
 + tm-tm_mday = m48t86_rtc_readbyte(dev, M48T86_REG_DOM);
   /* tm_mon is 0-11 */
 - tm-tm_mon  = ops-readbyte(M48T86_REG_MONTH) - 1;
 - tm-tm_year = ops-readbyte(M48T86_REG_YEAR) + 100;
 - tm-tm_wday = ops-readbyte(M48T86_REG_DOW);
 + tm-tm_mon  = m48t86_rtc_readbyte(dev, M48T86_REG_MONTH) - 
 1;
 + tm-tm_year = m48t86_rtc_readbyte(dev, M48T86_REG_YEAR) + 
 100;
 + tm-tm_wday = m48t86_rtc_readbyte(dev, M48T86_REG_DOW);
   } else {
   /* bcd mode */
 - tm-tm_sec  = bcd2bin(ops-readbyte(M48T86_REG_SEC));
 - tm-tm_min  = bcd2bin(ops-readbyte(M48T86_REG_MIN));
 - tm-tm_hour = bcd2bin(ops-readbyte(M48T86_REG_HOUR)  
 0x3F);
 - tm-tm_mday = bcd2bin(ops-readbyte(M48T86_REG_DOM));
 + tm-tm_sec  = bcd2bin(m48t86_rtc_readbyte(dev, 
 M48T86_REG_SEC));
 + tm-tm_min  = bcd2bin(m48t86_rtc_readbyte(dev, 
 M48T86_REG_MIN));
 + tm-tm_hour = bcd2bin(m48t86_rtc_readbyte(dev, 
 M48T86_REG_HOUR)  0x3F);
 + tm-tm_mday = bcd2bin(m48t86_rtc_readbyte(dev, 
 M48T86_REG_DOM));
   /* tm_mon is 0-11 */
 - tm-tm_mon  = bcd2bin(ops-readbyte(M48T86_REG_MONTH)) - 1;
 - tm-tm_year = bcd2bin(ops-readbyte(M48T86_REG_YEAR)) + 100;
 - tm-tm_wday = bcd2bin(ops-readbyte(M48T86_REG_DOW));
 + tm-tm_mon

Re: [PATCH 2/6] rtc: rtc-m48t86: add hooks to support driver side memory mapping


On Tue, Apr 02, 2013 at 10:36:43AM +1100, Ryan Mallon wrote:

On 02/04/13 10:22, Alexander Clouter wrote:

If platform_data is not defined (as before), then named memory io
ranges need to be defined (rtc_index and rtc_data).  The driver
then maps those regions and uses them as the RTC index and data
addresses.

Does compile with the following warnings, I cannot see the codepath
affected myself:

drivers/rtc/rtc-m48t86.c: In function ‘m48t86_rtc_probe’:
drivers/rtc/rtc-m48t86.c:180: warning: ‘res_index’ may be used uninitialized in 
this function
drivers/rtc/rtc-m48t86.c:180: warning: ‘res_data’ may be used uninitialized in 
this function


It is caused by the exit paths. If pdev-dev.platform_data is set, the
res_index and res_data are never initialised, but in the error case you
still for rtc_device_register you jump to out_io_data, which will then
dereference res_index/res_data. You need to make the exit paths
conditional on pdev-dev.platform_data (or init res_index/data to NULL
and make the release_mem_regions conditional on that).


However, the 'goto out_io_data' in the 'IS_ERR(priv-rtc)' is wrapped in a 'if 
(!pdev-dev.platform_data)', else we jump to out_free.


I suspect I am probably missing something *too* obvious here for it to click?

Cheers


+   priv-rtc = rtc_device_register(m48t86,
+   pdev-dev, m48t86_rtc_ops, THIS_MODULE);
+   if (IS_ERR(priv-rtc)) {--
+   err = PTR_ERR(priv-rtc);
+   if (!pdev-dev.platform_data)   --
+   goto out_io_data;
+   else
+   goto out_free;
+   }

/* read battery status */
-   reg = ops-readbyte(M48T86_REG_D);
-   dev_info(dev-dev, battery %s\n,
+   reg = m48t86_rtc_readbyte(pdev-dev, M48T86_REG_D);
+   dev_info(pdev-dev, battery %s\n,
(reg  M48T86_REG_D_VRT) ? ok : exhausted);

return 0;
+
+out_io_data:
+   iounmap(priv-io_data);
+out_io_index:
+   iounmap(priv-io_index);
+out_release_data:
+   release_mem_region(res_data-start, resource_size(res_data));
+out_release_index:
+   release_mem_region(res_index-start, resource_size(res_index));
+out_free:
+   platform_set_drvdata(pdev, NULL);
+   kfree(priv);
+   return err;
 }


--
Alexander Clouter
.sigmonster says: Zeus gave Leda the bird.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: How to represent negative values for device tree property

2013-04-01 Thread David Collins

On 04/01/2013 03:00 PM, Stephen Warren wrote:
 On 04/01/2013 03:08 PM, David Collins wrote:
 Hi,

 I am working on a thermal driver which needs to be able to read a
 temperature threshold from a device tree property.  The hardware supports
 thresholds in the range -204.8 to +204.7 C in 0.1 C steps.  I have found,
 as I am sure others have as well, that dtc treats a '-' before an integer
 in a dtsi file as a syntax error.  Therefore, I need some artificial way
 to represent negative numbers in device tree.  Here are the possibilities
 that I have thought of so far:
 
 Doesn't the very latest dtc, which contains integer expression support,
 allow unary -? I thought that code had been imported into the kernel
 (goes and checks) yes it has. What's the error you're seeing;
 over/underflow or syntax?
 
 That said, DT cells are supposed to be u32 not s32, so perhaps this
 isn't unexpected.

It is likely that my dtc version is out of date.  dtc -v outputs 1.2.0.  I
will try updating to a newer version of dtc.  The error that I currently
get is a syntax error: FATAL ERROR: Unable to parse input tree.

Does the device tree binary documentation define any format for negative
numbers?  Unsigned 32-bit integers are clearly defined as bytes in
big-endian order.  I suppose that you could assume 32-bit signed integers
are 2's complement with bytes in big-endian order, but that would need to
be well defined somewhere.

Assuming that dtb has no well defined means of holding a negative integer
value, then what is the most elegant workaround to specify a negative value?

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] bcm2835: Add Broadcom BCM2835 RNG to the device tree

2013-04-01 Thread Stephen Warren

On 03/28/2013 12:12 AM, Lubomir Rintel wrote:
 This adds a device tree binding for random number generator present on 
 Broadcom
 BCM2835 SoC, used in Raspberry Pi and Roku 2 devices.

FYI, I intend to apply this patch to the bcm2835 tree whenever the RNG
driver itself is applied to the hw_random tree. If you could ping me
when that happens to jog my memory, that'd be great. Thanks.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V2] DMA: PL330: Add check if device tree compatible

2013-04-01 Thread Padma Venkat

Hi Vinod,

I apologies for the delayed reply. Last week I was out of station and
no access to mails. I will send another patch addressing your
comments.

Thanks
Padma
On Mon, Apr 1, 2013 at 11:51 PM, Vinod Koul vinod.k...@intel.com wrote:

 On Mon, Apr 01, 2013 at 08:13:31AM -0500, Rob Herring wrote:
  On Thu, Mar 21, 2013 at 4:39 AM, Vinod Koul vinod.k...@intel.com wrote:
   On Tue, Mar 05, 2013 at 02:55:31PM +0530, Padmavathi Venna wrote:
   This patch register the dma controller with generic dma helpers only
   in DT case. This also adds some extra error handling in the driver.
  
   Signed-off-by: Padmavathi Venna padm...@samsung.com
   Reported-by: Sachin Kamat sachin.ka...@linaro.org
 
  What's the status on this? It is needed for 3.9 to fix pl330 on highbank.
 Well the status is that submitter has been rude. I had few questions and
 comments on this patch and they are yet to be addressed.

 --
 ~Vinod
 
  Rob
 
   ---
  
   Based on Vinod Koul next branch.
  
   Changes since V1:
 - return silently when of_dma_controller_register fails, as
   suggested by Arnd.
  
drivers/dma/pl330.c |   38 +++---
1 files changed, 27 insertions(+), 11 deletions(-)
  
   diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
   index 7181531..5dbc594 100644
   --- a/drivers/dma/pl330.c
   +++ b/drivers/dma/pl330.c
   @@ -2882,7 +2882,7 @@ pl330_probe(struct amba_device *adev, const struct 
   amba_id *id)
{
 struct dma_pl330_platdata *pdat;
 struct dma_pl330_dmac *pdmac;
   - struct dma_pl330_chan *pch;
   + struct dma_pl330_chan *pch, *_p;
 struct pl330_info *pi;
 struct dma_device *pd;
 struct resource *res;
   @@ -2984,7 +2984,16 @@ pl330_probe(struct amba_device *adev, const 
   struct amba_id *id)
 ret = dma_async_device_register(pd);
 if (ret) {
 dev_err(adev-dev, unable to register DMAC\n);
   - goto probe_err2;
   + goto probe_err3;
   + }
   +
   + if (adev-dev.of_node) {
   + ret = of_dma_controller_register(adev-dev.of_node,
   +  of_dma_pl330_xlate, pdmac);
   + if (ret) {
   + dev_err(adev-dev,
   + unable to register DMA to the generic DT DMA 
   helpers\n);
   Indent?

Okey.

   + }
 }
  
 dev_info(adev-dev,
   @@ -2995,16 +3004,21 @@ pl330_probe(struct amba_device *adev, const 
   struct amba_id *id)
 pi-pcfg.data_bus_width / 8, pi-pcfg.num_chan,
 pi-pcfg.num_peri, pi-pcfg.num_events);
  
   - ret = of_dma_controller_register(adev-dev.of_node,
   -  of_dma_pl330_xlate, pdmac);
   - if (ret) {
   - dev_err(adev-dev,
   - unable to register DMA to the generic DT DMA helpers\n);
   - goto probe_err2;
   - }
   -
 return 0;
   +probe_err3:
   + amba_set_drvdata(adev, NULL);
  
   + /* Idle the DMAC */
   + list_for_each_entry_safe(pch, _p, pdmac-ddma.channels,
   + chan.device_node) {
   +
   + /* Remove the channel */
   + list_del(pch-chan.device_node);
   +
   + /* Flush the channel */
   + pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
   + pl330_free_chan_resources(pch-chan);
   free_chan for error handling in probe?


Will remove this.

  

   + }
probe_err2:
 pl330_del(pi);
probe_err1:
   @@ -3023,8 +3037,10 @@ static int pl330_remove(struct amba_device *adev)
 if (!pdmac)
 return 0;
  
   - of_dma_controller_free(adev-dev.of_node);
   + if (adev-dev.of_node)
   + of_dma_controller_free(adev-dev.of_node);
  
   + dma_async_device_unregister(pdmac-ddma);
 amba_set_drvdata(adev, NULL);
  
 /* Idle the DMAC */
   --
   1.7.4.4
  
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 2/6] rtc: rtc-m48t86: add hooks to support driver side memory mapping

On 02/04/13 10:22, Alexander Clouter wrote:
 If platform_data is not defined (as before), then named memory io
 ranges need to be defined (rtc_index and rtc_data).  The driver
 then maps those regions and uses them as the RTC index and data
 addresses.
 
 Does compile with the following warnings, I cannot see the codepath
 affected myself:
 
 drivers/rtc/rtc-m48t86.c: In function ‘m48t86_rtc_probe’:
 drivers/rtc/rtc-m48t86.c:180: warning: ‘res_index’ may be used uninitialized 
 in this function
 drivers/rtc/rtc-m48t86.c:180: warning: ‘res_data’ may be used uninitialized 
 in this function
 
 
 Signed-off-by: Alexander Clouter a...@digriz.org.uk
 ---
  drivers/rtc/rtc-m48t86.c |  230 
 ++
  1 file changed, 173 insertions(+), 57 deletions(-)
 
 diff --git a/drivers/rtc/rtc-m48t86.c b/drivers/rtc/rtc-m48t86.c
 index 25e0116..6f99e64 100644
 --- a/drivers/rtc/rtc-m48t86.c
 +++ b/drivers/rtc/rtc-m48t86.c
 @@ -18,6 +18,8 @@
  #include linux/platform_device.h
  #include linux/platform_data/rtc-m48t86.h
  #include linux/bcd.h
 +#include linux/slab.h
 +#include linux/io.h
  
  #define M48T86_REG_SEC   0x00
  #define M48T86_REG_SECALRM   0x01
 @@ -41,40 +43,71 @@
  
  #define DRV_VERSION 0.1
  
 +struct m48t86_rtc_private_data {
 + void __iomem*io_index;
 + void __iomem*io_data;
 +
 + struct rtc_device   *rtc;
 + struct m48t86_ops   *ops;
 +};
 +
 +static void m48t86_rtc_writebyte(struct device *dev,
 + unsigned char value, unsigned long addr)
 +{
 + struct m48t86_rtc_private_data *priv = dev_get_drvdata(dev);
 +
 + if (priv-ops) {
 + priv-ops-writebyte(value, addr);
 + return;
 + }
 +
 + writeb(addr, priv-io_index);
 + writeb(value, priv-io_data);
 +}
 +
 +static unsigned char m48t86_rtc_readbyte(struct device *dev,
 + unsigned long addr)

The read/writebyte functions should return a u8 and take a u8 for the
address (since you are using readb/writeb). For the temporary step which
still has the ops structure, you can explicitly cast addr to unsigned
long if you want to make it obvious that the old api was silly.

~Ryan

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

Re: [PATCH 2/6] rtc: rtc-m48t86: add hooks to support driver side memory mapping