From: Emil Velikov <hidden> Date: 2017-02-16 16:54:50
On 16 February 2017 at 12:43, Tobias Jakobi
[off-list ref] 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 in the kernel, nor in
userspace. I'm aware that the Mali kernel driver is open-source. But it
is not upstream, maintained out of tree, and won't land upstream in its
current form (no resemblence to a DRM driver at all). And let's not talk
about the userspace part.
So, why should this be here?
Have to agree with Tobias, here.
I can see the annoyance that Maxime and others have to go through to
their systems working.
At the same time, changing upstream kernel to suit out of tree
module(s) is not how things work. Right ?
Not to mention that the series adds stable ABI exclusively(?) used by
a module which does not seem to be in the process of getting merged.
Maxime, you're a great guy but I don't think this is suitable for
upstream... yet.
Regards,
Emil
From: Maxime Ripard <hidden> Date: 2017-02-17 15:44:22
On Thu, Feb 16, 2017 at 04:54:45PM +0000, Emil Velikov wrote:
On 16 February 2017 at 12:43, Tobias Jakobi
[off-list ref] wrote:
quoted
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 driver is open-source. But it
is not upstream, maintained out of tree, and won't land upstream in its
current form (no resemblence to a DRM driver at all). And let's not talk
about the userspace part.
So, why should this be here?
Have to agree with Tobias, here.
I can see the annoyance that Maxime and others have to go through to
their systems working.
At the same time, changing upstream kernel to suit out of tree
module(s) is not how things work. Right ?
Not to mention that the series adds stable ABI exclusively(?) used by
a module which does not seem to be in the process of getting merged.
It really doesn't have any relation to whether a particular component
is supported in Linux. Our git repo just happens to be the canonical
source of DT, but those DTs are also used in other systems and
projects that have *no* relation with Linux, and might have a
different view on things than we do.
There's been a long-running discussion about moving the DTs out of the
kernel and in a separate repo. Would you still be opposed to it if I
happened to contribute that binding to that repo, even if Linux didn't
have any in-tree support for it? I'm pretty sure you wouldn't, yet
this is the exact same case.
And taking the ACPI example once again, this doesn't seem to bother
you at all that ACPI reports that it has a device that is not
supported in-tree in Linux. Why is it any different in DT.
We already have DT bindings for out of tree drivers, there's really
nothing new here.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170217/63ac141b/attachment.sig>
From: Emil Velikov <hidden> Date: 2017-02-17 20:39:38
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 pointing to the documentation (conclusion of a
previous discussion). This way you don't have to repeat yourself and
get [too] annoyed over silly suggestions.
- The series has code changes which [seemingly] cater for out of tree
module(s).
Clearly state in the commit message who is the user, why it's save to
do so and get an Ack from more prominent [DRM] developers.
Please try to understand that I do not want to annoy/agitate you, I'm
merely pointing what seems [to me] as incorrect.
Nobody is perfect, so if I/others are wrong do point me/us to a
reading to educate ourselves.
Thanks
Emil
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 Tree", or simply Device Tree (DT), is a data
structure and language for describing hardware. More specifically, it
is a description of hardware that is readable by an operating system
so that the operating system doesn't need to hard code details of the
machine."
"2.1 High Level View
-------------------
The most important thing to understand is that the DT is simply a data
structure that describes the hardware."
--
Rask Ingemann Lambertsen
From: Maxime Ripard <hidden> Date: 2017-02-24 00:21:47
Hi,
On Fri, Feb 17, 2017 at 08:39:33PM +0000, 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
bindings should go hand in hand, prove them wrong.
But please, do so by pointing to the documentation (conclusion of a
previous discussion). This way you don't have to repeat yourself and
get [too] annoyed over silly suggestions.
http://lxr.free-electrons.com/source/Documentation/devicetree/usage-model.txt#L13
"The "Open Firmware Device Tree", or simply Device Tree (DT), is a
data structure and language for describing hardware. More
specifically, it is a description of hardware that is readable by an
operating system so that the operating system doesn't need to hard
code details of the machine"
http://lxr.free-electrons.com/source/Documentation/devicetree/usage-model.txt#L79
"What it does do is provide a language for decoupling the hardware
configuration from the board and device driver support in the Linux
kernel (or any other operating system for that matter)."
And like I said, we already had bindings for out of tree bindings,
like this one:
https://patchwork.kernel.org/patch/9275707/
Which triggered no discussion at the time (but the technical one,
hence a v2, that should always be done).
- The series has code changes which [seemingly] cater for out of tree
module(s).
That patch was dropped, only DT changes remains now, and do not depend
of that missing patch anyway.
Clearly state in the commit message who is the user, why it's save to
do so and get an Ack from more prominent [DRM] developers.
DRM is really not important here. We could implement a driver using
i2c as far as the DT is concerned.
FreeBSD for example uses a different, !DRM framework to support our
display stack, and still uses the DT.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170223/db231799/attachment.sig>
From: Emil Velikov <hidden> Date: 2017-02-26 14:15:59
Hi Maxime,
Thanks for the links.
On 24 February 2017 at 00:19, Maxime Ripard
[off-list ref] wrote:
Hi,
On Fri, Feb 17, 2017 at 08:39:33PM +0000, Emil Velikov wrote:
quoted
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 pointing to the documentation (conclusion of a
previous discussion). This way you don't have to repeat yourself and
get [too] annoyed over silly suggestions.
The above seems to imply that there is (merged) device driver support
in the Linux kernel (or other) that uses the bindings.
It's not my call to make any of the policy, so I'll just kindly
suggest improving the existing documentation:
- Reword/elaborate if out of tree [Linux or in general?] drivers are
suitable counterpart.
- Patches could/should reference the "other OS" driver, or the "other
OS" name at least ?
Rather than clumping the above in 2.1 a separate section would be better ?
And like I said, we already had bindings for out of tree bindings,
like this one:
https://patchwork.kernel.org/patch/9275707/
Which triggered no discussion at the time (but the technical one,
hence a v2, that should always be done).
Needless to say, there's many of us waiting to see a Mali driver land
- hence the noise. It's not meant to belittle/sway the work you and
others do.
quoted
- The series has code changes which [seemingly] cater for out of tree
module(s).
That patch was dropped, only DT changes remains now, and do not depend
of that missing patch anyway.
quoted
Clearly state in the commit message who is the user, why it's save to
do so and get an Ack from more prominent [DRM] developers.
DRM is really not important here. We could implement a driver using
i2c as far as the DT is concerned.
What I meant to say is:
Please, provide clear expectations from the start - "Linux driver is
OOT with no ETA on landing" or "driver for $FOO OS is at $LINK".
Afaict Hans did the former in the patch mentioned. Perhaps you already
did - in which case pardon for missing it.
FreeBSD for example uses a different, !DRM framework to support our
display stack, and still uses the DT.
Interesting - do you have a link handy ? Does it use open-source usespace ?
Thanks
Emil