On Wed, Aug 10, 2011 at 01:57:11PM +0800, Barry Song wrote:
2011/8/10 Mark Brown broo...@opensource.wolfsonmicro.com:
struct ads7846_platform_data {
u16 model; /* 7843, 7845, 7846, 7873. */
u16 vref_mv; /* external vref value,
On 09/08/11 21:17, Rob Herring wrote:
From: Rob Herring rob.herr...@calxeda.com
This adds gic initialization using device tree data. An example device tree
binding looks like this:
intc: interrupt-controller@fff11000 {
compatible = arm,cortex-a9-gic;
#interrupt-cells = 1;
Grant,
Do you need this patch resent with you on the Cc: list or can you pick
up the discussion from here? I am just trying to minimize noise on
the mailing lists if it is not needed.
The essence of the discussion to this point is:
1) Freescale built a board support package for a new processor
Manju,
On 8/10/2011 9:07 AM, Jarkko Nikula wrote:
Hi
On Tue, 09 Aug 2011 19:10:22 +0500
G, Manjunath Kondaiahmanj...@ti.com wrote:
From: Kevin Hilmankhil...@ti.com
For converting from struct device to platform_device, and from
platform_device to struct device, there are existing macros.
On Tue, 2011-08-09 at 14:51 -0600, Grant Likely wrote:
On Tue, Aug 09, 2011 at 09:57:29PM +0200, Daniel Morsing wrote:
This patch adds support for probing the dm9000 driver through device
trees.
The patch works by supplying its own platform_data struct when probed
via device tree. This
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add pd_size in the AUXDATA structure so that device drivers which require
platform_data size can pass along with AUXDATA.
It is really needed by device driver? Or is it because omap_device_build
is using platform_device_add_data that is doing
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add omap3 soc file for handling omap3 soc i2c controllers existing
on l4-core bus.
Signed-off-by: G, Manjunath Kondaiahmanj...@ti.com
---
arch/arm/boot/dts/omap3-soc.dtsi | 62 ++
1 files changed, 62
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Update omap3 beagle dts file with required clock frequencies for the i2c
client devices existing on beagle board.
Beagle custom board dts file is cleaned up so that it can coexist with omap3
soc dts file.
Signed-off-by: G, Manjunath
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Adapt dt for omap i2c1 controller and remove legacy i2c
initilization in omap3 generic board file.
Tested on omap3 beagle board for dt and non-dt builds.
Signed-off-by: G, Manjunath Kondaiahmanj...@ti.com
---
arch/arm/boot/dts/omap3-soc.dtsi
Hi all,
I'm working on a driver for the PMU found in L220/PL310 L2 Cache Controllers
(as an extension to the existing L2x0 code).
I've taken a look into what BSP support would be required and mocked up some
platform_device support, though I notice that Rob Herring has provided
devicetree
On Tue, Aug 09, 2011 at 03:16:58PM -0500, Rob Herring wrote:
From: Rob Herring rob.herr...@calxeda.com
In preparation to scan and initialize interrupt controllers from a
device-tree, create struct to pass to interrupt controller initialization
functions.
irq_base should go away with
On Wed, Aug 10, 2011 at 5:57 AM, Cousson, Benoit b-cous...@ti.com wrote:
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add pd_size in the AUXDATA structure so that device drivers which require
platform_data size can pass along with AUXDATA.
It is really needed by device driver? Or is it
Mark,
On 08/10/2011 07:48 AM, Mark Rutland wrote:
Hi all,
I'm working on a driver for the PMU found in L220/PL310 L2 Cache Controllers
(as an extension to the existing L2x0 code).
I've taken a look into what BSP support would be required and mocked up some
platform_device support, though
On Wednesday 10 August 2011, Mark Rutland wrote:
I realise I'm a bit late to the party here, but I'd like to propose adding an
optional interrupt parameter to the binding. I'm not aware of any
implementations which use separate interrupts, but given the binding
seems to be generic across L2CC
On Wednesday 10 August 2011, Will Deacon wrote:
On Wed, Aug 10, 2011 at 02:59:12PM +0100, Rob Herring wrote:
I think you should allow for either the single irq or individual irqs.
You can specify that the event counter interrupt must be first, then the
pmu driver could work either way
On Wed, Aug 10, 2011 at 03:24:27PM +0100, Arnd Bergmann wrote:
On Wednesday 10 August 2011, Will Deacon wrote:
On Wed, Aug 10, 2011 at 02:59:12PM +0100, Rob Herring wrote:
I think you should allow for either the single irq or individual irqs.
You can specify that the event counter
On Wed, Aug 10, 2011 at 03:37:26PM +0100, Rob Herring wrote:
On 08/10/2011 09:10 AM, Will Deacon wrote:
Hi Rob,
On Wed, Aug 10, 2011 at 02:59:12PM +0100, Rob Herring wrote:
I think you should allow for either the single irq or individual irqs.
You can specify that the event counter
Hi Rob,
On Wed, Aug 10, 2011 at 02:59:12PM +0100, Rob Herring wrote:
I think you should allow for either the single irq or individual irqs.
You can specify that the event counter interrupt must be first, then the
pmu driver could work either way ignoring the rest. The driver probably
needs to
On Aug 9, 2011, at 3:59 PM, Robin Holt wrote:
I guess my poor wording may have gotten me in trouble. I am getting
ready to repost this patch, but I want to ensure I am getting it as
right as possible.
I think I should reword the commit message to indicate we are removing
the
On Wed, Aug 10, 2011 at 03:31:54PM +0100, Rob Herring wrote:
Here's all the interrupts on the PL310:
DECERRINTR Decode error received on master ports from L3
SLVERRINTR Slave error received on master ports from L3
ERRRDINTR Error on L2 data RAM read
ERRRTINTR Error on L2 tag RAM read
On 08/09/2011 10:12 AM, Jamie Iles wrote:
+Optional properties:
+- bank-width : Width (in bytes) of the device. If not present, the width
+ defaults to 8 bits.
in bytes versus defaults to 8 bits...
+- chip-delay : chip dependent delay for transferring data from array to
+ read registers
On 08/09/2011 08:52 PM, David Gibson wrote:
Of course, the problem with reg-names is that it will be ignored by
older OSes, and so 'reg' must still be in the correct order. In which
case you could argue it's more sensible to just have a static place to
name mapping in the Linux driver.
I
On 8/10/2011 5:18 PM, Scott Wood wrote:
On 08/09/2011 08:52 PM, David Gibson wrote:
Of course, the problem with reg-names is that it will be ignored by
older OSes, and so 'reg' must still be in the correct order. In which
case you could argue it's more sensible to just have a static place to
On Wed, Aug 10, 2011 at 07:16:30AM -0600, Grant Likely wrote:
On Wed, Aug 10, 2011 at 5:57 AM, Cousson, Benoit b-cous...@ti.com wrote:
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add pd_size in the AUXDATA structure so that device drivers which require
platform_data size can pass
On Wed, Aug 10, 2011 at 12:15:50PM +0200, Cousson, Benoit wrote:
Manju,
On 8/10/2011 9:07 AM, Jarkko Nikula wrote:
Hi
On Tue, 09 Aug 2011 19:10:22 +0500
G, Manjunath Kondaiahmanj...@ti.com wrote:
From: Kevin Hilmankhil...@ti.com
For converting from struct device to platform_device,
On Wed, Aug 10, 2011 at 09:52:07AM -0500, Kumar Gala wrote:
On Aug 9, 2011, at 3:59 PM, Robin Holt wrote:
I guess my poor wording may have gotten me in trouble. I am getting
ready to repost this patch, but I want to ensure I am getting it as
right as possible.
I think I should
On powerpc, the OpenFirmware devices are not matched without specifying
an of_match array. Introduce that array as that is used for matching
on the Freescale P1010 processor.
Signed-off-by: Robin Holt h...@sgi.com
Acked-by: Marc Kleine-Budde m...@pengutronix.de
Acked-by: Wolfgang Grandegger
This patch cleans up the documentation of the device-tree binding for
the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
properties are not needed as the frequency of the source clock is
fixed, there is not external divider beyond what the driver already
works with, and the clock
On Wed, Aug 10, 2011 at 02:42:56PM +0200, Cousson, Benoit wrote:
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Update omap3 beagle dts file with required clock frequencies for the i2c
client devices existing on beagle board.
Beagle custom board dts file is cleaned up so that it can
On 08/10/2011 11:27 AM, Robin Holt wrote:
-CPI Clock- Can Protocol Interface Clock
- This CLK_SRC bit of CTRL(control register) selects the clock source to
- the CAN Protocol Interface(CPI) to be either the peripheral clock
- (driven by the PLL) or the crystal oscillator clock. The
On Wed, Aug 10, 2011 at 02:36:50PM +0200, Cousson, Benoit wrote:
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add omap3 soc file for handling omap3 soc i2c controllers existing
on l4-core bus.
Signed-off-by: G, Manjunath Kondaiahmanj...@ti.com
---
arch/arm/boot/dts/omap3-soc.dtsi
On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
Hi Manju,
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
The omap dt requires new omap hwmod api to be added for in order
to support omap dt.
Both the subject and the
On Wed, Aug 10, 2011 at 11:56:28AM -0500, Scott Wood wrote:
On 08/10/2011 11:27 AM, Robin Holt wrote:
-CPI Clock- Can Protocol Interface Clock
- This CLK_SRC bit of CTRL(control register) selects the clock source to
- the CAN Protocol Interface(CPI) to be either the peripheral clock
-
On 08/10/2011 12:19 PM, Robin Holt wrote:
On Wed, Aug 10, 2011 at 11:56:28AM -0500, Scott Wood wrote:
On 08/10/2011 11:27 AM, Robin Holt wrote:
-CPI Clock- Can Protocol Interface Clock
- This CLK_SRC bit of CTRL(control register) selects the clock source to
- the CAN Protocol
+ Tony
On 8/10/2011 6:57 PM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 02:36:50PM +0200, Cousson, Benoit wrote:
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add omap3 soc file for handling omap3 soc i2c controllers existing
on l4-core bus.
Signed-off-by: G, Manjunath
On Wed, Aug 10, 2011 at 10:41 PM, Cousson, Benoit b-cous...@ti.com wrote:
On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
Hi Manju,
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
The omap dt requires new omap hwmod api
On 8/10/2011 8:03 PM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 10:41 PM, Cousson, Benoitb-cous...@ti.com wrote:
On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
Hi Manju,
On 8/9/2011 4:10 PM, G, Manjunath
On 08/10/2011 03:08 AM, Marc Zyngier wrote:
On 09/08/11 21:17, Rob Herring wrote:
From: Rob Herring rob.herr...@calxeda.com
This adds gic initialization using device tree data. An example device tree
binding looks like this:
intc: interrupt-controller@fff11000 {
compatible =
On Wed, Aug 10, 2011 at 12:36:22PM -0500, Scott Wood wrote:
On 08/10/2011 12:19 PM, Robin Holt wrote:
On Wed, Aug 10, 2011 at 11:56:28AM -0500, Scott Wood wrote:
On 08/10/2011 11:27 AM, Robin Holt wrote:
-CPI Clock- Can Protocol Interface Clock
- This CLK_SRC bit of CTRL(control register)
On Wed, Aug 10, 2011 at 01:40:30PM -0500, Scott Wood wrote:
On 08/10/2011 01:30 PM, Robin Holt wrote:
On Wed, Aug 10, 2011 at 12:36:22PM -0500, Scott Wood wrote:
On 08/10/2011 12:19 PM, Robin Holt wrote:
On Wed, Aug 10, 2011 at 11:56:28AM -0500, Scott Wood wrote:
Also may want to list
On Tue, Aug 9, 2011 at 7:52 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:49 PM, Grant Likely wrote:
That won't work either because that also breaks the existing 'reg'
binding. Anything you do will need to
On Wed, Aug 10, 2011 at 01:22:16PM -0600, Grant Likely wrote:
Please, stick with the established convention and explicitly order
'reg' and 'interrupts' properties. If there is a specific use case
where this doesn't work, then bring it up, but I haven't seen any yet.
The current users of
Olof Johansson wrote at Tuesday, August 09, 2011 11:35 AM:
On Mon, Aug 8, 2011 at 2:42 PM, Stephen Warren swar...@nvidia.com wrote:
Grant, Linus, all,
I was thinking of adding some Device Tree support to Tegra's existing
pinmux driver. This would remove the dependence of
On Wed, Aug 10, 2011 at 1:57 PM, David Brown dav...@codeaurora.org wrote:
On Wed, Aug 10, 2011 at 01:22:16PM -0600, Grant Likely wrote:
Please, stick with the established convention and explicitly order
'reg' and 'interrupts' properties. If there is a specific use case
where this doesn't
Hi,
We'd like to use devicetree and gpio-leds magic to enable the HDD LED
on the XO-1.5 laptop. There are 3 steps needed. Review would be
appreciated:
1. The vx855-gpio driver patch just resubmitted:
http://marc.info/?l=linux-kernelm=131300843332366w=2
2. Addition of the gpio-leds device to the
45 matches
Mail list logo