On Thu, 2011-08-11 at 22:57 -0700, Dmitry Torokhov wrote:
> On Fri, Aug 12, 2011 at 01:41:22PM +0900, Mark Brown wrote:
> > You tend to find that in a lot of systems only need a subset of the
> > platform data - some of it can get pretty esoteric - or perhaps none at
> > all so they'll be able to
On Fri, Aug 12, 2011 at 01:41:22PM +0900, Mark Brown wrote:
> On Thu, 2011-08-11 at 20:53 -0700, Dmitry Torokhov wrote:
>
> > Maybe should not add DT bindings for devices that can't be adequately
> > expressed via DT properties [yet]? Because I do not see what benefits we
> > get since platform co
On Thu, 2011-08-11 at 20:53 -0700, Dmitry Torokhov wrote:
> On Fri, Aug 12, 2011 at 11:16:49AM +0800, Barry Song wrote:
> > at least wakeup, irq_flags in the structure should be something
> > related with driver implementation not hardware. Suppose all others
> > are hardware properties, it looks
2011/8/12 Dmitry Torokhov :
> On Fri, Aug 12, 2011 at 11:16:49AM +0800, Barry Song wrote:
>> 2011/8/10 Mark Brown :
>> > On Wed, Aug 10, 2011 at 01:57:11PM +0800, Barry Song wrote:
>> >> 2011/8/10 Mark Brown :
>> >
>> >> >> struct ads7846_platform_data {
>> >> >> u16 model;
On Tue, Aug 09, 2011 at 11:37:10PM +0200, Cousson, Benoit wrote:
> On 8/9/2011 11:16 PM, Grant Likely wrote:
> >On Tue, Aug 09, 2011 at 11:06:30PM +0200, Cousson, Benoit wrote:
> >>On 8/9/2011 10:55 PM, Grant Likely wrote:
> >>>On Tue, Aug 09, 2011 at 07:47:20PM +0200, Cousson, Benoit wrote:
>
On Fri, Aug 12, 2011 at 11:16:49AM +0800, Barry Song wrote:
> 2011/8/10 Mark Brown :
> > On Wed, Aug 10, 2011 at 01:57:11PM +0800, Barry Song wrote:
> >> 2011/8/10 Mark Brown :
> >
> >> >> struct ads7846_platform_data {
> >> >> u16 model; /* 7843, 7845, 7846, 7873. */
2011/8/10 Mark Brown :
> On Wed, Aug 10, 2011 at 01:57:11PM +0800, Barry Song wrote:
>> 2011/8/10 Mark Brown :
>
>> >> struct ads7846_platform_data {
>> >> u16 model; /* 7843, 7845, 7846, 7873. */
>> >> u16 vref_mv; /* external vref value, mi
Marc,
On 08/11/2011 02:56 AM, Marc Zyngier wrote:
> Hi Rob,
>
> Thanks for looking at this.
>
> On 10/08/11 21:15, Rob Herring wrote:
>> From: Rob Herring
>>
>> This adds gic initialization using device tree data. An example device tree
>> binding looks like this:
>>
>> intc: interrupt-controll
On Thu, Aug 11, 2011 at 02:28:55PM +0200, Cousson, Benoit wrote:
> On 8/10/2011 9:22 PM, Grant Likely wrote:
> >On Tue, Aug 9, 2011 at 7:52 PM, David Gibson
> > 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
On Tue, Aug 09, 2011 at 09:21:31AM -0700, Stephen Warren wrote:
> Stephen Warren wrote at Monday, August 08, 2011 1:26 PM:
> > Rob Herring wrote at Sunday, August 07, 2011 8:38 AM:
> > > On 08/05/2011 05:50 PM, Stephen Warren wrote:
> > > > The patch adds empty function of_get_property for non-dt b
On 8/11/2011 10:06 AM, Stephen Warren wrote:
Thomas Abraham wrote at Thursday, August 11, 2011 12:09 PM:
I did some work on the gpio and pinmux device tree support for exynos.
I thought to discuss with you about what was done before proceeding
further.
In the dts file, the interrupt controller
Thomas Abraham wrote at Thursday, August 11, 2011 12:09 PM:
> I did some work on the gpio and pinmux device tree support for exynos.
> I thought to discuss with you about what was done before proceeding
> further.
>
> In the dts file, the interrupt controller node is listed as
>
> GPA: gpio-contr
Hi Grant,
I did some work on the gpio and pinmux device tree support for exynos.
I thought to discuss with you about what was done before proceeding
further.
In the dts file, the interrupt controller node is listed as
GPA: gpio-controller@1140 {
compatible = "samsung,exynos4-
On Aug 11, 2011, at 11:18 AM, Marc Kleine-Budde wrote:
> On 08/11/2011 06:07 PM, Robin Holt wrote:
>> If our CAN device's device tree node has a clock-frequency property,
>> then use that value for the can devices clock frequency. If not, fall
>> back to asking the platform/mach code for the clo
On Thu, Aug 11, 2011 at 10:07 AM, Robin Holt wrote:
> 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 used by the driver so we are removing them.
>
> Signed-off-by: Robin Holt
> To: Marc K
On 08/11/2011 06:07 PM, Robin Holt wrote:
> If our CAN device's device tree node has a clock-frequency property,
> then use that value for the can devices clock frequency. If not, fall
> back to asking the platform/mach code for the clock frequency associated
> with the flexcan device.
>
> Signed
On Thu, Aug 11, 2011 at 05:06:23PM +0100, Rob Herring wrote:
> On 08/11/2011 10:38 AM, Will Deacon wrote:
> >
> > You mean putting the combined interrupt first? If so, we may as well just
> > specify that until somebody builds a platform that doesn't have it.
> >
>
> No, either you have 1 interr
On 08/11/2011 06:07 PM, Robin Holt wrote:
> If our CAN device's device tree node has a clock-frequency property,
> then use that value for the can devices clock frequency. If not, fall
> back to asking the platform/mach code for the clock frequency associated
> with the flexcan device.
nitpicking
If our CAN device's device tree node has a clock-frequency property,
then use that value for the can devices clock frequency. If not, fall
back to asking the platform/mach code for the clock frequency associated
with the flexcan device.
Signed-off-by: Robin Holt
To: Kumar Gala
To: Wolfgang Gran
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
Acked-by: Marc Kleine-Budde
Acked-by: Wolfgang Grandegger
Cc: U Bhaskar-B22300
Cc: Grant Lik
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 used by the driver so we are removing them.
Signed-off-by: Robin Holt
To: Marc Kleine-Budde ,
To: Wolfgang Grandegger ,
To: U Bhaskar-B22300
To
On 08/11/2011 10:38 AM, Will Deacon wrote:
> On Thu, Aug 11, 2011 at 04:32:08PM +0100, Rob Herring wrote:
>> On 08/11/2011 08:09 AM, Will Deacon wrote:
>>> On Thu, Aug 11, 2011 at 02:05:11PM +0100, Arnd Bergmann wrote:
On Wednesday 10 August 2011, Will Deacon wrote:
> I was hoping that it
On Thu, Aug 11, 2011 at 04:32:08PM +0100, Rob Herring wrote:
> On 08/11/2011 08:09 AM, Will Deacon wrote:
> > On Thu, Aug 11, 2011 at 02:05:11PM +0100, Arnd Bergmann wrote:
> >> On Wednesday 10 August 2011, Will Deacon wrote:
> >>> I was hoping that it was possible to have separate properties which
On 08/11/2011 08:09 AM, Will Deacon wrote:
> On Thu, Aug 11, 2011 at 02:05:11PM +0100, Arnd Bergmann wrote:
>> On Wednesday 10 August 2011, Will Deacon wrote:
>>> I was hoping that it was possible to have separate properties which describe
>>> the interrupt. So you could have something like pmu-int
Following the discussion here:
http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-August/007301.html
The L2x0 L2 Cache Controllers support a combined interrupt line
which can be used for several events (e.g. read/write/parity errors on
tag/data RAM, event counter increment/overflow). Unfort
On Thu, Aug 11, 2011 at 02:05:11PM +0100, Arnd Bergmann wrote:
> On Wednesday 10 August 2011, Will Deacon wrote:
> > I was hoping that it was possible to have separate properties which describe
> > the interrupt. So you could have something like pmu-interrupt <75> and
> > abort-interrupt <76> rathe
On Wednesday 10 August 2011, Will Deacon wrote:
> I was hoping that it was possible to have separate properties which describe
> the interrupt. So you could have something like pmu-interrupt <75> and
> abort-interrupt <76> rather than interrupts <75, 76>.
Ok, I see.
> I've not played with DT bind
On 8/10/2011 9:22 PM, Grant Likely wrote:
On Tue, Aug 9, 2011 at 7:52 PM, David Gibson
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 d
On Wed, Aug 10, 2011 at 10:13:27AM -0500, Scott Wood wrote:
> 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-d
Hi Rob,
Thanks for looking at this.
On 10/08/11 21:15, Rob Herring wrote:
> From: Rob Herring
>
> 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";
>
30 matches
Mail list logo
