Από το iPhone μου
6 Νοε 2012, 12:16, ο/η Grant Likely έγραψε:
> On Tue, Nov 6, 2012 at 8:14 AM, Pantelis Antoniou
> wrote:
>> On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote:
>>> Sure, so if we add data type supplementary properties to the tree to
>>> indicate the data type as "indirect ph
On Tue, Nov 6, 2012 at 8:14 AM, Pantelis Antoniou
wrote:
> On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote:
>> Sure, so if we add data type supplementary properties to the tree to
>> indicate the data type as "indirect phandle", then kernel could refer
>> to the index in the got-like table to f
Hi Joel,
On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote:
> Hi Grant,
>
> On Mon, Nov 5, 2012 at 5:58 PM, Grant Likely
> wrote:
>>
>>
>> Joel A Fernandes wrote:
>>
>>> Hi Grant,
>>>
>>> On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely
>>> wrote:
I'm open to suggestions if anyone has
Hi Grant,
On Mon, Nov 5, 2012 at 5:58 PM, Grant Likely wrote:
>
>
> Joel A Fernandes wrote:
>
>>Hi Grant,
>>
>>On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely
>> wrote:
>>> I'm open to suggestions if anyone has any. I have not objections to a
>>> fixup approach, but I'm not comfortable with anythin
Joel A Fernandes wrote:
>Hi Grant,
>
>On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely
> wrote:
>> I'm open to suggestions if anyone has any. I have not objections to a
>> fixup approach, but I'm not comfortable with anything that is fragile
>> to modifications to the fragment.
>
>I am fairly new t
Hi Grant,
On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely wrote:
> On Mon, Nov 5, 2012 at 7:54 PM, Pantelis Antoniou
> wrote:
>>> This handles many of the use cases, but it assumes that an overlay is
>>> board specific. If it ever is required to support multiple base boards
>>> with a single overla
On Mon, Nov 5, 2012 at 7:54 PM, Pantelis Antoniou
wrote:
>> This handles many of the use cases, but it assumes that an overlay is
>> board specific. If it ever is required to support multiple base boards
>> with a single overlay file then there is a problem. The .dtb overlays
>> generated in this
Hi Grant,
On Nov 5, 2012, at 8:10 PM, Grant Likely wrote:
> On Mon, Nov 5, 2012 at 3:37 PM, Pantelis Antoniou
> wrote:
>> Hi Grant,
>>
>> On Nov 5, 2012, at 1:37 AM, Grant Likely wrote:
>>
>>> On Fri, Nov 2, 2012 at 12:32 PM, Pantelis Antoniou
>>> wrote:
The i2c2 alias cannot be resolved
On Mon, Nov 5, 2012 at 3:56 PM, Rob Herring wrote:
> On 11/05/2012 08:34 AM, Grant Likely wrote:
>> Good. I'm about 80% though putting together a project plan of what is
>> required to implement this. I'll post it for RFC shortly. I would
>> appreciate feedback and help on flushing out the design.
On Mon, Nov 5, 2012 at 3:37 PM, Pantelis Antoniou
wrote:
> Hi Grant,
>
> On Nov 5, 2012, at 1:37 AM, Grant Likely wrote:
>
>> On Fri, Nov 2, 2012 at 12:32 PM, Pantelis Antoniou
>> wrote:
>>> The i2c2 alias cannot be resolved at compile time; there has to be
>>>
>>> a) A DT object format where unr
On 11/05/2012 08:34 AM, Grant Likely wrote:
> On Mon, Nov 5, 2012 at 1:25 PM, Pantelis Antoniou
> wrote:
>>
>> On Nov 5, 2012, at 1:22 AM, Grant Likely wrote:
>>
>>> On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou
>>> wrote:
Assuming that we do work on a DT object format, and that the runt
Hi Grant,
On Nov 5, 2012, at 1:37 AM, Grant Likely wrote:
> On Fri, Nov 2, 2012 at 12:32 PM, Pantelis Antoniou
> wrote:
>> The i2c2 alias cannot be resolved at compile time; there has to be
>>
>> a) A DT object format where unresolved aliases (symbols) are tracked
>> b) A runtime DT linker that
* Grant Likely [121105 06:36]:
> On Mon, Nov 5, 2012 at 1:25 PM, Pantelis Antoniou
> wrote:
> >
> > On Nov 5, 2012, at 1:22 AM, Grant Likely wrote:
> >
> >> On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou
> >> wrote:
> >>> Assuming that we do work on a DT object format, and that the runtime
>
On Mon, Nov 5, 2012 at 1:25 PM, Pantelis Antoniou
wrote:
>
> On Nov 5, 2012, at 1:22 AM, Grant Likely wrote:
>
>> On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou
>> wrote:
>>> Assuming that we do work on a DT object format, and that the runtime
>>> resolution mechanism is approved,
>>> then I
On Nov 5, 2012, at 1:22 AM, Grant Likely wrote:
> On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou
> wrote:
>> Assuming that we do work on a DT object format, and that the runtime
>> resolution mechanism is approved,
>> then I agree that this part of the capebus patches can be dropped and the
On Fri, Nov 2, 2012 at 4:07 PM, Jason Kridner wrote:
>> Take a look at arch/x86/platform/mrst/mrst.c. It's a specific example of
>> a platform which parses tables and attaches devices to the right physical
>> bus in a manner they can be reliably probed even when the device has no
>> sane autodetec
On Fri, Nov 2, 2012 at 12:32 PM, Pantelis Antoniou
wrote:
> The i2c2 alias cannot be resolved at compile time; there has to be
>
> a) A DT object format where unresolved aliases (symbols) are tracked
> b) A runtime DT linker that will resolve the alias, and will insert the
>i2c2-devices child
On Fri, Nov 2, 2012 at 10:19 AM, Koen Kooi wrote:
> button@1 {
> debounce_interval = <50>;
> linux,code = <105>;
> label = "left";
> gpios = <&gpi
On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou
wrote:
> Assuming that we do work on a DT object format, and that the runtime
> resolution mechanism is approved,
> then I agree that this part of the capebus patches can be dropped and the
> functionality assumed by generic
> DT core.
>
> The qu
On 11/02/2012 09:43 AM, Pantelis Antoniou wrote:
[...]
And then use the standard DT support to create later the platform_device that
does represent the new super-cape devices.
We know this is the ideal case. In fact that's the long term goal and we had
internal discussions about it.
Sinc
On Fri, Nov 2, 2012 at 4:00 AM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Nov 02, 2012 at 02:42:51AM -0700, Russ Dill wrote:
>> >> browse through various detect functions, yes, some of them key off an
>> >> ID, but a lot of them just check various registers to see if certain
>> >> bits are zero, or ce
> Further, it is critical to enable hardware vendors to avoid writing
> any code for which there are existing drivers.
Which is why you don't want to create a new bus type for it.
> Capebus seems to me to provide this solution fairly well. I don't
> believe the SFI approach covers the most critic
On Fri, Nov 2, 2012 at 7:21 AM, Alan Cox wrote:
>> >> Fair enough. But there's no such thing a 'hotplug enumeration
>> >> construct' in Linux yet, and a bus is the closest thing to it. It does
>> >> take advantage of the nice way device code matches drivers and devices
>> >> though.
>
> A bus is t
Hi Alan,
On Nov 2, 2012, at 1:21 PM, Alan Cox wrote:
Fair enough. But there's no such thing a 'hotplug enumeration
construct' in Linux yet, and a bus is the closest thing to it. It does
take advantage of the nice way device code matches drivers and devices
though.
>
> A bus i
> >> Fair enough. But there's no such thing a 'hotplug enumeration
> >> construct' in Linux yet, and a bus is the closest thing to it. It does
> >> take advantage of the nice way device code matches drivers and devices
> >> though.
A bus is the wrong construct. You need something to add devices on
Hi,
On Fri, Nov 02, 2012 at 02:42:51AM -0700, Russ Dill wrote:
> >> browse through various detect functions, yes, some of them key off an
> >> ID, but a lot of them just check various registers to see if certain
> >> bits are zero, or certain bits are one. A lot of I²C devices I've
> >> dealt with
Op 2 nov. 2012, om 10:42 heeft Russ Dill het volgende
geschreven:
> On Fri, Nov 2, 2012 at 1:57 AM, Felipe Balbi wrote:
>> Hi,
>>
>> On Thu, Nov 01, 2012 at 04:49:23PM -0700, Russ Dill wrote:
>>> On Thu, Nov 1, 2012 at 3:05 PM, Felipe Balbi wrote:
HI,
On Thu, Nov 01, 2012 at
Op 2 nov. 2012, om 10:26 heeft "Cousson, Benoit" 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
On Fri, Nov 2, 2012 at 1:57 AM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Nov 01, 2012 at 04:49:23PM -0700, Russ Dill wrote:
>> On Thu, Nov 1, 2012 at 3:05 PM, Felipe Balbi wrote:
>> > HI,
>> >
>> > On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote:
>> >> Hi Alan,
>> >>
>> >> On Nov 1
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 [121031 15:02]:
So when device's node is 'disabled' of_plat
Hi,
On Thu, Nov 01, 2012 at 04:49:23PM -0700, Russ Dill wrote:
> On Thu, Nov 1, 2012 at 3:05 PM, Felipe Balbi wrote:
> > HI,
> >
> > On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote:
> >> Hi Alan,
> >>
> >> On Nov 1, 2012, at 3:51 PM, Alan Cox wrote:
> >>
> >> >> What they want,
Hi Benoit,
On Nov 2, 2012, at 10:15 AM, Cousson, Benoit wrote:
> On 11/1/2012 1:00 PM, Koen Kooi wrote:
>> tl;dr: please suggest an actual solution that allows plug&play when plugging
>> in multiple capes and applying power after that. Preferably one that doesn't
>> pass the buck to u-boot.
>>
On 11/1/2012 1:00 PM, Koen Kooi wrote:
tl;dr: please suggest an actual solution that allows plug&play when plugging in
multiple capes and applying power after that. Preferably one that doesn't pass the
buck to u-boot.
Op 1 nov. 2012, om 12:26 heeft "Cousson, Benoit" het
volgende geschreven:
On Thu, Nov 1, 2012 at 3:05 PM, Felipe Balbi wrote:
> HI,
>
> On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote:
>> Hi Alan,
>>
>> On Nov 1, 2012, at 3:51 PM, Alan Cox wrote:
>>
>> >> What they want, and what every user wants, is I plug this board in, and
>> >> the driver make sure
HI,
On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote:
> Hi Alan,
>
> On Nov 1, 2012, at 3:51 PM, Alan Cox wrote:
>
> >> What they want, and what every user wants, is I plug this board in, and
> >> the driver make sure everything is loaded and ready. No, the end users
> >> don't
* Jason Kridner [121101 11:52]:
> 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 [121031 15:02]:
> >>
> >> So when device's node is 'disabled' of_pla
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 [121031 15:02]:
>>
>> So when device's node is 'disabled' of_platform_device_create_pdata()
>> will not create the de
Hi Alan,
On Nov 1, 2012, at 3:51 PM, Alan Cox wrote:
>> What they want, and what every user wants, is I plug this board in, and
>> the driver make sure everything is loaded and ready. No, the end users
>> don't want to see any of the implementation details of how the bitfile
>> is transported; th
> What they want, and what every user wants, is I plug this board in, and
> the driver make sure everything is loaded and ready. No, the end users
> don't want to see any of the implementation details of how the bitfile
> is transported; the driver can handle it.
That doesn't necessarily make it a
Hi
On Nov 1, 2012, at 3:16 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Nov 01, 2012 at 02:57:26PM +0200, Pantelis Antoniou wrote:
>>> Each cape will have their own DTS and based on some board id you
>>> will fix the DT dynamically.
>>>
>>> My point is that the issue you are facing
Op 1 nov. 2012, om 14:06 heeft Felipe Balbi het volgende
geschreven:
> Hi,
>
> On Thu, Nov 01, 2012 at 01:00:21PM +0100, Koen Kooi wrote:
>> tl;dr: please suggest an actual solution that allows plug&play when
>> plugging in multiple capes and applying power after that. Preferably
>> one that d
Hi,
On Thu, Nov 01, 2012 at 02:57:26PM +0200, Pantelis Antoniou wrote:
> > Each cape will have their own DTS and based on some board id you
> > will fix the DT dynamically.
> >
> > My point is that the issue you are facing is a real limitation of
> > DT, so you should fix the
Hi,
On Thu, Nov 01, 2012 at 01:00:21PM +0100, Koen Kooi wrote:
> tl;dr: please suggest an actual solution that allows plug&play when
> plugging in multiple capes and applying power after that. Preferably
> one that doesn't pass the buck to u-boot.
I can think of a few ways:
1) ship your distribu
Hi,
On Nov 1, 2012, at 2:40 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Nov 01, 2012 at 01:26:10PM +0200, Pantelis Antoniou wrote:
>> Hi
>>
>> On Nov 1, 2012, at 1:04 PM, Felipe Balbi wrote:
>>
>>> Hi,
>>>
>>> On Thu, Nov 01, 2012 at 12:39:30PM +0200, Pantelis Antoniou wrote:
>>>
Hi,
On Thu, Nov 01, 2012 at 01:26:10PM +0200, Pantelis Antoniou wrote:
> Hi
>
> On Nov 1, 2012, at 1:04 PM, Felipe Balbi wrote:
>
> > Hi,
> >
> > On Thu, Nov 01, 2012 at 12:39:30PM +0200, Pantelis Antoniou wrote:
> >lcd@0 {
> >compatible = "adafr
tl;dr: please suggest an actual solution that allows plug&play when plugging in
multiple capes and applying power after that. Preferably one that doesn't pass
the buck to u-boot.
Op 1 nov. 2012, om 12:26 heeft "Cousson, Benoit" het
volgende geschreven:
> Hi Panto,
>
> On 11/1/2012 11:39 AM,
Hi Benoit,
On Nov 1, 2012, at 1:26 PM, Cousson, Benoit wrote:
> Hi Panto,
>
> On 11/1/2012 11:39 AM, Pantelis Antoniou wrote:
>> Hi Benoit,
>>
>> On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote:
>>
>>> On 11/1/2012 8:02 AM, Pantelis Antoniou wrote:
Hi Felibe,
On Nov 1, 2012,
Hi
On Nov 1, 2012, at 1:04 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Nov 01, 2012 at 12:39:30PM +0200, Pantelis Antoniou wrote:
>lcd@0 {
>compatible = "adafruit,tft-lcd-1.8-red",
> "sitronix,st7735";
>spi-max-frequ
Hi Panto,
On 11/1/2012 11:39 AM, Pantelis Antoniou wrote:
Hi Benoit,
On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote:
On 11/1/2012 8:02 AM, Pantelis Antoniou wrote:
Hi Felibe,
On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote:
Hi,
On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Anton
Hi,
On Thu, Nov 01, 2012 at 12:39:30PM +0200, Pantelis Antoniou wrote:
> >>> lcd@0 {
> >>> compatible = "adafruit,tft-lcd-1.8-red",
> >>> "sitronix,st7735";
> >>> spi-max-frequency = <800>;
> >>> reg = <0>
Hi Benoit,
On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote:
> On 11/1/2012 8:02 AM, Pantelis Antoniou wrote:
>> Hi Felibe,
>>
>> On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote:
>>
>>> Hi,
>>>
>>> On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote:
> * Pantelis Antoniou
On 11/1/2012 8:02 AM, Pantelis Antoniou wrote:
Hi Felibe,
On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote:
Hi,
On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote:
* Pantelis Antoniou [121031 13:14]:
On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote:
Yeah, I do agree. I'm c
Hi Felibe,
On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote:
>>> * Pantelis Antoniou [121031 13:14]:
On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote:
>
> Yeah, I do agree. I'm confused as well. Only OMAP
Hi,
On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote:
> > * Pantelis Antoniou [121031 13:14]:
> >> On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote:
> >>>
> >>> Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control
> >>> could have an hwmod and thus must be h
* Pantelis Antoniou [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
Hi Tony,
On Oct 31, 2012, at 11:43 PM, Tony Lindgren wrote:
> * Pantelis Antoniou [121031 14:38]:
>>
>> There a a whole bunch of conflicting capes. There's no
>> way to instantiate them together. They must be instantiated
>> only after their EEPROMs are read and they are matched
>> to their cor
* Pantelis Antoniou [121031 14:38]:
>
> There a a whole bunch of conflicting capes. There's no
> way to instantiate them together. They must be instantiated
> only after their EEPROMs are read and they are matched
> to their corresponding cape drivers.
You don't need to instantiate the capes dur
Tony,
On Oct 31, 2012, at 11:26 PM, Tony Lindgren wrote:
> * Pantelis Antoniou [121031 13:14]:
>> On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote:
>>>
>>> Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control
>>> could have an hwmod and thus must be handled by an omap_devic
* Pantelis Antoniou [121031 13:14]:
> On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote:
> >
> > Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control
> > could have an hwmod and thus must be handled by an omap_device.
> >
> > Any devices that is created later cannot be omap_d
Hi Benoit,
On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote:
> Hi Panto,
>
> On 10/31/2012 07:09 PM, Tony Lindgren wrote:
>> * Pantelis Antoniou [121031 11:05]:
>>> Hi Tony,
>>>
>>> On Oct 31, 2012, at 7:52 PM, Tony Lindgren wrote:
>>>
* Pantelis Antoniou [121031 10:26]:
> It is pa
Hi Panto,
On 10/31/2012 07:09 PM, Tony Lindgren wrote:
> * Pantelis Antoniou [121031 11:05]:
>> Hi Tony,
>>
>> On Oct 31, 2012, at 7:52 PM, Tony Lindgren wrote:
>>
>>> * Pantelis Antoniou [121031 10:26]:
It is painless to move the adapter DT devices to arch/arm/mach-omap2
However
On Oct 31, 2012, at 8:09 PM, Tony Lindgren wrote:
> * Pantelis Antoniou [121031 11:05]:
>> Hi Tony,
>>
>> On Oct 31, 2012, at 7:52 PM, Tony Lindgren wrote:
>>
>>> * Pantelis Antoniou [121031 10:26]:
It is painless to move the adapter DT devices to arch/arm/mach-omap2
However I
* Pantelis Antoniou [121031 11:05]:
> Hi Tony,
>
> On Oct 31, 2012, at 7:52 PM, Tony Lindgren wrote:
>
> > * Pantelis Antoniou [121031 10:26]:
> >> It is painless to move the adapter DT devices to arch/arm/mach-omap2
> >>
> >> However I got bit by the __init at omap_build_device family functio
Hi Tony,
On Oct 31, 2012, at 7:52 PM, Tony Lindgren wrote:
> * Pantelis Antoniou [121031 10:26]:
>> It is painless to move the adapter DT devices to arch/arm/mach-omap2
>>
>> However I got bit by the __init at omap_build_device family functions.
>> If you don't remove it, crashes every time you
* Pantelis Antoniou [121031 10:26]:
> It is painless to move the adapter DT devices to arch/arm/mach-omap2
>
> However I got bit by the __init at omap_build_device family functions.
> If you don't remove it, crashes every time you instantiate a device
> at runtime, or you load the cape driver as
It is painless to move the adapter DT devices to arch/arm/mach-omap2
However I got bit by the __init at omap_build_device family functions.
If you don't remove it, crashes every time you instantiate a device
at runtime, or you load the cape driver as a module.
Pantelis Antoniou (3):
omap-device
66 matches
Mail list logo
