Hi,
On 02/06/2013 02:30 PM, Benoit Cousson wrote:
>> So a patch is being merged to handle triggers in the case of pwm leds [1].
>> When done, we will be able to add back the default trigger. Do you want
>> to wait on it to merge this series?
>
> What kind of dependency do we have between these tw
Add DT entry for MMC. Also add entry for pinmux information.
Tested on da850-evm without card detect and EDMA support as
DT support for GPIO and EDMA are yet come.
Signed-off-by: Manjunathappa, Prakash
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.ke
Adds device tree support for davinci_mmc. Also add binding documentation.
Tested in non-dma PIO mode and without GPIO card_detect/write_protect
option because of dependencies on EDMA and GPIO module DT support.
Signed-off-by: Manjunathappa, Prakash
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker.
Patch set adds DT support for davinci_mmc driver and is
verified on da850-evm without card_detect/write_protect and
EDMA support.
This patch depends on below patches under review:
1) Patch "drivers/pinctrl: grab default handles from device core"
http://www.gossamer-threads.com/lists/linux/
Populate OF_DEV_AUXDATA with desired device name expected by
davinci_mmc driver. Without this clk_get of davinci_mmc DT driver
fails.
Signed-off-by: Manjunathappa, Prakash
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: davinci-linux-ope
On 02/07/2013 12:06 PM, Manish Badarkhe wrote:
> Hi Tushar
>
> On Thu, Feb 7, 2013 at 11:56 AM, Tushar Behera
> wrote:
>> On 02/07/2013 11:47 AM, Kumar, Anil wrote:
>>> On Thu, Feb 07, 2013 at 10:45:25, Tushar Behera wrote:
Added GPIO buttons DT node to Arndale board file.
Signed-
Hi,
On Thursday 07 February 2013 11:51 AM, Rajendra Nayak wrote:
[]...
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentatio
On 02/07/2013 11:47 AM, Kumar, Anil wrote:
> On Thu, Feb 07, 2013 at 10:45:25, Tushar Behera wrote:
>> Added GPIO buttons DT node to Arndale board file.
>>
>> Signed-off-by: Tushar Behera
>> Signed-off-by: Sachin Kamat
>> ---
>> This series is based on for-next branch of Kukjin Kim's tree
>> and
[]...
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB
On Thu, Feb 07, 2013 at 10:45:25, Tushar Behera wrote:
> Added GPIO buttons DT node to Arndale board file.
>
> Signed-off-by: Tushar Behera
> Signed-off-by: Sachin Kamat
> ---
> This series is based on for-next branch of Kukjin Kim's tree
> and added on top of the below patch:
> https://patchwor
On 02/07/2013 11:19 AM, Kumar, Anil wrote:
> On Thu, Feb 07, 2013 at 10:45:26, Tushar Behera wrote:
>> From: Amit Daniel Kachhap
>>
>> Added S5M8767 PMIC DT nodes to Arndale board.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> Signed-off-by: Sachin Kamat
>> Signed-off-by: Tushar Behera
>> ---
>>
On Thu, Feb 07, 2013 at 10:45:26, Tushar Behera wrote:
> From: Amit Daniel Kachhap
>
> Added S5M8767 PMIC DT nodes to Arndale board.
>
> Signed-off-by: Amit Daniel Kachhap
> Signed-off-by: Sachin Kamat
> Signed-off-by: Tushar Behera
> ---
> arch/arm/boot/dts/exynos5250-arndale.dts | 213
>
From: Sachin Kamat
Added HDMI hot plug and regulator nodes to Arndale DT file.
Signed-off-by: Sachin Kamat
Signed-off-by: Tushar Behera
---
arch/arm/boot/dts/exynos5250-arndale.dts | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos525
From: Sachin Kamat
Added MFC codec node to Arndale DT file.
Signed-off-by: Sachin Kamat
Signed-off-by: Tushar Behera
---
arch/arm/boot/dts/exynos5250-arndale.dts |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/b
From: Sachin Kamat
Added vmmc regulator node to Arndale DT file.
Signed-off-by: Sachin Kamat
Signed-off-by: Tushar Behera
---
arch/arm/boot/dts/exynos5250-arndale.dts | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
From: Amit Daniel Kachhap
Added S5M8767 PMIC DT nodes to Arndale board.
Signed-off-by: Amit Daniel Kachhap
Signed-off-by: Sachin Kamat
Signed-off-by: Tushar Behera
---
arch/arm/boot/dts/exynos5250-arndale.dts | 213 +-
1 files changed, 212 insertions(+), 1 deleti
Added GPIO buttons DT node to Arndale board file.
Signed-off-by: Tushar Behera
Signed-off-by: Sachin Kamat
---
This series is based on for-next branch of Kukjin Kim's tree
and added on top of the below patch:
https://patchwork.kernel.org/patch/2042451/
---
arch/arm/boot/dts/exynos5250-arndale.d
Hi Sylwester,
On Wed, Feb 6, 2013 at 8:20 PM, Sylwester Nawrocki
wrote:
> 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 co
On Wed, Feb 06, 2013 at 07:37:37PM +, Jonathan Cameron wrote:
> On 02/06/2013 06:29 PM, Guenter Roeck wrote:
> > Provide bindings and parse OF data during initialization.
> >
> > Signed-off-by: Guenter Roeck
> looks good to me. Couple of little queries inline.
>
[ ... ]
> > +
> > +Example
Hi Iwamatsu-san
> >> +Required properties:
> >> +- compatible: "renesas,sh-eth";
> >> +- interrupt-parent: The phandle for the interrupt controller
> >> that
> >> +services interrupts for this device.
> >> +- reg:
On Wed, Feb 06, 2013 at 10:24:20PM +, Arnd Bergmann wrote:
> On Wednesday 06 February 2013, Guennadi Liakhovetski wrote:
> > +* Toshiba Mobile IO SD/MMC controller
> > +
> > +The tmio-mmc driver doesn't probe its devices actively, instead its
> > binding to
> > +devices is managed by either MF
Support for loading the simple-card module via devicetree.
It requests cpu/codec information for probing.
Signed-off-by: Kuninori Morimoto
---
v3 -> v4
- removed port-name
- it gets dai_name from node and port number
v4 -> v5
- fixup compile error on !CONFIG_OF
.../devicetree/bindings/sou
On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote:
> Before the camera ports can be used the pinmux needs to be configured
> properly. This patch adds a function to set the camera ports pinctrl
> to a default state within the media driver's probe().
> The camera port(s) are then configured for the v
On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote:
> The sensor (I2C and/or SPI client) devices are instantiated by their
> corresponding control bus drivers. Since the I2C client's master clock
> is often provided by a video bus receiver (host interface) or other
> than I2C/SPI controller device, t
On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote:
> This patch adds support for FIMC devices instantiated from devicetree
> for S5PV210 and Exynos4 SoCs. The FIMC IP features include colorspace
> conversion and scaling (mem-to-mem) and parallel/MIPI CSI2 bus video
> capture interface.
>
> Multiple
On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote:
> s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC
> device. This patch support for binding the driver to the MIPI-CSIS
> devices instantiated from device tree and for parsing all SoC and
> board specific properties.
> diff --gi
On Wednesday 06 February 2013, Guennadi Liakhovetski wrote:
> +*NOTE* on CD and WP polarity. As of 3.8, SD/MMC drivers parse their DT nodes
> +each in its own way, including calculation of CD and WP polarities. Our goal
> is
> +to implement a common MMC DT parser and convert all drivers to using i
On Wednesday 06 February 2013, Guennadi Liakhovetski wrote:
> +* Toshiba Mobile IO SD/MMC controller
> +
> +The tmio-mmc driver doesn't probe its devices actively, instead its binding
> to
> +devices is managed by either MFD drivers or by the sh_mobile_sdhi platform
> +driver. Those drivers supply
On Wednesday 06 February 2013, Guennadi Liakhovetski wrote:
>
> 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 anythi
On 02/06/2013 03:03 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
> ---
> drivers/dma/omap-dma.c | 31
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
---
drivers/dma/omap-dma.c | 31 ++-
1 file changed, 30 inse
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
---
.../devi
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 OMA
From: Thomas Gleixner
With the locking cleanup in place (from "OF: Fixup resursive
locking code paths"), we can now do the conversion from the
rw_lock to a raw spinlock as required for preempt-rt.
The previous cleanup and this conversion were originally
separate since they predated when mainline
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
> >
> > loo
On Wed, Feb 06, 2013 at 07:37:37PM +, Jonathan Cameron wrote:
> On 02/06/2013 06:29 PM, Guenter Roeck wrote:
> > Provide bindings and parse OF data during initialization.
> >
> > Signed-off-by: Guenter Roeck
> looks good to me. Couple of little queries inline.
>
> > ---
> > v4:
> > - Fixed
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
---
drivers/mmc/host/sh_mobile_sdhi.c |4
include/linux/mmc/sh_mobi
The "extern" keyword isn't required in function declarations, remove it.
Signed-off-by: Guennadi Liakhovetski
---
include/linux/mmc/host.h | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 13c
Add parsing of common and driver-specific DT bindings to the tmio-mmc
MMC host driver.
Signed-off-by: Guennadi Liakhovetski
Cc: Arnd Bergmann
---
v3: remove the "toshiba,mmc-cap-sdio-irq" property
drivers/mmc/host/tmio_mmc_pio.c | 24 ++--
1 files changed, 22 insertions(
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
---
include/linux/mfd/tmio.h | 18 --
1 files changed, 0 insertions(+), 18 deletions(-)
diff --git a/include/linux/mfd/tmio.h b
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 par
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
tur
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
m
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 mmc_allo
Without barriers SDIO operations fail with runtime PM enabled.
Signed-off-by: Guennadi Liakhovetski
Cc: Paul Mundt
---
v3: use iowrite16_rep() and ioread16_rep() for consistency.
drivers/mmc/host/tmio_mmc.h | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --g
Clarify ways to specify write-protect and card-detect MMC lines in FDT.
Cc: Arnd Bergmann
Signed-off-by: Guennadi Liakhovetski
---
v3: {wp,cd}-inverted properties can now be used together with GPIO
binding flags. A detailed explanation added.
Documentation/devicetree/bindings/mmc/mmc.txt
Use managed allocations to get memory, clock and interrupts . This
significantly simplifies clean up paths.
Signed-off-by: Guennadi Liakhovetski
---
drivers/mmc/host/sh_mobile_sdhi.c | 57 +
1 files changed, 14 insertions(+), 43 deletions(-)
diff --git a/dr
Use mmc_of_parse() to get interface capability flags and used GPIOs from
device-tree bindings.
Cc: Arnd Bergmann
Signed-off-by: Guennadi Liakhovetski
---
v3: updated on top of "mmc: sh_mmcif: Avoid unnecessary mmc_delay() at
mmc_card_sleepawake()"
drivers/mmc/host/sh_mmcif.c |3 ++-
1
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
---
drivers/mmc/host/sh_mobile_sdhi.c |3 +--
Define device-tree bindings for the tmio-mmc driver to be able to specify
parameters, currently provided in platform data.
Cc: Arnd Bergmann
Signed-off-by: Guennadi Liakhovetski
---
v3: make the property to set TMIO_MMC_SDIO_IRQ global
Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 15
On 02/06/2013 06:29 PM, Guenter Roeck wrote:
> Provide bindings and parse OF data during initialization.
>
> Signed-off-by: Guenter Roeck
looks good to me. Couple of little queries inline.
> ---
> v4:
> - Fixed wrong parameter to dummy of_iio_channel_get_by_name if CONFIG_OF is
> undefined, a
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 re
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
Applied to togreg bran
On Tue, Feb 5, 2013 at 6:56 PM, 김승우 wrote:
>
>
> On 2013년 02월 06일 09:56, Sean Paul wrote:
>> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren wrote:
>>> On 02/05/2013 05:37 PM, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
wrote:
> n 02/05/2013 04:42 PM, Sean Paul
Provide bindings and parse OF data during initialization.
Signed-off-by: Guenter Roeck
---
v4:
- Fixed wrong parameter to dummy of_iio_channel_get_by_name if CONFIG_OF is
undefined, and wrong return value.
- Initialize indio_dev->of_node in iio_device_register if the calling driver
neglected
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
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 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 tre
On Thu, Feb 7, 2013 at 1:54 AM, Arnd Bergmann wrote:
> On Wednesday 06 February 2013 17:38:20 Linus Walleij wrote:
>> On Wed, Jan 9, 2013 at 9:43 PM, Thierry Reding
>> wrote:
>>
>> > When using deferred driver probing, PCI host controller drivers may
>> > actually require this function after the
From: Lars Poeschel
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 chipselect.
Signed-off-by:
From: Lars Poeschel
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
---
drivers/gpio/gpio-mcp23s08.c |4 ++--
1 file changed, 2 insertions(+), 2 deletio
From: Lars Poeschel
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 Poeschel (2):
gpio: mc
On Wednesday 06 February 2013 17:38:20 Linus Walleij wrote:
> On Wed, Jan 9, 2013 at 9:43 PM, 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
>
> Ther
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
> suppl
Hi David,
On Tue, Feb 5, 2013 at 11:16 PM, David Gibson
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 to be a tool for dump
On Wed, Jan 9, 2013 at 9:43 PM, 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
There seem to be a proliferation of these patches now.
Isn't this just papering o
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
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.
On 02/04/2013 10:05 AM, Paul Gortmaker wrote:
> From: Thomas Gleixner
>
> With the locking cleanup in place (from "OF: Fixup resursive
> locking code paths"), we can now do the conversion from the
> rw_lock to a raw spinlock as required for preempt-rt.
>
> The previous cleanup and the this conve
(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:
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
> Acked-by: Arnd Berg
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
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
---
arch/arm/boot/dts/omap5.dtsi | 14 ++
1 file changed, 14 insertions(+)
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-.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 mode.
The
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
Signed-off-by: Kishon Vija
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
---
arch/a
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: dt
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
---
arch
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
---
arch/arm/boot/dts/omap5.dtsi |7 +++
1 file changed, 7 insert
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
---
arch/arm/boot/dts/omap5.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --gi
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
---
arch/arm/boot/dts/omap5.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arc
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 t
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
On Wed, Feb 6, 2013 at 1:32 PM, James Hogan 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 a risk of b
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: Rah
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 from
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 opti
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 p
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 eff
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 sup
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 D
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 boa
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 fo
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
---
Depends on patch: "arm: mvebu: i2c come back in defconfig"
arch/arm/configs/mvebu_defconfig |3 +++
1 files changed, 3 insertions(+), 0 deletions
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
Cc: Lior Amsalem
Tested-by: Gregory Clemen
Cc: Thomas Petazzoni
Cc: Lior Amsalem
Acked-by: Gregory Clement
Signed-off-by: Ezequiel Garcia
---
arch/arm/configs/mvebu_defconfig |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 43a0dbf..322ba
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 t
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
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 i
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 Febr
1 - 100 of 130 matches
Mail list logo
