* Mitch Bradley wrote:
> On 6/12/2012 10:15 AM, Stephen Warren wrote:
> >On 06/12/2012 11:20 AM, Thierry Reding wrote:
> >...
> >>I came up with the following alternative:
> >>
> >>pci {
> >>compatible = "nvidia,tegra20-pcie";
> >>reg =<0x80003000 0x0800 /* PADS re
* Stephen Warren wrote:
> On 06/12/2012 11:20 AM, Thierry Reding wrote:
> ...
> > I came up with the following alternative:
> >
> > pci {
> > compatible = "nvidia,tegra20-pcie";
> > reg = <0x80003000 0x0800 /* PADS registers */
> >0x80003800 0x
On Tue, Jun 12, 2012 at 04:14:38PM -0700, Greg KH wrote:
> On Fri, Jun 08, 2012 at 08:37:06PM +0800, Richard Zhao wrote:
> > Sometimes, the driver bindings may know what phy they use.
> > For example, when using device tree, the usb controller may have a
> > phandler pointing to usb phy.
> >
> > S
* Mitch Bradley wrote:
> On 6/12/2012 9:46 AM, Stephen Warren wrote:
> >On 06/12/2012 01:10 PM, Mitch Bradley wrote:
> >>On 6/12/2012 7:20 AM, Thierry Reding wrote:
> >...
> >>>I came up with the following alternative:
> >>>
> >>> pci {
> >>> compatible = "nvidia,tegra20-pcie";
> >>>
On Tue, Jun 12, 2012 at 02:48:12PM -0600, Stephen Warren wrote:
> From: Stephen Warren
>
> When compiling the current code-base with gcc 4.6.1, the following warning
> is raised, which is interpreted as an error:
>
> cc1: warnings being treated as errors
> tests/setprop_inplace.c: In function ‘m
On Fri, Jun 08, 2012 at 08:37:06PM +0800, Richard Zhao wrote:
> Sometimes, the driver bindings may know what phy they use.
> For example, when using device tree, the usb controller may have a
> phandler pointing to usb phy.
>
> Signed-off-by: Richard Zhao
> Reviewed-by: Marek Vasut
> Acked-by: F
From: Stephen Warren
dtc currently allows the contents of properties to be changed, and the
contents of nodes to be added to. There are situations where removing
properties or nodes may be useful. This change implements the following
syntax to do that:
/ {
propname /delprop/;
On 6/12/2012 10:15 AM, Stephen Warren wrote:
On 06/12/2012 11:20 AM, Thierry Reding wrote:
...
I came up with the following alternative:
pci {
compatible = "nvidia,tegra20-pcie";
reg =<0x80003000 0x0800 /* PADS registers */
0x
From: Stephen Warren
When merging one device tree over the top of a previous tree, it is
possible to define a duplicate label that has the same name and points
to the same property or node. This is currently allowed by the duplicate
label checking code. However, alternative duplicate label checki
From: Stephen Warren
When compiling the current code-base with gcc 4.6.1, the following warning
is raised, which is interpreted as an error:
cc1: warnings being treated as errors
tests/setprop_inplace.c: In function ‘main’:
tests/setprop_inplace.c:62: error: format ‘%016llx’ expects type ‘long l
On 06/12/2012 11:20 AM, Thierry Reding wrote:
...
> I came up with the following alternative:
>
> pci {
> compatible = "nvidia,tegra20-pcie";
> reg = <0x80003000 0x0800 /* PADS registers */
> 0x80003800 0x0200 /* AFI registers */
>
On 6/12/2012 9:46 AM, Stephen Warren wrote:
On 06/12/2012 01:10 PM, Mitch Bradley wrote:
On 6/12/2012 7:20 AM, Thierry Reding wrote:
...
I came up with the following alternative:
pci {
compatible = "nvidia,tegra20-pcie";
reg =<0x80003000 0x0800 /*
On 06/12/2012 01:10 PM, Mitch Bradley wrote:
> On 6/12/2012 7:20 AM, Thierry Reding wrote:
...
>> I came up with the following alternative:
>>
>> pci {
>> compatible = "nvidia,tegra20-pcie";
>> reg = <0x80003000 0x0800 /* PADS registers */
>>
This patch adds a driver for the MLC NAND controller of the LPC32xx SoC.
Signed-off-by: Roland Stigge
Signed-off-by: Alexandre Pereira da Silva
---
Applies to v3.5-rc2 + LPC32xx SLC NAND driver (Kconfig + Makefile)
Changes since v7:
* Cleanup: Use mtd nand default functions for single byte rea
On 6/12/2012 7:20 AM, Thierry Reding wrote:
* Stephen Warren wrote:
On 06/12/2012 12:21 AM, Thierry Reding wrote:
* Stephen Warren wrote:
On 06/11/2012 09:05 AM, Thierry Reding wrote:
This commit adds support for instantiating the Tegra PCIe
controller from a device tree.
+++ b/Documentati
Tested on an OLPC XO-1.75. (MMP2, sdhci-pxav3, CONFIG_MACH_MMP2_DT=y)
Signed-off-by: Chris Ball
---
.../devicetree/bindings/mmc/sdhci-pxa.txt | 21
drivers/mmc/host/sdhci-pxav2.c | 52
drivers/mmc/host/sdhci-pxav3.c
On Tue, Jun 12, 2012 at 02:04:33PM +0200, Andrew Lunn wrote:
> > > + spi@10600 {
> > > + compatible = "marvell,orion-spi";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + cell-index = <0>;
> > > +
Hi Heiko,
On 6/2/2012 1:06 AM, Sekhar Nori wrote:
> Hi Heiko,
>
> On 5/30/2012 3:48 PM, Heiko Schocher wrote:
>> Signed-off-by: Heiko Schocher
>> Cc: davinci-linux-open-sou...@linux.davincidsp.com
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: devicetree-discuss@lists.ozlabs.org
>> Cc: Grant
* Stephen Warren wrote:
> On 06/12/2012 12:10 AM, Thierry Reding wrote:
> > * Thierry Reding wrote:
> >> * Stephen Warren wrote:
> >>> On 06/11/2012 09:05 AM, Thierry Reding wrote:
> > [...]
> +static int tegra_pcie_disable_msi(struct platform_device
> *pdev)
> >>>
> >>> Should this free
* Stephen Warren wrote:
> On 06/12/2012 12:21 AM, Thierry Reding wrote:
> > * Stephen Warren wrote:
> >> On 06/11/2012 09:05 AM, Thierry Reding wrote:
> >>> This commit adds support for instantiating the Tegra PCIe
> >>> controller from a device tree.
> >>
> >>> +++ b/Documentation/devicetree/bind
On 06/12/2012 10:47 AM, Mike Turquette wrote:
> On 20120612-09:41, Rob Herring wrote:
>> From: Rob Herring
>>
>> This series defines clock bindings for Device-Tree and adds kernel
>> support using the common clock infrastructure. The last patch enables
>> DT clock
On 06/12/2012 01:24 AM, Thierry Reding wrote:
> * Thierry Reding wrote:
>> AFAICT the even partitioning of the non-prefetchable and
>> prefetchable memory regions is arbitrary and it could
>> potentially be useful to make it configurable via the DT.
>
> So it turns out that this isn't true. But a
On 20120612-09:41, Rob Herring wrote:
> From: Rob Herring
>
> This series defines clock bindings for Device-Tree and adds kernel
> support using the common clock infrastructure. The last patch enables
> DT clock support for the Calxeda Highbank platform.
>
> I'm pos
On 06/12/2012 12:21 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 06/11/2012 09:05 AM, Thierry Reding wrote:
>>> This commit adds support for instantiating the Tegra PCIe
>>> controller from a device tree.
>>
>>> +++ b/Documentation/devicetree/bindings/pci/tegra-pcie.txt
>>
>> Can we
On 06/12/2012 12:10 AM, Thierry Reding wrote:
> * Thierry Reding wrote:
>> * Stephen Warren wrote:
>>> On 06/11/2012 09:05 AM, Thierry Reding wrote:
> [...]
+static int tegra_pcie_disable_msi(struct platform_device
*pdev)
>>>
>>> Should this free pcie->msi->pages?
>>
>> Yes it should. I
On 06/11/2012 11:48 PM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 06/11/2012 09:05 AM, Thierry Reding wrote:
>>> With the device tree support in place, probe the PCIe
>>> controller from the device tree and remove the corresponding
>>> workaround in the board file.
>>
>>> diff --git a/
From: Rob Herring
This adds real clock support to Calxeda Highbank SOC using the common
clock infrastructure.
Signed-off-by: Rob Herring
---
.../devicetree/bindings/clock/calxeda.txt | 17 +
arch/arm/Kconfig |1 +
arch/arm/boot/dts/highbank.dts
From: Rob Herring
Add clock binding information for primecell peripherals. For most, a
clock input name of "apb_pclk" is required. Any primecell peripherals
which are different will need to be documented separately.
Signed-off-by: Rob Herring
---
.../devicetree/bindings/arm/primecell.txt
From: Grant Likely
Add support for DT "fixed-clock" binding to the common fixed rate clock
support.
Signed-off-by: Grant Likely
[Rob Herring] Rework and move into common clock infrastructure
Signed-off-by: Rob Herring
---
drivers/clk/clk-fixed-rate.c | 23 +++
include/li
From: Grant Likely
Based on work 1st by Ben Herrenschmidt and Jeremy Kerr, then by Grant
Likely, this patch adds support to clk_get to allow drivers to retrieve
clock data from the device tree.
Platforms scan for clocks in DT with of_clk_init and a match table, and
the register a provider throug
From: Rob Herring
This series defines clock bindings for Device-Tree and adds kernel
support using the common clock infrastructure. The last patch enables
DT clock support for the Calxeda Highbank platform.
I'm posting this again to solicit further review. There has been some
discussion[1], but
> > + spi@10600 {
> > + compatible = "marvell,orion-spi";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + cell-index = <0>;
> > + reg = <0x10600 0x28>;
> > + status = "di
Heteregeneous ARM platform uses arch_scale_freq_power function
to reflect the relative capacity of each core
Signed-off-by: Vincent Guittot
---
kernel/sched/features.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/features.h b/kernel/sched/features.h
index d
Use cpu compatibility field and clock-frequency field of DT to
estimate the capacity of each core of the system
Signed-off-by: Vincent Guittot
---
arch/arm/kernel/topology.c | 122
1 file changed, 122 insertions(+)
diff --git a/arch/arm/kernel/topol
The factorization has also be proposed in another patch that is not merge yet.
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html
So it could be dropped depending of the state of the other patch.
Signed-off-by: Lorenzo Pieralisi
Signed-off-by: Vincent Guittot
---
arc
Add infrastructure to be able to modify the cpu_power of each core
Signed-off-by: Vincent Guittot
---
arch/arm/include/asm/topology.h |2 ++
arch/arm/kernel/topology.c | 36 +++-
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm/in
This patchset creates an arch_scale_freq_power function for ARM, which is used
to set the relative capacity of each core of a big.LITTLE system.
Vincent Guittot (4):
ARM: topology: Add arch_scale_freq_power function
ARM: topology: factorize the update of sibling masks
ARM: topology: Update
* Thierry Reding wrote:
> AFAICT the even partitioning of the non-prefetchable and prefetchable
> memory regions is arbitrary and it could potentially be useful to make
> it configurable via the DT.
So it turns out that this isn't true. But apart from the comments in the
driver I couldn't find any
* Jon Hunter [120607 15:15]:
> Simple DTS file for OMAP2420 SDP adding memory information to allow
> device-tree
> testing on an OMAP2420 SDP.
>
> Verified that kernel boots with DT using a simple RAMDISK file-system on
> OMAP2420 SDP.
I suspect this is the H4 board? If so, please rename it to
39 matches
Mail list logo
