On 6 February 2013 13:02, Inki Dae inki@samsung.com wrote:
Looks good to me but please add document for it.
Yes. I will. I was planning to send the bindings document patch along
with the dt patches (adding node entries to dts files).
Sylwester had suggested adding this to
This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device tree properties are OS
independent but optional properties allow linux specific support for rc
protocols and
Hey Simon, Iwamatsu-san,
On Wed, Feb 6, 2013 at 11:00 AM, Simon Horman
horms+rene...@verge.net.au wrote:
From: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
This adds support of device tree probe for Renesas sh-ether driver.
Signed-off-by: Nobuhiro Iwamatsu
Hi Simon, Iwamatsu-san
+Required properties:
+- compatible: renesas,sh-eth;
+- interrupt-parent: The phandle for the interrupt controller that
+services interrupts for this device.
+- reg: Offset and
Dear Thierry Reding,
On Wed, 9 Jan 2013 21:43:06 +0100, Thierry Reding wrote:
When using deferred driver probing, PCI host controller drivers may
actually require this function after the init stage.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thomas Petazzoni
Hi Mark, Stephen
Kuninori Morimoto (3):
ASoC: use list_add_tail() instead of list_add() for platform/codec/dai
list
ASoC: add snd_soc_of_get_port_dai_name()
ASoC: simple-card: add Device Tree support
#1, #2 enable to get cpu/codec_dai_name from device node and
-Original Message-
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: Wednesday, February 06, 2013 5:03 PM
To: Inki Dae
Cc: linux-me...@vger.kernel.org; dri-de...@lists.freedesktop.org;
devicetree-discuss@lists.ozlabs.org; k.deb...@samsung.com;
s.nawro...@samsung.com;
On 02/05/2013 06:11 PM, Mark Rutland wrote:
[...]
+
+- single_ulpi_bypass: Must be present if the controller contains a single
+ ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
Again it would be nicer to have '-' rather than '_' here. It might be worth
prefixing this ti,.
Is
On Wednesday 06 February 2013, Padmavathi Venna wrote:
This patch adds a new pl330_dt_filter for DT case to filter the
required channel based on the new filter params and modifies the
old filter only for non-DT case as suggested by Arnd Bergmann.
Signed-off-by: Padmavathi Venna
On Wednesday 06 February 2013, Padmavathi Venna wrote:
This patch removes the usage of DMACH_DT_PROP and dt_dmach_prop
from dma code as the new generic dma dt binding support has been
added.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
On Tuesday 05 February 2013 at 15:29:09, Grant Likely wrote:
On Thu, 31 Jan 2013 21:51:36 +0100, Linus Walleij
linus.wall...@linaro.org wrote:
On Thu, Jan 31, 2013 at 4:58 PM, Lars Poeschel la...@wh2.tu-dresden.de
wrote:
--- /dev/null
+++
Add I2C0 device tree and pin muxing information to da850-evm.
Also, add OF_DEV_AUXDATA for I2C0 controller driver in da850
board dt file to use I2C0 clock.
Verified i2c0 node gets created in sys class interface as
/sys/class/i2c-dev/i2c-0/subsystem/i2c-0.
Signed-off-by: Vishwanathrao Badarkhe,
On Wed, Feb 6, 2013 at 10:31 AM, Lars Poeschel poesc...@lemonage.de wrote:
The thing that confused me was, that the platform_data for the chip has a
mandatory base member, that sets the linux global gpio number at which the
chip should appear.
Yes this is common. I think you should look at
On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote:
Doesn't look very elegant to me, but I wouldn't mind if there is no better
option.
Even then, we can't rely on the device name as its index can change based on
where it is
Well, thats what I said in the first mail, that *if* you are
On 02/06/2013 12:21 PM, Rajendra Nayak wrote:
On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote:
Doesn't look very elegant to me, but I wouldn't mind if there is no better
option.
Even then, we can't rely on the device name as its index can change based on
where it is
Well, thats
Hi Gregory,
On Tue, Feb 05, 2013 at 09:17:02PM +0100, Gregory CLEMENT wrote:
On 02/05/2013 05:28 PM, Gregory CLEMENT wrote:
Hi Ezequiel,
On 02/05/2013 12:24 PM, Ezequiel Garcia wrote:
This patch adds an SPI master device node for Armada XP-GP board.
This master node is an SPI flash
On Mon, Jan 21, 2013 at 12:59:21PM -0800, Simon Glass wrote:
Since fdtgrep does everything that fdtdump does now, perhaps we should
replace it with a symlink.
Nack. The point of fdtdump is not simply to be a tool for dumping
device trees - dtc -I dtb -O dts will do that already. The point is
Hi Koen,
SNIP
Since AM335x is DT only, why is there a platform data codepath and why
is it the first branch it tries? And I guess the next question is
related to the first: why doesn't it work when used with DT? When I
copy over the nodes from the evm.dts to my board I get tsc
On 02/06/2013 09:51 AM, Inki Dae wrote:
[...]
I think that it's better to go to gpu than media and we can divide Exynos
IPs into the bellow categories,
Media : mfc
GPU : g2d, g3d, fimc, gsc
Heh, nice try! :) GPU and FIMC ? FIMC is a camera subsystem (hence 'C'
in the acronym), so what it
On 6 February 2013 16:53, Sylwester Nawrocki s.nawro...@samsung.com wrote:
On 02/06/2013 09:51 AM, Inki Dae wrote:
[...]
So I propose following classification, which seems less inaccurate:
GPU: g2d, g3d
Media: mfc, fimc, fimc-lite, fimc-is, mipi-csis, gsc
Video: fimd, hdmi, eDP,
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Sylwester Nawrocki
Sent: Wednesday, February 06, 2013 8:24 PM
To: Inki Dae
Cc: 'Sachin Kamat'; linux-me...@vger.kernel.org; dri-
de...@lists.freedesktop.org;
Added G2D DT node to Exynos4210.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4210.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 79ba247..3410d5f
This patch series is based on for-next branch of Kukjin Kim's tree
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
Patches added on top of MFC DT series which has been accepted by Kukjin.
http://www.spinics.net/lists/linux-samsung-soc/msg15419.html
Sachin Kamat (7):
ARM:
Added G2D DT node to SMDKV310 board.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4210-smdkv310.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts
Added G2D DT node to Origen4210 board.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4210-origen.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
Added G2D DT node to exynos4x12.dtsi file.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4x12.dtsi |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index
Added G2D DT node to SMDK4412 board.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
This patch is added on top of below patch:
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15148.html
---
arch/arm/boot/dts/exynos4412-smdk4412.dts |4
1 files changed, 4
Added G2D DT node to Origen4412 board.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
This patch is added on top of below patch:
http://www.spinics.net/lists/linux-samsung-soc/msg15543.html
---
arch/arm/boot/dts/exynos4412-origen.dts |4
1 files changed, 4 insertions(+), 0
Added documentaion about G2D bindings.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
.../devicetree/bindings/gpu/samsung-g2d.txt| 30
1 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644
On 02/06/2013 11:54 AM, Ezequiel Garcia wrote:
Hi Gregory,
On Tue, Feb 05, 2013 at 09:17:02PM +0100, Gregory CLEMENT wrote:
On 02/05/2013 05:28 PM, Gregory CLEMENT wrote:
Hi Ezequiel,
On 02/05/2013 12:24 PM, Ezequiel Garcia wrote:
This patch adds an SPI master device node for Armada XP-GP
On Tue, Feb 05, 2013 at 02:23:55PM +0100, Peter De Schrijver wrote:
On Tue, Feb 05, 2013 at 06:42:11AM +0100, Prashant Gaikwad wrote:
On Monday 04 February 2013 08:02 PM, Peter De Schrijver wrote:
On Mon, Feb 04, 2013 at 07:06:47AM +0100, Prashant Gaikwad wrote:
On Friday 01 February 2013
Hi Matt!
At first thanks for you efforts on DMA Engine on AM33XX.
On Friday 01 February 2013 at 22:01:17, Matt Porter wrote:
This series adds DT DMA Engine Client support to the omap_hsmmc.
It leverages the generic DMA OF helpers in -next and the
dma_request_slave_channel_compat() wrapper
This is second version of the SPI patchset for Armada 370/XP.
This series first adds support for the SPI controller
and then adds the SPI flash for the Armada XP GP board.
This series is based on 3.8-rc5 plus:
* arm: mvebu: support for the new Armada XP development board(DB-MV784MP-GP)
* arm:
The Armada 370 and Armada XP SoC has an SPI controller.
This patch adds support for this controller in Armada 370
and Armada XP SoC common device tree files.
Note that the Armada XP SPI register length is 0x50 bytes,
while Armada 370 SPI register length is 0x28 bytes,
so we choose the smaller of
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Lior Amsalem al...@marvell.com
Acked-by: Gregory Clement gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/configs/mvebu_defconfig |2 ++
1 files changed, 2
This patch adds an SPI master device node for Armada XP-GP board.
This master node is an SPI flash controller 'n25q128a13'.
Since there is no 'partitions' node declared, one full sized
partition named as the device will be created.
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc:
The Armada XP DB-MV784MP-GP board has an SPI flash device.
These options allow to access that device over MTD.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Depends on patch: arm: mvebu: i2c come back in defconfig
arch/arm/configs/mvebu_defconfig |3 +++
1 files
On 02/06/2013 02:06 PM, Ezequiel Garcia wrote:
This is second version of the SPI patchset for Armada 370/XP.
This series first adds support for the SPI controller
and then adds the SPI flash for the Armada XP GP board.
This series is based on 3.8-rc5 plus:
* arm: mvebu: support for the
On Wed, Feb 06, 2013 at 02:16:54PM +0100, Gregory CLEMENT wrote:
On 02/06/2013 02:06 PM, Ezequiel Garcia wrote:
This is second version of the SPI patchset for Armada 370/XP.
This series first adds support for the SPI controller
and then adds the SPI flash for the Armada XP GP board.
On Wed, Feb 06, 2013 at 01:41:06PM +0100, Lars Poeschel wrote:
Hi Matt!
At first thanks for you efforts on DMA Engine on AM33XX.
On Friday 01 February 2013 at 22:01:17, Matt Porter wrote:
This series adds DT DMA Engine Client support to the omap_hsmmc.
It leverages the generic DMA OF
Salut Florian,
On 02/04/2013 10:14 AM, Florian Vaussard wrote:
Hello Benoit,
On 01/24/2013 01:21 PM, Benoit Cousson wrote:
+ Peter who did the original PWM
Hi Florian,
On 01/23/2013 06:56 PM, Florian Vaussard wrote:
Hello Benoit,
This patchset adds some new DT supports to the Overo
On 06/02/13 13:11, Grant Likely wrote:
Hi Stephen,
I've just pushed out a change which cleans up platform device
registration to use the same path whether or not the device tree is
used. It should be safe, but there is a risk of breakage on powerpc
platforms.
The patch has two effects of
On Friday 01 February 2013, Matt Porter wrote:
This series adds DT DMA Engine Client support to the omap_hsmmc.
It leverages the generic DMA OF helpers in -next and the
dma_request_slave_channel_compat() wrapper introduced in the
AM33XX DMA Engine series to support DMA in omap_hsmmc on
Hi,
On 02/06/2013 09:03 AM, Sebastian Hesselbarth wrote:
This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device tree properties are OS
independent but
Hi Stephen,
I've just pushed out a change which cleans up platform device
registration to use the same path whether or not the device tree is
used. It should be safe, but there is a risk of breakage on powerpc
platforms.
The patch has two effects of note:
- DT generated platform devices move
Binding Documents for drm-devices are placed in
Documentation/devicetree/bindings/drm/*. But these devices are common
for v4l framework, hence moved to a common place at
Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to
associate them with exynos soc series.
Signed-off-by:
On Wed, Feb 6, 2013 at 1:32 PM, James Hogan james.ho...@imgtec.com wrote:
On 06/02/13 13:11, Grant Likely wrote:
Hi Stephen,
I've just pushed out a change which cleans up platform device
registration to use the same path whether or not the device tree is
used. It should be safe, but there is
Binding Documents for drm-devices are placed in
Documentation/devicetree/bindings/drm/*. But these devices are common
for v4l framework, hence moved to a common place
Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to
associate them with exynos soc series.
Signed-off-by: Rahul
Hi Rahul,
On 02/06/2013 03:57 PM, Rahul Sharma wrote:
Binding Documents for drm-devices are placed in
Documentation/devicetree/bindings/drm/*. But these devices are common
for v4l framework, hence moved to a common place
Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to
Add ocp2scp data node in omap5 device tree file. The information for
the node added here can be found @
Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |8
1 file changed, 8 insertions(+)
Add dwc3 omap glue data to the omap5 dt data file. The information about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 11 +++
1 file changed, 11
Add dwc3 core dt data as a subnode to dwc3 omap glue data in omap5 dt
data file. The information for the entered data node is available @
Documentation/devicetree/bindings/usb/dwc3.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |7 +++
1 file
Add omap control usb data in omap4 device tree file. This will have the
register address of registers to power on the PHY and to write to
mailbox. The information about this data node is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
Hi Benoit,
Here are the dt data patches to get usb device functional in OMAP platforms.
This series applies cleanly in both for_3.9/dts and 3.8-rc6.
All the patches deal with modifying arch/arm/boot except one which modifies
Documentation/../usb/omap-usb.txt
Kishon Vijay Abraham I (8):
ARM:
Add omap control usb data in omap5 device tree file. This will have the
register address of registers to power on the USB2 PHY and USB3 PHY. The
information for the node added here is available in
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp. The information about this data node is availabe @
Documentation/devicetree/bindings/usb/usb-phy.txt
Acked-by: Felipe Balbi ba...@ti.com
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
The dt data specifies among others the interface type (ULPI or UTMI), mode
which is mostly OTG, power that specifies the amount of power this can supply
when in host
Add omap-usb3 and omap-usb2 data node in omap5 device tree file.
The information for the node added here is available @
Documentation/devicetree/bindings/usb/usb-phy.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 14 ++
1 file changed, 14
Hi,
On Wed, Jan 23, 2013 at 04:45:11PM +, Guennadi Liakhovetski wrote:
Many MMC capability flags are platform-dependent and are traditionally set
in platform data. With DT often each such capability requires a special
binding. Add bindings for MMC_CAP_SD_HIGHSPEED, MMC_CAP_MMC_HIGHSPEED
On 02/06/2013 12:18 AM, Padmavathi Venna wrote:
This patch adds #dma-cells property to PL330 DMA controller
nodes for supporting generic dma dt bindings on samsung
exynos5250 platform.
The subject doesn't reflect this is for pl330.
Signed-off-by: Padmavathi Venna padm...@samsung.com
(Adding mtd in Cc)
On Wed, Feb 06, 2013 at 07:54:31AM -0300, Ezequiel Garcia wrote:
Hi Gregory,
On Tue, Feb 05, 2013 at 09:17:02PM +0100, Gregory CLEMENT wrote:
On 02/05/2013 05:28 PM, Gregory CLEMENT wrote:
Hi Ezequiel,
On 02/05/2013 12:24 PM, Ezequiel Garcia wrote:
This patch
On 02/04/2013 10:05 AM, Paul Gortmaker wrote:
From: Thomas Gleixner t...@linutronix.de
With the locking cleanup in place (from OF: Fixup resursive
locking code paths), we can now do the conversion from the
rw_lock to a raw spinlock as required for preempt-rt.
The previous cleanup and the
Hi Mark
On Wed, 6 Feb 2013, Mark Rutland wrote:
Hi,
On Wed, Jan 23, 2013 at 04:45:11PM +, Guennadi Liakhovetski wrote:
Many MMC capability flags are platform-dependent and are traditionally set
in platform data. With DT often each such capability requires a special
binding. Add
On Tue, Feb 05, 2013 at 09:41:48PM +0100, Thierry Reding wrote:
On Wed, Jan 09, 2013 at 09:43:06PM +0100, Thierry Reding wrote:
When using deferred driver probing, PCI host controller drivers may
actually require this function after the init stage.
Signed-off-by: Thierry Reding
On Wed, Jan 9, 2013 at 9:43 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
When using deferred driver probing, PCI host controller drivers may
actually require this function after the init stage.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
There seem to be a
Hi David,
On Tue, Feb 5, 2013 at 11:16 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Mon, Jan 21, 2013 at 12:59:21PM -0800, Simon Glass wrote:
Since fdtgrep does everything that fdtdump does now, perhaps we should
replace it with a symlink.
Nack. The point of fdtdump is not simply
On Wednesday 06 February 2013 17:25:42 Guennadi Liakhovetski wrote:
Thank for pointing me out at that thread. However, I don't think
MMC_CAP_POWER_OFF_CARD has anything to do with compatibility or hardware
revisions. At least I haven't yet come across any sd/mmc hosts, that also
supply
On Wednesday 06 February 2013 17:38:20 Linus Walleij wrote:
On Wed, Jan 9, 2013 at 9:43 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
When using deferred driver probing, PCI host controller drivers may
actually require this function after the init stage.
Signed-off-by:
From: Lars Poeschel poesc...@lemonage.de
I wanted to use mcp23s08 driver with a device that boots using device tree.
I modified the driver to allow the DT usage and tested with a mcp23017
which is a i2c device. I could not test the spi path, because I have no
such device.
Regards,
Lars
Lars
From: Lars Poeschel poesc...@lemonage.de
Explicitly allow -1 as a legal value for the
mcp23s08_platform_data-base. This is the special value lets the
kernel choose a valid global gpio base number.
Signed-off-by: Lars Poeschel poesc...@lemonage.de
---
drivers/gpio/gpio-mcp23s08.c |4 ++--
1
From: Lars Poeschel poesc...@lemonage.de
This converts the mcp23s08 driver to be able to be used with device
tree.
There is a special mcp,chips property, that correspond to the chips
member of the struct mcp23s08_platform_data. It can be used for
multiple mcp23s08/mc23s17 on the same spi
On Thu, Feb 7, 2013 at 1:54 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 06 February 2013 17:38:20 Linus Walleij wrote:
On Wed, Jan 9, 2013 at 9:43 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
When using deferred driver probing, PCI host controller drivers may
actually
On 02/06/2013 02:48 PM, Sylwester Nawrocki wrote:
On 02/06/2013 09:03 AM, Sebastian Hesselbarth wrote:
This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device
On Wednesday 06 February 2013 18:07:53 Linus Walleij wrote:
However it leaves the question of how much __init, __initdata
and __initconst we have littering around. Oh, well, we'll see
I guess.
Actually, kbuild is pretty good at warning around the
bugs there.
Arnd
On Thu, 7 Feb 2013, Arnd Bergmann wrote:
On Wednesday 06 February 2013 17:25:42 Guennadi Liakhovetski wrote:
Thank for pointing me out at that thread. However, I don't think
MMC_CAP_POWER_OFF_CARD has anything to do with compatibility or hardware
revisions. At least I haven't yet come
Provide bindings and parse OF data during initialization.
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
v4:
- Fixed wrong parameter to dummy of_iio_channel_get_by_name if CONFIG_OF is
undefined, and wrong return value.
- Initialize indio_dev-of_node in iio_device_register if the calling
On Tue, Feb 5, 2013 at 6:56 PM, 김승우 sw0312@samsung.com wrote:
On 2013년 02월 06일 09:56, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/05/2013 05:37 PM, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren swar...@wwwdotorg.org
On 02/04/2013 11:57 PM, Chanwoo Choi wrote:
On 02/05/2013 05:26 AM, Guenter Roeck wrote:
For iio_channel_get to work with OF based configurations, it needs the
consumer device pointer instead of the consumer device name as argument.
Signed-off-by: Guenter Roeck li...@roeck-us.net
Applied to
On Wed, Feb 06, 2013 at 04:30:41PM +, Russell King - ARM Linux wrote:
On Tue, Feb 05, 2013 at 09:41:48PM +0100, Thierry Reding wrote:
On Wed, Jan 09, 2013 at 09:43:06PM +0100, Thierry Reding wrote:
When using deferred driver probing, PCI host controller drivers may
actually require
On 02/06/2013 06:29 PM, Guenter Roeck wrote:
Provide bindings and parse OF data during initialization.
Signed-off-by: Guenter Roeck li...@roeck-us.net
looks good to me. Couple of little queries inline.
---
v4:
- Fixed wrong parameter to dummy of_iio_channel_get_by_name if CONFIG_OF is
Define device-tree bindings for the tmio-mmc driver to be able to specify
parameters, currently provided in platform data.
Cc: Arnd Bergmann a...@arndb.de
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v3: make the property to set TMIO_MMC_SDIO_IRQ global
tmio-mmc platform flags can be set by various means, including caller
drivers and device-tree bindings, therefore it is better to only check
them in the tmio-mmc driver proper, not in caller drivers themselves.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Use mmc_of_parse() to get interface capability flags and used GPIOs from
device-tree bindings.
Cc: Arnd Bergmann a...@arndb.de
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v3: updated on top of mmc: sh_mmcif: Avoid unnecessary mmc_delay() at
mmc_card_sleepawake()
Use managed allocations to get memory, clock and interrupts . This
significantly simplifies clean up paths.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/host/sh_mobile_sdhi.c | 57 +
1 files changed, 14 insertions(+), 43
Clarify ways to specify write-protect and card-detect MMC lines in FDT.
Cc: Arnd Bergmann a...@arndb.de
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v3: {wp,cd}-inverted properties can now be used together with GPIO
binding flags. A detailed explanation added.
Without barriers SDIO operations fail with runtime PM enabled.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Paul Mundt let...@linux-sh.org
---
v3: use iowrite16_rep() and ioread16_rep() for consistency.
drivers/mmc/host/tmio_mmc.h | 18 ++
1 files changed,
MMC defines a number of standard DT bindings. Having each driver parse
them individually adds code redundancy and is error prone. Provide a
standard function to unify the parsing. After all drivers are converted
to using it instead of their own parsers, this function can be integrated
into
This is v3 of my mmc DT patchset with several patches updated and two
patches, previously sent separately, now integrated into the series.
Guennadi Liakhovetski (13):
mmc: sdhi, tmio: only check flags in tmio-mmc driver proper
mmc: detailed definition of CD and WP MMC line polarities in DT
Some SD/MMC interfaces use 2 power regulators: one to power the card itself
(Vcc) and another one to pull signal lines up (VccQ). In case of eMMC and
UHS SD cards the regulators also have to be configured to supply different
voltages. The preferred order of turning supply power on and off is to
Many MMC capability flags are platform-dependent and are traditionally set
in platform data. With DT often each such capability requires a special
binding. Add bindings for MMC_CAP_SD_HIGHSPEED, MMC_CAP_MMC_HIGHSPEED,
MMC_CAP_POWER_OFF_CARD and MMC_CAP_SDIO_IRQ capabilities. Also add code to
DT
The tmio_mmc_cd_wakeup() inline function has been deprecated since 3.4 and
is unused since 3.4 too. Remove them.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/linux/mfd/tmio.h | 18 --
1 files changed, 0 insertions(+), 18 deletions(-)
diff --git
Add parsing of common and driver-specific DT bindings to the tmio-mmc
MMC host driver.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Arnd Bergmann a...@arndb.de
---
v3: remove the toshiba,mmc-cap-sdio-irq property
drivers/mmc/host/tmio_mmc_pio.c | 24 ++--
The extern keyword isn't required in function declarations, remove it.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/linux/mmc/host.h | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/linux/mmc/host.h
The struct sh_mobile_sdhi_info::pdata field was only used for platform-
based card detection and isn't used anymore since the migration to GPIO-
based MMC slot functions. Remove it.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/host/sh_mobile_sdhi.c |4
On Wed, Feb 06, 2013 at 07:37:37PM +, Jonathan Cameron wrote:
On 02/06/2013 06:29 PM, Guenter Roeck wrote:
Provide bindings and parse OF data during initialization.
Signed-off-by: Guenter Roeck li...@roeck-us.net
looks good to me. Couple of little queries inline.
---
v4:
-
On Wednesday 06 of February 2013 12:05:13 Guenter Roeck wrote:
On Wed, Feb 06, 2013 at 07:37:37PM +, Jonathan Cameron wrote:
On 02/06/2013 06:29 PM, Guenter Roeck wrote:
Provide bindings and parse OF data during initialization.
Signed-off-by: Guenter Roeck li...@roeck-us.net
From: Thomas Gleixner t...@linutronix.de
With the locking cleanup in place (from OF: Fixup resursive
locking code paths), we can now do the conversion from the
rw_lock to a raw spinlock as required for preempt-rt.
The previous cleanup and this conversion were originally
separate since they
Adds device-tree bindings from SDMA on OMAP2+ devices. DMA client
bindings are also added for devices that have SPI and MMC bindings
populated. Client binding data is based upon existing HWMOD data for
OMAP and has been checked against OMAP documentation.
Testing includes ...
1. Boot tested on
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC periperhal on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter
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
---
drivers/dma/omap-dma.c | 31 ++-
1
1 - 100 of 129 matches
Mail list logo
