On 08/16/2012 10:05 PM, Thomas Abraham wrote:
> Add device tree based discovery support for Samsung's sdhci controller
>
> Cc: Ben Dooks
> Cc: Kukjin Kim
> Cc: Chris Ball
> Signed-off-by: Thomas Abraham
> ---
> Changes since v3:
>
> The patch series that adds device tree support for Samsung s
On Wed, Aug 15, 2012 at 01:38:45PM +0100, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla
>
> This patch allows dtc to strip out nodes in its output based on status
> property. Now the dtc has additional long option --strip-disabled to
> strip all the nodes which have status property set t
On Thu, Aug 16, 2012 at 22:27:42, Hunter, Jon wrote:
>
> On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
> >
> >
> > On 7/14/2012 3:56 AM, Jon Hunter wrote:
> >> OMAP3 devices may or may not have security features enabled. Security
> >> enabled
> >> devices are known as high-secure (HS) and dev
On 08/16/2012 07:52 PM, Shawn Guo wrote:
> On Thu, Aug 16, 2012 at 11:05:54PM +0200, Rafael J. Wysocki wrote:
>> On Friday, August 10, 2012, Shawn Guo wrote:
>>> With a lot of devices booting from device tree nowadays, it requires
>>> that OPP table can be initialized from device tree. The patch a
Hi,
2012/8/16 Leela Krishna Amudala :
> Add device tree based discovery support for DRM-FIMD driver.
>
> Signed-off-by: Leela Krishna Amudala
> ---
> Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95
>
On Thu, Aug 16, 2012 at 11:05:54PM +0200, Rafael J. Wysocki wrote:
> On Friday, August 10, 2012, Shawn Guo wrote:
> > With a lot of devices booting from device tree nowadays, it requires
> > that OPP table can be initialized from device tree. The patch adds
> > a helper function of_init_opp_table
Hi Leela.
2012/8/16 Leela Krishna Amudala :
> The name of the exynos drm fimd device is renamed to exynos-drm-fimd
> and two device ids are created for exynos4-fb and exynos5-drm-fimd.
> Also, added driver data for exynos5 to pick the fimd version at runtime and
> to choose the VIDTCON register of
On Thu, Aug 16, 2012 at 06:47:31PM +0800, Hui Wang wrote:
> i.MX6Q sabrelite board uses i2c3 to connect an eeti egalax
> touchscreen controller, add it as an i2c slave device in the dts.
>
> Signed-off-by: Hui Wang
Looks good. Will apply it after the driver part gets accepted.
--
Regards,
Sha
On Thu, Aug 16, 2012 at 06:47:30PM +0800, Hui Wang wrote:
> The egalax_ts driver needs to get the gpio number of the irq pin,
> and use this gpio to wake up the controller. So add a note
> for this change.
>
> Signed-off-by: Hui Wang
Reviewed-by: Shawn Guo
__
On Thu, Aug 16, 2012 at 06:47:29PM +0800, Hui Wang wrote:
> The irq_to_gpio() is old, most platforms use GENERIC_GPIO framework
> and don't support this API anymore.
>
> The i.MX6q sabrelite platform equips an egalax touchscreen controller,
> and this platform already transfered to GENERIC_GPIO fr
On Aug 16, 2012 3:46 PM, "Mitch Bradley" wrote:
>
> Here is the situation: We (OLPC) have an audio codec that is strongly
> associated with an audio controller, but it also has some registers that
> you get at with I2C.
>
> In some sense, the codec has two parents, the audio controller
> (connect
Here is the situation: We (OLPC) have an audio codec that is strongly
associated with an audio controller, but it also has some registers that
you get at with I2C.
In some sense, the codec has two parents, the audio controller
(connected via I2S) and the I2C controller.
Is there an established L
On Thursday, August 16, 2012, Alexandre Courbot wrote:
> Overdue revision of this new feature, some changes required additional thought
> and rework.
>
> The most important change is in the way power sequences are expressed in the
> device tree. In order to avoid having to specify #address-cells,
On 8/16/2012 9:34 AM, Stephen Warren wrote:
> As I understand it, there is a rule when writing device tree files (and
> bindings) that nodes should be named after the type of object they
> represent, and not the particular instance of the object. Related, node
> names should not be interpreted as d
On 08/15/2012 09:30 PM, Dong Aisheng wrote:
> On Wed, Aug 15, 2012 at 09:59:50PM +0800, Shawn Guo wrote:
> ...
>>> Another known issue is that via this way, that means the pinctrl subsystem
>>> can only see the using pads, this is a bit not align with the pinctrl
>>> subsystem design. No sure if Li
On 8/16/2012 8:38 AM, Stephen Warren wrote:
> On 08/16/2012 12:08 AM, Alexandre Courbot wrote:
>> Some device drivers (panel backlights especially) need to follow precise
>> sequences for powering on and off, involving gpios, regulators, PWMs
>> with a precise powering order and delays to respect b
On Friday, August 10, 2012, Shawn Guo wrote:
> With a lot of devices booting from device tree nowadays, it requires
> that OPP table can be initialized from device tree. The patch adds
> a helper function of_init_opp_table together with a binding doc for
> that purpose.
>
> Signed-off-by: Shawn G
On Thu, Aug 16, 2012 at 12:38:33PM -0600, Stephen Warren wrote:
> On 08/16/2012 12:08 AM, Alexandre Courbot wrote:
> > diff --git a/Documentation/power/power_seq.txt
> > b/Documentation/power/power_seq.txt
>
> > +Usage by Drivers and Resources Management
> > +-
* Add a ioctls for adding/removing nodes using binary blobs.
Signed-off-by: Alan Tull
---
drivers/of/Makefile |1 +
drivers/of/dynamic.c | 287 ++
drivers/of/dynamic.h | 26 +
3 files changed, 314 insertions(+), 0 deletions(-)
create
Hello,
I'm Alan Tull, interested in dynamic features of device trees.
The following patch adds a char driver to add or remove device tree
nodes dynamically. Its ioctl passes a struct with:
- size of the blob
- pointer to the blob
The path to add the nodes under is coded in the blob with dumm
On 08/16/2012 12:57 PM, Stephen Warren wrote:
> On 08/16/2012 12:47 PM, Mark Brown wrote:
>> On Thu, Aug 16, 2012 at 12:38:33PM -0600, Stephen Warren wrote:
>>
>>> Note that this somewhat conflicts with accessing the top-level power
>>> sequence by name too; perhaps that should be re-thought too. I
As I understand it, there is a rule when writing device tree files (and
bindings) that nodes should be named after the type of object they
represent, and not the particular instance of the object. Related, node
names should not be interpreted as data.
This rules makes perfect sense when talking ab
On 08/16/2012 12:47 PM, Mark Brown wrote:
> On Thu, Aug 16, 2012 at 12:38:33PM -0600, Stephen Warren wrote:
>
>> Note that this somewhat conflicts with accessing the top-level power
>> sequence by name too; perhaps that should be re-thought too. I must
>> admit this DT rule kinda sucks.
>
> Given
On Wed, Aug 15, 2012 at 10:30 PM, Dong Aisheng wrote:
> On Wed, Aug 15, 2012 at 09:59:50PM +0800, Shawn Guo wrote:
> ...
>> > Another known issue is that via this way, that means the pinctrl subsystem
>> > can only see the using pads, this is a bit not align with the pinctrl
>> > subsystem design.
On Thu, Aug 16, 2012 at 12:38:33PM -0600, Stephen Warren wrote:
> Note that this somewhat conflicts with accessing the top-level power
> sequence by name too; perhaps that should be re-thought too. I must
> admit this DT rule kinda sucks.
Given that currently the information there is useless and
ather than add that as a separate node at the top-level, I think just
add another sub-node to the "regulators" node. Oh, in fact it's already
there in next-20120816; you just need to add a label.
> +++ b/arch/arm/boot/dts/tegra20.dtsi
> - pwm {
> + pwm: pwm {
>
On 08/16/2012 12:08 AM, Alexandre Courbot wrote:
> Make use of the power sequences specified in the device tree or platform
> data to control how the backlight is powered on and off.
> +++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> Required properties:
>- compati
On 08/16/2012 12:08 AM, Alexandre Courbot wrote:
> Some device drivers (panel backlights especially) need to follow precise
> sequences for powering on and off, involving gpios, regulators, PWMs
> with a precise powering order and delays to respect between each steps.
> These sequences are board-sp
On 16 August 2012 22:22, Chris Ball wrote:
> Hi Thomas,
>
> On Thu, Aug 16 2012, Thomas Abraham wrote:
>> +Optional Board Specific Properties:
>> +- One of the following properties for card detect type.
>> + - samsung,sdhci-cd-internal: Card detect line from the card slot is
>> +connected to
On Thu, Aug 16, 2012 at 09:18:20AM -0600, Stephen Warren wrote:
> On 08/15/2012 12:49 AM, Thierry Reding wrote:
> ...
> > Stephen: Could you try to find out whether the regular
> > configuration space translation can just be omitted if we already
> > set up the one for the extended configuration sp
On Wed, Aug 15, 2012 at 10:45 PM, Shawn Guo wrote:
> On Wed, Aug 15, 2012 at 11:49:01AM -0500, Matt Sealey wrote:
>> > Rather than betting how DTC will implement macro, we'd better make the
>> > the safest assumption - it will not support that syntax.
>>
>> It won't.
>
> There were a lot of pushin
On Fri, Jul 20, 2012 at 06:18:46PM +0300, Dan Carpenter wrote:
> On Fri, Jul 20, 2012 at 08:00:42AM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Jul 20, 2012 at 09:56:23AM +0300, Dan Carpenter wrote:
> > > What prompted this patch is that in dma_pool_create() we call
> > > dev_to_node() before chec
On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
>
>
> On 7/14/2012 3:56 AM, Jon Hunter wrote:
>> OMAP3 devices may or may not have security features enabled. Security enabled
>> devices are known as high-secure (HS) and devices without security are known
>> as
>> general purpose (GP).
>>
>> For
Hi Thomas,
On Thu, Aug 16 2012, Thomas Abraham wrote:
> +Optional Board Specific Properties:
> +- One of the following properties for card detect type.
> + - samsung,sdhci-cd-internal: Card detect line from the card slot is
> +connected to the card detect pad of the sdhci controller. A gpio i
The SDHCI controller nodes in platforms which are based on Samsung's Exynos4210
SoC are using the older custom Samsung SDHCI bindings. Remove the old Samsung
specific bindings and use the generic mmc bindings that are defined for mmc
controllers.
Cc: Kukjin Kim
Cc: Chris Ball
Signed-off-by: Thom
On 16 August 2012 21:59, Chris Ball wrote:
> Hi,
>
> On Thu, Aug 16 2012, Thomas Abraham wrote:
>> Add device tree based discovery support for Samsung's sdhci controller
>>
>> Cc: Ben Dooks
>> Cc: Kukjin Kim
>> Cc: Chris Ball
>> Signed-off-by: Thomas Abraham
>> ---
>> Changes since v3:
>>
>> T
Hi,
On Thu, Aug 16 2012, Thomas Abraham wrote:
> Add device tree based discovery support for Samsung's sdhci controller
>
> Cc: Ben Dooks
> Cc: Kukjin Kim
> Cc: Chris Ball
> Signed-off-by: Thomas Abraham
> ---
> Changes since v3:
>
> The patch series that adds device tree support for Samsung s
Add device tree based discovery support for Samsung's sdhci controller
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Chris Ball
Signed-off-by: Thomas Abraham
---
Changes since v3:
The patch series that adds device tree support for Samsung sdhci controller
had six patches in total, of which, the first five
Hi Chris,
Thanks for your review.
On 16 August 2012 21:17, Chris Ball wrote:
> Hi Thomas,
>
> On Thu, Aug 16 2012, Thomas Abraham wrote:
>> Add device tree based discovery support for Samsung's sdhci controller
>>
>> Cc: Ben Dooks
>> Cc: Kukjin Kim
>> Cc: Chris Ball
>> Signed-off-by: Thomas A
Hi Thomas,
On Thu, Aug 16 2012, Thomas Abraham wrote:
> Add device tree based discovery support for Samsung's sdhci controller
>
> Cc: Ben Dooks
> Cc: Kukjin Kim
> Cc: Chris Ball
> Signed-off-by: Thomas Abraham
> ---
> drivers/mmc/host/sdhci-s3c.c | 146
> +++
Add a doc to describe the Xen ARM device tree bindings
Signed-off-by: Stefano Stabellini
CC: devicetree-discuss@lists.ozlabs.org
CC: David Vrabel
---
Documentation/devicetree/bindings/arm/xen.txt | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 10064
Add device tree based discovery support for Samsung's sdhci controller
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Chris Ball
Signed-off-by: Thomas Abraham
---
drivers/mmc/host/sdhci-s3c.c | 146 --
1 files changed, 140 insertions(+), 6 deletions(-)
diff --git a
On 08/15/2012 12:49 AM, Thierry Reding wrote:
...
> Stephen: Could you try to find out whether the regular
> configuration space translation can just be omitted if we already
> set up the one for the extended configuration space? In
> tegra_pcie_setup_translations(), BAR 0 is setup for regular
> co
On Aug 16, 2012, at 6:18 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 16:38 Wed 15 Aug , Linus Walleij wrote:
>>> +static void at91_mux_pio3_set_A_periph(void __iomem *pio, unsigned mask)
>>> +{
>>> +
>>> + __raw_writel(__raw_readl(pio + PIO_ABCDSR1) & ~mask,
>>> +
Hi Vaibhav,
On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
>
>
> On 7/23/2012 8:54 PM, Jon Hunter wrote:
>> Hi Rob,
>>
>> On 07/16/2012 10:56 AM, Jon Hunter wrote:
>>> Hi Rob,
>>>
>>> On 07/13/2012 09:15 PM, Rob Herring wrote:
On 07/13/2012 05:26 PM, Jon Hunter wrote:
> Add the 12 GP t
On 16:38 Wed 15 Aug , Linus Walleij wrote:
> (Hm maybe I should've read this patch first, well whatever.)
>
> On Fri, Aug 10, 2012 at 3:02 PM, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>
> > This is also include the gpio controller as the IP share both.
> > Each soc will have to describe the
On Thu, Aug 16, 2012 at 03:08:55PM +0900, Alexandre Courbot wrote:
> + power-off-sequence {
> + step0 {
> + gpio = "enable";
> + disable;
I'd change the name to "reset" or something in the example - avoids any
On Thursday 16 August 2012, Linus Walleij wrote:
> + fpga {
> + compatible = "arm,amba-bus", "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + rtc: rtc@1500 {
> + c
On Thursday 16 August 2012, Linus Walleij wrote:
> +- irq-start: the u32 hardware IRQ number of the first interrupt handled by
> + this FPGA IRQ instance - since there may be many FPGA IRQ controller
> + instances, each will have its unique hardware offset number.
The irq-start value is a Linux
On Thursday 16 August 2012, Linus Walleij wrote:
> There is currently a common integrator_init() function set up
> to be called from an arch_initcall(). The problem is that it is
> using machine_is_integrator() which is not working with device
> tree, let's call this from respective machine initili
On Thursday 16 August 2012, Linus Walleij wrote:
> This patch set moves all the non-DT platform code into
> #ifndef CONFIG_OF sections for clarity. The plan is to
> delete them after deprecation.
I'm fine with your playing around with this in any way you
like, but I think in general we should have
Device tree support for McBSP modules on OMAP2+ SoC.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/sound/omap-mcbsp.txt | 45 +
sound/soc/omap/omap-mcbsp.c| 66 +++-
2 files changed, 110 insertions(+), 1 deletions(-)
crea
Only create the devices in a legacy way if we do not have the DT data.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/mcbsp.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 660e00b..d57a357 100644
We can use the has_ccr flag to replace the cpu_is_omap* checks.
This provides future proof implementation and we do not need to update the
code if new OMAP revision starts to use the McBSP driver.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
sound/soc/omap/omap-mcbsp.c |8 +
NUM_LINKS is no longer in use by the code.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
sound/soc/omap/omap-mcbsp.h | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/omap/omap-mcbsp.h
index baebcee..ba83
Remove the feature to configure the CLKR/FSR mux on McBSP port with 6pin
configuration.
When moving to devicetree these callback can no longer be used in a clean
way anymore.
If a board require to change the 6pin port to work in 4pin setup it needs
to set up the mux in the board file.
For OMAP2/3:
The muxing is done at board level, no need to do it in the ASoC machine
driver.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
sound/soc/omap/am3517evm.c | 20 ++--
1 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/sound/soc/omap/am3517evm.c b/sound/so
am3517evm board uses McBSP1 for audio with 4pin configuration.
The CLKR/FSR signals need to be connected to CLKX/FSX pin of the SoC in
this case.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
arch/arm/mach-omap2/board-am3517evm.c | 13 +
1 files changed, 13 insertions(
Hello,
Changes since v2:
- Replaced the IS_ERR_OR_NULL() with IS_ERR()
Changes since v1:
- ICLK workaround for the sidetone module has been kept for legacy mode.
Intro mail from v2:
in order to be able to add DT support for the McBSP driver which is used on all
OMAP platforms (OMAP1/2/3/4/5) I
Move the McBSP CLKS re-parenting code to ASoC driver from
arch/arm/mach-omap2.
The call fort the re-parenting has been already limited to OMAP2+ SoC in
the ASoC driver. There is no longer need to have callback function for it.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
arch/arm/m
On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
the FIFO for the audio stack.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
---
arch/arm/mach-omap2/mcbsp.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b
On 14:16 Thu 16 Aug , Linus Walleij wrote:
> This converts the AMBA (PrimeCell) devices on the Integrator/AP
> and Integrator/CP over to probing from the Device Tree if the
> kernel is compiled for Device Tree support.
>
> We continue to #ifdef out all non-DT code and vice versa on
> respectiv
There is currently a common integrator_init() function set up
to be called from an arch_initcall(). The problem is that it is
using machine_is_integrator() which is not working with device
tree, let's call this from respective machine initilization
function and add a parameter to tell whether it's
This moves the physmap flash and SMSC91x ethernet devices
over to the device tree, moving the static board code down
into the #ifndef CONFIG_OF section.
Signed-off-by: Linus Walleij
---
arch/arm/boot/dts/integratorap.dts | 5 ++
arch/arm/boot/dts/integratorcp.dts | 12 +
arch/ar
This converts the AMBA (PrimeCell) devices on the Integrator/AP
and Integrator/CP over to probing from the Device Tree if the
kernel is compiled for Device Tree support.
We continue to #ifdef out all non-DT code and vice versa on
respective boot type to get a clean cut.
We need to add a bunch of
This is initial device tree support for the ARM Integrator family,
we create a very basic device tree, #ifdef out the non-DT machines
when compiling for device tree.
Signed-off-by: Linus Walleij
---
Documentation/devicetree/bindings/arm/arm-boards | 12 +++
arch/arm/boot/dts/integratorap.dts
This adds Device Tree probing support to the Versatile FPGA
IRQ controller.
Signed-off-by: Linus Walleij
---
.../devicetree/bindings/arm/versatile-fpga-irq.txt | 35 ++
arch/arm/plat-versatile/fpga-irq.c | 41 ++
arch/arm/plat-versatile/include
In the PL010 UART callback a comparison against the base address is
done to figure out which UART is doing the callback. This does not
play well with device tree, so let's check the dev_name() of the
device instead.
Signed-off-by: Linus Walleij
---
arch/arm/mach-integrator/core.c | 2 +-
1 file
Adds basic pinctrl device tree data for AM33XX family of devices.
This patch is based on the pinctrl-single driver.
Signed-off-by: AnilKumar Ch
---
Changes from v3:
- Updated the reg length based on latest AM335x TRM.
Changes from v2:
- user led pinmux comments updated according
This is a patch set for devicetree on the Integrator/AP and
Integrator/CP I've been cooking. I did some stepwise development
in recent kernels moving to sparse IRQs, per-system clock
source then common clk. Now we can do single zImage and
also devicetree on this platform, so this is a first patch
s
Add Bosch D_CAN controller device tree data to AM33XX dtsi
file by adding d_can device nodes with all the necessary
parameters.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-evm.dts |4
arch/arm/boot/dts/am33xx.dtsi| 18 ++
2 files changed, 22 insertions
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-bone.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
Add D_CAN1 pinctrl node to am3358_pinmux master node to export
D_CAN functionality on AM335x EVM according to pinctrl-single
driver.
Signed-off-by: AnilKumar Ch
---
Changes from v2:
- Incorporated Vaibhav H's comments on v2
* Added dcan0 instances to am33xx.dtsi file
Changes fr
Add pinctrl and d_can device tree data to AM33XX family of devices.
First two patches add support for pinctrl DT data and rest adds
dcan DT data.
Reason behind combining these patches is to apply cleanly on
linux-omap devel-dt tree because these are sequential patches.
These patches were tested o
On Wed, Aug 15, 2012 at 05:18:04AM -0700, Bjorn Helgaas wrote:
> On Tue, Aug 14, 2012 at 11:37 PM, Thierry Reding
> wrote:
> > On Tue, Aug 14, 2012 at 04:50:26PM -0700, Bjorn Helgaas wrote:
> >> On Tue, Aug 14, 2012 at 1:12 PM, Thierry Reding
> >> wrote:
> >> > On Thu, Jul 26, 2012 at 09:55:12PM
TWL6040 provides GPO lines to be used for controlling external devices.The
number
of lines different between versions: twl6040 have 3 GPO while TWL6041 have 1.
Signed-off-by: Sergio Aguirre
Signed-off-by: Peter Ujfalusi
Acked-by: Linus Walleij
---
drivers/gpio/Kconfig|7 ++
driver
Add needed platform data structure and code to be able to load
the GPO child of twl6040.
Update the devicetree binding documentation at the same time.
Signed-off-by: Sergio Aguirre
Signed-off-by: Peter Ujfalusi
---
Documentation/devicetree/bindings/mfd/twl6040.txt |9 ++---
drivers/mfd/
Signed-off-by: Peter Ujfalusi
---
include/linux/mfd/twl6040.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
index eaad49f..269b706 100644
--- a/include/linux/mfd/twl6040.h
+++ b/include/linux/mfd/twl6040.h
@@ -1
Hello,
Changes since v1:
- Removed the ti,use-gpo property from DT bindings
- Register the GPO driver if we booted with DT blob or in legacy if the pdata
for the GPO driver is present
- DT binding Documentation update
The Documentation update has reference to the twl6040.dtsi file which will be
On 16 August 2012 18:01, Arun Kumar K wrote:
> From: Naveen Krishna Chatradhi
>
> This patch adds device tree entry for MFC in the Exynos
> machines. Exynos4 SoCs support MFC v5 version and Exynos5 has
> MFC v6.x version. So making the required changes in the clock
> files and adds MFC to the DT
On Thu, Aug 16, 2012 at 07:33:27PM +0900, Alex Courbot wrote:
> On 08/16/2012 06:52 PM, Thierry Reding wrote:
> >* PGP Signed by an unknown key
> >
> >On Thu, Aug 16, 2012 at 06:19:08PM +0900, Alex Courbot wrote:
> >>On 08/16/2012 04:42 PM, Thierry Reding wrote:
> Old Signed by an unknown key
>
>>On 08/08/2012 07:54 PM, Tony Prisk wrote:
>> This patchset updates arch-vt8500 to devicetree and removes all the old-style
>> code. Support for WM8650 has also been added.
>Sorry for taking such a long time to re-review this.
>I scanned the series looking for just the changes to the issues I ra
On Thu, Aug 16, 2012 at 06:19:08PM +0900, Alex Courbot wrote:
> On 08/16/2012 04:42 PM, Thierry Reding wrote:
> >* PGP Signed by an unknown key
> >
> >On Thu, Aug 16, 2012 at 03:08:55PM +0900, Alexandre Courbot wrote:
[...]
> >>+Usage by Drivers and Resources Management
> >>+---
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala
---
Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95 -
2 files changed, 173 insertions(+), 2
This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250.
It includes parsing platform data from dts file. Also, adds the driver data
for exynos5 device.
This patchset is based and tested on top of v3.6-rc1
Also depends on below patchset
http://lists.freedesktop.org/archives/
The name of the exynos drm fimd device is renamed to exynos-drm-fimd
and two device ids are created for exynos4-fb and exynos5-drm-fimd.
Also, added driver data for exynos5 to pick the fimd version at runtime and
to choose the VIDTCON register offsets accordingly.
Signed-off-by: Leela Krishna Amud
It really becomes an issue that every time a device needs to look
up (clk_get) a clock we have to patch kernel clock file to call
clk_register_clkdev for that clock.
Since clock DT support which is meant to resolve clock lookup in device
tree is in place, the patch moves imx6q client devices' cloc
For those SoCs that have hundreds of clock outputs, their clock
DT bindings could reasonably define #clock-cells as 1 and require
the client device specify the index of the clock it consumes in the
cell of its "clocks" phandle.
Add a generic of_clk_src_onecell_get() function for this purpose.
Sig
The series adds a generic of_clk_src_onecell_get() function into clock
framework, and then moves imx6q clock lookup over to device tree, so
that any new clock lookup to be added at later time does not need to
patch kerenel.
Shawn Guo (2):
clk: add of_clk_src_onecell_get() support
ARM: imx6q: r
On Thu, Aug 16, 2012 at 07:03:50AM +, Arnd Bergmann wrote:
> On Thursday 16 August 2012, Thierry Reding wrote:
> > At least for the config space this is incorrect. There's a single region
> > to access the configuration space for all devices below the PCIe
> > controller. So it is shared by bot
On Thu, Aug 16, 2012 at 03:08:55PM +0900, Alexandre Courbot wrote:
> Some device drivers (panel backlights especially) need to follow precise
> sequences for powering on and off, involving gpios, regulators, PWMs
> with a precise powering order and delays to respect between each steps.
> These sequ
On Thursday 16 August 2012, Thierry Reding wrote:
> At least for the config space this is incorrect. There's a single region
> to access the configuration space for all devices below the PCIe
> controller. So it is shared by both (Tegra20) or all three (Tegra30)
> root ports.
>
> I'm not sure abou
92 matches
Mail list logo
