On Fri, Apr 1, 2011 at 11:43 PM, Eric Miao wrote:
> Just FYI - lengthy but very interesting read, Linus was really good at
> wording, enjoy heh :-)
>
> https://lkml.org/lkml/2011/3/17/283
>
> So maybe it's just a right time to talk about using linaro ARM kernel
> tree as a fork for quick merge of
On Sun, 3 Apr 2011, Andy Green wrote:
> I just don't see people tweaking DT tables by package update and leaving the
> kernel package unchanged, I do see wrong version DT tables getting pulled in,
> bootloader environments pointing to the wrong place or NAND or default
> environments coming in and
On Sun, Apr 3, 2011 at 11:26 AM, Jaswinder Singh
wrote:
> On 3 April 2011 21:44, Andy Green wrote:
>> On 04/03/2011 05:05 PM, Somebody in the thread at some point said:
>>
>>> Above everything else, I definitely like to see DT get done first,
>>> it's essential for SoC these days.
>>
>> All I am
On Sun, Apr 3, 2011 at 1:26 PM, Andy Green wrote:
> On 04/03/2011 06:19 PM, Somebody in the thread at some point said:
>> hardware in the device tree and remove the old kernel code that was
>> building the description. Move on to device trees provided by the
>> bootloader. After basic hardware des
On 04/03/2011 06:19 PM, Somebody in the thread at some point said:
Hi -
On the other hand, device trees aren't a static solution. For example,
they haven't come up with a generic mechanism for completely
describing things like clock and power management domains. But let's
figure out schemes for
On 3 April 2011 21:44, Andy Green wrote:
> On 04/03/2011 05:05 PM, Somebody in the thread at some point said:
>
>> Above everything else, I definitely like to see DT get done first,
>> it's essential for SoC these days.
>
> All I am suggesting is bind the DTs in the kernel. That's easier and fast
On Sun, Apr 3, 2011 at 12:46 PM, Matt Sealey wrote:
> At the point where device tree specification and maintenance is done
> in-kernel, device trees get very Linux-specific and very
> Linux-driver-specific. Plenty of mistakes were made in the move to
> flattened device trees on PowerPC which took
On 04/03/2011 05:46 PM, Somebody in the thread at some point said:
As long as the experience is driven by both the SoC vendor and the
board designer and not the kernel driver engineer, this will go very
well..
At the point where device tree specification and maintenance is done
in-kernel, device
As long as the experience is driven by both the SoC vendor and the
board designer and not the kernel driver engineer, this will go very
well..
At the point where device tree specification and maintenance is done
in-kernel, device trees get very Linux-specific and very
Linux-driver-specific. Plenty
On 04/03/2011 05:05 PM, Somebody in the thread at some point said:
Above everything else, I definitely like to see DT get done first,
it's essential for SoC these days.
All I am suggesting is bind the DTs in the kernel. That's easier and
faster than the alternatives and there is a lot less t
On 04/03/2011 04:25 PM, Somebody in the thread at some point said:
Hi -
Think of the DT as a way of probing a bus that doesn't have probe
capabilities. This gives you a way to dynamically load drivers from
initrd if you want. For example we dynamically loaded drivers for I2C
devices that were p
On Sun, Apr 3, 2011 at 10:25 AM, jonsm...@gmail.com wrote:
> On Sun, Apr 3, 2011 at 4:38 AM, Andy Green wrote:
>> On 04/03/2011 04:07 AM, Somebody in the thread at some point said:
>>
>> Hi -
>>
* And very hardware specific code moved out to a controllable place,
i.e. something li
On Sun, Apr 3, 2011 at 4:38 AM, Andy Green wrote:
> On 04/03/2011 04:07 AM, Somebody in the thread at some point said:
>
> Hi -
>
>>> * And very hardware specific code moved out to a controllable place,
>>> i.e. something like BIOS
>>
>> Sorry, but I must vehemently disagree here. BIOSes ar
I'm trying to get this data from the Smarttop to show the SPDIF device
but I get the same "No PulseAudio daemon running, or not running as
session daemon." as Shawn.. under exactly the same operating system as
Jason..
Is there a special place I need to be running this, in a certain
shell? All I ca
On 04/03/2011 04:07 AM, Somebody in the thread at some point said:
Hi -
* And very hardware specific code moved out to a controllable place,
i.e. something like BIOS
Sorry, but I must vehemently disagree here. BIOSes are a problem for
Open Source, not a solution. On X86 they use BIO
15 matches
Mail list logo