Από το 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
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
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 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 grant.lik...@secretlab.ca
wrote:
Joel A Fernandes agnel.j...@gmail.com wrote:
Hi Grant,
On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely
grant.lik...@secretlab.ca
On Tue, Nov 6, 2012 at 8:14 AM, Pantelis Antoniou
pa...@antoniou-consulting.com 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
Από το iPhone μου
6 Νοε 2012, 12:16, ο/η Grant Likely grant.lik...@secretlab.ca έγραψε:
On Tue, Nov 6, 2012 at 8:14 AM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote:
Sure, so if we add data type supplementary properties to the
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
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
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
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
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
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
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
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
* 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 Nov 5, 2012, at 1:22 AM, Grant Likely wrote:
On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou
pa...@antoniou-consulting.com 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
On Mon, Nov 5, 2012 at 1:25 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
On Nov 5, 2012, at 1:22 AM, Grant Likely wrote:
On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Assuming that we do work on a DT object format, and that the runtime
* Grant Likely grant.lik...@secretlab.ca [121105 06:36]:
On Mon, Nov 5, 2012 at 1:25 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
On Nov 5, 2012, at 1:22 AM, Grant Likely wrote:
On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou
pa...@antoniou-consulting.com 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
pa...@antoniou-consulting.com 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
On 11/05/2012 08:34 AM, Grant Likely wrote:
On Mon, Nov 5, 2012 at 1:25 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
On Nov 5, 2012, at 1:22 AM, Grant Likely wrote:
On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Assuming that we do work
On Mon, Nov 5, 2012 at 3:37 PM, Pantelis Antoniou
pa...@antoniou-consulting.com 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
pa...@antoniou-consulting.com wrote:
The i2c2 alias cannot be resolved at compile time; there
On Mon, Nov 5, 2012 at 3:56 PM, Rob Herring robherri...@gmail.com 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
Hi Grant,
On Nov 5, 2012, at 8:10 PM, Grant Likely wrote:
On Mon, Nov 5, 2012 at 3:37 PM, Pantelis Antoniou
pa...@antoniou-consulting.com 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
pa...@antoniou-consulting.com
On Mon, Nov 5, 2012 at 7:54 PM, Pantelis Antoniou
pa...@antoniou-consulting.com 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
Hi Grant,
On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely grant.lik...@secretlab.ca wrote:
On Mon, Nov 5, 2012 at 7:54 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
This handles many of the use cases, but it assumes that an overlay is
board specific. If it ever is required to
Joel A Fernandes agnel.j...@gmail.com wrote:
Hi Grant,
On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely
grant.lik...@secretlab.ca 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
Hi Grant,
On Mon, Nov 5, 2012 at 5:58 PM, Grant Likely grant.lik...@secretlab.ca wrote:
Joel A Fernandes agnel.j...@gmail.com wrote:
Hi Grant,
On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
I'm open to suggestions if anyone has any. I have not objections to a
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
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 = < 16
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
On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou
pa...@antoniou-consulting.com 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
On Fri, Nov 2, 2012 at 10:19 AM, Koen Kooi k...@dominion.thruhere.net wrote:
button@1 {
debounce_interval = 50;
linux,code = 105;
label = left;
On Fri, Nov 2, 2012 at 12:32 PM, Pantelis Antoniou
pa...@antoniou-consulting.com 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
On Fri, Nov 2, 2012 at 4:07 PM, Jason Kridner jkrid...@beagleboard.org 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
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.
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.
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
> 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
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
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
> >> 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
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
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
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'
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 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 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
On 11/1/2012 1:00 PM, Koen Kooi wrote:
tl;dr: please suggest an actual solution that allows plugplay 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 b-cous...@ti.com het
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 plugplay when plugging
in multiple capes and applying power after that. Preferably one that doesn't
pass the buck to u-boot.
Op 1
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 ba...@ti.com 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
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@xxx [121031 15:02]:
So when
On Fri, Nov 2, 2012 at 1:57 AM, Felipe Balbi ba...@ti.com 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 ba...@ti.com wrote:
HI,
On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote:
Hi Alan,
On Nov 1,
Op 2 nov. 2012, om 10:26 heeft Cousson, Benoit b-cous...@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
Op 2 nov. 2012, om 10:42 heeft Russ Dill russ.d...@ti.com het volgende
geschreven:
On Fri, Nov 2, 2012 at 1:57 AM, Felipe Balbi ba...@ti.com 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 ba...@ti.com wrote:
HI,
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 have no
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 onto the
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 is the wrong
On Fri, Nov 2, 2012 at 7:21 AM, Alan Cox a...@lxorguk.ukuu.org.uk 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
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 critical
On Fri, Nov 2, 2012 at 4:00 AM, Felipe Balbi ba...@ti.com 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
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
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'
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
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;
> 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
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
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 when
>> plugging in multiple capes and applying power after that. Preferably
>> one that
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 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 distribution
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 =
tl;dr: please suggest an actual solution that allows plug 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,
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";
>
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
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 =
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
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
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 pa...@antoniou-consulting.com [121031 13:14]:
On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote:
Yeah, I do agree. I'm confused as well.
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 pa...@antoniou-consulting.com [121031 13:14]:
On Oct 31, 2012, at 9:55 PM, Benoit Cousson
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
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 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
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-frequency = 800;
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, at 12:14 AM, Felipe
tl;dr: please suggest an actual solution that allows plugplay 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 b-cous...@ti.com het
volgende geschreven:
Hi Panto,
On 11/1/2012
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 = adafruit,tft-lcd-1.8-red,
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:
lcd@0 {
Hi,
On Thu, Nov 01, 2012 at 01:00:21PM +0100, Koen Kooi wrote:
tl;dr: please suggest an actual solution that allows plugplay 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
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 DT core and not workaround it
Op 1 nov. 2012, om 14:06 heeft Felipe Balbi ba...@ti.com 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 plugplay when
plugging in multiple capes and applying power after that. Preferably
one
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 is a real limitation of
DT,
1 - 100 of 132 matches
Mail list logo
