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 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
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, milliVolts
> >>
2011/8/10 Mark Brown :
> On Wed, Aug 10, 2011 at 09:21:16AM +0800, Barry Song wrote:
>> 2011/8/9 Mark Brown :
>
>> > Oh, if that's the case the driver ought to have device tree bindings
>> > which replicate the platform data. Unless the platform data is
>> > sufficiently obscure for hardly anyone
On Wed, Aug 10, 2011 at 09:21:16AM +0800, Barry Song wrote:
> 2011/8/9 Mark Brown :
> > Oh, if that's the case the driver ought to have device tree bindings
> > which replicate the platform data. Unless the platform data is
> > sufficiently obscure for hardly anyone to want to use it I guess.
>
2011/8/9 Mark Brown :
> On Mon, Aug 08, 2011 at 11:51:00PM -0700, Dmitry Torokhov wrote:
>
>> The issue I have with the ads7846 driver is that it still needs platform
>> code to supply the needed platform data structure to make the
>> driver/device usable. So I am not sure what the benefit DT match
On Mon, Aug 08, 2011 at 11:51:00PM -0700, Dmitry Torokhov wrote:
> The issue I have with the ads7846 driver is that it still needs platform
> code to supply the needed platform data structure to make the
> driver/device usable. So I am not sure what the benefit DT matching code
> brings to that dr
Hi Barry,
On Mon, Aug 08, 2011 at 04:38:41PM +0800, Barry Song wrote:
> 2011/8/8 Mark Brown :
> > Signed-off-by: Mark Brown
>
> Without this patch, DT can still connect driver with device by the
> heuristic way(of_modalias_node).
>
> i have a patch just like yours in input subsystem "[PATCH v2]
On Mon, Aug 08, 2011 at 04:38:41PM +0800, Barry Song wrote:
> 2011/8/8 Mark Brown :
> > Signed-off-by: Mark Brown
> Without this patch, DT can still connect driver with device by the
> heuristic way(of_modalias_node).
Well, the other part of things is that it explicitly defines the
bindings (inc
2011/8/8 Mark Brown :
> Signed-off-by: Mark Brown
Without this patch, DT can still connect driver with device by the
heuristic way(of_modalias_node).
i have a patch just like yours in input subsystem "[PATCH v2] input:
touchscreen: add OF match table for ads7846" with "Acked-by: Grant
Likely", b
14 matches
Mail list logo
