Hi Maxime,
Thanks for the links.
On 24 February 2017 at 00:19, Maxime Ripard
wrote:
> Hi,
>
> On Fri, Feb 17, 2017 at 08:39:33PM +, Emil Velikov wrote:
>> As I feared things have taken a turn for the bitter end :-]
>>
>> It seems that this is a heated topic, so I'l kindly ask that we try
>>
On Fri, Feb 17, 2017 at 9:56 AM, Tobias Jakobi
wrote:
> Alexandre Belloni wrote:
>> On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote:
The device tree is a representation of the hardware itself. The state
of the driver support doesn't change the hardware you're running on,
just l
Hi,
On Fri, Feb 17, 2017 at 08:39:33PM +, Emil Velikov wrote:
> As I feared things have taken a turn for the bitter end :-]
>
> It seems that this is a heated topic, so I'l kindly ask that we try
> the following:
>
> - For people such as myself/Tobias/others who feel that driver and DT
> bi
Hi Thierry,
On Mon, Feb 20, 2017 at 05:49:26PM +0100, Thierry Reding wrote:
> On Fri, Feb 17, 2017 at 04:43:41PM +0100, Maxime Ripard wrote:
> > On Fri, Feb 17, 2017 at 01:45:44PM +0100, Tobias Jakobi wrote:
> > > Hello Maxime,
> > >
> > > Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > On Thu,
On Fri, Feb 17, 2017 at 04:43:41PM +0100, Maxime Ripard wrote:
> On Fri, Feb 17, 2017 at 01:45:44PM +0100, Tobias Jakobi wrote:
> > Hello Maxime,
> >
> > Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
> > >> I was wondering about the foll
On Fri, Feb 17, 2017 at 04:44:19PM +0100, Maxime Ripard wrote:
[...]
> We already have DT bindings for out of tree drivers, there's really
> nothing new here.
We have DT bindings for *hardware*, not for drivers. As stated in
Documentation/devicetree/usage-model.txt:
"The "Open Firmware Device Tre
Hi Maxime,
As I feared things have taken a turn for the bitter end :-]
It seems that this is a heated topic, so I'l kindly ask that we try
the following:
- For people such as myself/Tobias/others who feel that driver and DT
bindings should go hand in hand, prove them wrong.
But please, do so by
Alexandre Belloni wrote:
> On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote:
>>> The device tree is a representation of the hardware itself. The state
>>> of the driver support doesn't change the hardware you're running on,
>>> just like your BIOS/UEFI on x86 won't change the device it reports
On Thu, Feb 16, 2017 at 04:54:45PM +, Emil Velikov wrote:
> On 16 February 2017 at 12:43, Tobias Jakobi
> wrote:
> > Hello,
> >
> > I was wondering about the following. Wasn't there some strict
> > requirement about code going upstream, which also included that there
> > was a full open-source
On Fri, Feb 17, 2017 at 01:45:44PM +0100, Tobias Jakobi wrote:
> Hello Maxime,
>
> Maxime Ripard wrote:
> > Hi,
> >
> > On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
> >> I was wondering about the following. Wasn't there some strict
> >> requirement about code going upstream, whi
On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote:
> > The device tree is a representation of the hardware itself. The state
> > of the driver support doesn't change the hardware you're running on,
> > just like your BIOS/UEFI on x86 won't change the device it reports to
> > Linux based on wheth
On 17 February 2017 at 12:45, Tobias Jakobi
wrote:
> Hello Maxime,
>
> Maxime Ripard wrote:
>> Hi,
>>
>> On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
>>> I was wondering about the following. Wasn't there some strict
>>> requirement about code going upstream, which also included t
Hello Maxime,
Maxime Ripard wrote:
> Hi,
>
> On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
>> I was wondering about the following. Wasn't there some strict
>> requirement about code going upstream, which also included that there
>> was a full open-source driver stack for it?
>>
>
Hi,
On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
> I was wondering about the following. Wasn't there some strict
> requirement about code going upstream, which also included that there
> was a full open-source driver stack for it?
>
> I don't see how this is the case for Mali, n
On 16 February 2017 at 12:43, Tobias Jakobi
wrote:
> Hello,
>
> I was wondering about the following. Wasn't there some strict
> requirement about code going upstream, which also included that there
> was a full open-source driver stack for it?
>
> I don't see how this is the case for Mali, neither
Hello,
I was wondering about the following. Wasn't there some strict
requirement about code going upstream, which also included that there
was a full open-source driver stack for it?
I don't see how this is the case for Mali, neither in the kernel, nor in
userspace. I'm aware that the Mali kernel
16 matches
Mail list logo