Re: [PATCH 5/9] drm/exynos: add support for exynos5420 mixer

2013-06-14 Thread 김승우
Hello Rahul, This patch looks good to me just with mixer part of 2nd patch because there is no hdmiphy related things. On 2013년 06월 11일 23:11, Rahul Sharma wrote: > Add support for exynos5420 mixer IP in the drm mixer driver. > > Signed-off-by: Rahul Sharma > --- > drivers/gpu/drm/exynos/exyno

[PATCH v2] extcon: Add an API to get extcon device from dt node

2013-06-14 Thread Chanwoo Choi
From: Kishon Vijay Abraham I Added an API of_extcon_get_extcon_dev() to be used by drivers to get extcon device in the case of dt boot (this can be used instead of extcon_get_extcon_dev()). Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Chanwoo Choi Signed-off-by: Myungjoo Ham --- Chang

Re: [PATCH v2 07/11] ARM:stixxxx: Add STiH416 SOC support

2013-06-14 Thread Srinivas KANDAGATLA
On 10/06/13 14:52, Arnd Bergmann wrote: > On Monday 10 June 2013 10:27:05 Srinivas KANDAGATLA wrote: > >> > + soc { >> > + pin-controller-sbc { >> > + #address-cells = <1>; >> > + #size-cells = <1>; >> > + compatible = "st,stih

Re: [PATCH 7/9] drm/exynos: use of_get_named_gpio to get hdmi hpd gpio

2013-06-14 Thread 김승우
Hello Rahul, this patch is not related with others and it looks good to me. On 2013년 06월 11일 23:11, Rahul Sharma wrote: > Cleanup by removing flags variable from drm_hdmi_dt_parse_pdata > which is not used anywhere. Swtiching to of_get_named_gpio instead > of of_get_named_gpio_flags solved this.

Re: [PATCH v2 06/11] ARM:stixxxx: Add STiH415 SOC support

2013-06-14 Thread Srinivas KANDAGATLA
On 10/06/13 17:38, Srinivas Kandagatla wrote: >> +++ b/arch/arm/boot/dts/sti-pincfg.h >> >> @@ -0,0 +1,94 @@ >> >> +#ifndef _STI_PINCFG_H_ >> >> +#define _STI_PINCFG_H_ >> >> + >> >> +/* Alternate functions */ >> >> +#define ALT1 1 >> >> +#define ALT2 2 >> >> +#define ALT3 3 >> >>

Re: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos

2013-06-14 Thread Jingoo Han
On Thursday, June 13, 2013 11:14 PM, Arnd Bergmann wrote: > On Thursday 13 June 2013 22:22:31 Jingoo Han wrote: > > > +struct pcie_port_info { > > + u32 cfg0_size; > > + u32 cfg1_size; > > + u32 io_size; > > + u32 mem_size; > > + phys_addr_

Re: [PATCH v2 1/3] ARM: tegra: basic support for Trusted Foundations

2013-06-14 Thread Alexandre Courbot
On Fri, Jun 14, 2013 at 4:19 AM, Stephen Warren wrote: > On 06/13/2013 03:12 AM, Alexandre Courbot wrote: >> Add basic support for booting secondary processors on Tegra devices >> using the Trusted Foundations secure monitor. >> >> Signed-off-by: Alexandre Courbot >> --- >> Documentation/devicet

Re: [PATCH v2] extcon: Add an API to get extcon device from dt node

2013-06-14 Thread Kishon Vijay Abraham I
Hi, On Friday 14 June 2013 12:45 PM, Chanwoo Choi wrote: From: Kishon Vijay Abraham I Added an API of_extcon_get_extcon_dev() to be used by drivers to get extcon device in the case of dt boot (this can be used instead of extcon_get_extcon_dev()). Signed-off-by: Kishon Vijay Abraham I Signed-

Re: [PATCH v2 1/3] ARM: tegra: basic support for Trusted Foundations

2013-06-14 Thread Alexandre Courbot
On Thu, Jun 13, 2013 at 11:35 PM, Dave Martin wrote: >> diff --git a/Documentation/devicetree/bindings/arm/tegra.txt >> b/Documentation/devicetree/bindings/arm/tegra.txt >> index ed9c853..d59bc19 100644 >> --- a/Documentation/devicetree/bindings/arm/tegra.txt >> +++ b/Documentation/devicetree/bin

Re: [PATCH v2 2/3] ARM: tegra: split setting of CPU reset handler

2013-06-14 Thread Alexandre Courbot
On Fri, Jun 14, 2013 at 4:21 AM, Stephen Warren wrote: > On 06/13/2013 03:12 AM, Alexandre Courbot wrote: >> Not all Tegra devices need to set the CPU reset handler in the same way. > > s/need/can/ ? Fixed, thanks! Alex. ___ devicetree-discuss mailing l

Re: [PATCH v2] extcon: Add an API to get extcon device from dt node

2013-06-14 Thread Chanwoo Choi
On 06/14/2013 05:36 PM, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 14 June 2013 12:45 PM, Chanwoo Choi wrote: >> From: Kishon Vijay Abraham I >> >> Added an API of_extcon_get_extcon_dev() to be used by drivers to get >> extcon device in the case of dt boot (this can be used instead of >> e

Re: [PATCH v2 3/3] ARM: tegra: set CPU reset handler with firmware op

2013-06-14 Thread Alexandre Courbot
On Fri, Jun 14, 2013 at 4:23 AM, Stephen Warren wrote: > On 06/13/2013 03:12 AM, Alexandre Courbot wrote: >> Use a firmware operation to set the CPU reset handler and only resort to >> doing it ourselves if there is none defined. >> >> This supports the booting of secondary CPUs on devices using a

[PATCH v2 0/4] GPIO DT support for da850

2013-06-14 Thread Philip Avinash
With conversion of GPIO davinci driver to platform driver, gpio-davinci driver can support DT boot. This patch series - adds dt binding support for gpio-davinci. - da850 dt support goio. This patch series is based on Linux 3.10-rc4 and is availabel at [1]. 1. https://github.com/avinashphilip/am3

[PATCH v2 1/4] ARM: davinci: da850: Use #include for all device trees

2013-06-14 Thread Philip Avinash
Replace /include/ by #include for da850 device tree files, in order to use the C pre-processor, making use of #define features possible. Signed-off-by: Philip Avinash --- Changes since v1: - New patch and comes as a dependency of patch 3/4 arch/arm/boot/dts/da850-enbw-cmc.dts |2 +-

[PATCH v2 4/4] ARM: davinci: da850 evm: add GPIO DT data

2013-06-14 Thread Philip Avinash
From: KV Sujith - Add GPIO DT Data and pinmux for DA850 EVM. GPIO is configurable differently on different boards. So add GPIO pinmuxing in dts file. - Dependency: This patch is dependent on Grab-pin-control patch; https://patchwork.kernel.org/patch/2013751/ Signed-off-by: KV Sujith Signed-

[PATCH v2 3/4] ARM: davinci: da850: add GPIO DT entries

2013-06-14 Thread Philip Avinash
From: KV Sujith Add DT entries for Davinci GPIO. Signed-off-by: KV Sujith Signed-off-by: Philip Avinash --- Changes since v1: - interrupts member defined as array and with interrupt flags arch/arm/boot/dts/da850.dtsi | 15 +++ 1 file changed, 15 insertions(+) diff --gi

Re: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos

2013-06-14 Thread Thierry Reding
On Fri, Jun 14, 2013 at 05:18:46PM +0900, Jingoo Han wrote: > On Thursday, June 13, 2013 11:14 PM, Arnd Bergmann wrote: > > On Thursday 13 June 2013 22:22:31 Jingoo Han wrote: [...] > > > +static int __exit exynos_pcie_remove(struct platform_device *pdev) > > > +{ > > > + struct pcie_port *pp = pla

RE: [PATCH 2/2] rtc: omap: add rtc wakeup support to alarm events

2013-06-14 Thread Hebbar, Gururaja
On Fri, Jun 14, 2013 at 03:51:43, Kevin Hilman wrote: > "Hebbar, Gururaja" writes: > > > Hi Kevin, > > > > On Mon, Jun 10, 2013 at 16:55:17, Hebbar, Gururaja wrote: > >> On Fri, May 31, 2013 at 23:11:22, Kevin Hilman wrote: > >> > Hebbar Gururaja writes: > >> > > >> > > On some platforms (like

Re: [RFC PATCH v3 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support

2013-06-14 Thread Lorenzo Pieralisi
Hi Olof, thank you very much for having a look. On Thu, Jun 13, 2013 at 11:52:33PM +0100, Olof Johansson wrote: > Hi, > > Overall this driver looks like it just needs more cooking > time. It's... gritty. Complicated when it should be simple and > layered. Naming is nonobvious, and overall it's

Re: [PATCH 1/7] ARM: mxc: fix gpio-ranges for VF610

2013-06-14 Thread Shawn Guo
On Thu, Jun 13, 2013 at 02:59:53PM -0600, Stephen Warren wrote: > From: Stephen Warren > > The gpio-ranges properties in vf610.dtsi were written according to an > older version of the GPIO bindings. Unfortunately, these were changed > incompatibly in commit 86853c8 "gpio: add gpio offset in gpio

Re: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos

2013-06-14 Thread Arnd Bergmann
On Friday 14 June 2013 12:53:11 Thierry Reding wrote: > > I think the biggest missing piece is pci_common_exit(), the counterpart > of pci_common_init(), to cleanup a host bridge on ARM. I haven't looked > in detail at the other architectures, but I suspect there must be some > code to call when a

Re: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos

2013-06-14 Thread Arnd Bergmann
On Friday 14 June 2013 17:18:46 Jingoo Han wrote: > On Thursday, June 13, 2013 11:14 PM, Arnd Bergmann wrote: > > On Thursday 13 June 2013 22:22:31 Jingoo Han wrote: > > > +struct pcie_port { > > > + struct device *dev; > > > + u8 controller; > > > + u8

Re: [RFC PATCH v3 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support

2013-06-14 Thread Pawel Moll
On Thu, 2013-06-13 at 23:52 +0100, Olof Johansson wrote: > > + reg = <0 0x7FFF 0 0x1000>; > > #size-cells 2 on the parent bus? That's somewhat unusual. LPAE == 40 bit physical addresses == potential > 32 bit sizes (memory blocks > 4GB) Paweł ___

[PATCH v4] usb: dwc3: use extcon fwrk to receive connect/disconnect

2013-06-14 Thread Kishon Vijay Abraham I
Modified dwc3-omap to receive connect and disconnect notification using extcon framework. Also did the necessary cleanups required after adapting to extcon framework. Signed-off-by: Kishon Vijay Abraham I Acked-by: Felipe Balbi --- This patch depends on git://git.kernel.org/pub/scm/linux/kernel/

[PATCH] ARM: dts: AM43x EPOS EVM support

2013-06-14 Thread Afzal Mohammed
Add AM43x ePOS EVM minimal DT source - this is a minimal one to get it booting. Also include it in omap2plus dtbs and document bindings. The hardware is under development. Signed-off-by: Afzal Mohammed --- Hi Benoit, This is based on your for_3.11/dts branch. Ideally I wanted to split this int

Re: [PATCH 1/3] ARM: mach-moxart: add MOXA ART SoC files

2013-06-14 Thread Jonas Jensen
Hi, Thanks for the replies. What isn't commented below should already be fixed. I'll resubmit the entire set when it looks like there's nothing left to amend. On 13 June 2013 00:42, Olof Johansson wrote: > You should provide a commit message, ideally with a short introduction of the > platform.

Re: [PATCH 2/3] ARM: mach-moxart: add MOXA ART device tree files

2013-06-14 Thread Jonas Jensen
Hi, Thanks for the replies. What isn't commented below should already be fixed. On 13 June 2013 00:49, Olof Johansson wrote: > Hi, > > You should add a bindings description for the MOXA SoC platforms, similar to > how others do it, under Documentation/devicetree/bindings/arm/. The following is

Re: [PATCH v2 1/3] ARM: tegra: basic support for Trusted Foundations

2013-06-14 Thread Stephen Warren
On 06/14/2013 02:27 AM, Alexandre Courbot wrote: > On Fri, Jun 14, 2013 at 4:19 AM, Stephen Warren wrote: >> On 06/13/2013 03:12 AM, Alexandre Courbot wrote: >>> Add basic support for booting secondary processors on Tegra devices >>> using the Trusted Foundations secure monitor. >>> diff --git a/

Re: [PATCH v2 1/3] ARM: tegra: basic support for Trusted Foundations

2013-06-14 Thread Stephen Warren
On 06/14/2013 02:43 AM, Alexandre Courbot wrote: > On Thu, Jun 13, 2013 at 11:35 PM, Dave Martin wrote: ... >>> + compatible = "tl,trusted-foundations"; >>> + }; >> >> For now, it might make more sense to make this binding tegra-specific, >> and to interpret the node is only implyi

Re: [PATCH v2 3/3] ARM: tegra: set CPU reset handler with firmware op

2013-06-14 Thread Stephen Warren
On 06/14/2013 02:54 AM, Alexandre Courbot wrote: > On Fri, Jun 14, 2013 at 4:23 AM, Stephen Warren wrote: >> On 06/13/2013 03:12 AM, Alexandre Courbot wrote: >>> Use a firmware operation to set the CPU reset handler and only resort to >>> doing it ourselves if there is none defined. >>> >>> This s

[PATCH 0/5] pinctrl: fix some issues with new pinconfig dt parsing

2013-06-14 Thread Heiko Stübner
Some issues with the recently submitted generic pinconfig parsing from dt came up, so fix these in this follow-up series. Hopefully I did catch all of them. Tested on my rk3066 device. Heiko Stuebner (5): pinctrl: update the documentation for some pinconfig params pinctrl: clarify some dt pi

[PATCH 1/5] pinctrl: update the documentation for some pinconfig params

2013-06-14 Thread Heiko Stübner
The BIAS_DISABLE and BIAS_HIGH_IMPEDANCE generic pinconfig options were missing information about their argument - which should be ignored. Also the BIAS_PULL_* options may have the pull strength as argument when they are activated, while simpler hardware can use any non-0 value for it. Update th

[PATCH 2/5] pinctrl: clarify some dt pinconfig options

2013-06-14 Thread Heiko Stübner
The bias-pull-* options use values > 0 to indicate that the pull should be activated and optionally also indicate the strength of the pull. Therefore use an default value of 1 for these options. Split the low-power-mode option into low-power-enable and -disable. Update the documentation to descri

[PATCH 3/5] pinctrl: handle zero found dt pinconfig properties better

2013-06-14 Thread Heiko Stübner
This adds a shortcut when no valid pinconf properties are found in the parsed dt node, to set the values immediately and return. Suggested-by: Laurent Pinchart Signed-off-by: Heiko Stuebner --- drivers/pinctrl/pinconf-generic.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drive

[PATCH 4/5] pinctrl: dynamically alloc temp array when parsing dt pinconf options

2013-06-14 Thread Heiko Stübner
Allocating the temorary array in pinconf_generic_parse_dt_config on stack might cause problems later on, when the number of options grows over time. Therefore also allocate this array dynamically to be on the safe side. Suggested-by: Laurent Pinchart Signed-off-by: Heiko Stuebner --- drivers/pi

[PATCH 5/5] pinctrl: rockchip: correctly handle arguments of pinconf options

2013-06-14 Thread Heiko Stübner
Change the rockchip pinctrl driver to handle the arguments of 0 or 1 to the pull pinconfig options correctly, so that the pull gets disabled when either the bias_disable options is set or the pull option has the argument 0. Signed-off-by: Heiko Stuebner --- drivers/pinctrl/pinctrl-rockchip.c |

Re: [PATCH 0/5] pinctrl: fix some issues with new pinconfig dt parsing

2013-06-14 Thread James Hogan
On 14/06/13 16:41, Heiko Stübner wrote: > Some issues with the recently submitted generic pinconfig parsing from dt > came up, so fix these in this follow-up series. > > Hopefully I did catch all of them. > > Tested on my rk3066 device. > > Heiko Stuebner (5): > pinctrl: update the documentati

RE: Device tree flattening code not copying properties from blob

2013-06-14 Thread Collins, Rod
Grant That makes perfect sense, but I find that the DTB is included in the vmlinux.lds.h file which lives in source/include/asm-generic. This seems to always want to put the dtb in the init section which gets removed. To fix this the asm-generic/vmlinux.lds.h file would need to be changed. Forgi

[RFC v2 00/12] MBus device tree binding

2013-06-14 Thread Ezequiel Garcia
This is the v2 of the MBus driver patchset. A considerable re-work has been made to the DT layout proposed in the previous patchset, as a result of the recent discussion [1]. [1] http://www.spinics.net/lists/arm-kernel/msg249496.html In the current device tree binding proposal, for each MBus' chi

[RFC v2 01/12] bus: mvebu-mbus: Factor out initialization details

2013-06-14 Thread Ezequiel Garcia
We introduce a common initialization function mvebu_mbus_common_init() that will be used by both legacy and device-tree initialization code. This patch is an intermediate step, which will allow to introduce the DT binding for this driver in a less intrusive way. Signed-off-by: Thomas Petazzoni Si

[RFC v2 02/12] bus: mvebu-mbus: Introduce device tree binding

2013-06-14 Thread Ezequiel Garcia
This patch adds the most fundamental device-tree initialization. We only introduce what's required to be able to probe the mvebu-mbus driver from the DT. Follow-up patches will extend the device tree binding, allowing to describe static address decoding windows. Signed-off-by: Thomas Petazzoni Si

[RFC v2 03/12] bus: mvebu-mbus: Add static window allocation to the DT binding

2013-06-14 Thread Ezequiel Garcia
This patch adds static window allocation to the device tree binding. Each first-child of the mbus-compatible node, with a suitable 'ranges' property, declaring an address translation, will trigger an address decoding window allocation. Signed-off-by: Ezequiel Garcia --- .../devicetree/bindings/b

[RFC v2 04/12] ARM: mvebu: Initialize MBus using the DT binding

2013-06-14 Thread Ezequiel Garcia
Now that the mbus device tree binding has been introduced, we can switch over to it. Also, and since the initialization of the mbus driver is quite fundamental for the system to work properly, this patch adds a BUG() in case mbus fails to initialize. Signed-off-by: Ezequiel Garcia --- arch/arm/

[RFC v2 05/12] ARM: mvebu: Remove the harcoded BootROM window allocation

2013-06-14 Thread Ezequiel Garcia
The address decoding window to access the BootROM should not be allocated programatically, but instead declared in the device tree. Signed-off-by: Ezequiel Garcia --- arch/arm/mach-mvebu/platsmp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mv

[RFC v2 09/12] ARM: mvebu: Add BootROM to Armada 370/XP device tree

2013-06-14 Thread Ezequiel Garcia
In order to access the SoC BootROM, we need to declare a mapping (through a ranges property). The mbus driver will use this property to allocate a suitable address decoding window. Signed-off-by: Ezequiel Garcia --- arch/arm/boot/dts/armada-370-xp.dtsi | 2 ++ arch/arm/boot/dts/armada-370.dtsi

[RFC v2 06/12] memory: mvebu-devbus: Remove address decoding window workaround

2013-06-14 Thread Ezequiel Garcia
Now that mbus device tree binding has been introduced, remove the address decoding window management from this driver. A suitable 'ranges' entry should be added to the devbus-compatible node in the device tree, as described by the mbus binding documentation. Signed-off-by: Ezequiel Garcia --- dr

[RFC v2 07/12] ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files

2013-06-14 Thread Ezequiel Garcia
Signed-off-by: Ezequiel Garcia --- arch/arm/boot/dts/armada-370-db.dts | 2 +- arch/arm/boot/dts/armada-370-mirabox.dts | 2 +- arch/arm/boot/dts/armada-370-rd.dts | 2 +- arch/arm/boot/dts/armada-370.dtsi| 2 +- arch/arm/boot/dts/armada-xp-db.dts

[RFC v2 10/12] ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes

2013-06-14 Thread Ezequiel Garcia
Now that mbus has been added to the device tree, it's possible to move the DeviceBus out of internal registers, placing it directly below the mbus. This is a more accurate representation of the hardware. Signed-off-by: Ezequiel Garcia --- arch/arm/boot/dts/armada-370-xp.dtsi | 89 +++

[RFC v2 08/12] ARM: mvebu: Add MBus to Armada 370/XP device tree

2013-06-14 Thread Ezequiel Garcia
The Armada 370/XP SoC family has a completely configurable address space handled by the MBus controller. This patch introduces the device tree layout of MBus, making the 'soc' node as mbus-compatible. Since every peripheral/controller is a child of this 'soc' node, this makes all of them sit behin

[RFC v2 11/12] ARM: mvebu: Relocate Armada 370 PCIe device tree nodes

2013-06-14 Thread Ezequiel Garcia
Now that mbus has been added to the device tree, it's possible to move the PCIe nodes out of internal registers, placing it directly below the mbus. This is a more accurate representation of the hardware. Signed-off-by: Ezequiel Garcia --- arch/arm/boot/dts/armada-370-mirabox.dts | 32 +-

[RFC v2 12/12] ARM: mvebu: Relocate Armada XP PCIe device tree nodes

2013-06-14 Thread Ezequiel Garcia
Now that mbus has been added to the device tree, it's possible to move the PCIe nodes out of internal registers, placing it directly below the mbus. This is a more accurate representation of the hardware. Signed-off-by: Ezequiel Garcia --- arch/arm/boot/dts/armada-xp-db.dts | 66 +

[RFC PATCH 0/5] Generic PHY driver for Exynos SoCs MIPI CSI-2/DSIM DPHYs

2013-06-14 Thread Sylwester Nawrocki
Hi, The following is a simple driver for the Samsung S5P/Exynos SoCs MIPI CSI-2 receiver and MIPI DSI transmitter DPHYs, using the generic PHY framework [1]. Previously the MIPI CSIS and MIPI DSIM used a platform callback to control the PHY power enable and reset bits. The callback can be dropped

[RFC PATCH 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs

2013-06-14 Thread Sylwester Nawrocki
Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2 receiver and MIPI DSI transmitter DPHYs. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- .../bindings/phy/exynos-video-mipi-phy.txt | 16 ++ drivers/phy/Kconfig| 10

[RFC PATCH 2/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi

2013-06-14 Thread Sylwester Nawrocki
Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- 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

[RFC PATCH 3/5] video: exynos_dsi: Use generic PHY driver

2013-06-14 Thread Sylwester Nawrocki
Use the generic PHY API instead of the platform callback to control the MIPI DSIM DPHY. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- drivers/video/display/source-exynos_dsi.c | 36 + include/video/exynos_dsi.h|5 2 fil

[RFC PATCH 5/5] ARM: Samsung: Remove MIPI PHY setup code

2013-06-14 Thread Sylwester Nawrocki
Generic PHY drivers are used to handle the MIPI CSIS and MIPI DSIM DPHYs so we can remove now unused code at arch/arm/plat-samsung. In case there is any board file for S5PV210 platforms using MIPI CSIS/DSIM (not any upstream currently) it should use the generic PHY API to bind the PHYs to respectiv

Re: [RFC PATCH v3 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support

2013-06-14 Thread Olof Johansson
On Fri, Jun 14, 2013 at 02:04:00PM +0100, Pawel Moll wrote: > On Thu, 2013-06-13 at 23:52 +0100, Olof Johansson wrote: > > > + reg = <0 0x7FFF 0 0x1000>; > > > > #size-cells 2 on the parent bus? That's somewhat unusual. > > LPAE == 40 bit physical addresses == potential > 32 bit sizes (m

[RFC PATCH 4/5] exynos4-is: Use generic MIPI CSIS PHY driver

2013-06-14 Thread Sylwester Nawrocki
Use the generic PHY API instead of the platform callback to control the MIPI CSIS DPHY. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- drivers/media/platform/exynos4-is/mipi-csis.c | 11 +-- include/linux/platform_data/mipi-csis.h |9 - 2 files ch

[PATCH] exynos4-is: Add Exynos5250 SoC support to fimc-lite driver

2013-06-14 Thread Sylwester Nawrocki
This patch adds support for the Exynos5250 SoC variant of the FIMC-LITE IP. A 'compatible' string is added for Exynos5250 compatible devices and the capture DMA handling is reworked to use the FLITE_REG_CIFCNTSEQ register, masking output DMA buffer address slots. The frame interrupt is enabled so t

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

2013-06-14 Thread Joel A Fernandes
Hi, On Wed, Mar 6, 2013 at 7:37 AM, Matt Porter wrote: > On Tue, Mar 05, 2013 at 09:26:01PM +, Arnd Bergmann wrote: >> On Tuesday 05 March 2013, Matt Porter wrote: >> > Changes since v1: >> > - rebase to 3.9-rc1, previous dependencies upstream >> > >> > This series adds DT DMA Engine

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

2013-06-14 Thread Joel A Fernandes
Resending on Matt's new email, thanks. On Fri, Jun 14, 2013 at 1:10 PM, Joel A Fernandes wrote: > Hi, > > On Wed, Mar 6, 2013 at 7:37 AM, Matt Porter wrote: >> On Tue, Mar 05, 2013 at 09:26:01PM +, Arnd Bergmann wrote: >>> On Tuesday 05 March 2013, Matt Porter wrote: >>> > Changes since v1:

Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support

2013-06-14 Thread Joel A Fernandes
Hi Tony, Vaibhav, >> I just doublechecked MMC rootfs on bone and evmsk as it's the standard >> smoke test. My EVM is intermittent now so trying to coax it to power up >> to reverify. >> > > Matt, > > Your branch is working for me, I tested it on EVM. Not sure what is wrong > with manual rebasing

[PATCH] ARM: mmp: irq: Improve DT layout

2013-06-14 Thread Daniel Drake
In the mmp2 device tree, the interrupt mux nodes were peers of the interrupt controller, yet they mapped registers in conflict with the interrupt controller's register block. Furthermore, the reg properties of the muxes disagreed with the unit address specified after the node's @-sign. Move the in

Re: [PATCH] of: irq: Pass trigger type in IRQ resource flags

2013-06-14 Thread Grant Likely
On Wed, 05 Jun 2013 20:20:39 +0200, Tomasz Figa wrote: > Hi, > > On Sunday 19 of May 2013 00:56:30 Tomasz Figa wrote: > > Some drivers might rely on availability of trigger flags in IRQ > > resource, for example to configure the hardware for particular interrupt > > type. However current code cre

Re: [PATCH] dtc: ensure #line directives don't consume data from the next line

2013-06-14 Thread Grant Likely
On Wed, 05 Jun 2013 10:50:02 -0600, Stephen Warren wrote: > On 06/03/2013 09:36 AM, Stephen Warren wrote: > > From: Stephen Warren > > > > Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS} > > could match line-break characters. If the #line directive did not contain > > th

Re: [PATCH RFC 1/3] clk: omap: introduce clock driver

2013-06-14 Thread Grant Likely
On Mon, 3 Jun 2013 23:39:16 -0700, Mike Turquette wrote: > Parses OMAP clock data from DT and registers those clocks with the clock > framework. dt_omap_clk_init must be called early during boot for timer > initialization so it is exported and called from the existing clock code > instead of pr

Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support

2013-06-14 Thread Felipe Balbi
Hi, On Fri, Jun 14, 2013 at 02:54:33PM -0500, Joel A Fernandes wrote: > Hi Tony, Vaibhav, > > >> I just doublechecked MMC rootfs on bone and evmsk as it's the standard > >> smoke test. My EVM is intermittent now so trying to coax it to power up > >> to reverify. > >> > > > > Matt, > > > > Your br

[PATCH] gpio MIPS/OCTEON: Add a driver for OCTEON's on-chip GPIO pins.

2013-06-14 Thread David Daney
From: David Daney The SOCs in the OCTEON family have 16 (or in some cases 20) on-chip GPIO pins, this driver handles them all. Configuring the pins as interrupt sources is handled elsewhere (OCTEON's irq handling code). Signed-off-by: David Daney --- This patch depends somewhat on patches in

Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support

2013-06-14 Thread Joel A Fernandes
Felipe, On Friday, June 14, 2013, Felipe Balbi wrote: > Hi, > > On Fri, Jun 14, 2013 at 02:54:33PM -0500, Joel A Fernandes wrote: > > Hi Tony, Vaibhav, > > > > >> I just doublechecked MMC rootfs on bone and evmsk as it's the standard > > >> smoke test. My EVM is intermittent now so trying to coax

Re: RFC: New release for DTC?

2013-06-14 Thread Grant Likely
On Thu, 30 May 2013 11:45:23 -0600, Stephen Warren wrote: > On 08/23/2012 12:15 PM, Yann E. MORIN wrote: > > Hello All! > > > > Following advice from Jon Loeliger, I would suggest that a new release > > of DTC be tagged and packaged. > > > > It is important for some projects to rely on a releas

Re: [PATCH 0/1] gpio-rcar: Add DT support

2013-06-14 Thread Olof Johansson
On Thu, Jun 13, 2013 at 04:00:26PM +0900, Simon Horman wrote: > From: Laurent Pinchart > > Add DT bindings for the gpio-rcar driver and read the device > configuration from the DT node at probe time if available. > > Cc: devicetree-discuss@lists.ozlabs.org > Signed-off-by: Laurent Pinchart > Si

Re: [PATCH] of: irq: Pass trigger type in IRQ resource flags

2013-06-14 Thread Javier Martinez Canillas
On 15/06/2013, at 00:00, Grant Likely wrote: > On Wed, 05 Jun 2013 20:20:39 +0200, Tomasz Figa wrote: >> Hi, >> >> On Sunday 19 of May 2013 00:56:30 Tomasz Figa wrote: >>> Some drivers might rely on availability of trigger flags in IRQ >>> resource, for example to configure the hardware for pa

Re: [PATCH] Bump version number to 1.4.0

2013-06-14 Thread David Gibson
On Tue, Jun 11, 2013 at 11:11:25AM -0600, Stephen Warren wrote: > From: Stephen Warren > > Many useful new features have been added to dtc since the last release. > Projects that use dtc wish to test the version number to determine > which features are available. Increment the version number to a

Re: [PATCH] Bump version number to 1.4.0

2013-06-14 Thread Stephen Warren
On 06/14/2013 07:12 PM, David Gibson wrote: > On Tue, Jun 11, 2013 at 11:11:25AM -0600, Stephen Warren wrote: >> From: Stephen Warren >> >> Many useful new features have been added to dtc since the last >> release. Projects that use dtc wish to test the version number to >> determine which featur