* Stephen Warren wrote:
> On 03/08/2012 07:51 AM, Thierry Reding wrote:
> > diff --git a/arch/arm/mach-tegra/pcie.c b/arch/arm/mach-tegra/pcie.c
>
> > +static int tegra_pcie_enable_msi(struct platform_device *pdev)
> > +{
> > + struct tegra_pcie_info *pcie = platform_get_drvdata(pdev);
> > + v
On Monday 12 March 2012, Jason Cooper wrote:
> > Or even use the ranges property to remap everything into
> > a simpler address range:
> >
> > ocp@f100 {
> > compatible = "simple-bus";
> > ranges = <0 0xf100 0x100>;
> > #address-cells = 1
On Monday 12 March 2012, Jason Cooper wrote:
> > + dnskw_gpio_register(39, "dnskw:power:sata0", 1);
> > + dnskw_gpio_register(40, "dnskw:power:sata1", 1);
> > +
> > + /* Set NAS to turn back on after a power failure */
> > + dnskw_gpio_register(37, "dnskw:power:recover", 1);
> > +}
On Thu, Mar 08, 2012 at 02:31:41PM -0700, Stephen Warren wrote:
> On 03/08/2012 07:51 AM, Thierry Reding wrote:
> > +- vdd-supply: power supply for controller (1.05V)
> Should those *-supply properties really be optional? I got the
> impression talking to Mark in a different thread that all regul
On Fri, Mar 09, 2012 at 11:14:33AM -0700, Stephen Warren wrote:
> The core pin controller bindings define:
> * The fact that pin controllers expose pin configurations as nodes in
> device tree.
> * That the bindings for those pin configuration nodes is defined by the
> individual pin controller
On 12.03.2012 06:58, Thomas Abraham wrote:
Hi Thomas!
> On 9 March 2012 22:34, Karol Lewandowski wrote:
>> Reorganize driver a bit to better handle device tree-based systems:
>>
>> - move machine type to driver's private structure instead of
>> quering platform device variants in runtime
>>
>
> I was thinking some more about how to expand the device tree syntax to
> allow expressions.
Excellent!
> I wondered if we should use a concept/syntax more
> inspired by template processors. Playing with jinja2 and gpp led me
> towards (...) being an inline expression syntax that can calculate
>
> It is often inconvenient to place device tree files in the same directory
> as their includes, or to specify the full path to include files.
>
> An example of this is in U-Boot where we have a .dtsi file for each SOC
> type, and this is included by the board .dts file. We need to either use
> a
This patch adds support to configure the STMMAC ethernet driver via
device-tree instead of platform_data.
Currently, only the properties needed on SPEAr600 are provided. All
other properties should be added once needed on other platforms.
Signed-off-by: Stefan Roese
Cc: Giuseppe Cavallaro
Cc: V
* Mark Brown wrote:
> On Thu, Mar 08, 2012 at 02:31:41PM -0700, Stephen Warren wrote:
> > On 03/08/2012 07:51 AM, Thierry Reding wrote:
>
> > > +- vdd-supply: power supply for controller (1.05V)
>
> > Should those *-supply properties really be optional? I got the
> > impression talking to Mark in
On 12 March 2012 18:46, Karol Lewandowski wrote:
> On 12.03.2012 06:58, Thomas Abraham wrote:
>
> Hi Thomas!
>
>> On 9 March 2012 22:34, Karol Lewandowski wrote:
>>> Reorganize driver a bit to better handle device tree-based systems:
>>>
>>> - move machine type to driver's private structure inst
On Mon, 12 Mar 2012 08:17:19 -, Arnd Bergmann wrote:
On Monday 12 March 2012, Jason Cooper wrote:
> + dnskw_gpio_register(39, "dnskw:power:sata0", 1);
> + dnskw_gpio_register(40, "dnskw:power:sata1", 1);
> +
> + /* Set NAS to turn back on after a power failure */
> + dnskw_
On Mon, Mar 12, 2012 at 03:17:05PM +0100, Thierry Reding wrote:
> My understanding of the fixed regulator was that it was meant to be used for
> fixed voltage supplies that can still be enabled or disabled (for example as
> supplied by a GPIO) but not regulators that are fix in the sense that they
On Mon, Mar 12, 2012 at 02:22:24PM -, Jamie Lentin wrote:
> On Mon, 12 Mar 2012 08:17:19 -, Arnd Bergmann wrote:
>
> >On Monday 12 March 2012, Jason Cooper wrote:
> >>> + dnskw_gpio_register(39, "dnskw:power:sata0", 1);
> >>> + dnskw_gpio_register(40, "dnskw:power:sata1", 1);
> >>
* Mark Brown wrote:
> On Mon, Mar 12, 2012 at 03:17:05PM +0100, Thierry Reding wrote:
>
> > My understanding of the fixed regulator was that it was meant to be used for
> > fixed voltage supplies that can still be enabled or disabled (for example as
> > supplied by a GPIO) but not regulators that
On Sat, Mar 10, 2012 at 02:14:33AM +0800, Stephen Warren wrote:
> The core pin controller bindings define:
> * The fact that pin controllers expose pin configurations as nodes in
> device tree.
> * That the bindings for those pin configuration nodes is defined by the
> individual pin controller
On Mon, Mar 12, 2012 at 03:28:58PM +0100, Thierry Reding wrote:
> In that case I'll mark the *-supply properties required. Would it be a good
> idea to mention this (or even give an example with fixed regulators) in the
> binding documentation or can I assume this to be common knowledge?
Probably
On 03/12/2012 09:05 AM, Stefan Roese wrote:
> This patch adds support to configure the STMMAC ethernet driver via
> device-tree instead of platform_data.
>
> Currently, only the properties needed on SPEAr600 are provided. All
> other properties should be added once needed on other platforms.
>
>
On Monday 12 March 2012, Jason Cooper wrote:
> >
> > It probably depends on how easy it is to add the gpiochips into
> > devicetree. Being able to put the LED, buttons and fans in
> > devicetree would make board-dt.c much more manageable. I started to
> > look into it and wasn't immediately obviou
The series adds device tree support for OMAP hsmmc
driver.
Changes in V2:
-1- Minor fixes based on comments from Grant.
-2- Added a seperate compatible for omap3.
-3- Added a new binding "ti,needs-special-reset"
to handle some mmc modules which need special
softreset sequence.
-4- Updated board dt
Add omap mmc related device tree data for OMAP4.
Currenly limited to only omap4-panda and omap4-sdp
boards.
Signed-off-by: Rajendra Nayak
---
arch/arm/boot/dts/omap4-panda.dts | 22 ++
arch/arm/boot/dts/omap4-sdp.dts | 24
arch/arm/boot/dts/omap
Add omap mmc related device tree data for OMAP3.
Currenly limited to only omap3-beagle board.
Signed-off-by: Rajendra Nayak
---
arch/arm/boot/dts/omap3-beagle.dts | 14 ++
arch/arm/boot/dts/omap3.dtsi | 16
2 files changed, 30 insertions(+), 0 deletions(-)
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.
Signed-off-by: Rajendra Nayak
Acked-by: Rob Herring
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 33 +
drivers/mmc/host/omap_hsmmc.c
When booting with Device tree, the omap_hsmmc driver does not
program the pbias cell (inside OMAP control module) during
a regulator voltage change.
In case of non-dt boot, this is handled using callbacks
from within platform_data and implemented in machine code.
To be able to do this with device t
Hi Rob,
On Monday 12 March 2012 15:34:59 Rob Herring wrote:
> On 03/12/2012 09:05 AM, Stefan Roese wrote:
> > This patch adds support to configure the STMMAC ethernet driver via
> > device-tree instead of platform_data.
> >
> > Currently, only the properties needed on SPEAr600 are provided. All
>
On 15:05 Mon 12 Mar , Stefan Roese wrote:
> This patch adds support to configure the STMMAC ethernet driver via
> device-tree instead of platform_data.
>
> Currently, only the properties needed on SPEAr600 are provided. All
> other properties should be added once needed on other platforms.
>
On Monday 12 March 2012 15:38:25 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > @@ -58,6 +94,22 @@ static int stmmac_pltfr_probe(struct platform_device
> > *pdev)
> >
> > ret = -ENOMEM;
> > goto out_release_region;
> >
> > }
> >
> > +
> > +#ifdef CONFIG_OF
> > + pl
On Sun, 11 Mar 2012 19:25:37 +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> On 08:07 Sun 11 Mar , Grant Likely wrote:
> > On Fri, 9 Mar 2012 19:25:44 +0100, Jean-Christophe PLAGNIOL-VILLARD
> > wrote:
> > > This will allow to use gpio for chip select with no modification in the
> > > dri
On 16:25 Mon 12 Mar , Stefan Roese wrote:
> On Monday 12 March 2012 15:38:25 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > @@ -58,6 +94,22 @@ static int stmmac_pltfr_probe(struct platform_device
> > > *pdev)
> > >
> > > ret = -ENOMEM;
> > > goto out_release_region;
> > >
On Mon, 6 Feb 2012 18:59:02 +0100, Tobias Klauser wrote:
> This driver supports the Altera PIO core.
>
> Signed-off-by: Thomas Chou
> Signed-off-by: Tobias Klauser
> ---
> This driver was submitted already about a year ago by Thomas, was
> adjusted by him according to some remarks made by Gran
On Mon, Mar 12, 2012 at 08:11:22AM +, Arnd Bergmann wrote:
> On Monday 12 March 2012, Jason Cooper wrote:
> > > Or even use the ranges property to remap everything into
> > > a simpler address range:
> > >
> > > ocp@f100 {
> > > compatible = "simple-bus";
> > >
On Monday 12 March 2012 16:30:37 Giuseppe CAVALLARO wrote:
> >>> +Required properties:
> >>> +- compatible: Should be "stm,gmac"
> >>
> >> This is too generic. This should be 1 string per version of h/w.
> >
> > Viresh, Giuseppe, can you please suggest a proper string for the SPEAr600
> > STMMAC
On Monday 12 March 2012, Jason Cooper wrote:
> Okay, that's what smelled funny. wdt and intc both only have registers
> in virtual address space defined. Can I assume they map like everything
> else to corresponding physical addresses?
>
> eg wdt@fed20300 -> wdt@f1020300 ?
Yes, correct. Or just
On 16:06 Mon 12 Mar , Stefan Roese wrote:
> Hi Rob,
>
> On Monday 12 March 2012 15:34:59 Rob Herring wrote:
> > On 03/12/2012 09:05 AM, Stefan Roese wrote:
> > > This patch adds support to configure the STMMAC ethernet driver via
> > > device-tree instead of platform_data.
> > >
> > > Current
On 03/12/2012 02:00 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 03/08/2012 07:51 AM, Thierry Reding wrote:
>>> diff --git a/arch/arm/mach-tegra/pcie.c b/arch/arm/mach-tegra/pcie.c
...
>> Free the IRQ descriptors in the error paths?
...
>>> + for (msi = 0; msi < INT_PCI_MSI_NR; msi++
Hi Jon,
On Mon, Mar 12, 2012 at 6:54 AM, Jon Loeliger wrote:
>> It is often inconvenient to place device tree files in the same directory
>> as their includes, or to specify the full path to include files.
>>
>> An example of this is in U-Boot where we have a .dtsi file for each SOC
>> type, and
On 16:30 Mon 12 Mar , Giuseppe CAVALLARO wrote:
> On 3/12/2012 4:06 PM, Stefan Roese wrote:
> > Hi Rob,
> >
> > On Monday 12 March 2012 15:34:59 Rob Herring wrote:
> >> On 03/12/2012 09:05 AM, Stefan Roese wrote:
> >>> This patch adds support to configure the STMMAC ethernet driver via
> >>> d
On 03/12/2012 08:34 AM, Dong Aisheng wrote:
> On Sat, Mar 10, 2012 at 02:14:33AM +0800, Stephen Warren wrote:
>> The core pin controller bindings define:
>> * The fact that pin controllers expose pin configurations as nodes in
>> device tree.
>> * That the bindings for those pin configuration nod
On 09:40 Mon 12 Mar , Grant Likely wrote:
> On Sun, 11 Mar 2012 19:25:37 +0100, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
> > On 08:07 Sun 11 Mar , Grant Likely wrote:
> > > On Fri, 9 Mar 2012 19:25:44 +0100, Jean-Christophe PLAGNIOL-VILLARD
> > > wrote:
> > > > This will allow to use
On Mon, 12 Mar 2012 03:02:32 -, Jason Cooper
wrote:
On Sun, Mar 11, 2012 at 02:33:25PM +, Jamie Lentin wrote:
Add support for the DNS-320 and DNS-325. Describe as much as currently
possible
in the devicetree files, leave everything else in board-dt.c to be
patched
later.
Signed-
On Mon, Mar 12, 2012 at 05:59:50PM -, Jamie Lentin wrote:
> On Mon, 12 Mar 2012 03:02:32 -, Jason Cooper
> wrote:
>
> >On Sun, Mar 11, 2012 at 02:33:25PM +, Jamie Lentin wrote:
> >>Add support for the DNS-320 and DNS-325. Describe as much as
> >>currently possible
> >>in the devicetre
On 03/09/2012 10:36 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
Ugh. so any value other than 1 returns false? I think that will surprise
most people.
I don't like this api or binding. If it is a bool property, then why isn't
simply testing for the property existance suff
On 03/12/2012 11:46 AM, Giuseppe CAVALLARO wrote:
> On 3/12/2012 5:23 PM, Stefan Roese wrote:
>> On Monday 12 March 2012 16:30:37 Giuseppe CAVALLARO wrote:
>> +Required properties:
>> +- compatible: Should be "stm,gmac"
>
> This is too generic. This should be 1 string per version of
Hi Rob/Grant,
On 23 February 2012 18:08, Thomas Abraham wrote:
> Changes since v2:
> - Atleast one voltage level has to be specfied for Buck 1/2/5 even if GPIO
> DVS option is not used (suggested by MyungJoo Ham).
> - Reworked the irq_domain support based the v5 of irq_domain generalization
> p
This series begins the process of converting all of the drivers initialized
from kirkwood_init() to devicetree.
The first three patches are code cleanup from Andrew Lunn.
The rest of the series is the initial conversion to devicetree for kirkwood,
use by dreamplug, and devicetree bindings for dri
From: Andrew Lunn
Signed-off-by: Andrew Lunn
Signed-off-by: Jason Cooper
Acked-by: Grant Likely
---
drivers/spi/spi-orion.c |5 -
include/linux/spi/orion_spi.h |1 -
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orio
Signed-off-by: Jason Cooper
---
drivers/rtc/rtc-mv.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/rtc/rtc-mv.c b/drivers/rtc/rtc-mv.c
index 768e2ed..0dd8421 100644
--- a/drivers/rtc/rtc-mv.c
+++ b/drivers/rtc/rtc-mv.c
@@ -12,6 +12,7 @@
#include
#incl
This uart is the primary console for the dreamplug. Removed
kirkwood_uart0_init() call from board-dreamplug.c.
There are two uarts on the kirkwood SoC, all or none of them may be
enabled, and the clock-frequency is board-dependant. So, enabling and
clock-frequency are left to the board dts.
Sig
Signed-off-by: Jason Cooper
---
arch/arm/boot/dts/kirkwood.dtsi |6 ++
arch/arm/mach-kirkwood/board-dt.c |1 -
arch/arm/mach-kirkwood/common.c |2 +-
arch/arm/mach-kirkwood/common.h |1 -
4 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/ki
Initially, copied guruplug-setup.c and did s/guruplug/dreamplug/g.
Then, switched to SPI based NOR flash.
After talking to Arnd Bergman, chose an incremental approach to adding
devicetree support. First, we use the dtb to tell us we are on the
dreamplug, then we gradually port over drivers.
Driv
From: Andrew Lunn
It is not used anywhere in the sound driver.
Signed-off-by: Andrew Lunn
Signed-off-by: Jason Cooper
---
arch/arm/mach-kirkwood/common.c |1 -
arch/arm/plat-orion/include/plat/audio.h |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/a
From: Andrew Lunn
Signed-off-by: Andrew Lunn
Signed-off-by: Jason Cooper
Acked-by: Grant Likely
---
Note: This code is the exact same as that originally Acked by Grant. I've
simply removed the fdt bindings, as I need to hold off until common clock is
added. If it's not appropriate to retain
On Tue, Mar 13, 2012 at 01:16:19AM +0800, Stephen Warren wrote:
> On 03/12/2012 08:34 AM, Dong Aisheng wrote:
> > On Sat, Mar 10, 2012 at 02:14:33AM +0800, Stephen Warren wrote:
> >> The core pin controller bindings define:
> >> * The fact that pin controllers expose pin configurations as nodes in
On Thu, 23 Feb 2012 18:08:07 +0530, Thomas Abraham
wrote:
> Add irq domain support for max8997 interrupts. The reverse mapping method
> used is linear mapping since the sub-drivers of max8997 such as regulator
> and charger drivers can use the max8997 irq_domain to get the linux irq
> number for
On 14:39 Mon 12 Mar , Scott Wood wrote:
> On 03/09/2012 10:36 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Ugh. so any value other than 1 returns false? I think that will
> surprise
> most people.
>
> I don't like this api or binding. If it is a bool property, then
On Tue, Mar 06, 2012 at 05:10:12PM -0800, Simon Glass wrote:
> It is often inconvenient to place device tree files in the same directory
> as their includes, or to specify the full path to include files.
>
> An example of this is in U-Boot where we have a .dtsi file for each SOC
> type, and this i
On Mon, Mar 12, 2012 at 08:53:05AM -0500, Jon Loeliger wrote:
> > I was thinking some more about how to expand the device tree syntax to
> > allow expressions.
>
> Excellent!
>
> > I wondered if we should use a concept/syntax more
> > inspired by template processors. Playing with jinja2 and gpp l
On Thu, 23 Feb 2012 18:08:08 +0530, Thomas Abraham
wrote:
> Add device tree based discovery support for max8997.
>
> Cc: MyungJoo Ham
> Cc: Rajendra Nayak
> Cc: Rob Herring
> Cc: Grant Likely
> Signed-off-by: Thomas Abraham
> ---
> .../devicetree/bindings/regulator/max8997-pmic.txt | 134
On Fri, 9 Mar 2012 11:14:33 -0700, Stephen Warren
wrote:
> The core pin controller bindings define:
> * The fact that pin controllers expose pin configurations as nodes in
> device tree.
> * That the bindings for those pin configuration nodes is defined by the
> individual pin controller dri
On Tue, 13 Mar 2012 04:17:39 +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> On 14:39 Mon 12 Mar , Scott Wood wrote:
> > On 03/09/2012 10:36 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > Ugh. so any value other than 1 returns false? I think that will
> > surprise
> > most
On Wed, Mar 07, 2012 at 05:40:37PM -0700, Stephen Warren wrote:
> I was thinking some more about how to expand the device tree syntax to
> allow expressions. I wondered if we should use a concept/syntax more
> inspired by template processors. Playing with jinja2 and gpp led me
> towards (...) being
On 13 March 2012 08:58, Grant Likely wrote:
> On Thu, 23 Feb 2012 18:08:07 +0530, Thomas Abraham
> wrote:
>> Add irq domain support for max8997 interrupts. The reverse mapping method
>> used is linear mapping since the sub-drivers of max8997 such as regulator
>> and charger drivers can use the m
On 13 March 2012 09:13, Grant Likely wrote:
> On Thu, 23 Feb 2012 18:08:08 +0530, Thomas Abraham
> wrote:
>> Add device tree based discovery support for max8997.
>>
>> Cc: MyungJoo Ham
>> Cc: Rajendra Nayak
>> Cc: Rob Herring
>> Cc: Grant Likely
>> Signed-off-by: Thomas Abraham
>> ---
>> .
63 matches
Mail list logo
