Από το 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 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
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
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 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 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
20 matches
Mail list logo
