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
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
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
>
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
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
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
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
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
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
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,
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
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,
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
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
Hi,
This serie is building on the recently merged bindings for the ARM Mali
Utgard GPU.
The two features that are supported with this serie are DVFS and the fbdev
support. The first one uses devfreq and is pretty standard, the only
addition being the generic OPP mechanism we have, plus some DT
17 matches
Mail list logo