lkml.org 
[lkml]   [2012]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 0/3] capebus moving omap_devices to mach-omap2
From
Date

Op 2 nov. 2012, om 10:26 heeft "Cousson, Benoit" <b-cousson@ti.com> het volgende geschreven:

> Hi Jason,
>
> On 11/1/2012 7:50 PM, Jason Kridner wrote:
>> My apologies for starting a new thread, but I don't have this thread
>> in my Inbox.
>>
>> http://www.spinics.net/lists/linux-omap/msg81034.html
>>
>> Tony Lindgren wrote:
>>
>>> * Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> [121031 15:02]:
>>>>
>>>> So when device's node is 'disabled' of_platform_device_create_pdata()
>>>> will not create the device.
>>>>
>>>> Now, of course it is possible to re-trigger the platform's probe method
>>>> to be called, and in fact I do so in the capebus patches.
>>>
>>> You should fix this in generic way then rather than working
>>> around it in capebus. The same problem exists changing
>>> between different functionality for the shared pins,
>>> let's say between USB pins and UART pins if you want a
>>> serial debug console on some phone.
>>
>> The current capebus solution goes a long way to fixing a huge issue
>> for BeagleBone users and I don't understand what seems to be a
>> push-back on principle. On BeagleBone capes, these conflicts cannot be
>> resolved early.
>
> I don't think there is any push-back on the principle. It is a very valid problem that does not have any solution today.
>
> The comments are more on the implementation.
>
>> Do you have suggestions on some more generic method? It seems to me
>> the proposed capebus approach strikes a good balance.
>
> Well, yeah, that's a generic DT issue, not a beagle-cape issue.
> We should not necessarily handle it by introducing some fake bus and some new binding like spi-dt / i2c-dt that does not mean anything in term of HW.
>
> DT is about pure HW representation. Introducing some fake hierarchy to make SW life easier is not necessarily the good approach.

I see, pure HW. Let's look at this:

gpio_keys {
compatible = "gpio-keys";
pinctrl-names = "default";
pinctrl-0 = <&bone_lcd3_cape_keys_00A0_pins>;

#address-cells = <1>;
#size-cells = <0>;

button@1 {
debounce_interval = <50>;
linux,code = <105>;
label = "left";
gpios = <&gpio2 16 0x0>;
gpio-key,wakeup;
autorepeat;
};

Is the "linux,code" pure hardware or have there already been exceptions to that rule?

regards,

Koen

\
 
 \ /
  Last update: 2012-11-02 12:01    [W:0.077 / U:0.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site