Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-26 Thread Emil Velikov
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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-24 Thread Rob Herring
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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-23 Thread Maxime Ripard
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 >

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-22 Thread Maxime Ripard
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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-20 Thread Thierry Reding
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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-17 Thread Alexandre Belloni
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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-17 Thread Rask Ingemann Lambertsen
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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-17 Thread Emil Velikov
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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-17 Thread Tobias Jakobi
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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-17 Thread Maxime Ripard
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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-17 Thread Maxime Ripard
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,

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-17 Thread Emil Velikov
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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-17 Thread Tobias Jakobi
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? >>

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-17 Thread Maxime Ripard
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,

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-16 Thread Emil Velikov
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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-16 Thread Tobias Jakobi
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

[PATCH 0/8] ARM: sun8i: a33: Mali improvements

2017-02-09 Thread Maxime Ripard
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