ARM topic: Is DT on ARM the solution, or is there something better?

ARM topic: Is DT on ARM the solution, or is there something better?

[Stephen Warren]

IIRC (and perhaps I don't; it was really slightly before my active
involvement in kernel development) Linus triggered the whole ARM DT
conversion in response to disliking the volume of changes, and
conflicts, in board files. The idea of DT conversion being that all the
board-specific details could be moved out of the kernel and into DT
files, thus causing him not to have to see it.

Note: As part of implementing DT on ARM, we've also cleaned up and
modularized a lot of code, and created new subsystems and APIs. I think
this is a separate issue, and much of that could have happened
completely independently from doard->DT conversion.

I wonder if DT is solving the problem at the right level of abstraction?
The kernel still needs to be aware of all the nitty-gritty details of
how each board is hooked up different, and have explicit code to deal
the union of all the different board designs.

For example, if some boards have a SW-controlled regulator for a device
but others don't, the kernel still needs to have driver code to actively
control that regulator, /plus/ the regulator subsystem needs to be able
to substitute a dummy regulator if it's optional or simply missing from
the DT.

Another example: MMC drivers need to support some boards detecting SD
card presence or write-protect via arbitrary GPIOs, and others via
dedicated logic in the MMC controller.

In general, the kernel still needs a complete driver to every last
device on every strange board, and needs to support every strange way
some random board hooks all the devices together.

The only thing we've really moved out of the kernel is the exact IDs of
which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the
simple stuff not the hard stuff. The code hasn't really been simplified
by DT - if anything, it's more complicated since we now have to parse
those values from DT rather than putting them into simple data-structures.

I wonder if some other solution with a higher level of abstraction
wouldn't be a better idea? Would it make more sense to define some kind
of firmware interface that the kernel deals with, so that all HW details
are hidden behind that firmware interface, and the kernel just deals
with the firmware interface, which hopefully has less variation than the
actual HW (or even zero variation).

* Would UEFI/ACPI/similar fulfill this role?

* Perhaps a standard virtualization interface could fulfil this role?
IIUC, there are already standard mechanisms of exposing e.g. disks, USB
devices, PCI devices, etc. into VMs, and recent ARM HW[1] supports
virtualization well now. A sticking point might be graphics, but it
sounds like there's work to transport GL or Gallium command streams over
the virtualization divide.

Downsides might be:

- Overhead, due to invoking the para-virtualized VM host for IO, and
extra resources to run the host.

- The host SW still has to address the HW differences. Would it be more
acceptable to run a vendor kernel as the VM host if it meant that the
VMs could be a more standardized environment, with a more single-purpose
upstream kernel? Would it be easier to create a simple VM host than a
full Linux kernel with a full arbitrary Linux distro, thus allowing the
HW differences to be addressed in a simple way?

These techniques would allow distros to target a single HW environment,
e.g. para-virtualized KVM, rather than many many different SoCs and
boards each with different bootloaders, bootloader configurations, IO
peripherals, DT storage locations, etc. Perhaps a solution like this
would allow distros to easily support a similar environment across a
range of HW in a way that "just works" for many users, while not
preventing people with more specific needs crafting more HW-specific
environments?

Note: This is all just slightly random thinking that came to me while I
couldn't sleep last night, so apologies if it isn't fully coherent. It's
certainly not a proposal, just perhaps something to mull over.

[1] All /recent/ consumer-grade ARM laptop or desktop HW that I'm aware
of that's shipped has Cortex A15 cores that support virtualization.

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Mark Brown]

On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:

> IIRC (and perhaps I don't; it was really slightly before my active
> involvement in kernel development) Linus triggered the whole ARM DT
> conversion in response to disliking the volume of changes, and
> conflicts, in board files. The idea of DT conversion being that all the
> board-specific details could be moved out of the kernel and into DT
> files, thus causing him not to have to see it.

A large part of this was to do with the needs of distros and their users
- they have a strong need to ship a device neutral kernel and to have a
reasonable ability to have their kernel deploy on hardware unknown to
them.  Allowing the device tree to be delivered with the system rather
than have the board configuration in the kernel helps achieve that goal.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131020/9f27877f/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Stephen Warren]

On 10/20/2013 11:08 PM, Mark Brown wrote:
> On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
> 
>> IIRC (and perhaps I don't; it was really slightly before my
>> active involvement in kernel development) Linus triggered the
>> whole ARM DT conversion in response to disliking the volume of
>> changes, and conflicts, in board files. The idea of DT conversion
>> being that all the board-specific details could be moved out of
>> the kernel and into DT files, thus causing him not to have to see
>> it.
> 
> A large part of this was to do with the needs of distros and their
> users - they have a strong need to ship a device neutral kernel and
> to have a reasonable ability to have their kernel deploy on
> hardware unknown to them.  Allowing the device tree to be delivered
> with the system rather than have the board configuration in the
> kernel helps achieve that goal.

Yes.

I guess one thing I didn't make clear was my hope that whatever
firmware API or VM host implementation exists would be pre-installed
on the system so that distros never had to deal with it, or even know
it existed. That would then transform the many different HW
configurations into a single HW configuration as far as distros are
concerned, since they only target running as firmware clients or VM
guests. Essentially, we are creating a standard platform in SW, which
perhaps is still possible, rather than in HW, which seems unlikely at
present.

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Nicolas Pitre]

On Sun, 20 Oct 2013, Stephen Warren wrote:

> On 10/20/2013 11:08 PM, Mark Brown wrote:
> > On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
> > 
> >> IIRC (and perhaps I don't; it was really slightly before my
> >> active involvement in kernel development) Linus triggered the
> >> whole ARM DT conversion in response to disliking the volume of
> >> changes, and conflicts, in board files. The idea of DT conversion
> >> being that all the board-specific details could be moved out of
> >> the kernel and into DT files, thus causing him not to have to see
> >> it.
> > 
> > A large part of this was to do with the needs of distros and their
> > users - they have a strong need to ship a device neutral kernel and
> > to have a reasonable ability to have their kernel deploy on
> > hardware unknown to them.  Allowing the device tree to be delivered
> > with the system rather than have the board configuration in the
> > kernel helps achieve that goal.
> 
> Yes.
> 
> I guess one thing I didn't make clear was my hope that whatever
> firmware API or VM host implementation exists would be pre-installed
> on the system so that distros never had to deal with it, or even know
> it existed. That would then transform the many different HW
> configurations into a single HW configuration as far as distros are
> concerned, since they only target running as firmware clients or VM
> guests. Essentially, we are creating a standard platform in SW, which
> perhaps is still possible, rather than in HW, which seems unlikely at
> present.

The idea of some firmware to abstract hardware differences in order to 
greatly simplify kernel development and maintenance comes up with some 
regularity.  In other words, you are far from being the first one to 
suggest that.

However this needs some reality check.

Every hardware system has its share of complexity that the software has 
to deal with.

If that complexity is not in the kernel, it has to be in the firmware.  
Given we already struggles to have proper and bug free hardware support 
in the kernel today, even with all the debugging aid and peer review 
available from the kernel community, I really don't see how you'd manage 
to make it any less complex in some firmware implementation.

If a firmware is involved, that implies a standard API you have to 
implement your firmware for.  And if that firmware API has to cater for 
different hardware variations and differences, it will have to be very 
generic and abstract.  And the more generic and remote from the hardware 
details the API is, the more complex the code making the bridge between 
the hardware and the API will have to be.

And if it is complex, it *will* have bugs.  Fixing those bugs implies 
firmware updates which is likely to be just as difficult as bootloaders, 
if not more, to update in the field.

And expecting the firmware implementation to be ready before the 
hardware ships is almost impossible.  Some tradeoff will need to be made 
in order to meet the shipping deadline which normally implies a lot of 
pressure from other departments in your company.  Most of the time that 
tradeoff translates into quality reduction in your firmware 
implementation.

There is simply no magic.  If some hardware driver needs a year to be 
top quality in the kernel, then the equivalent hardware abstraction in 
the firmware would require the same level of development effort. You're 
only moving the implementation complexity around.

And there will always come a case for which the firmware API doesn't 
cover the hardware needs well, and you'll start adding hardware specific 
quirks in the kernel directly anyway, or attempt to bypass the firmware 
entirely for performance reasons.

So in theory the firmware idea always looks great.  but that works only 
if the firmware is perfect in the first place and from the beginning.  
In practice that never works like that.

The hardware support in the kernel, on the other hand, can be improved 
incrementally with time.  It doesn't matter if it is not optimal at 
first. It can be revisited, optimized, reviewed, and sometimes even 
redesigned.  And only when it reaches maturity would be the time to use 
the experience from the kernel development and make some firmware out of 
it.  But what would be the point then?

IMHO the idea of simplifying our lives with firmware is an illusion.


Nicolas

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Sun, Oct 20, 2013 at 09:00:08PM -0400, Nicolas Pitre wrote:
[...]
> The hardware support in the kernel, on the other hand, can be improved 
> incrementally with time.  It doesn't matter if it is not optimal at 
> first. It can be revisited, optimized, reviewed, and sometimes even 
> redesigned.  And only when it reaches maturity would be the time to use 
> the experience from the kernel development and make some firmware out of 
> it.  But what would be the point then?

I agree. However that's currently no longer the case. We're severely
limiting ourselves because we're requiring DT to be a stable ABI.

A stable ABI means there's about zero chance of redesigning something
after it's been merged. Unless we want to live with having to support
several DT bindings in a driver.

The kind of flexibility and unstable API within the kernel is something
that I've always been very fond of, precisely because it allows us to
get features implemented fairly quickly. At the same time we have the
possibility to redesign code when we have to. It's just impossible to
take into account every possible detail up front simply because we're
all only human and because some things just might change over time. I'm
fairly sure that Linux wouldn't be where it is today if we didn't have
that flexibility.

Right now, we're taking away much of that flexibility and I see progress
on ARM actively hindered.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131021/bca948a4/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Maxime Bizon]

On Mon, 2013-10-21 at 11:15 +0200, Thierry Reding wrote:

> A stable ABI means there's about zero chance of redesigning something
> after it's been merged. Unless we want to live with having to support
> several DT bindings in a driver.
> 
That will happen for sure, and it will suffer from lack of testing of
"old" bindings, like every uncommon combinations supported by the kernel
today (think 32b userspace over 64b kernel).

Solution: always use latest DT shipped with kernel. 

> impossible to take into account every possible detail up front simply
> because we're all only human and because some things just might change
> over time. I'm fairly sure that Linux wouldn't be where it is today if
> we didn't have that flexibility.

Also, as you said in another mail, new roadblocks have appeared to reach
mainline, you now have to convince DT maintainers that your DT bindings
are correct / future proof.

IMO this will cause even more un-mainlined SOCs/boards, with the added
difficulty to integrate the existing proprietary bindings if someone
wants to mainline later.


-- 
Maxime

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Mon, Oct 21, 2013 at 11:15:56AM +0200, Thierry Reding wrote:
> 
> Right now, we're taking away much of that flexibility and I see progress
> on ARM actively hindered.

Baloney.

No one is taking away your flexibility or hindering progress. It is
really very simple. Just make an arm-dt-devel tree where you can both
change the bindings at will and recommend to people. Once bindings
have seen some real world testing and have had time to mature, then
request a merge into mainline.

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Stephen Warren]

On 10/21/2013 06:07 PM, Richard Cochran wrote:
> On Mon, Oct 21, 2013 at 11:15:56AM +0200, Thierry Reding wrote:
>>
>> Right now, we're taking away much of that flexibility and I see progress
>> on ARM actively hindered.
> 
> Baloney.
> 
> No one is taking away your flexibility or hindering progress. It is
> really very simple. Just make an arm-dt-devel tree where you can both
> change the bindings at will and recommend to people. Once bindings
> have seen some real world testing and have had time to mature, then
> request a merge into mainline.

Thierry already has working patches for LCD support, and the "request
[for] a merge into mainline" is just "send the patch to be applied to
mainline", which he did, and was blocked on, because of the potential
existance of CDF if the future.

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Oct 21, 2013 at 07:07:11PM +0200, Richard Cochran wrote:
> On Mon, Oct 21, 2013 at 11:15:56AM +0200, Thierry Reding wrote:
> > 
> > Right now, we're taking away much of that flexibility and I see progress
> > on ARM actively hindered.
> 
> Baloney.
> 
> No one is taking away your flexibility or hindering progress. It is
> really very simple. Just make an arm-dt-devel tree where you can both
> change the bindings at will and recommend to people.

Oh, I've been doing that for quite a while. In fact the patches that
gave rise to the current frustration have been in a separate tree in
various forms for over a year. But that's not what we want, is it? I
used to think that we actively wanted people to contribute code back
upstream, so telling everyone to keep code in their own trees isn't
helping anyone.

Besides, we all know that people are reluctant to test trees other than
Linus'. That's just the way it is. There is the occasional tester for a
new feature who will be happy to run code from a different tree. I think
those people are an invaluable resource, but I'm pretty sure they'd be
even happier to test the code if they could just take it from Linus'
tree. Nothing ever gets any widespread testing unless it goes into the
mainline kernel.

That's the primary reason why we have things like drivers/staging: we
want people to test code, even things that are considered low quality,
buggy and incomplete. Because that's the way we can make it easy for
people to test code and that allows us to make it better. It is also a
good way to get more people involved. Also, I think that people, given
the choice, often tend to choose functionality over stability.

There's no point at all in running a Linux kernel that never crashes if
it prevents you from using half of the hardware you have. I don't think
we should dictate what drivers people can use based on what we perceive
as qualifying criteria.

Instead what we should be doing is give people a choice. If we tell them
up front that using a given driver (or DT binding) might require them to
update the kernel or DTB at some point because it's likely to change and
if they choose to use it nevertheless, then by all means they should be
allowed to do that.

We're already doing this with staging drivers. I don't see any reason
why we shouldn't be able to do the same with DT bindings. Let's give our
users a warning about tentative or experimental bindings. That way they
can be aware of the potential issues and choose not to use or rely on
them if they want to play it safe. But if they don't mind the occasional
inconvenience, then we shouldn't prevent them from making the best use
of the devices that they have.

> Once bindings have seen some real world testing and have had time to
> mature, then request a merge into mainline.

I don't think that's the way the world works. There simply is no way to
get any real world testing of DT bindings outside of mainline. Sure you
can test-drive code in downstream kernels, but most downstream kernels
have not yet converted to DT and those that have are nothing like the
upstream kernel. Bindings in downstream kernels are likely to be very
broken by upstream standards and therefore any real world testing done
with those will be useless in an upstream context.

We've been preaching for years that vendors should contribute to the
upstream Linux kernel more actively. But I think the only way we can get
them to do that is by making upstream a viable solution. Currently it
isn't for most SoC vendors, because by the time we've finally settled on
a DT binding the hardware for which it was designed has already been
obsoleted. That has resulted in the endless game of catch-up that we've
been playing.

People have been telling vendors that they need to get involved with
Linux upstreaming very early on, at best even prior to having silicon
available. But if it takes months or even years before a driver can be
put to any active use, being blocked by the DT binding being considered
immature, then we loose. There's no point for vendors in contributing to
upstream Linux if they can't eventually take advantage of it. If we ever
want to be able to have something reasonably close to upstream Linux
ship on recent hardware we need to find ways to make it easier to get
code merged faster. Creating additional roadblocks won't help at all.

If that's impossible with DT, then perhaps we really ought to second-
guess whether DT is the right technology. I don't think anyone's been
able to point out a fundamental flaw in DT that would make it useless
for the intended purpose, but various people have pointed out that our
current process may be flawed.

Which brings me back to my earlier point: I think what could really help
alleviate the pain is experimental bindings. If we make it abundantly
clear that someone is using an experimental binding, I don't see why we
shouldn't be able to provide those. This gives us an easy way to test-
drive new bindings and code, but it preserves the possibility to turn
the bindings into stable ones when they are ready, so that they can be
used in production devices.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131022/e395fe10/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Tue, Oct 22, 2013 at 11:24:11AM +0200, Thierry Reding wrote:
> 
> Oh, I've been doing that for quite a while. In fact the patches that
> gave rise to the current frustration have been in a separate tree in
> various forms for over a year. But that's not what we want, is it?

I can't see anything wrong with that. Your code is not the first to
have to wait for a long time before being finally merged. Think of
alsa, or of the pps stuff, or wakelocks, or preempt_rt, etc, etc.

As an end user, I don't mind waiting for a feature if that means
stability and QA. If I get impatient, still I always have the choice
to take a development version. But I do not want to be forced to take
unfinished work in a released kernel.

> I
> used to think that we actively wanted people to contribute code back
> upstream, so telling everyone to keep code in their own trees isn't
> helping anyone.

Actually, I mean to propose that the ARM/DT people use a single
marshaling tree, one step away in the process from mainline.

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Wed, Oct 23, 2013 at 07:30:33PM +0200, Richard Cochran wrote:
> On Tue, Oct 22, 2013 at 11:24:11AM +0200, Thierry Reding wrote:
> > 
> > Oh, I've been doing that for quite a while. In fact the patches that
> > gave rise to the current frustration have been in a separate tree in
> > various forms for over a year. But that's not what we want, is it?
> 
> I can't see anything wrong with that. Your code is not the first to
> have to wait for a long time before being finally merged. Think of
> alsa, or of the pps stuff, or wakelocks, or preempt_rt, etc, etc.

Heh... that's no news for me.

> As an end user, I don't mind waiting for a feature if that means
> stability and QA. If I get impatient, still I always have the choice
> to take a development version. But I do not want to be forced to take
> unfinished work in a released kernel.

This isn't about stability and QA. The DT binding has nothing to do
whatsoever with the quality of the code. Also in many cases with DT we
end up with work that's actually finished and pretty well tested, and
the only thing blocking it is the DT binding.

> > I
> > used to think that we actively wanted people to contribute code back
> > upstream, so telling everyone to keep code in their own trees isn't
> > helping anyone.
> 
> Actually, I mean to propose that the ARM/DT people use a single
> marshaling tree, one step away in the process from mainline.

I don't think fragmentation of that sort will do us any good. It will
only make it harder to get things merged because they get developed
outside of the upstream process.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131023/8692bdc8/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Jason Gunthorpe]

On Mon, Oct 21, 2013 at 07:07:11PM +0200, Richard Cochran wrote:
> On Mon, Oct 21, 2013 at 11:15:56AM +0200, Thierry Reding wrote:
> > 
> > Right now, we're taking away much of that flexibility and I see progress
> > on ARM actively hindered.
> 
> Baloney.
> 
> No one is taking away your flexibility or hindering progress. It is
> really very simple. Just make an arm-dt-devel tree where you can both
> change the bindings at will and recommend to people. Once bindings
> have seen some real world testing and have had time to mature, then
> request a merge into mainline.

The argument is that DT is a stable ABI we must never change it once
it hits mainline.

This leads to not accepting patches into mainline until they are
'stable'.

Whihc leads to vendors shipping code in real systems to real customers
with those out of tree patches. (Deadlines are a bitch)

The vendors are now forced to treat the DT as an *UNSTABLE* ABI
because they are shipping non-mainline DT schemas and plan to upgrade
to mainline someday.

Now the vendors no longer value DT as a stable ABI.

So, why are we making argument #1? Seems pretty self defeating to me.

Jason

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Stephen Warren]

On 10/21/2013 02:00 AM, Nicolas Pitre wrote:
...
> The idea of some firmware to abstract hardware differences in order to 
> greatly simplify kernel development and maintenance comes up with some 
> regularity.  In other words, you are far from being the first one to 
> suggest that.
> 
> However this needs some reality check.
> 
> Every hardware system has its share of complexity that the software has 
> to deal with.
> 
> If that complexity is not in the kernel, it has to be in the firmware.  
> Given we already struggles to have proper and bug free hardware support 
> in the kernel today, even with all the debugging aid and peer review 
> available from the kernel community, I really don't see how you'd manage 
> to make it any less complex in some firmware implementation.

True. Hiding all the HW details sucks in some ways.

So, if we have chosen not to do that, and instead have the kernel know
all the details of the HW, then why not simply do that? What do we get
from DT that we don't get from board files? The driver complexity still
all needs to be present in the kernel.

The only thing we can move out is some of the board-specific
parameterization data. That might reduce the code-size of kernel board
files a bit (or rather, eliminate them), but taking the big picture into
account, observe that we make life a lot more difficult for distros,
since they need to get the device tree from somewhere. Distros now are
forced to work out which DTB goes with which board, or perhaps we need
to define a firmware interface to obtain the DTB and pass it to the
kernel. It'd be a lot simpler just to embed the data into the kernel. I
think we can still have a hack-free, churn-free, multi-platform kernel
without requiring DT, but by using board files.

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Nicolas Pitre]

On Mon, 21 Oct 2013, Stephen Warren wrote:

> On 10/21/2013 02:00 AM, Nicolas Pitre wrote:
> ...
> > The idea of some firmware to abstract hardware differences in order to 
> > greatly simplify kernel development and maintenance comes up with some 
> > regularity.  In other words, you are far from being the first one to 
> > suggest that.
> > 
> > However this needs some reality check.
> > 
> > Every hardware system has its share of complexity that the software has 
> > to deal with.
> > 
> > If that complexity is not in the kernel, it has to be in the firmware.  
> > Given we already struggles to have proper and bug free hardware support 
> > in the kernel today, even with all the debugging aid and peer review 
> > available from the kernel community, I really don't see how you'd manage 
> > to make it any less complex in some firmware implementation.
> 
> True. Hiding all the HW details sucks in some ways.
> 
> So, if we have chosen not to do that, and instead have the kernel know
> all the details of the HW, then why not simply do that? What do we get
> from DT that we don't get from board files? The driver complexity still
> all needs to be present in the kernel.

Driver complexity: obviously.

DT is only meant to abstract away the configuration part.

> The only thing we can move out is some of the board-specific
> parameterization data. That might reduce the code-size of kernel board
> files a bit (or rather, eliminate them),

That is effectively the point of DT.

> but taking the big picture into
> account, observe that we make life a lot more difficult for distros,
> since they need to get the device tree from somewhere. Distros now are
> forced to work out which DTB goes with which board,

This is not a new problem.  Before you had to figure out which kernel 
would go with which board.

> or perhaps we need
> to define a firmware interface to obtain the DTB and pass it to the
> kernel.

That's the bootloader's job.  Nothing magical actually: just have U-Boot 
or whatever load the DTB from some flash area.

> It'd be a lot simpler just to embed the data into the kernel.

For one target, this is indeed the simplest way.

> I
> think we can still have a hack-free, churn-free, multi-platform kernel
> without requiring DT, but by using board files.

I kinda agree with you, but this is too late for that now.

We have DT, and the best way forward is to fix the process which is, 
arguably, somewhat obstructive and broken at the moment.


Nicolas

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Oct 21, 2013 at 04:40:15PM -0400, Nicolas Pitre wrote:
> On Mon, 21 Oct 2013, Stephen Warren wrote:
[...]
> > but taking the big picture into
> > account, observe that we make life a lot more difficult for distros,
> > since they need to get the device tree from somewhere. Distros now are
> > forced to work out which DTB goes with which board,
> 
> This is not a new problem.  Before you had to figure out which kernel 
> would go with which board.

You still need to match kernels to boards even with DT. It's no good if
you provide a full DTB that describes your hardware if the kernel
doesn't support any of it.

> > or perhaps we need
> > to define a firmware interface to obtain the DTB and pass it to the
> > kernel.
> 
> That's the bootloader's job.  Nothing magical actually: just have U-Boot 
> or whatever load the DTB from some flash area.

I agree. I think most if not all architectures that support DT have long
had some interface on how to pass a DTB to the kernel. At least I know
that ARM and x86 have, but I'm pretty sure that PowerPC, SPARC and
others do too.

> > I
> > think we can still have a hack-free, churn-free, multi-platform kernel
> > without requiring DT, but by using board files.
> 
> I kinda agree with you, but this is too late for that now.
> 
> We have DT, and the best way forward is to fix the process which is, 
> arguably, somewhat obstructive and broken at the moment.

I agree that the process could use some enhancements. But I also think
that we should be open to move away from DT again if it turns out to not
be a good enough solution. "It's too late" doesn't sound like a very
good argument to me.

Essentially DT is just a different way to represent what we used to have
in platform data, so we haven't fundamentally changed anything at that
level. Well, we've made things worse to some degree.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131022/de1ef011/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Matt Porter]

On Tue, Oct 22, 2013 at 11:39:24AM +0200, Thierry Reding wrote:
> On Mon, Oct 21, 2013 at 04:40:15PM -0400, Nicolas Pitre wrote:
> > On Mon, 21 Oct 2013, Stephen Warren wrote:
> > > I
> > > think we can still have a hack-free, churn-free, multi-platform kernel
> > > without requiring DT, but by using board files.
> > 
> > I kinda agree with you, but this is too late for that now.
> > 
> > We have DT, and the best way forward is to fix the process which is, 
> > arguably, somewhat obstructive and broken at the moment.
> 
> I agree that the process could use some enhancements. But I also think
> that we should be open to move away from DT again if it turns out to not
> be a good enough solution. "It's too late" doesn't sound like a very
> good argument to me.
> 
> Essentially DT is just a different way to represent what we used to have
> in platform data, so we haven't fundamentally changed anything at that
> level. Well, we've made things worse to some degree.

DT started that way. However, the direction set by binding reviews have
essentially limited DT to only external hardware configuration. So, yes,
we've made things worse. DT, as defined and maintained today, does not
replace platform data since it's been de facto limited to a tiny subset
of system configuration info. Further, the current approach to "breaking
compatibility" with old DTBs that has resulted from the claims of "DT as
ABI" is completely tied to the vision of moving DT independent of the
kernel. Platform data in code never had this compatibility issue.

DT has many benefits. It would be great to leverage them as long as it
doesn't interfere with the rate of change and willingness to evolve code
that's always been the strength of the kernel process. That strength is
too valuable to trade away for the "DT as ABI" vision.

All these failings can start to be fixed by addressing the process and
what DT *is*.

-Matt

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Jason Gunthorpe]

On Tue, Oct 22, 2013 at 11:04:26AM -0400, Matt Porter wrote:

> DT has many benefits. It would be great to leverage them as long as it
> doesn't interfere with the rate of change and willingness to evolve code
> that's always been the strength of the kernel process. That strength is
> too valuable to trade away for the "DT as ABI" vision.

I agree with this, and have posted similar things before.

The question I asked last time this came up, which was left unaswered:

 Who does this stable DT ABI vision benifit, and how much is that
 benifit worth?

As an embedded ODM, I don't get very much value out of it, and I think
others in my space would say the same.

I continue to think the embedded vs not embedded are different and it
makes no sense to pretend that my embedded system has the same
requirements as something like a chromebook.

Jason

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Guenter Roeck]

On Tue, Oct 22, 2013 at 11:13:46AM -0600, Jason Gunthorpe wrote:
> On Tue, Oct 22, 2013 at 11:04:26AM -0400, Matt Porter wrote:
> 
> > DT has many benefits. It would be great to leverage them as long as it
> > doesn't interfere with the rate of change and willingness to evolve code
> > that's always been the strength of the kernel process. That strength is
> > too valuable to trade away for the "DT as ABI" vision.
> 
> I agree with this, and have posted similar things before.
> 
> The question I asked last time this came up, which was left unaswered:
> 
>  Who does this stable DT ABI vision benifit, and how much is that
>  benifit worth?
> 

You might add: Who does the DT restriction to "hardware description only"
(ie it must not describe what the system is supposed to do with the hardware)
benefit, and how much is that benefit (or restriction) worth ?

Guenter

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Tue, Oct 22, 2013 at 11:13:46AM -0600, Jason Gunthorpe wrote:
> The question I asked last time this came up, which was left unaswered:
> 
>  Who does this stable DT ABI vision benifit, and how much is that
>  benifit worth?

[Sigh]

I already answered this question more than once. I guess it doesn't
hurt to answer it again: It helps the users. Please, don't forget
about them.

If I, as an embedded developer, design my board to work with kernel
version N and a given DTB, then I can upgrade to any kernel version
M (where M > N) using the *same* DTB, and it still works.

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Wed, Oct 23, 2013 at 10:06:31AM +0200, Richard Cochran wrote:
> On Tue, Oct 22, 2013 at 11:13:46AM -0600, Jason Gunthorpe wrote:
> > The question I asked last time this came up, which was left unaswered:
> > 
> >  Who does this stable DT ABI vision benifit, and how much is that
> >  benifit worth?
> 
> [Sigh]
> 
> I already answered this question more than once. I guess it doesn't
> hurt to answer it again: It helps the users. Please, don't forget
> about them.

But DT ABI stability doesn't help our users if we can't get them any new
features because we're afraid of not getting the binding perfect from
the start.

Real world example: we currently can't settle on the DT binding for
display panels, so while our users may not have to worry about having to
upgrade their DTBs, they can't use their devices because we're too
afraid of ABI stability to allow us to power up the panel. That's
ridiculous.

> If I, as an embedded developer, design my board to work with kernel
> version N and a given DTB, then I can upgrade to any kernel version
> M (where M > N) using the *same* DTB, and it still works.

I get that. I even agree that a stable DTB is a good thing to strive
for. But I also thing requiring every DTB to be stable absolutely is an
unnecessary burden. DT on ARM isn't very mature yet and I think we could
use some flexibility until we've figured a lot more of it out.

We could even add infrastructure to give people a choice. If we start
marking unstable bindings (which arguable would be the majority of the
bindings for the time being) and output a big warning when a device is
matched whose driver implements an unstable binding or which refers to
an unstable binding in the DTB, then it would discourage people from
relying on it if they don't want to be faced with the hassle of having
to update the DTB occasionally. But it also gives people the choice to
consciously ignore the warning if they prefer functionality over ABI
stability. That's nothing unheard of, we've been doing it for quite some
time using the staging tree.

If a runtime warning isn't good enough, we can easily add a Kconfig
option too. If people want to test-drive new functionality and accept
that they might have to update the DTB even on a regular basis, they
could activate that option and use all supported devices, even those
with experimental bindings. Such an option could default to n, upon
which the OF core just wouldn't match anything that carries the
experimental marker.

Does that sound like a good compromise?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131023/81451822/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Wed, Oct 23, 2013 at 11:49:04AM +0200, Thierry Reding wrote:
> 
> If a runtime warning isn't good enough, we can easily add a Kconfig
> option too. If people want to test-drive new functionality and accept
> that they might have to update the DTB even on a regular basis, they
> could activate that option and use all supported devices, even those
> with experimental bindings. Such an option could default to n, upon
> which the OF core just wouldn't match anything that carries the
> experimental marker.
> 
> Does that sound like a good compromise?

I think having a printk warning would be pointless because if the
majority of ARM bindings are unstable as you say, then the average
system will emit tons of them, encouraging people to just ignore them.

A kconfig option to allow unstable bindings seems okay to me in
principle, as long as progress toward getting stable bindings
continues. However, I expect that this option would become a "sticky
bit" that is just left on forever (remember CONFIG_EXPERIMENTAL?).
There would be little motivation for developers to ever get bindings
into the "stable" category.

I still don't understand why someone (linario?) can't host an
arm-dt-devel tree that allows the freedom to change bindings and
features the best source for supporting the latest ARM SoCs. I don't
buy the argument that only Linus' tree gets enough testing. If another
tree really is the best ARM tree, then it will get plenty of attention
and testing. Other people do this (for example, the TI arago tree),
apparently with good success.

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Matt Porter]

On Wed, Oct 23, 2013 at 07:16:21PM +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 11:49:04AM +0200, Thierry Reding wrote:
> > 
> > If a runtime warning isn't good enough, we can easily add a Kconfig
> > option too. If people want to test-drive new functionality and accept
> > that they might have to update the DTB even on a regular basis, they
> > could activate that option and use all supported devices, even those
> > with experimental bindings. Such an option could default to n, upon
> > which the OF core just wouldn't match anything that carries the
> > experimental marker.
> > 
> > Does that sound like a good compromise?
> 
> I think having a printk warning would be pointless because if the
> majority of ARM bindings are unstable as you say, then the average
> system will emit tons of them, encouraging people to just ignore them.
> 
> A kconfig option to allow unstable bindings seems okay to me in
> principle, as long as progress toward getting stable bindings
> continues. However, I expect that this option would become a "sticky
> bit" that is just left on forever (remember CONFIG_EXPERIMENTAL?).
> There would be little motivation for developers to ever get bindings
> into the "stable" category.
> 
> I still don't understand why someone (linario?) can't host an
> arm-dt-devel tree that allows the freedom to change bindings and
> features the best source for supporting the latest ARM SoCs. I don't
> buy the argument that only Linus' tree gets enough testing. If another
> tree really is the best ARM tree, then it will get plenty of attention
> and testing. Other people do this (for example, the TI arago tree),
> apparently with good success.

No, please, no!

Do not hold up TI's vendor tree as an example of success. We don't want
more vendor trees, we want less. Even TI knows that the vendor tree
model was a failure. All development will move there forever. If we lose
submit early and submit often we've completely failed.

"It's a trap!"

-Matt

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Wed, Oct 23, 2013 at 01:25:58PM -0400, Matt Porter wrote:
> 
> No, please, no!

On the one hand, I agree with you that the arago work is kind of scary
to look at, but on the other hand, it is being used in tons of beagle
bones and other devices. It is a success, of sorts.

I know of commercial products shipping with the arago kernel (not
mine, of course). The chip vendors have a legitimate need to offer
*something* that boots on their new devices. The BSP development has
to be done quickly (and, more importantly, it cannot cost much
either).

There is really nothing wrong with non-mainline trees. If they serve
someone's needs, then they do get used.

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Nicolas Pitre]

On Wed, 23 Oct 2013, Richard Cochran wrote:

> There is really nothing wrong with non-mainline trees. If they serve
> someone's needs, then they do get used.

They scatter away from the mainline tree the limited development force 
we have.

Are you suggesting we should go back to vendor provided kernel tree 
forks?  Because that's what non mainline trees are.


Nicolas

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Matt Porter]

On Wed, Oct 23, 2013 at 08:05:08PM +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 01:25:58PM -0400, Matt Porter wrote:
> > 
> > No, please, no!
> 
> On the one hand, I agree with you that the arago work is kind of scary
> to look at, but on the other hand, it is being used in tons of beagle
> bones and other devices. It is a success, of sorts.
> 
> I know of commercial products shipping with the arago kernel (not
> mine, of course). The chip vendors have a legitimate need to offer
> *something* that boots on their new devices. The BSP development has
> to be done quickly (and, more importantly, it cannot cost much
> either).
> 
> There is really nothing wrong with non-mainline trees. If they serve
> someone's needs, then they do get used.

Please don't confuse what is in arago trees (or the beagleboard.org
trees) and being aligned with what is happening upstream.

You are implying that there is some development happening there that is
closely tied to submission of candidate patches upstream. Those trees
have all been dumping grounds for patches that by and large go no where.

The context of this discussion is upstream process. No where did I
suggest that they lacked value for production.

-Matt

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Nicolas Pitre]

On Wed, 23 Oct 2013, Richard Cochran wrote:

> A kconfig option to allow unstable bindings seems okay to me in
> principle, as long as progress toward getting stable bindings
> continues. However, I expect that this option would become a "sticky
> bit" that is just left on forever (remember CONFIG_EXPERIMENTAL?).
> There would be little motivation for developers to ever get bindings
> into the "stable" category.

Such config option is therefore pointless.

> I still don't understand why someone (linario?) can't host an
> arm-dt-devel tree that allows the freedom to change bindings and
> features the best source for supporting the latest ARM SoCs. I don't
> buy the argument that only Linus' tree gets enough testing. If another
> tree really is the best ARM tree, then it will get plenty of attention
> and testing.

So you're basically saying that we should split the development effort 
across multiple trees instead of encouraging people to converge on the 
same tree?  This is completely contrary to all the efforts we've been 
deploying to encourage people to submit their code upstream.

ii> As an end user, I don't mind waiting for a feature if that means
> stability and QA. If I get impatient, still I always have the choice
> to take a development version. But I do not want to be forced to take
> unfinished work in a released kernel.

If as an end user you want full QA, you should go with a distro kernel.

We're talking about the upstream kernel here, and given the current 
development and release rate we hardly can guarantee you that it'll be 
free of unfinished work (as long as it doesn't regress existing 
features).


Nicolas

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Wed, Oct 23, 2013 at 01:55:24PM -0400, Nicolas Pitre wrote:
> On Wed, 23 Oct 2013, Richard Cochran wrote:
> > I still don't understand why someone (linario?) can't host an
> > arm-dt-devel tree that allows the freedom to change bindings and
> > features the best source for supporting the latest ARM SoCs. I don't
> > buy the argument that only Linus' tree gets enough testing. If another
> > tree really is the best ARM tree, then it will get plenty of attention
> > and testing.
> 
> So you're basically saying that we should split the development effort 
> across multiple trees instead of encouraging people to converge on the 
> same tree?  This is completely contrary to all the efforts we've been 
> deploying to encourage people to submit their code upstream.

No, just a single tree, please.
 
> ii> As an end user, I don't mind waiting for a feature if that means
> > stability and QA. If I get impatient, still I always have the choice
> > to take a development version. But I do not want to be forced to take
> > unfinished work in a released kernel.
> 
> If as an end user you want full QA, you should go with a distro kernel.

No, no, NO! I won't ship a distro kernel because they screw things
up (at least, in my experience). I will ship a 3.x.y stable kernel,
though.
 
> We're talking about the upstream kernel here, and given the current 
> development and release rate we hardly can guarantee you that it'll be 
> free of unfinished work (as long as it doesn't regress existing 
> features).

I read a quote from a Big Cheese saying how the Linux kernel is a
stable release cycle. There are bugs, to be sure, but, in my
experience, each release is pretty stable on x86 (but not on arm).

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Wed, Oct 23, 2013 at 08:13:55PM +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 01:55:24PM -0400, Nicolas Pitre wrote:
> > On Wed, 23 Oct 2013, Richard Cochran wrote:
> > > I still don't understand why someone (linario?) can't host an
> > > arm-dt-devel tree that allows the freedom to change bindings and
> > > features the best source for supporting the latest ARM SoCs. I don't
> > > buy the argument that only Linus' tree gets enough testing. If another
> > > tree really is the best ARM tree, then it will get plenty of attention
> > > and testing.
> > 
> > So you're basically saying that we should split the development effort 
> > across multiple trees instead of encouraging people to converge on the 
> > same tree?  This is completely contrary to all the efforts we've been 
> > deploying to encourage people to submit their code upstream.
> 
> No, just a single tree, please.

In that case, why not just go one step further and leave out that
intermediary tree in the first place? If only code that's completely
finished and never subject to change goes into the upstream kernel, then
it's very unlikely that we'll ever see any support at all for new SoCs
upstream. What would be the incentive for vendors to upstream code if
there's another canonical tree that users can pull from. How is that
different from any other vendor tree?

> > ii> As an end user, I don't mind waiting for a feature if that means
> > > stability and QA. If I get impatient, still I always have the choice
> > > to take a development version. But I do not want to be forced to take
> > > unfinished work in a released kernel.
> > 
> > If as an end user you want full QA, you should go with a distro kernel.
> 
> No, no, NO! I won't ship a distro kernel because they screw things
> up (at least, in my experience). I will ship a 3.x.y stable kernel,
> though.

If you want full QA and feature set, perhaps you should be using a
vendor kernel.

> > We're talking about the upstream kernel here, and given the current 
> > development and release rate we hardly can guarantee you that it'll be 
> > free of unfinished work (as long as it doesn't regress existing 
> > features).
> 
> I read a quote from a Big Cheese saying how the Linux kernel is a
> stable release cycle. There are bugs, to be sure, but, in my
> experience, each release is pretty stable on x86 (but not on arm).

I've already stated this elsewhere, but I'll gladly repeat it here: the
DT, whether with or without stable bindings, should not influence the
stability of the kernel as a whole. That's why I prefer to refer to
bindings that aren't finalized yet as "experimental" rather than
"unstable". Any driver using any binding should not crash if that
binding doesn't look like what it expects.

I also think it's accepted for things to not be perfect from the start.
Nobody expects support for an SoC to be rock-solid when merged. Often
you can't do very much with the initial SoC support when it is merged,
so whether it's stable or not is largely irrelevant.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131023/04044d49/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Jason Gunthorpe]

On Wed, Oct 23, 2013 at 10:06:31AM +0200, Richard Cochran wrote:
> On Tue, Oct 22, 2013 at 11:13:46AM -0600, Jason Gunthorpe wrote:
> > The question I asked last time this came up, which was left unaswered:
> > 
> >  Who does this stable DT ABI vision benifit, and how much is that
> >  benifit worth?
> 
> [Sigh]
> 
> I already answered this question more than once. I guess it doesn't
> hurt to answer it again: It helps the users. Please, don't forget
> about them.

I've seen that nebulous answer before. It is awfully vauge. Don't you
think a better, more excting answer is required to commit the kernel
community to such a huge amount of work+pain?

What users? What use cases? Who exactly?

Crucially: Does the above justify the huge effort on the kernel side?

I'm a user of the kernel and I'm sitting here saying I don't need
this.

Thierry represents a chunk of users and he is saying much the same.

Others have made similar comments.

> If I, as an embedded developer, design my board to work with kernel
> version N and a given DTB, then I can upgrade to any kernel version
> M (where M > N) using the *same* DTB, and it still works.

You can use the DTB that comes with your kernel version. Just like
modules, and everything else that comes with the kernel.

The embedded vendor doing turnkey stuff (eg folks like me) can supply
the dtb, kernel, modules, etc as a bundle.

The less embedded, distro focused machines can supply dtb, kernel, modules,
etc as a bundle through the distro.

This is all very doable, and it isn't really even that hard.

As far as I can see, all stable DTB gets you is the ability to flash
the DTB into the firmware and never change it. Who does that actually
help?

Jason

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
> 
> As far as I can see, all stable DTB gets you is the ability to flash
> the DTB into the firmware and never change it. Who does that actually
> help?

Once I design my board, and it goes into production, the hardware is
fixed. It doesn't change, and neither should the description of the
hardware, also known as the DTB. If I have to research all of the ways
that the bindings changed in order to upgrade my kernel, then I am
better off with the old, static, platform data. At least there the
compiler would complain if fields are removed or renamed. 

I understand that having the bindings in flux makes life easier for
kernel developers, as it frees them from the burden of having to think
about the consequences of their hasty decisions. But those people are
not the only users. There is a much larger body of users than that.

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Maxime Bizon]

On Wed, 2013-10-23 at 19:45 +0200, Richard Cochran wrote:
> 
> Once I design my board, and it goes into production, the hardware is
> fixed. It doesn't change, and neither should the description of the
> hardware, also known as the DTB. If I have to research all of the
> ways 

SOC support are never completely finished; subsystems are getting new
features.
 
It's possible to ship a product with a kernel version that does not
handle all the chip goodies, then want to upgrade the kernel later when
someone has written the driver for a previously unused hardware block.

the first iteration of your DTB would be incomplete, the bindings to
describe that hardware block would not exist inside it.

real life example with Marvell Kirkwood, hw crypto support was added 1
year after initial SOC support.

I'm happy I can use it now on existing boards by "just" upgrading the
kernel.

-- 
Maxime

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Wed, Oct 23, 2013 at 08:46:22PM +0200, Maxime Bizon wrote:
> 
> the first iteration of your DTB would be incomplete, the bindings to
> describe that hardware block would not exist inside it.
> 
> real life example with Marvell Kirkwood, hw crypto support was added 1
> year after initial SOC support.
> 
> I'm happy I can use it now on existing boards by "just" upgrading the
> kernel.

I have no problem with new kernel features unlocked by new DT
bindings.

I *do* have a problem with new kernels breaking existing DT bindings.

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Maxime Bizon]

On Wed, 2013-10-23 at 20:51 +0200, Richard Cochran wrote:

> I have no problem with new kernel features unlocked by new DT
> bindings.
> 
> I *do* have a problem with new kernels breaking existing DT bindings.

well this assume the new feature does not need modifying an existing
binding.

again taking the Kirkwood crypto example, the driver was written using
lets say "PIO" mode, and a patch has been posted recently that mostly
rewrite the driver to use DMA mode after.

chances are the binding written by the first developer would not be the
same at all as the second

does the "DT bindings validation team" will have to look inside SOC
datasheet and decide whether the developer described the hardware
correctly ?

In another post, someone proposed that time would tell if a binding was
"stable" enough. In that case that's not true, 2 years have passed
before someone took a glance at what the hardware could do and proposed
a different implementation.

-- 
Maxime

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Grant Likely]

On Wed, 23 Oct 2013 20:46:22 +0200, Maxime Bizon <mbizon@freebox.fr> wrote:
> 
> On Wed, 2013-10-23 at 19:45 +0200, Richard Cochran wrote:
> > 
> > Once I design my board, and it goes into production, the hardware is
> > fixed. It doesn't change, and neither should the description of the
> > hardware, also known as the DTB. If I have to research all of the
> > ways 
> 
> SOC support are never completely finished; subsystems are getting new
> features.
>  
> It's possible to ship a product with a kernel version that does not
> handle all the chip goodies, then want to upgrade the kernel later when
> someone has written the driver for a previously unused hardware block.
> 
> the first iteration of your DTB would be incomplete, the bindings to
> describe that hardware block would not exist inside it.

At this point if the hardware exists then it should be described in DTB,
even if it is merely compatible, reg, interrupts and maybe clocks
properties. In many cases that is all that is required. It /is/ okay to
amend a binding later and to use default values if the new properties
aren't present.

> real life example with Marvell Kirkwood, hw crypto support was added 1
> year after initial SOC support.

That said, enabling new hardware is a different problem from changing
the binding on working hardware. It is entirely reasonable to update the
hardware description when enabling previously unused peripherals, but it
is absolutely not friendly to change a binding/driver in a what that fails on
previously working DTB (with the caveat that if no one notices, it
isn't breakage).

g.

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Maxime Bizon]

On Thu, 2013-10-24 at 10:52 +0100, Grant Likely wrote:

> At this point if the hardware exists then it should be described in DTB,
> even if it is merely compatible, reg, interrupts and maybe clocks

if your driver does not use them, chances are you'll get them wrong.

> properties. In many cases that is all that is required. It /is/ okay to
> amend a binding later and to use default values if the new properties
> aren't present.

how do you handle the case of a wrong property, because you only wrote
hardware description and not the driver ?

> hardware description when enabling previously unused peripherals, but it
> is absolutely not friendly to change a binding/driver in a what that fails on
> previously working DTB (with the caveat that if no one notices, it
> isn't breakage).

ok then how do we solve that case:

 - Marvell SOC 1 is mainlined
 - Marvell SOC 2 is mainlined
 - Marvell SOC 'x' is mainlined
 - "PIO" hw crypto driver is written, working for all SOCs
 - [1 year]
 - SOCs bindings are marked as stable
 - [1 year]
 - someone rewrite the driver of hw crypto to use DMA, existing binding
is not ok because clock 'foo' or interrupt 'bar', now required, are not
present.

what is the process merge that driver ?

if the answer is that you need to keep PIO mode in driver so that
existing DTBs still works with it, then this is just plain *wrong*.

-- 
Maxime

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[David Woodhouse]

On Thu, 2013-10-24 at 13:33 +0200, Maxime Bizon wrote:
> 
> ok then how do we solve that case:
> 
>  - Marvell SOC 1 is mainlined
>  - Marvell SOC 2 is mainlined
>  - Marvell SOC 'x' is mainlined
>  - "PIO" hw crypto driver is written, working for all SOCs
>  - [1 year]
>  - SOCs bindings are marked as stable
>  - [1 year]
>  - someone rewrite the driver of hw crypto to use DMA, existing binding
> is not ok because clock 'foo' or interrupt 'bar', now required, are not
> present.
> 
> what is the process merge that driver ?
> 
> if the answer is that you need to keep PIO mode in driver so that
> existing DTBs still works with it, then this is just plain *wrong*.

If you can automatically infer the correct clock/interrupt/etc in order
to do DMA correctly, despite the fact that it wasn't explicitly spelled
out in the old DT, then the property is *not* a "required" property.
It's optional, and you have a default behaviour for when it's not
present.

(And if you *can't* automatically infer that or otherwise get away
without it, then you're asking for the impossible, surely?)

The default behaviour in the absence of these properties may be
horrendously complex, and it may be defined only for SOC [1..x] and not
newer versions; it may be *mandatory* for SOC x+1. 

But if you really want the new driver to do DMA on platforms even where
this information wasn't originally provided by the DT, what option do
you have?

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/aefaa3eb/attachment.bin>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Maxime Bizon]

On Thu, 2013-10-24 at 12:47 +0100, David Woodhouse wrote:

> If you can automatically infer the correct clock/interrupt/etc in order
> to do DMA correctly, despite the fact that it wasn't explicitly spelled
> out in the old DT, then the property is *not* a "required" property.
> It's optional, and you have a default behaviour for when it's not
> present.

so inside the new version of driver-hwcrypto.c:

if (irq_of_parse_and_map(...) == NO_IRQ) {
	switch (get_soc_model()) {
		case SOC1:
			irq = 51;
			break;

		case SOC2:
			irq = 62;
			break;

		[...]
	}
}

?

-- 
Maxime

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[David Woodhouse]

>
> On Thu, 2013-10-24 at 12:47 +0100, David Woodhouse wrote:
>
>> If you can automatically infer the correct clock/interrupt/etc in order
>> to do DMA correctly, despite the fact that it wasn't explicitly spelled
>> out in the old DT, then the property is *not* a "required" property.
>> It's optional, and you have a default behaviour for when it's not
>> present.
>
> so inside the new version of driver-hwcrypto.c:
>
> if (irq_of_parse_and_map(...) == NO_IRQ) {
> 	switch (get_soc_model()) {
> 		case SOC1:
> 			irq = 51;
> 			break;
>
> 		case SOC2:
> 			irq = 62;
> 			break;
>
> 		[...]
> 	}
> }


If you are correct to insist that DMA needs yo be supported in the new
driver *even* with old firmware, then yes, maybe.

The alternative is a quirk to "fix" the DT up on the affected boards and
not actually doing the special cases in the driver itself. But that can be
seen as an implementation detail.

-- 
dwmw2

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[David Woodhouse]

>
> On Thu, 2013-10-24 at 12:47 +0100, David Woodhouse wrote:
>
>> If you can automatically infer the correct clock/interrupt/etc in order
>> to do DMA correctly, despite the fact that it wasn't explicitly spelled
>> out in the old DT, then the property is *not* a "required" property.
>> It's optional, and you have a default behaviour for when it's not
>> present.
>
> so inside the new version of driver-hwcrypto.c:
>
> if (irq_of_parse_and_map(...) == NO_IRQ) {
> 	switch (get_soc_model()) {
> 		case SOC1:
> 			irq = 51;
> 			break;
>
> 		case SOC2:
> 			irq = 62;
> 			break;
>
> 		[...]
> 	}
> }


If you are correct to insist that DMA needs yo be supported in the new
driver *even* with old firmware, then yes, maybe.

The alternative is a quirk to "fix" the DT up on the affected boards and
not actually doing the special cases in the driver itself. But that can be
seen as an implementation detail.

-- 
dwmw2

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Maxime Bizon]

On Thu, 2013-10-24 at 12:22 +0000, David Woodhouse wrote:

> If you are correct to insist that DMA needs yo be supported in the new
> driver *even* with old firmware, then yes, maybe.

if DMA gives a performance boost for all workloads, what is the argument
for not always enabling it ?

> The alternative is a quirk to "fix" the DT up on the affected boards and
> not actually doing the special cases in the driver itself. But that can be
> seen as an implementation detail.

I don't understand why having the soc-foo.h with the internal interrupt
mapping in the kernel tree is a no-no, whereas it's ok to add the
missing part of it in the form of fixups or directly in driver code.

-- 
Maxime

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[David Woodhouse]

>
> On Thu, 2013-10-24 at 12:22 +0000, David Woodhouse wrote:
>
>> If you are correct to insist that DMA needs yo be supported in the new
>> driver *even* with old firmware, then yes, maybe.
>
> if DMA gives a performance boost for all workloads, what is the argument
> for not always enabling it ?

If DMA gives a performance boost for all workloads, what bloody idiot
defined or reviewed a DT binding that didn't include the information which
is required to uae DMA? :)


>> The alternative is a quirk to "fix" the DT up on the affected boards and
>> not actually doing the special cases in the driver itself. But that can
>> be
>> seen as an implementation detail.
>
> I don't understand why having the soc-foo.h with the internal interrupt
> mapping in the kernel tree is a no-no, whereas it's ok to add the
> missing part of it in the form of fixups or directly in driver code.

It's the difference between doing it as a matter of course, and doing it
only in the very rare "OMG we fucked up but we really *need* to fix it up
this time" case.


-- 
dwmw2

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Maxime Bizon]

On Thu, 2013-10-24 at 13:14 +0000, David Woodhouse wrote:

> If DMA gives a performance boost for all workloads, what bloody idiot
> defined or reviewed a DT binding that didn't include the information which

who defined it:
  - hobbyist programmer without DMA knowledge 
  - hobbyist programmer without time
  - hobbyist programmer without datasheet access
  - SOC-vendor employed programmer with deadline

who reviewed it:
  - someone without time
  - someone without datasheet access
  - no-one (programmer was part of DT team :)

> It's the difference between doing it as a matter of course, and doing it
> only in the very rare "OMG we fucked up but we really *need* to fix it up
> this time" case.

we manage to screw syscalls, even with the amount of people that have
the ability to review them (as opposed to hardware when you need
datasheet)

few syscalls, lots of hardware.

-- 
Maxime

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Matt Porter]

On Thu, Oct 24, 2013 at 03:46:00PM +0200, Maxime Bizon wrote:
> 
> On Thu, 2013-10-24 at 13:14 +0000, David Woodhouse wrote:
> 
> > If DMA gives a performance boost for all workloads, what bloody idiot
> > defined or reviewed a DT binding that didn't include the information which
> 
> who defined it:
>   - hobbyist programmer without DMA knowledge 
>   - hobbyist programmer without time
>   - hobbyist programmer without datasheet access
>   - SOC-vendor employed programmer with deadline
> 
> who reviewed it:
>   - someone without time
>   - someone without datasheet access
>   - no-one (programmer was part of DT team :)

One more for each list:
    - professional programmer without datasheet access

I don't have docs for the parts I'm paid to work on. There's lots of
reasons why we don't know *all* information on day 0 and the notion of
binding perfection is flawed.

-Matt

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Matt Sealey]

On Thu, Oct 24, 2013 at 8:14 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>
>>
>> On Thu, 2013-10-24 at 12:22 +0000, David Woodhouse wrote:
>>
>>> If you are correct to insist that DMA needs yo be supported in the new
>>> driver *even* with old firmware, then yes, maybe.
>>
>> if DMA gives a performance boost for all workloads, what is the argument
>> for not always enabling it ?
>
> If DMA gives a performance boost for all workloads, what bloody idiot
> defined or reviewed a DT binding that didn't include the information which
> is required to uae DMA? :)

Two cases;

1) Where nobody documented that DMA was possible - if it is via an
external DMA controller with a configurable event number, then it is
not part of the binding for that IP block anyway except to optionally
specify what the dma controller in use is (phandle) and the event
number (irq, dma-channels, whatever)

2 a) Where there was not any driver for DMA so nobody even knew it
worked, but could only trust the documentation.

2 b) Where there are errata in older hardware which stopped it working
and consensus was that it shouldn't be defined until it works, and
then new hardware made it work

Either way, your fix is the correct one. If an interrupt or dma
channel for a device is totally fixed per SoC and that device is ONLY
used on that SoC, you can add a fixup in the driver to deal with older
bindings. This may be seen as a "huge leap backwards" but it is the
only way to do it and that is a fact of life.

This is the way the original Efika PPC was designed; Genesi/bplan did
not put a lot of properties (including interrupt numbers and DMA
functionality) in the tree because they were already used in pre-OF
drivers and the mappings were ostensibly fixed and in the manual. As
long as those drivers knew the values already, why describe them again
and have to write hundreds of lines of code to override a static value
with a dynamic DT-derived one?

Once it hits another SoC (i.e. number of users of the driver is >1)
then the property has to be required for the SECOND SoC unless it's
exactly the same mapping. Then you can mandate the property defining
the new values on newer hardware (with a particular compatible
property that differentiates it) for the purposes of future proofing
the driver, but on older hardware it can know what the real value is.
In the case where it's EXACTLY the same, the property stays optional
because drivers would always, as per older binding, know how to deal
with it.

Then came this edict that *absolutely everything* needed to be defined
in DT, even though there were no other platforms (and still aren't)
using those peripherals, and stuff like this got written:

http://www.powerdeveloper.org/platforms/efika/devicetree

Which I am quite proud of writing. And executing this script before
loading the OS meant Linux kept working - at least during 2008 - and
it is up to the user or distro to put that script in place when the OS
requires it. What is infuriating is the reluctance for the
distributions to mandate being able to script device tree changes when
they also want to mandate scriptable boot.. it seems like a lot of "we
don't want to, shove it on the vendors' back instead." All that is
going to do is piss off board designers and their software engineering
teams..

>> I don't understand why having the soc-foo.h with the internal interrupt
>> mapping in the kernel tree is a no-no, whereas it's ok to add the
>> missing part of it in the form of fixups or directly in driver code.
>
> It's the difference between doing it as a matter of course, and doing it
> only in the very rare "OMG we fucked up but we really *need* to fix it up
> this time" case.

Right. It doesn't need to be in a header or source just because it
exists - it needs to be there as, and ONLY as, it is used.

Most values are taken from the manuals anyway, so if they exist, they
exist in the manual even if they are unused in the OS.

If it really was as strict a process as some people would like it, the
i.MX NFC NAND driver and a couple others, none of the i.MX pinctrl
bindings currently existing or the very concept of defining clock
providers (&clocknode XY where XY is an arbitrary enum inside the OS)
would NEVER have hit. I absolutely loathe all 3 of these since they
make it very very difficult for everyone involved in bringing up OS
support on a new board, hardcoded values here and there but DT
properties elsewhere..constant cross-referencing of bindings and
headers and source code and Linux abstractions vs. manuals and host
controller specs. Some of that is a fact of life.. a lot of it is
definitely imposed by stupid design.

-- 
Matt Sealey <neko@bakuhatsu.net>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Stephen Warren]

On 10/24/2013 01:13 PM, Maxime Bizon wrote:
> 
> On Thu, 2013-10-24 at 12:47 +0100, David Woodhouse wrote:
> 
>> If you can automatically infer the correct clock/interrupt/etc in order
>> to do DMA correctly, despite the fact that it wasn't explicitly spelled
>> out in the old DT, then the property is *not* a "required" property.
>> It's optional, and you have a default behaviour for when it's not
>> present.
> 
> so inside the new version of driver-hwcrypto.c:
> 
> if (irq_of_parse_and_map(...) == NO_IRQ) {
> 	switch (get_soc_model()) {
> 		case SOC1:
> 			irq = 51;
> 			break;
> 
> 		case SOC2:
> 			irq = 62;
> 			break;
> 
> 		[...]
> 	}
> }

Uggh. Then you start embedding all the per-SoC or per-board description
in the drivers. It doesn't seem scalable for every driver to know about
every HW configuration. Adding extra IRQ/DMA/... properties to DT to
enable new features should be fine.

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 12:47:58PM +0100, David Woodhouse wrote:
> On Thu, 2013-10-24 at 13:33 +0200, Maxime Bizon wrote:
> > 
> > ok then how do we solve that case:
> > 
> >  - Marvell SOC 1 is mainlined
> >  - Marvell SOC 2 is mainlined
> >  - Marvell SOC 'x' is mainlined
> >  - "PIO" hw crypto driver is written, working for all SOCs
> >  - [1 year]
> >  - SOCs bindings are marked as stable
> >  - [1 year]
> >  - someone rewrite the driver of hw crypto to use DMA, existing binding
> > is not ok because clock 'foo' or interrupt 'bar', now required, are not
> > present.
> > 
> > what is the process merge that driver ?
> > 
> > if the answer is that you need to keep PIO mode in driver so that
> > existing DTBs still works with it, then this is just plain *wrong*.
> 
> If you can automatically infer the correct clock/interrupt/etc in order
> to do DMA correctly, despite the fact that it wasn't explicitly spelled
> out in the old DT, then the property is *not* a "required" property.
> It's optional, and you have a default behaviour for when it's not
> present.
> 
> (And if you *can't* automatically infer that or otherwise get away
> without it, then you're asking for the impossible, surely?)
> 
> The default behaviour in the absence of these properties may be
> horrendously complex, and it may be defined only for SOC [1..x] and not
> newer versions; it may be *mandatory* for SOC x+1. 
> 
> But if you really want the new driver to do DMA on platforms even where
> this information wasn't originally provided by the DT, what option do
> you have?

To me it sounds more like the sensible default would be to continue to
run with PIO support if the optional properties needed for DMA support
are not present.

Determining default values for the properties pretty much defeats the
purpose of putting them in the DT in the first place, doesn't it?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/61ce78ef/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[David Woodhouse]

> On Thu, Oct 24, 2013 at 12:47:58PM +0100, David Woodhouse wrote:
>> On Thu, 2013-10-24 at 13:33 +0200, Maxime Bizon wrote:
>> >
>> > ok then how do we solve that case:
>> >
>> >  - Marvell SOC 1 is mainlined
>> >  - Marvell SOC 2 is mainlined
>> >  - Marvell SOC 'x' is mainlined
>> >  - "PIO" hw crypto driver is written, working for all SOCs
>> >  - [1 year]
>> >  - SOCs bindings are marked as stable
>> >  - [1 year]
>> >  - someone rewrite the driver of hw crypto to use DMA, existing
>> binding
>> > is not ok because clock 'foo' or interrupt 'bar', now required, are
>> not
>> > present.
>> >
>> > what is the process merge that driver ?
>> >
>> > if the answer is that you need to keep PIO mode in driver so that
>> > existing DTBs still works with it, then this is just plain *wrong*.
>>
>> If you can automatically infer the correct clock/interrupt/etc in order
>> to do DMA correctly, despite the fact that it wasn't explicitly spelled
>> out in the old DT, then the property is *not* a "required" property.
>> It's optional, and you have a default behaviour for when it's not
>> present.
>>
>> (And if you *can't* automatically infer that or otherwise get away
>> without it, then you're asking for the impossible, surely?)
>>
>> The default behaviour in the absence of these properties may be
>> horrendously complex, and it may be defined only for SOC [1..x] and not
>> newer versions; it may be *mandatory* for SOC x+1.
>>
>> But if you really want the new driver to do DMA on platforms even where
>> this information wasn't originally provided by the DT, what option do
>> you have?
>
> To me it sounds more like the sensible default would be to continue to
> run with PIO support if the optional properties needed for DMA support
> are not present.
>
> Determining default values for the properties pretty much defeats the
> purpose of putting them in the DT in the first place, doesn't it?

Right. All that was implicit when I said "If you are correct to insist
that DMA has to be supported..."

It doesn't entirely defeat the purpose. It may have been easy to infer the
answers for the first incarnations of the hardware, but later it gets more
complex and needs to be spelled out.

-- 
dwmw2

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Maxime Bizon]

On Thu, 2013-10-24 at 14:23 +0200, Thierry Reding wrote:

> To me it sounds more like the sensible default would be to continue to
> run with PIO support if the optional properties needed for DMA support
> are not present.

huge leap backward

 - need to maintain & test two completely different code paths (might as
well fork the driver)

 - we can no longer claim: "upgrade to mainline, you get all new stuff
for free"

Today I can 'just' upgrade my kernel and get all improvements in
networking stack, fs scalability, ... Before DT, hardware support &
drivers improvement were part of that package, now we are proposing they
won't.

> Determining default values for the properties pretty much defeats the
> purpose of putting them in the DT in the first place, doesn't it?

my point

before DT scenario for my hw crypto driver example: 
  - edit socX.h to add the missing #define HW_CRYPTO_INTERRUPT
  - edit platform data to add IRQ resource
  - change driver code to use DMA
  - single bisectable merge
  - anyone with socX benefits by just upgrading kernel

DTS files are sometimes describing SOCs hardware properties that cannot
be changed in any way, these values would better be left in soc-foo.h
(where they were before).

-- 
Maxime

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[David Woodhouse]

>
> On Thu, 2013-10-24 at 14:23 +0200, Thierry Reding wrote:
> my point
>
> before DT scenario for my hw crypto driver example:

Note that you are not describing a normal "DT scenario" here. You are
describing a case in which we screwed up and allowed non-invariant
features of the hardware to be left out of the DT schema for the device in
question - apparently because the Linux driver at the time didn't happen
to use them yet. That was a fundamental mistake and should not have
happened that way.

So yes, after the public flogging has happened, and we're trying to work
out how best to cope with the screwup, we don't necessarily have any
perfect choices. The perfect choice was to do it properly in the first
place.

-- 
dwmw2

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Maxime Bizon]

On Thu, 2013-10-24 at 13:10 +0000, David Woodhouse wrote:

> Note that you are not describing a normal "DT scenario" here. You are
> describing a case in which we screwed up

AKA "real world"

> So yes, after the public flogging has happened, and we're trying to
> work out how best to cope with the screwup, we don't necessarily have
> any perfect choices. The perfect choice was to do it properly in the
> first place.

or avoid shooting ourselves in the foot in the first place, and keep
these unmodifiable stuff in kernel :)

-- 
Maxime

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[David Woodhouse]

>
> On Thu, 2013-10-24 at 13:10 +0000, David Woodhouse wrote:
>
>> Note that you are not describing a normal "DT scenario" here. You are
>> describing a case in which we screwed up
>
> AKA "real world"

No. Absolutely not. That was a screwup, and it needs to be *rare*. The
excuses you present for it are crappy and uunacceptable.

>> So yes, after the public flogging has happened, and we're trying to
>> work out how best to cope with the screwup, we don't necessarily have
>> any perfect choices. The perfect choice was to do it properly in the
>> first place.
>
> or avoid shooting ourselves in the foot in the first place, and keep
> these unmodifiable stuff in kernel :)

No. That doesn't scale. It doesn't work. We can cope with special-cases
for the rare screw-up, but that's a *long* way from always special-casing
*everything* as we used to.

-- 
dwmw2

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 02:05:58PM -0000, David Woodhouse wrote:
> 
> >
> > On Thu, 2013-10-24 at 13:10 +0000, David Woodhouse wrote:
> >
> >> Note that you are not describing a normal "DT scenario" here. You are
> >> describing a case in which we screwed up
> >
> > AKA "real world"
> 
> No. Absolutely not. That was a screwup, and it needs to be *rare*. The
> excuses you present for it are crappy and uunacceptable.

That's not helping. The fact is that is has happened. And we've handled
this in the past by just changing the DT bindings. Much of the current
frustration comes from the fact that things we used to be able to do
easily are now impossible.

While I agree that many of these screwups shouldn't have happened in the
first place, it's nothing that we were prepared for two years ago. At
some point everyone agreed that DT was the way forward, so DT is what we
did. Nobody said anything about stable ABI back then, so nobody cared.
We treated DT the same way we had treated platform data before, which
has inevitable lead to the current mess, which is only slightly better
than what we used to have.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/470d94f1/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[David Woodhouse]

> On Thu, Oct 24, 2013 at 02:05:58PM -0000, David Woodhouse wrote:
>>
>> >
>> > On Thu, 2013-10-24 at 13:10 +0000, David Woodhouse wrote:
>> >
>> >> Note that you are not describing a normal "DT scenario" here. You are
>> >> describing a case in which we screwed up
>> >
>> > AKA "real world"
>>
>> No. Absolutely not. That was a screwup, and it needs to be *rare*. The
>> excuses you present for it are crappy and uunacceptable.
>
> That's not helping. The fact is that is has happened.

It has happened, yes. But we're describing how things *shall* work going
forward. Coping with existing mistakes is a slightly separate issue.
(Albeit only slightly since mistakes *will* continue to happen, but
hopefully more rarely so our defined processes for coping are based on the
assumption that it should be rare)


-- 
dwmw2

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 02:30:09PM -0000, David Woodhouse wrote:
> 
> > On Thu, Oct 24, 2013 at 02:05:58PM -0000, David Woodhouse wrote:
> >>
> >> >
> >> > On Thu, 2013-10-24 at 13:10 +0000, David Woodhouse wrote:
> >> >
> >> >> Note that you are not describing a normal "DT scenario" here. You are
> >> >> describing a case in which we screwed up
> >> >
> >> > AKA "real world"
> >>
> >> No. Absolutely not. That was a screwup, and it needs to be *rare*. The
> >> excuses you present for it are crappy and uunacceptable.
> >
> > That's not helping. The fact is that is has happened.
> 
> It has happened, yes. But we're describing how things *shall* work going
> forward. Coping with existing mistakes is a slightly separate issue.
> (Albeit only slightly since mistakes *will* continue to happen, but
> hopefully more rarely so our defined processes for coping are based on the
> assumption that it should be rare)

Agreed.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/89208197/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Nicolas Pitre]

On Thu, 24 Oct 2013, David Woodhouse wrote:

> 
> > On Thu, Oct 24, 2013 at 02:05:58PM -0000, David Woodhouse wrote:
> >>
> >> >
> >> > On Thu, 2013-10-24 at 13:10 +0000, David Woodhouse wrote:
> >> >
> >> >> Note that you are not describing a normal "DT scenario" here. You are
> >> >> describing a case in which we screwed up
> >> >
> >> > AKA "real world"
> >>
> >> No. Absolutely not. That was a screwup, and it needs to be *rare*. The
> >> excuses you present for it are crappy and uunacceptable.
> >
> > That's not helping. The fact is that is has happened.
> 
> It has happened, yes. But we're describing how things *shall* work going
> forward. Coping with existing mistakes is a slightly separate issue.
> (Albeit only slightly since mistakes *will* continue to happen, but
> hopefully more rarely so our defined processes for coping are based on the
> assumption that it should be rare)

No.  Doing so would only be an exercice in wishful thinking and a 
mistake.

Please let's get real.

Mistakes happen all the time.  And with all the diversity of hardware IP 
blocks out there, and all the different ways they're been connected, we 
have this combinatorial configuration explosion that absolutely no one 
can have the entire knowledge about.  Obstacles in the name of binding 
immutability is hurting more people than the amount of people who are 
benefiting from it right now.

So it is time IMHO that the description of how things *shall* work be 
itself revised.


Nicolas

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[David Woodhouse]

> So it is time IMHO that the description of how things *shall* work be
> itself revised.

It *is* being revised, with an explicit explicit understanding that things
will have to change and a defined process for how to cope with that.

That was discussed yesterday and we will be finishing the write-up to be
presented at the Kernel Summit tomorrow.


-- 
dwmw2

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Nicolas Pitre]

On Thu, 24 Oct 2013, David Woodhouse wrote:

> 
> > So it is time IMHO that the description of how things *shall* work be
> > itself revised.
> 
> It *is* being revised, with an explicit explicit understanding that things
> will have to change and a defined process for how to cope with that.

Good.

Your previous emails seemed to imply that the lack of binding stability 
enforcement was the problem.

And you said: "our defined processes for coping are based on the 
assumption that it (mistakes) should be rare". I think this statement is 
wrong.  So if this is what's being revised then fine.



Nicolas

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[jonsmirl at gmail.com]

On Thu, Oct 24, 2013 at 12:45 PM, David Woodhouse <dwmw2@infradead.org> wrote:
>
>> So it is time IMHO that the description of how things *shall* work be
>> itself revised.
>
> It *is* being revised, with an explicit explicit understanding that things
> will have to change and a defined process for how to cope with that.
>
> That was discussed yesterday and we will be finishing the write-up to be
> presented at the Kernel Summit tomorrow.

Did the concept of vertical and horizontal schemas make it in?

Horizontal schema - generic class descriptions for subsystems (spi,
alsa, uart, usb, etc). All specific DTS instantiations of the
subsystem would have to validate against the subsystem schema. And
conversely this schema would contain all of the weird chip specific
attributes that can't be handled generically.  These schemas serve two
purposes - they provide a generic skeleton for someone implementing a
new instance of the subsystem to start from and they allow the
subsystem maintainer to control the proliferation of similarly named
attributes (nscs, numcs, cs, ti,cs, chipsel, etc all describing the
same thing - the number of chip selects).  These schemas would be
highly documented and discussed on device-tree list.

The subsystem schemas would be included by higher level generic schema
files. So starting at the root of this tree all DTS files in the
kernel should validate against the tree. Anything that doesn't
validate should produce a warning or error. Can't get your DTS
mainlined until it can be validated without errors.

Vertical schema - the main goal of these schemas is error checking.
For example there may be an iMX6 or OMAP schema. These schemas would
check the device trees validated against them for as many errors as
possible. Like attribute names that are from the wrong chip or invalid
gpio or interrupt numbers, etc. These would be maintained by the SOC
vendors and not subject to intense review on the device-tree list.


>
>
> --
> dwmw2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Jon Smirl
jonsmirl at gmail.com

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Thu, Oct 24, 2013 at 04:19:56PM +0200, Thierry Reding wrote:
> 
> While I agree that many of these screwups shouldn't have happened in the
> first place, it's nothing that we were prepared for two years ago. At
> some point everyone agreed that DT was the way forward, so DT is what we
> did. Nobody said anything about stable ABI back then, so nobody cared.

The idea of a device tree has not changed. I guess the arm crowd
jumped on the DT bandwagon with no clue what it was about.

> We treated DT the same way we had treated platform data before, which
> has inevitable lead to the current mess, which is only slightly better
> than what we used to have.

So, are you saying that arm/dt is a failure?

(I won't argue with you on that point.)

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 04:32:52PM +0200, Richard Cochran wrote:
> On Thu, Oct 24, 2013 at 04:19:56PM +0200, Thierry Reding wrote:
> > 
> > While I agree that many of these screwups shouldn't have happened in the
> > first place, it's nothing that we were prepared for two years ago. At
> > some point everyone agreed that DT was the way forward, so DT is what we
> > did. Nobody said anything about stable ABI back then, so nobody cared.
> 
> The idea of a device tree has not changed. I guess the arm crowd
> jumped on the DT bandwagon with no clue what it was about.

Yes, that's what I'm saying. I've played my part in it, too. Perhaps it
was obvious from the beginning and I just didn't notice, but no document
about DT that I read mentioned anything about ABI stability and such.
Then again I reckon none of the other DT implementations can really be
compared to Linux in terms of diversity and perhaps even number of
contributors. So perhaps a lot of the things that we now run into were
implied but never explicitly mentioned. Or I and most of the others
missed them.

> > We treated DT the same way we had treated platform data before, which
> > has inevitable lead to the current mess, which is only slightly better
> > than what we used to have.
> 
> So, are you saying that arm/dt is a failure?

Yeah, I think it is in some regards. But I wouldn't go as far as to call
it a total failure. I still think we can make it work, and even
reasonably well. We just need to fix our process. Perhaps we need to
start by documenting things better, such as what you can and can't do to
stable bindings and point people to that documentation.

Furthermore I don't think anyone has proposed a better alternative. ACPI
or UEFI have been mentioned, but are they really any superior? From what
I can tell they have all the same problems that we now face with DT as
well, so we might as well just stick with DT.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/cdfbf978/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Nicolas Pitre]

On Thu, 24 Oct 2013, Richard Cochran wrote:

> On Thu, Oct 24, 2013 at 04:19:56PM +0200, Thierry Reding wrote:
> > 
> > While I agree that many of these screwups shouldn't have happened in the
> > first place, it's nothing that we were prepared for two years ago. At
> > some point everyone agreed that DT was the way forward, so DT is what we
> > did. Nobody said anything about stable ABI back then, so nobody cared.
> 
> The idea of a device tree has not changed. I guess the arm crowd
> jumped on the DT bandwagon with no clue what it was about.

No no no.  The ARM crowd _resisted_ the introduction of DT but the 
PowerPC refugees convinced us this was a good idea and that it would 
solve most of our problems.

DT did solve some problems indeed.  But it brought new ones with it.


Nicolas

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Maxime Bizon]

On Thu, 2013-10-24 at 16:19 +0200, Thierry Reding wrote:

> We treated DT the same way we had treated platform data before, which
> has inevitable lead to the current mess, which is only slightly better
> than what we used to have. 

Side question, in your point of view, how is that better ?

current DT tools are not able to validate a file wrt its schema, so for
now we just moved platdata to DTS files and lost compiler type checking
in between.

I respectfully understand people fighting for *stable* DT because I see
the benefits behind this, even if IMO they absolutely do not outweigh
the pain.

But I fail to see any benefits of "forever unstable" DT, if you have to
tie the kernel tree with a DTB file, the description could have been
left in C code.

-- 
Maxime

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 04:33:39PM +0200, Maxime Bizon wrote:
> 
> On Thu, 2013-10-24 at 16:19 +0200, Thierry Reding wrote:
> 
> > We treated DT the same way we had treated platform data before, which
> > has inevitable lead to the current mess, which is only slightly better
> > than what we used to have. 
> 
> Side question, in your point of view, how is that better ?

The representation of the data may not be all that much better. But as a
side-effect of the whole DT shebang we've made improvements in many
other areas as well. Granted, we could've done that without DT too, but
DT was a pretty good motivator.

I also think that during the conversion of platform data to DT we've
made attempts to make the representation more generic and introduce
common or standard properties. So on the whole I think we have managed
to unify many things, which I think is a good thing.

> current DT tools are not able to validate a file wrt its schema, so for
> now we just moved platdata to DTS files and lost compiler type checking
> in between.

There's been talk about fixing that. I guess it might have been better
if we had had such a tool two years ago, but I certainly hadn't thought
about it before, so who am I to blame anyone else for not writing it.

> I respectfully understand people fighting for *stable* DT because I see
> the benefits behind this, even if IMO they absolutely do not outweigh
> the pain.
> 
> But I fail to see any benefits of "forever unstable" DT, if you have to
> tie the kernel tree with a DTB file, the description could have been
> left in C code.

Well the longterm goal certainly is to separate both, and keeping both
in lockstep was a means of easing the initial conversion. There's
certainly a lot of pain, but I also think that whatever we had before
just didn't work out so well. If it had all been sunshine and lollipops
then there wouldn't have been a need to change anything, right?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/2486e105/attachment-0001.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Nicolas Pitre]

On Thu, 24 Oct 2013, David Woodhouse wrote:

> 
> >
> > On Thu, 2013-10-24 at 13:10 +0000, David Woodhouse wrote:
> >
> >> Note that you are not describing a normal "DT scenario" here. You are
> >> describing a case in which we screwed up
> >
> > AKA "real world"
> 
> No. Absolutely not. That was a screwup, and it needs to be *rare*. The
> excuses you present for it are crappy and uunacceptable.

Let's get real please.  It is just too easy for DT reviewers in their 
ivory tower to shot down submissions because the bindings are not to 
their liking.

The world out there is not stable.  Things change.  Hardware is revised 
all the time.  Software change to cope.  And even when the hardware is 
stable, new software solutions come about to improve things.  That's the 
point of _soft_ware, isn't it?  Flexibility is needed in order to scale.

"DT only describe the hardware" is often brought up as if that was the 
ultimate argument for its "stability".  But descriptions, even hardware 
descriptions, may be subjective i.e. two humans might describe it 
differently.  Incidentally DT bindings are created by humans and are 
therefore imperfect and suboptimal most of the time.

We used to have very lenient reviews on new DT bindings.  Sure some of 
them were bad.  The recent reaction to that was to go 180 degrees and 
accept only near perfect bindings.  But the cure is now hurting more 
than the initial problem.

Sure, the world would be so much better if DT bindings could be optimal 
on the first shot.  But asking that DT bindings remain stable when the 
world around them is not is asking for the impossible.

So IMHO the failure with DT right now is actually the expectations that 
come with it.  Those expectations are not realistic.

Special cases are the norm, whether you like it or not.  In fact we all 
hate special cases because they make what would otherwise be a very 
straight forward and elegant process rather messy.  This is why a 
process needs to concern itself with special cases since this is where a 
process is even more helpful.

So instead of trying to enforce even more stability in the DT bindings 
with stricter rules, I think that the process should instead concern 
itself with better ways to _allow_ and _facilitate_ binding updates.  
This is much more likely to scale, and result in a better system in the 
end.

And since there is so many changes one can bring to ultimately describe 
some piece of hardware, the DT bindings will naturally reach a stable 
state eventually. But that cannot be known in advance when that will be.


Nicolas

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 01:10:22PM -0000, David Woodhouse wrote:
> 
> >
> > On Thu, 2013-10-24 at 14:23 +0200, Thierry Reding wrote:
> > my point
> >
> > before DT scenario for my hw crypto driver example:
> 
> Note that you are not describing a normal "DT scenario" here. You are
> describing a case in which we screwed up and allowed non-invariant
> features of the hardware to be left out of the DT schema for the device in
> question - apparently because the Linux driver at the time didn't happen
> to use them yet. That was a fundamental mistake and should not have
> happened that way.
> 
> So yes, after the public flogging has happened, and we're trying to work
> out how best to cope with the screwup, we don't necessarily have any
> perfect choices. The perfect choice was to do it properly in the first
> place.

The original point that I was arguing and which triggered my proposal to
allow bindings to be experimental is that we're currently being hindered
to add new features because we're afraid of screwing up. How are we to
know that a binding is sufficient if we can't put it through some real
world testing.

I think asking for DT bindings to be specified in all completeness from
the beginning is unrealistic. There's simply no process in place to do
that. It's taken us the better part of two years to figure out that we
even have a problem.

We've ended up in a situation where software engineers that write the
drivers are required to define hardware in it's entirety before any code
can be merged. In my experience that's very difficult, if not impossible
to do. At the same time hardware engineers aren't very likely to have
heard of DT at all, so they won't be able to come up with a good binding
either.

We can argue forever that DT should describe hardware, but at some point
software engineers need to get involved and work out whether what's in
the binding is sufficient to write a functional driver. This is further
complicated by the fact that unless the people involved *really* know
what they're doing, and even then they may overlook something, the only
way you can be reasonably sure that a DT binding is accurate and
complete is if you have a fully functional driver that implements it.
And the majority of people don't have much experience with DT at all.

Perhaps the solution to aim for in the long run would be to take what we
have learned over the past few years back to vendors and try to get them
to provide the DT bindings along with new hardware. My understanding is
that that's what people have done on architectures that have implemented
DT in the past.

At the same time, the situation we're in is fairly unique, because from
what I can tell, none of the existing DT architectures are anywhere near
as complex or diverse as ARM. Also, even if we can solve this by getting
vendors involved from the start, that doesn't help us now. Unless we
want the better part of ARM to come to a halt for a year or more we need
to find a temporary solution.

Experimental bindings could be a suitable temporary measure, but perhaps
other, better solutions exist.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/22bef7c6/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[David Woodhouse]

> Experimental bindings could be a suitable temporary measure, but perhaps
> other, better solutions exist.

Yes, unstable bindings are part of the currently-documented plan. You are
not expected to need it as a matter of course, but that facility will
exist.


-- 
dwmw2

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 02:22:06PM -0000, David Woodhouse wrote:
> 
> > Experimental bindings could be a suitable temporary measure, but perhaps
> > other, better solutions exist.
> 
> Yes, unstable bindings are part of the currently-documented plan. You are
> not expected to need it as a matter of course, but that facility will
> exist.

Can you point me to the documented plan? I must have missed it.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/843f5c5e/attachment-0001.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[David Woodhouse]

> On Thu, Oct 24, 2013 at 02:22:06PM -0000, David Woodhouse wrote:
>>
>> > Experimental bindings could be a suitable temporary measure, but
>> perhaps
>> > other, better solutions exist.
>>
>> Yes, unstable bindings are part of the currently-documented plan. You
>> are
>> not expected to need it as a matter of course, but that facility will
>> exist.
>
> Can you point me to the documented plan? I must have missed it.

It's not quite out there yet.

It was thrashed out in the ARM summit yesterday, and Grant and I will be
polishing the draft tonight before presenting it to the Kernel Summit
tomorrow.


-- 
dwmw2

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 02:38:16PM -0000, David Woodhouse wrote:
> 
> > On Thu, Oct 24, 2013 at 02:22:06PM -0000, David Woodhouse wrote:
> >>
> >> > Experimental bindings could be a suitable temporary measure, but
> >> perhaps
> >> > other, better solutions exist.
> >>
> >> Yes, unstable bindings are part of the currently-documented plan. You
> >> are
> >> not expected to need it as a matter of course, but that facility will
> >> exist.
> >
> > Can you point me to the documented plan? I must have missed it.
> 
> It's not quite out there yet.
> 
> It was thrashed out in the ARM summit yesterday, and Grant and I will be
> polishing the draft tonight before presenting it to the Kernel Summit
> tomorrow.

Okay, that's great. Please let me know if there's anything I can do to
help push this forward.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/29d8814f/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Matt Porter]

On Thu, Oct 24, 2013 at 02:22:06PM -0000, David Woodhouse wrote:
> 
> > Experimental bindings could be a suitable temporary measure, but perhaps
> > other, better solutions exist.
> 
> Yes, unstable bindings are part of the currently-documented plan. You are
> not expected to need it as a matter of course, but that facility will
> exist.

I know I'm going to be told to wait for the plan but...

Can you elaborate on the notion of "not expected to need [unstable
bindings] as a matter of course"?

-Matt

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Grant Likely]

Can we end this thread now? Please?

The same arguments are going around and around. and around. Nothing new
has been said in the past 50 emails. We've also had some pretty intense
dicussions here in Edinburgh at the ARM summit and about 12 of us
hammered out a proposal for a way to address the log jam of binding
review and to attempt to address the concerns on *both* sides of the
stable-abi debate. Mark Rutland talked a bit about it during his
presentation at ELCE today. Tomorrow it will be discussed at kernel
summit, and I'll be posting it to the list ASAP.

Take a breath. Go for a walk in the garden. Enjoy your weekend, and we
can start a new flame war on Monday on the devicetree list.

g.

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Stephen Warren]

On 10/24/2013 12:33 PM, Maxime Bizon wrote:
> 
> On Thu, 2013-10-24 at 10:52 +0100, Grant Likely wrote:
> 
>> At this point if the hardware exists then it should be described in DTB,
>> even if it is merely compatible, reg, interrupts and maybe clocks
> 
> if your driver does not use them, chances are you'll get them wrong.
> 
>> properties. In many cases that is all that is required. It /is/ okay to
>> amend a binding later and to use default values if the new properties
>> aren't present.
> 
> how do you handle the case of a wrong property, because you only wrote
> hardware description and not the driver ?
> 
>> hardware description when enabling previously unused peripherals, but it
>> is absolutely not friendly to change a binding/driver in a what that fails on
>> previously working DTB (with the caveat that if no one notices, it
>> isn't breakage).
> 
> ok then how do we solve that case:
> 
>  - Marvell SOC 1 is mainlined
>  - Marvell SOC 2 is mainlined
>  - Marvell SOC 'x' is mainlined
>  - "PIO" hw crypto driver is written, working for all SOCs
>  - [1 year]
>  - SOCs bindings are marked as stable
>  - [1 year]
>  - someone rewrite the driver of hw crypto to use DMA, existing binding
> is not ok because clock 'foo' or interrupt 'bar', now required, are not
> present.
> 
> what is the process merge that driver ?
> 
> if the answer is that you need to keep PIO mode in driver so that
> existing DTBs still works with it, then this is just plain *wrong*.

That situation describes enabling a new feature. New features aren't
necessarily expected to work without revising the DT, e.g. adding new
properties/entries to describe the additional clocks/DMA-channels/...
that are required. In many cases, those additions can even be made in a
backwards-compatible way. Compatibility means that we shouldn't break
old functionality, not that we shouldn't augment the existing bindings.

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Fri, Oct 25, 2013 at 09:52:53AM +0100, Stephen Warren wrote:
> On 10/24/2013 12:33 PM, Maxime Bizon wrote:
> > 
> > On Thu, 2013-10-24 at 10:52 +0100, Grant Likely wrote:
> > 
> >> At this point if the hardware exists then it should be described in DTB,
> >> even if it is merely compatible, reg, interrupts and maybe clocks
> > 
> > if your driver does not use them, chances are you'll get them wrong.
> > 
> >> properties. In many cases that is all that is required. It /is/ okay to
> >> amend a binding later and to use default values if the new properties
> >> aren't present.
> > 
> > how do you handle the case of a wrong property, because you only wrote
> > hardware description and not the driver ?
> > 
> >> hardware description when enabling previously unused peripherals, but it
> >> is absolutely not friendly to change a binding/driver in a what that fails on
> >> previously working DTB (with the caveat that if no one notices, it
> >> isn't breakage).
> > 
> > ok then how do we solve that case:
> > 
> >  - Marvell SOC 1 is mainlined
> >  - Marvell SOC 2 is mainlined
> >  - Marvell SOC 'x' is mainlined
> >  - "PIO" hw crypto driver is written, working for all SOCs
> >  - [1 year]
> >  - SOCs bindings are marked as stable
> >  - [1 year]
> >  - someone rewrite the driver of hw crypto to use DMA, existing binding
> > is not ok because clock 'foo' or interrupt 'bar', now required, are not
> > present.
> > 
> > what is the process merge that driver ?
> > 
> > if the answer is that you need to keep PIO mode in driver so that
> > existing DTBs still works with it, then this is just plain *wrong*.
> 
> That situation describes enabling a new feature. New features aren't
> necessarily expected to work without revising the DT, e.g. adding new
> properties/entries to describe the additional clocks/DMA-channels/...
> that are required. In many cases, those additions can even be made in a
> backwards-compatible way. Compatibility means that we shouldn't break
> old functionality, not that we shouldn't augment the existing bindings.

In other words, the absence of the new properties should make the driver
fall back to a previous working mode, even if that means it might not be
as good as it could be. Making it use the new features would require the
DT to be updated.

Doesn't that entail that new properties will intrinsically be optional?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131025/4af9ff52/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
> 
> I've seen that nebulous answer before. It is awfully vauge. Don't you
> think a better, more excting answer is required to commit the kernel
> community to such a huge amount of work+pain?
> 
> What users? What use cases? Who exactly?

Gimme a break. The use case I mentioned is not at all vague. It is
about a specific a use case as you'll ever see.
 
> Crucially: Does the above justify the huge effort on the kernel side?

The effort is no more or less than is required of every other kernel
development.

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Nicolas Pitre]

On Wed, 23 Oct 2013, Richard Cochran wrote:

> On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
> > 
> > I've seen that nebulous answer before. It is awfully vauge. Don't you
> > think a better, more excting answer is required to commit the kernel
> > community to such a huge amount of work+pain?
> > 
> > What users? What use cases? Who exactly?
> 
> Gimme a break. The use case I mentioned is not at all vague. It is
> about a specific a use case as you'll ever see.

Let's agree to disagree then.  I side with Jason on this.


Nicolas

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Jason Gunthorpe]

On Wed, Oct 23, 2013 at 07:47:37PM +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
> > 
> > I've seen that nebulous answer before. It is awfully vauge. Don't you
> > think a better, more excting answer is required to commit the kernel
> > community to such a huge amount of work+pain?
> > 
> > What users? What use cases? Who exactly?
> 
> Gimme a break. The use case I mentioned is not at all vague. It is
> about a specific a use case as you'll ever see.

I can rephrase your use case as wanting to boot kernels M > N where N
is the first working mainline kernel. I think we all want that.

But it doesn't concretely tie back to stable DTB as the only possible
solution. As you pointed out we could do this with board.c files.

In other words, I don't think it is a compelling justification.

> > Crucially: Does the above justify the huge effort on the kernel side?
> 
> The effort is no more or less than is required of every other kernel
> development.

Bollocks. User space API development is the single most difficult
thing to do in the kernel. It is much harder than any other change,
and stable ABI DT is elevated to *that* level. 

Regards,
Jason

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Wed, Oct 23, 2013 at 12:02:40PM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 23, 2013 at 07:47:37PM +0200, Richard Cochran wrote:
> > 
> > The effort is no more or less than is required of every other kernel
> > development.
> 
> Bollocks. User space API development is the single most difficult
> thing to do in the kernel. It is much harder than any other change,
> and stable ABI DT is elevated to *that* level. 

Yes, that is the kind of effort needed. It comes with the territory.
System calls and ioctls are added all the time. Yes, they do require
some thought and review to get them right.

Creating new DT bindings also requires effort, but I don't agree with
the idea of making a mess for the end user just to avoid this effort.

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Wed, Oct 23, 2013 at 08:23:47PM +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 12:02:40PM -0600, Jason Gunthorpe wrote:
> > On Wed, Oct 23, 2013 at 07:47:37PM +0200, Richard Cochran wrote:
> > > 
> > > The effort is no more or less than is required of every other kernel
> > > development.
> > 
> > Bollocks. User space API development is the single most difficult
> > thing to do in the kernel. It is much harder than any other change,
> > and stable ABI DT is elevated to *that* level. 
> 
> Yes, that is the kind of effort needed. It comes with the territory.
> System calls and ioctls are added all the time. Yes, they do require
> some thought and review to get them right.
> 
> Creating new DT bindings also requires effort, but I don't agree with
> the idea of making a mess for the end user just to avoid this effort.

There's another thing with DT bindings that makes them needlessly hard
to settle on. Let's say you come up with a binding that accurately
describes the hardware at hand and has been proven to work. Now people
keep telling you that it might not be good enough, for whatever reason
so eventually you decide to be bold and tell them that you're aware of
everything that stable DT bindings imply and that there might be some
risk of having to maintain two bindings because the first one didn't
turn out to be perfect and yada yada.

So you are actually prepared to take the risk of having to maintain two
different bindings and do all the work to get a new feature supported.
Now people tell you that you can't do that either because you might not
be around forever and some poor sod will have to maintain it for you.

What do you do then? You try to convince people that we are in a big
mess right now and that we need to find a way out of it.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/3fe22272/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Thu, Oct 24, 2013 at 10:34:12AM +0200, Thierry Reding wrote:
> 
> There's another thing with DT bindings that makes them needlessly hard
> to settle on. Let's say you come up with a binding that accurately
> describes the hardware at hand and has been proven to work. Now people
> keep telling you that it might not be good enough, for whatever reason
> so eventually you decide to be bold and tell them that you're aware of
> everything that stable DT bindings imply and that there might be some
> risk of having to maintain two bindings because the first one didn't
> turn out to be perfect and yada yada.

You make a good point here. In my own limited experiences with DT
kernel development, a big debate always emerged about exactly how
these bindings should be called. Not being a real DT expert myself, I
really couldn't understand what the point was, but I just implemented
what the DT people wanted (or just dropped the submission altogether,
in one case).

I think the frustration that you have experienced is simply a result
of the attitude on the DT list. Maybe the real issue is attitude
and personalities, and not the hurdle of stable bindings.

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Matt Porter]

On Thu, Oct 24, 2013 at 05:00:16PM +0200, Richard Cochran wrote:
> On Thu, Oct 24, 2013 at 10:34:12AM +0200, Thierry Reding wrote:
> > 
> > There's another thing with DT bindings that makes them needlessly hard
> > to settle on. Let's say you come up with a binding that accurately
> > describes the hardware at hand and has been proven to work. Now people
> > keep telling you that it might not be good enough, for whatever reason
> > so eventually you decide to be bold and tell them that you're aware of
> > everything that stable DT bindings imply and that there might be some
> > risk of having to maintain two bindings because the first one didn't
> > turn out to be perfect and yada yada.
> 
> You make a good point here. In my own limited experiences with DT
> kernel development, a big debate always emerged about exactly how
> these bindings should be called. Not being a real DT expert myself, I
> really couldn't understand what the point was, but I just implemented
> what the DT people wanted (or just dropped the submission altogether,
> in one case).
> 
> I think the frustration that you have experienced is simply a result
> of the attitude on the DT list. Maybe the real issue is attitude
> and personalities, and not the hurdle of stable bindings.

Well, you both hit on something here. There's no possible self-policing
of what is submitted as bindings.

There's really no canonical documentation on best practices. Most
bindings are inconsistent in format and deprecated in style of
content.

I'm not talking about referring back to ePAPR or the explanation of
compatible string best practices on devicetree.org. I'm talking about
all the decisions made in random threads. The "standards" and "best
practices" have not been documented like our kernel patch submission
process and best practices. As a result, people our generating
additional traffic with every new binding submission. Stephen had
a nice list of best practices but it's difficult to tell if that is
agreed on by *all* the DT maintainers or his personal preference. At
some point we need to agree on documentation for best practices acked
by the entire maintainer team.

-Matt

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Guenter Roeck]

On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
> 
> As far as I can see, all stable DTB gets you is the ability to flash
> the DTB into the firmware and never change it. Who does that actually
> help?
> 
Not me. We want to be able to run the same kernel on different hardware,
so we would not want to tie the dtb with the kernel image, but
the ability to update the dtb on a system when updating the kernel
is essential. There is no requirement to be backwards compatible.
Sure, it is nice to have, and in most cases the dtb _will_ be backward
compatible with newer kernels, but it is not a requirement.

For us, one of the advantages of dtb is that it is more flexible
and easier to update than, say, DSDT, which tends to be tied to the BIOS
and is much more difficult to update in the field.

That doesn't mean that one should go ahead and change DT bindings at a whim
without good reason. But I like the approach used for sysfs attributes much
over the notion of "Thou Shalt Not Change Anything" used for DT bindings.
sysfs attributes don't change at a whim either, as there is real impact
if they do, but that doesn't mean they are completely off limits either
(nor does the use of sysfs bindings residing in the 'ABI/testing' directory
result in kernel warnings or in tainted kernels).

Guenter

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Jason Gunthorpe]

On Wed, Oct 23, 2013 at 11:01:08AM -0700, Guenter Roeck wrote:
> Not me. We want to be able to run the same kernel on different hardware,
> so we would not want to tie the dtb with the kernel image, but
> the ability to update the dtb on a system when updating the kernel
> is essential. 

This is a really important point.

The complaint from distro-land was they don't want multiple kernel
packages.

What they want is one vmlinux/z, and a package of 'stuff' that they
can assemble a boot image for all hardware out of.

On x86 the package of 'stuff' is modules and grub. Distro scripts
package the modules into the initrd and configure grub based on the
installed hardware to make a bootable image.

On ARM the package of 'stuff' can very reasonably include dtb. Distro
scripts can package modules+DTB+vmlinuz into something the bootloader
can understand. (The next pain point will be to standardize that)

The DTB doesn't have to be 'outside' the distro/kernel to give users a
seamless upgrade experience.

Jason

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote:

> What they want is one vmlinux/z, and a package of 'stuff' that they
> can assemble a boot image for all hardware out of.

...

> On ARM the package of 'stuff' can very reasonably include dtb. Distro
> scripts can package modules+DTB+vmlinuz into something the bootloader
> can understand. (The next pain point will be to standardize that)
> 
> The DTB doesn't have to be 'outside' the distro/kernel to give users a
> seamless upgrade experience.

How can a distro possibly provide me a DTB?

They don't know what hardware I am using. Only I know that.

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Jason Gunthorpe]

On Wed, Oct 23, 2013 at 08:30:42PM +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote:

> > On ARM the package of 'stuff' can very reasonably include dtb. Distro
> > scripts can package modules+DTB+vmlinuz into something the bootloader
> > can understand. (The next pain point will be to standardize that)
> > 
> > The DTB doesn't have to be 'outside' the distro/kernel to give users a
> > seamless upgrade experience.
> 
> How can a distro possibly provide me a DTB?
> 
> They don't know what hardware I am using. Only I know that.

I'm not sure what you are asking? Treat DTBs like kernel drivers. If
you make hardware and you want distros to run on it, you have to
provide the DTB for that hardware to mainline+distros.

Remember, there are two ways to view DTB:
  a) It comes from the firmware and you have to live with whatever
     crap the firmware does
  b) It comes from the kernel, must match the kernel, and we don't
     have to tolerate crap in the DTB.

Both make sense, but, IMHO, minimizing the occurrence of 'a' is a
good goal...

Jason

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Sascha Hauer]

On Wed, Oct 23, 2013 at 12:54:35PM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 23, 2013 at 08:30:42PM +0200, Richard Cochran wrote:
> > On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote:
> 
> > > On ARM the package of 'stuff' can very reasonably include dtb. Distro
> > > scripts can package modules+DTB+vmlinuz into something the bootloader
> > > can understand. (The next pain point will be to standardize that)
> > > 
> > > The DTB doesn't have to be 'outside' the distro/kernel to give users a
> > > seamless upgrade experience.
> > 
> > How can a distro possibly provide me a DTB?
> > 
> > They don't know what hardware I am using. Only I know that.
> 
> I'm not sure what you are asking? Treat DTBs like kernel drivers. If
> you make hardware and you want distros to run on it, you have to
> provide the DTB for that hardware to mainline+distros.
> 
> Remember, there are two ways to view DTB:
>   a) It comes from the firmware and you have to live with whatever
>      crap the firmware does
>   b) It comes from the kernel, must match the kernel, and we don't
>      have to tolerate crap in the DTB.

c) It comes from the firmware and is at least good enough to bring up a
   kernel to install a better devicetree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 10:06:24AM +0200, Sascha Hauer wrote:
> On Wed, Oct 23, 2013 at 12:54:35PM -0600, Jason Gunthorpe wrote:
> > On Wed, Oct 23, 2013 at 08:30:42PM +0200, Richard Cochran wrote:
> > > On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote:
> > 
> > > > On ARM the package of 'stuff' can very reasonably include dtb. Distro
> > > > scripts can package modules+DTB+vmlinuz into something the bootloader
> > > > can understand. (The next pain point will be to standardize that)
> > > > 
> > > > The DTB doesn't have to be 'outside' the distro/kernel to give users a
> > > > seamless upgrade experience.
> > > 
> > > How can a distro possibly provide me a DTB?
> > > 
> > > They don't know what hardware I am using. Only I know that.
> > 
> > I'm not sure what you are asking? Treat DTBs like kernel drivers. If
> > you make hardware and you want distros to run on it, you have to
> > provide the DTB for that hardware to mainline+distros.
> > 
> > Remember, there are two ways to view DTB:
> >   a) It comes from the firmware and you have to live with whatever
> >      crap the firmware does
> >   b) It comes from the kernel, must match the kernel, and we don't
> >      have to tolerate crap in the DTB.
> 
> c) It comes from the firmware and is at least good enough to bring up a
>    kernel to install a better devicetree.

That's an interesting new view. And I think that makes a lot of sense
because it matches the product cycle pretty well. Typically I wouldn't
expect an upstream kernel to be fully featured when first shipped in a
product, for all the known reasons, but it should be possible to come
up with stable bindings good enough to perhaps boot to a command-line
prompt and have some way of accessing other files (network, block
device, ...).

Then again you could argue that the bootloader should be able to update
itself (and the DTB while at it).

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/bf466b98/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Sascha Hauer]

On Thu, Oct 24, 2013 at 10:17:33AM +0200, Thierry Reding wrote:
> On Thu, Oct 24, 2013 at 10:06:24AM +0200, Sascha Hauer wrote:
> > On Wed, Oct 23, 2013 at 12:54:35PM -0600, Jason Gunthorpe wrote:
> > > On Wed, Oct 23, 2013 at 08:30:42PM +0200, Richard Cochran wrote:
> > > > On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote:
> > > 
> > > > > On ARM the package of 'stuff' can very reasonably include dtb. Distro
> > > > > scripts can package modules+DTB+vmlinuz into something the bootloader
> > > > > can understand. (The next pain point will be to standardize that)
> > > > > 
> > > > > The DTB doesn't have to be 'outside' the distro/kernel to give users a
> > > > > seamless upgrade experience.
> > > > 
> > > > How can a distro possibly provide me a DTB?
> > > > 
> > > > They don't know what hardware I am using. Only I know that.
> > > 
> > > I'm not sure what you are asking? Treat DTBs like kernel drivers. If
> > > you make hardware and you want distros to run on it, you have to
> > > provide the DTB for that hardware to mainline+distros.
> > > 
> > > Remember, there are two ways to view DTB:
> > >   a) It comes from the firmware and you have to live with whatever
> > >      crap the firmware does
> > >   b) It comes from the kernel, must match the kernel, and we don't
> > >      have to tolerate crap in the DTB.
> > 
> > c) It comes from the firmware and is at least good enough to bring up a
> >    kernel to install a better devicetree.
> 
> That's an interesting new view. And I think that makes a lot of sense
> because it matches the product cycle pretty well. Typically I wouldn't
> expect an upstream kernel to be fully featured when first shipped in a
> product, for all the known reasons, but it should be possible to come
> up with stable bindings good enough to perhaps boot to a command-line
> prompt and have some way of accessing other files (network, block
> device, ...).
> 
> Then again you could argue that the bootloader should be able to update
> itself (and the DTB while at it).

barebox/u-boot usually can do this, but I think distributions can
provide a much better and more consistent user interface. Also it offers
a distribution to provide a way to update the devicetree. Otherwise
the distributions can only say: See your boards documentation how to update
the devicetree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Ben Hutchings]

On Wed, 2013-10-23 at 20:30 +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote:
> 
> > What they want is one vmlinux/z, and a package of 'stuff' that they
> > can assemble a boot image for all hardware out of.
> 
> ...
> 
> > On ARM the package of 'stuff' can very reasonably include dtb. Distro
> > scripts can package modules+DTB+vmlinuz into something the bootloader
> > can understand. (The next pain point will be to standardize that)
> > 
> > The DTB doesn't have to be 'outside' the distro/kernel to give users a
> > seamless upgrade experience.
> 
> How can a distro possibly provide me a DTB?
> 
> They don't know what hardware I am using. Only I know that.

This is what Debian runs when installing a kernel on most ARM systems:
http://sources.debian.net/src/flash-kernel/3.11/functions

It starts by looking up the machine ID (in procfs, but may be overridden
because some board vendors don't set it correctly).  If the machine is
supported using FDT then there is an associated DTB file which will have
been installed with the kernel.  The script copies/appends this to the
appropriate place for the boot loader.

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/158a3751/attachment-0001.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Richard Cochran]

On Thu, Oct 24, 2013 at 12:29:23AM +0100, Ben Hutchings wrote:
> 
> It starts by looking up the machine ID (in procfs, but may be overridden
> because some board vendors don't set it correctly).  If the machine is
> supported using FDT then there is an associated DTB file which will have
> been installed with the kernel.  The script copies/appends this to the
> appropriate place for the boot loader.

And if the ID is not recognized, then what?

Thanks,
Richard

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Ben Hutchings]

On Thu, 2013-10-24 at 09:32 +0200, Richard Cochran wrote:
> On Thu, Oct 24, 2013 at 12:29:23AM +0100, Ben Hutchings wrote:
> > 
> > It starts by looking up the machine ID (in procfs, but may be overridden
> > because some board vendors don't set it correctly).  If the machine is
> > supported using FDT then there is an associated DTB file which will have
> > been installed with the kernel.  The script copies/appends this to the
> > appropriate place for the boot loader.
> 
> And if the ID is not recognized, then what?

Then we have no idea even where to install the kernel, or what wrapper
might be needed, so the boot loader will load it.  Lack of a DTB file is
a small problem; it would be easy to add an option to provide one
outside the kernel package.

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/8c518504/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Andre Heider]

On Wed, Oct 23, 2013 at 8:25 PM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> On Wed, Oct 23, 2013 at 11:01:08AM -0700, Guenter Roeck wrote:
>> Not me. We want to be able to run the same kernel on different hardware,
>> so we would not want to tie the dtb with the kernel image, but
>> the ability to update the dtb on a system when updating the kernel
>> is essential.
>
> This is a really important point.
>
> The complaint from distro-land was they don't want multiple kernel
> packages.
>
> What they want is one vmlinux/z, and a package of 'stuff' that they
> can assemble a boot image for all hardware out of.
>
> On x86 the package of 'stuff' is modules and grub. Distro scripts
> package the modules into the initrd and configure grub based on the
> installed hardware to make a bootable image.
>
> On ARM the package of 'stuff' can very reasonably include dtb. Distro
> scripts can package modules+DTB+vmlinuz into something the bootloader
> can understand. (The next pain point will be to standardize that)

There aready is the Boot Loader Specification [0], and the barebox
bootloader supports these specs.

It does exactly what you describe:
After transferring a cross compiled zImage and the corresponding
devicetree I ran the bundled `install-kernel` tool, pointed it to
those files, and it generated the boot entries as described in the
specs.
Upon next boot, the bootloader automagically found the new entry and
offered to boot it via an menu entry. Like grub ;)

[0] http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/

Regards,
Andre

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Sascha Hauer]

On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 23, 2013 at 10:06:31AM +0200, Richard Cochran wrote:
> > On Tue, Oct 22, 2013 at 11:13:46AM -0600, Jason Gunthorpe wrote:
> > > The question I asked last time this came up, which was left unaswered:
> > > 
> > >  Who does this stable DT ABI vision benifit, and how much is that
> > >  benifit worth?
> > 
> > [Sigh]
> > 
> > I already answered this question more than once. I guess it doesn't
> > hurt to answer it again: It helps the users. Please, don't forget
> > about them.
> 
> I've seen that nebulous answer before. It is awfully vauge. Don't you
> think a better, more excting answer is required to commit the kernel
> community to such a huge amount of work+pain?
> 
> What users? What use cases? Who exactly?
> 
> Crucially: Does the above justify the huge effort on the kernel side?
> 
> I'm a user of the kernel and I'm sitting here saying I don't need
> this.

When you want to create images which run on multiple boards
(Distribution installers?) you depend on the board being able to
describe itself. Currently this is the purpose if the devicetree, so it
really makes sense to put it on the board.

I'm not mandating a 100% stable devicetree and I think the devicetree
in firmware still needs to be exchangable. Anyway, incompatible changes
will cause pain for users who don't ship a devicetree with each kernel.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 10:01:26AM +0200, Sascha Hauer wrote:
> On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
> > On Wed, Oct 23, 2013 at 10:06:31AM +0200, Richard Cochran wrote:
> > > On Tue, Oct 22, 2013 at 11:13:46AM -0600, Jason Gunthorpe wrote:
> > > > The question I asked last time this came up, which was left unaswered:
> > > > 
> > > >  Who does this stable DT ABI vision benifit, and how much is that
> > > >  benifit worth?
> > > 
> > > [Sigh]
> > > 
> > > I already answered this question more than once. I guess it doesn't
> > > hurt to answer it again: It helps the users. Please, don't forget
> > > about them.
> > 
> > I've seen that nebulous answer before. It is awfully vauge. Don't you
> > think a better, more excting answer is required to commit the kernel
> > community to such a huge amount of work+pain?
> > 
> > What users? What use cases? Who exactly?
> > 
> > Crucially: Does the above justify the huge effort on the kernel side?
> > 
> > I'm a user of the kernel and I'm sitting here saying I don't need
> > this.
> 
> When you want to create images which run on multiple boards
> (Distribution installers?) you depend on the board being able to
> describe itself. Currently this is the purpose if the devicetree, so it
> really makes sense to put it on the board.
> 
> I'm not mandating a 100% stable devicetree and I think the devicetree
> in firmware still needs to be exchangable. Anyway, incompatible changes
> will cause pain for users who don't ship a devicetree with each kernel.

Okay. I think we all can agree that we won't find one single answer to
this. But I don't think we need to. That's why I keep saying we should
give users a choice. If somebody wants to use only stable bindings
because they can't or don't want to ship DTB updates along with kernel
updates, then by all means, let give them that option.

At the same time I don't think we should force *everyone* to abide by
the same restrictions. People have said that they don't care about the
bindings being experimental and changing in incompatible ways, and if
they don't mind updating the DTB along with every kernel update, then
why wouldn't we want to give them that option as well?

Every discussion about this topic so far seems to have concluded with
one party saying that we absolutely must have stable bindings and the
other party saying that we don't. We can certainly go on doing that
forever, or we find a compromise that both parties can live with.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/fe198fbe/attachment-0001.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Nicolas Pitre]

On Tue, 22 Oct 2013, Matt Porter wrote:

> DT has many benefits. It would be great to leverage them as long as it
> doesn't interfere with the rate of change and willingness to evolve code
> that's always been the strength of the kernel process. That strength is
> too valuable to trade away for the "DT as ABI" vision.

Amen.  This is the best statement I've read about DT so far.

Having "stable" DT bindings is just a dream.  Experience so far is 
showing that this is neither practical nor realistic.

The unstructured free-for-all approach isn't good either.  Some 
compromise between the two extremes needs to be found.


Nicolas

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Peter Maydell]

On 22 October 2013 18:42, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> Having "stable" DT bindings is just a dream.  Experience so far is
> showing that this is neither practical nor realistic.
>
> The unstructured free-for-all approach isn't good either.  Some
> compromise between the two extremes needs to be found.

While I entirely agree that the concept of DT bindings as stable
ABI is a complete pipe dream, it would be nice if we could have
some suitably restricted parts of it that are defined as stable,
for the benefit of tools like kvmtool and QEMU which construct
device tree blobs from scratch to describe the virtual machine
environment. (That means roughly CPUs, RAM, virtio-mmio
devices and a UART at least.)

As the person who has to maintain the device-tree-writing
code for ARM QEMU, I'd actually trust a carefully limited
guarantee of ABI stability for specific bindings much more
than I do the current airy promises that everything is stable.

thanks
-- PMM

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Nicolas Pitre]

On Tue, 22 Oct 2013, Peter Maydell wrote:

> On 22 October 2013 18:42, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > Having "stable" DT bindings is just a dream.  Experience so far is
> > showing that this is neither practical nor realistic.
> >
> > The unstructured free-for-all approach isn't good either.  Some
> > compromise between the two extremes needs to be found.
> 
> While I entirely agree that the concept of DT bindings as stable
> ABI is a complete pipe dream, it would be nice if we could have
> some suitably restricted parts of it that are defined as stable,
> for the benefit of tools like kvmtool and QEMU which construct
> device tree blobs from scratch to describe the virtual machine
> environment. (That means roughly CPUs, RAM, virtio-mmio
> devices and a UART at least.)

This subset is probably uncontroversial and easy.


Nicolas

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Guenter Roeck]

On Tue, Oct 22, 2013 at 07:21:46PM +0100, Peter Maydell wrote:
> On 22 October 2013 18:42, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > Having "stable" DT bindings is just a dream.  Experience so far is
> > showing that this is neither practical nor realistic.
> >
> > The unstructured free-for-all approach isn't good either.  Some
> > compromise between the two extremes needs to be found.
> 
> While I entirely agree that the concept of DT bindings as stable
> ABI is a complete pipe dream, it would be nice if we could have
> some suitably restricted parts of it that are defined as stable,
> for the benefit of tools like kvmtool and QEMU which construct
> device tree blobs from scratch to describe the virtual machine
> environment. (That means roughly CPUs, RAM, virtio-mmio
> devices and a UART at least.)
> 
> As the person who has to maintain the device-tree-writing
> code for ARM QEMU, I'd actually trust a carefully limited
> guarantee of ABI stability for specific bindings much more
> than I do the current airy promises that everything is stable.
> 

Agreed. I like the idea of Documentation/ABI, though of course
it would help if its contents would move from testing/ to stable/
at some point ;-).

Guenter

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote:
> On Tue, 22 Oct 2013, Matt Porter wrote:
> 
> > DT has many benefits. It would be great to leverage them as long as it
> > doesn't interfere with the rate of change and willingness to evolve code
> > that's always been the strength of the kernel process. That strength is
> > too valuable to trade away for the "DT as ABI" vision.
> 
> Amen.  This is the best statement I've read about DT so far.
> 
> Having "stable" DT bindings is just a dream.  Experience so far is 
> showing that this is neither practical nor realistic.
> 
> The unstructured free-for-all approach isn't good either.  Some 
> compromise between the two extremes needs to be found.

I agree. I think we need an easy way to mark bindings as unstable. One
possible solution that I can think of would be to use some kind of
special marker within the compatible value defined by a binding that
would be used to qualify it as unstable. Perhaps something as simple as
a preceding exclamation mark (!) would do.

	gpio {
		compatible = "!foo-gpio";
	};

The DT core code could look for that when matching device nodes to the
list of compatible values supported by a driver and output a big warning
message to make users aware of the fact that the binding may change. The
driver could use the same marker in the OF device ID table to make it
clear that it implements an experimental binding. Whenever a binding is
deemed stable we can simply remove the marker from both the driver and
the binding, as well as DTS files.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131022/e9ee938b/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Nicolas Pitre]

On Tue, 22 Oct 2013, Thierry Reding wrote:

> On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote:
> > On Tue, 22 Oct 2013, Matt Porter wrote:
> > 
> > > DT has many benefits. It would be great to leverage them as long as it
> > > doesn't interfere with the rate of change and willingness to evolve code
> > > that's always been the strength of the kernel process. That strength is
> > > too valuable to trade away for the "DT as ABI" vision.
> > 
> > Amen.  This is the best statement I've read about DT so far.
> > 
> > Having "stable" DT bindings is just a dream.  Experience so far is 
> > showing that this is neither practical nor realistic.
> > 
> > The unstructured free-for-all approach isn't good either.  Some 
> > compromise between the two extremes needs to be found.
> 
> I agree. I think we need an easy way to mark bindings as unstable.

No, that's not a solution.

It is fairly easy to qualify a small set of bindings as "stable" for 
interoperability purpose (e.g. for qemu/kvm).

But for the vast majority it is very hard to decide when a particular 
binding has reached stability.  By definition, a binding may be 
considered "stable" only after seeing no change for a reasonable period 
of time being tested and used.  So stability may simply not be a 
criterion for upstream merging.

I think it is best to establish any process around DT assuming no strong 
binding stability.  Eventually the DT binding update frequency will 
converge to zero while the kernel will continue to be developed.  But 
the DTB for a particular hardware might have to change from time to 
time.


Nicolas

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Jason Gunthorpe]

On Tue, Oct 22, 2013 at 04:41:23PM -0400, Nicolas Pitre wrote:

> I think it is best to establish any process around DT assuming no strong 
> binding stability.  Eventually the DT binding update frequency will 
> converge to zero while the kernel will continue to be developed.  But 
> the DTB for a particular hardware might have to change from time to 
> time.

This is exactly what happened on our PPC platforms, the bindings
churned for a bit and have been stable now since 2.6.2x something.

I'm hopefully seeing something similar on kirkwood. 3.7 bindings look
nothing like 3.12 bindings, but the 3.12 bindings will run lightly
patched 3.10 and onwards just fine, and there are no pending patches
I've seen that would change that for 3.13..

To me, it is an advantage to DT that it does converge on something
stable, while .c code always gets light churn, no matter where it is.

Jason

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Tue, Oct 22, 2013 at 04:41:23PM -0400, Nicolas Pitre wrote:
> On Tue, 22 Oct 2013, Thierry Reding wrote:
> 
> > On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote:
> > > On Tue, 22 Oct 2013, Matt Porter wrote:
> > > 
> > > > DT has many benefits. It would be great to leverage them as long as it
> > > > doesn't interfere with the rate of change and willingness to evolve code
> > > > that's always been the strength of the kernel process. That strength is
> > > > too valuable to trade away for the "DT as ABI" vision.
> > > 
> > > Amen.  This is the best statement I've read about DT so far.
> > > 
> > > Having "stable" DT bindings is just a dream.  Experience so far is 
> > > showing that this is neither practical nor realistic.
> > > 
> > > The unstructured free-for-all approach isn't good either.  Some 
> > > compromise between the two extremes needs to be found.
> > 
> > I agree. I think we need an easy way to mark bindings as unstable.
> 
> No, that's not a solution.
> 
> It is fairly easy to qualify a small set of bindings as "stable" for 
> interoperability purpose (e.g. for qemu/kvm).
> 
> But for the vast majority it is very hard to decide when a particular 
> binding has reached stability.  By definition, a binding may be 
> considered "stable" only after seeing no change for a reasonable period 
> of time being tested and used.  So stability may simply not be a 
> criterion for upstream merging.

That's not what I was suggesting. I've been arguing all along that it
should be possible to upstream code that relies on unstable bindings
precisely so that we could get some reasonable amount of testing.

Perhaps I should also restate that stable doesn't actually mean "can
never change". If we're only concerned about stable ABI, then the
bindings can still change, *if* they do so in a backwards-compatible
way.

Furthermore, it's also been stated in this thread and elsewhere, that
it's entirely possible to pull something like that off even without
unstable bindings. The only additional requirement is that if a change
is introduced that causes backwards-incompatibility, then we cannot
change the binding, but instead have to add a new one. That's the same
thing we do with syscalls as Russell has said.

It is true that this requires additional code will have to be written.
At the same time it's likely that most of the driver code will still be
possible to be shared between two differing bindings, so perhaps the
result won't even be as catastrophic as people like to make it sound.
We're currently lacking functionality, even trivial things, because of
what? Because we're afraid of making mistakes.

I'm beginning to think that we need to grow a pair.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131023/e60b9347/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Tue, Oct 22, 2013 at 04:41:23PM -0400, Nicolas Pitre wrote:
[...]
> I think it is best to establish any process around DT assuming no strong 
> binding stability.  Eventually the DT binding update frequency will 
> converge to zero while the kernel will continue to be developed.  But 
> the DTB for a particular hardware might have to change from time to 
> time.

A stable ABI certainly has its advantages in my opinion. That's why I'm
convinced that we should try and accomodate for both options. We should
try to come up with a good binding to begin with, as much is clear. But
there's little point in reviewing it to death because any number of
reviewers are unlikely to consider every single possible use-case.

So I propose that we mark such bindings unstable to allow us to put them
through some real world testing in mainline to find out if they work in
practice or not. If they do work reasonably well for a large number of
use-cases, we can decide to mark them stable, at which point they can
only be modified in a backwards-compatible way. That still gives us the
freedom to supersede it by a better binding if that ever becomes
necessary.

The reason why I propose to explicitly mark bindings unstable rather
than the other way around is that I still have hope that we'll reach
some level of stability eventually. It will probably still need some
time because most of us are learning as we go and just don't have the
experience to get things right from the start.

Having some visual marker, such as the exclamation mark I proposed, in
the compatible value is irritating enough to make it clear that it's not
"good". That's an incentive for people to actively work on making it
good or giving it the necessary testing to be able to declare it good.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131023/4cbee42b/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Matt Porter]

On Tue, Oct 22, 2013 at 10:12:29PM +0200, Thierry Reding wrote:
> On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote:
> > On Tue, 22 Oct 2013, Matt Porter wrote:
> > 
> > > DT has many benefits. It would be great to leverage them as long as it
> > > doesn't interfere with the rate of change and willingness to evolve code
> > > that's always been the strength of the kernel process. That strength is
> > > too valuable to trade away for the "DT as ABI" vision.
> > 
> > Amen.  This is the best statement I've read about DT so far.
> > 
> > Having "stable" DT bindings is just a dream.  Experience so far is 
> > showing that this is neither practical nor realistic.
> > 
> > The unstructured free-for-all approach isn't good either.  Some 
> > compromise between the two extremes needs to be found.
> 
> I agree. I think we need an easy way to mark bindings as unstable. One
> possible solution that I can think of would be to use some kind of
> special marker within the compatible value defined by a binding that
> would be used to qualify it as unstable. Perhaps something as simple as
> a preceding exclamation mark (!) would do.
> 
> 	gpio {
> 		compatible = "!foo-gpio";
> 	};
> 
> The DT core code could look for that when matching device nodes to the
> list of compatible values supported by a driver and output a big warning
> message to make users aware of the fact that the binding may change. The
> driver could use the same marker in the OF device ID table to make it
> clear that it implements an experimental binding. Whenever a binding is
> deemed stable we can simply remove the marker from both the driver and
> the binding, as well as DTS files.

>From a technical POV this seems nice.

What does stable mean at this point? DTBs using the stable binding are
forever guaranteed compatibility with newer kernels? We really need to
define *exactly* what this implies for future support. More than likely,
most bindings will choose to stay experimental/testing indefinitely if
stable means a lifetime of ugly backward compatibility hacks.

-Matt

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Tue, Oct 22, 2013 at 04:42:38PM -0400, Matt Porter wrote:
> On Tue, Oct 22, 2013 at 10:12:29PM +0200, Thierry Reding wrote:
> > On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote:
> > > On Tue, 22 Oct 2013, Matt Porter wrote:
> > > 
> > > > DT has many benefits. It would be great to leverage them as long as it
> > > > doesn't interfere with the rate of change and willingness to evolve code
> > > > that's always been the strength of the kernel process. That strength is
> > > > too valuable to trade away for the "DT as ABI" vision.
> > > 
> > > Amen.  This is the best statement I've read about DT so far.
> > > 
> > > Having "stable" DT bindings is just a dream.  Experience so far is 
> > > showing that this is neither practical nor realistic.
> > > 
> > > The unstructured free-for-all approach isn't good either.  Some 
> > > compromise between the two extremes needs to be found.
> > 
> > I agree. I think we need an easy way to mark bindings as unstable. One
> > possible solution that I can think of would be to use some kind of
> > special marker within the compatible value defined by a binding that
> > would be used to qualify it as unstable. Perhaps something as simple as
> > a preceding exclamation mark (!) would do.
> > 
> > 	gpio {
> > 		compatible = "!foo-gpio";
> > 	};
> > 
> > The DT core code could look for that when matching device nodes to the
> > list of compatible values supported by a driver and output a big warning
> > message to make users aware of the fact that the binding may change. The
> > driver could use the same marker in the OF device ID table to make it
> > clear that it implements an experimental binding. Whenever a binding is
> > deemed stable we can simply remove the marker from both the driver and
> > the binding, as well as DTS files.
> 
> From a technical POV this seems nice.
> 
> What does stable mean at this point? DTBs using the stable binding are
> forever guaranteed compatibility with newer kernels? We really need to
> define *exactly* what this implies for future support.

I think there's some broad agreement about what stable bindings entail.
Essentially it means at no point in the future a new kernel is allowed
to stop working with an old binding.

It also entails that bindings can change, but only in ways that don't
break backwards-compatibility.

> More than likely, most bindings will choose to stay experimental/testing
> indefinitely if stable means a lifetime of ugly backward compatibility
> hacks.

Possibly, yes. I'd like to think that having an explicit marker for
unstable bindings would be incentive enough to keep efforts ongoing to
make it stable. Think of it as the DT equivalent of the staging tree.
Nobody wants code to stay in staging forever because, well, it's just
ugly. If we furthermore output a warning at runtime whenever the DT core
encounters a compatible string marked as experimental, then people will
likely be under pressure even more to stabilize.

I've also proposed in another subthread that we could easily add a
Kconfig option that could be used for people to decide whether they want
to use experimental bindings or not. If they don't, then their device
may simply run with degraded functionality. In my opinion that will also
help to get experimental bindings to a more stable state. I expect that
there will always be people that run a "conservative" configuration with
only stable bindings allowed, and if they end up missing out on much of
the functionality there's even more incentive to get bindings tested and
stabilized.

Marking bindings as experimental will also allow us to go and remove a
binding altogether when it has failed to stabilize after some period of
time. I believe there's a similar policy in the staging tree.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131023/0bb657da/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Peter Maydell]

On 23 October 2013 11:04, Thierry Reding <thierry.reding@gmail.com> wrote:
> I think there's some broad agreement about what stable bindings entail.
> Essentially it means at no point in the future a new kernel is allowed
> to stop working with an old binding.
>
> It also entails that bindings can change, but only in ways that don't
> break backwards-compatibility.

In my opinion it should also mean that all the same functionality
you got with the old kernel remains enabled. In other words,
if the old kernel could drive the framebuffer because the framebuffer
was still handled by platform data, then you can't break this when
you introduce a new dt binding for the framebuffer; you have to
cope with "dt blob has no node for this device because it's old".
"The kernel boots but it doesn't find half the devices" is just as broken
as "the kernel doesn't boot" if you're an end user trying to use the
old device tree blob with a new kernel...

thanks
-- PMM

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Matt Porter]

On Wed, Oct 23, 2013 at 12:04:57PM +0200, Thierry Reding wrote:
> On Tue, Oct 22, 2013 at 04:42:38PM -0400, Matt Porter wrote:
> > On Tue, Oct 22, 2013 at 10:12:29PM +0200, Thierry Reding wrote:
> > > On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote:
> > > > On Tue, 22 Oct 2013, Matt Porter wrote:
> > > > 
> > > > > DT has many benefits. It would be great to leverage them as long as it
> > > > > doesn't interfere with the rate of change and willingness to evolve code
> > > > > that's always been the strength of the kernel process. That strength is
> > > > > too valuable to trade away for the "DT as ABI" vision.
> > > > 
> > > > Amen.  This is the best statement I've read about DT so far.
> > > > 
> > > > Having "stable" DT bindings is just a dream.  Experience so far is 
> > > > showing that this is neither practical nor realistic.
> > > > 
> > > > The unstructured free-for-all approach isn't good either.  Some 
> > > > compromise between the two extremes needs to be found.
> > > 
> > > I agree. I think we need an easy way to mark bindings as unstable. One
> > > possible solution that I can think of would be to use some kind of
> > > special marker within the compatible value defined by a binding that
> > > would be used to qualify it as unstable. Perhaps something as simple as
> > > a preceding exclamation mark (!) would do.
> > > 
> > > 	gpio {
> > > 		compatible = "!foo-gpio";
> > > 	};
> > > 
> > > The DT core code could look for that when matching device nodes to the
> > > list of compatible values supported by a driver and output a big warning
> > > message to make users aware of the fact that the binding may change. The
> > > driver could use the same marker in the OF device ID table to make it
> > > clear that it implements an experimental binding. Whenever a binding is
> > > deemed stable we can simply remove the marker from both the driver and
> > > the binding, as well as DTS files.
> > 
> > From a technical POV this seems nice.
> > 
> > What does stable mean at this point? DTBs using the stable binding are
> > forever guaranteed compatibility with newer kernels? We really need to
> > define *exactly* what this implies for future support.
> 
> I think there's some broad agreement about what stable bindings entail.
> Essentially it means at no point in the future a new kernel is allowed
> to stop working with an old binding.
> 
> It also entails that bindings can change, but only in ways that don't
> break backwards-compatibility.

Agreed. This will have to be documented in the kernel going forward. Not
buried in 4 different threads where everybody has a different opinion.

> > More than likely, most bindings will choose to stay experimental/testing
> > indefinitely if stable means a lifetime of ugly backward compatibility
> > hacks.
> 
> Possibly, yes. I'd like to think that having an explicit marker for
> unstable bindings would be incentive enough to keep efforts ongoing to
> make it stable. Think of it as the DT equivalent of the staging tree.
> Nobody wants code to stay in staging forever because, well, it's just
> ugly. If we furthermore output a warning at runtime whenever the DT core
> encounters a compatible string marked as experimental, then people will
> likely be under pressure even more to stabilize.
> 
> I've also proposed in another subthread that we could easily add a
> Kconfig option that could be used for people to decide whether they want
> to use experimental bindings or not. If they don't, then their device
> may simply run with degraded functionality. In my opinion that will also
> help to get experimental bindings to a more stable state. I expect that
> there will always be people that run a "conservative" configuration with
> only stable bindings allowed, and if they end up missing out on much of
> the functionality there's even more incentive to get bindings tested and
> stabilized.

I can imagine situations where we have a trivial stable binding for the
"enterprise" users but then a feature rich experimental binding for the
same class of devices. The latter will result from all the vendors
pumping out new SoCs with previously unthought of configurations. This
does seems to allow both camps to be happy.

> Marking bindings as experimental will also allow us to go and remove a
> binding altogether when it has failed to stabilize after some period of
> time. I believe there's a similar policy in the staging tree.

I like it...as long as this is coupled with a process of DT binding
review that allows the experimental bindings to evolve over time just
like kernel frameworks.

The use case I think of is a new SoC entering the kernel. At first you
get your basics going and upstream: uart, mmc, etc. No common clock
driver and no PMU driver, those may be handled in the bootloader at
first. No need to have clock and regulator support in the binding at
this point. Then you incrementally add clock support and the properties
for the experimental bindings that are consumers of clocks. Same for
PMU/regulator support.

No more "we know everything for this entire SoC on day 0" for bindings.

-Matt

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[David Brown]

On Sun, Oct 20, 2013 at 09:00:08PM -0400, Nicolas Pitre wrote:

>The hardware support in the kernel, on the other hand, can be improved
>incrementally with time.  It doesn't matter if it is not optimal at
>first. It can be revisited, optimized, reviewed, and sometimes even
>redesigned.  And only when it reaches maturity would be the time to use
>the experience from the kernel development and make some firmware out of
>it.  But what would be the point then?

One other point that is kind of overlooked, but I think is important,
is that firmware will tend to be closed source.  The advantages we get
to having drivers shared in the kernel would be gone, and we would end
up with multiple implementations of essentially the same driver,
especially with reference hardware blocks that get used in different
platforms.

David

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

ARM topic: Is DT on ARM the solution, or is there something better?

[Russell King - ARM Linux]

On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
> The only thing we've really moved out of the kernel is the exact IDs of
> which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the
> simple stuff not the hard stuff. The code hasn't really been simplified
> by DT - if anything, it's more complicated since we now have to parse
> those values from DT rather than putting them into simple data-structures.

Here's my random thoughts this evening on DT, orientated mostly on a
problem area I've been paying attention to recently.

In some ways, DT has made things much harder.  I don't know whether
you've taken a look at DRM and the various drivers we have under there,
it's quite a mess of unreliable code which is trying to bend the DRM
card based model to a DT based multi-device component based description
with lots of sub-drivers.

What DRM currently expects is a certain initialisation order: the main
drm_device structure is created by the DRM code, and then supplied to
the DRM driver to populate all the different parts of the "DRM card".

Once all parts of the card have been setup (the CRTCs, encoders,
connectors, etc) then some helpers can be initialised.  Once the
helpers have been initialised, the "dimensions" of the "DRM card"
become rather fixed until the helper is torn down.

The problem is this: if you have a multi-driver based card, there is
no way to prevent any of those sub-drivers from being unbound from
their drivers at any time.  module refcounts don't save you from this.
Meanwhile, (at the moment) you can't half-tear down a "DRM card" and
have it still in a usable state.  The internals just don't allow for
it at present.

Yes, work can be put in to solve this problem, but it's being solved
because of a desire to bend the subsystem to the DT way of doing things.
That may or may not be the best idea.  However, what I do know is that
there is now great pressure to "bend stuff so that it works with DT
at all costs".  Evidence is the Exynos driver and the imx-drm driver.

Now, the flip side to this is that some DRM solutions include an I2C
device, which is itself a separate driver, and would appear to suffer
from this same problem.  This is handled via the drm_encoder_slave
infrastructure.  As it currently is written (ignoring DT) it get
around the problem by not actually using the driver model "properly".
If it were to, it would run into this same problem.

How would we sort this out pre-DT?  We'd pass a chunk of platform data
into a driver to describe the various options: eg, whether we wanted
HDMI output, the I2C bus details of the DDC bus, etc., which results
in a simpler solution - though traditionally a driver specific solution.

However, "driver specific solution" is bad - always has been.  What was
missed is that the platform datas should never have been specific to
any particular device.  They should have been class specific.  I tried
to do that with flash_platform_data for example - some people got the
idea, but the vast majority didn't.

What is clear to me is that there is no panacea "one size fits all"
approach to the problem of device driver bindings and turning them into
generic drivers.  Everyone has their own pet ideas and solutions to
this.  Some favour DT.  Others favour other solutions.

At the end of the day, the question should be - what is the easiest
solution.  In the case of DRM, it may well be that the easiest solution
is to have a translation layer which presents a DT multi-node
description (note the change in terminology: multi-node not multi-device)
to DRM as platform data so that DRM can preserve its "single card"
solution.  Or whatever other translation layer is necessary for whatever
solution is chosen in the future.

There's much much more to the DRM vs DT problem than the above.  In
short:
- we have several driver specific solutions to this same problem
- on the balance of probabilities, their solutions are buggy in some
  way, some more buggy than others.

I have one DRM driver which I've recently submitted to David Airlie
which I have *not* implemented DT support for and that is because I
don't want to solve this same problem in another driver specific way.
I'd rather the driver wasn't directly supportable by DT until there's
proper work in infrastructure than to create yet another driver
specific solution - or the DT mess is dealt with outside the main
driver.  (I believe that has already been done by Sebastian...)

Other thoughts on DT... it's a pain in the backside as it's far too
easy to make a subtle mistake in a DT source file and have it "build"
to a blob. You can then spend hours trying to debug why something isn't
working, and it's very simply because you typo'd something.  A recent
example:

	pintctrl-0 = <...>;

and then you start wondering why aren't I getting signals out from the
pins you want, and you start chasing around trying to find out if its
something that you haven't thought of, whether some setting in the
pin settings is wrong or whatever.  You completely fail to notice the
additional 't' for hours and hours.  Eventually, you start pasting it
onto IRC and at that point you spot the error.

You may laugh at that, but that's exactly what has happened - all
because the DT compiler is freeform - provided the strings look okay
to it, that's all it cares about.  Whether the description is correct
for the device or not is outside of its concern.

I'm pretty certain that I won't be the only one who has gone through
this - and I'm probably not going to be the last.

We already know that "board firmware" has a tendency to be buggy.  Well,
the DT compiler as it stands today does nothing what so ever to help
people make sure that what they _think_ they're typing into the DT
file is actually correct.  All the time that we're have a tool which
allows typos through we're going to encounter bugs like this.  Not a
problem when DT is shipped with the kernel, but when it isn't, what
then...

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Guenter Roeck]

On 10/20/2013 04:11 PM, Russell King - ARM Linux wrote:
> On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
>> The only thing we've really moved out of the kernel is the exact IDs of
>> which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the
>> simple stuff not the hard stuff. The code hasn't really been simplified
>> by DT - if anything, it's more complicated since we now have to parse
>> those values from DT rather than putting them into simple data-structures.
>
> Here's my random thoughts this evening on DT, orientated mostly on a
> problem area I've been paying attention to recently.
>
> In some ways, DT has made things much harder.  I don't know whether

On the other side, DT has made some things much simpler.

Problem case: Chip A's interrupt pin is connected to gpio pin of chip B.
Chip B's interrupt pin is connected to a gpio pin on chip C. Chip C's
interrupt pin is connected to the interrupt controller. Chips B and C
are multi-function FPGAs. Exact gpio pins used vary from board to board.

With DT, this relationship is easy to describe, and none of the chip drivers
really needs to know what is connected to what. Without DT, it would be
much more complex.

Guenter

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Russell King - ARM Linux]

On Sun, Oct 20, 2013 at 04:44:57PM -0700, Guenter Roeck wrote:
> On 10/20/2013 04:11 PM, Russell King - ARM Linux wrote:
>> On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
>>> The only thing we've really moved out of the kernel is the exact IDs of
>>> which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the
>>> simple stuff not the hard stuff. The code hasn't really been simplified
>>> by DT - if anything, it's more complicated since we now have to parse
>>> those values from DT rather than putting them into simple data-structures.
>>
>> Here's my random thoughts this evening on DT, orientated mostly on a
>> problem area I've been paying attention to recently.
>>
>> In some ways, DT has made things much harder.  I don't know whether
>
> On the other side, DT has made some things much simpler.

Yes, it's made simple things easier, but note the problem I also
pointed out towards the end of the email (I assume you stopped reading
it towards the end?)

DT also makes it much easier to make mistakes which take hours to find.

DT has also made hard things much harder to solve - and because they're
hard to solve people are hacking around the problem creating their own
custom solutions, thereby making the problem much worse to solve in the
future.  That's a disease - "we must have DT and sod everything else"
is a very bad thing to do.  The bad news is, it *is* happening.

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Guenter Roeck]

On 10/20/2013 04:51 PM, Russell King - ARM Linux wrote:
> On Sun, Oct 20, 2013 at 04:44:57PM -0700, Guenter Roeck wrote:
>> On 10/20/2013 04:11 PM, Russell King - ARM Linux wrote:
>>> On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
>>>> The only thing we've really moved out of the kernel is the exact IDs of
>>>> which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the
>>>> simple stuff not the hard stuff. The code hasn't really been simplified
>>>> by DT - if anything, it's more complicated since we now have to parse
>>>> those values from DT rather than putting them into simple data-structures.
>>>
>>> Here's my random thoughts this evening on DT, orientated mostly on a
>>> problem area I've been paying attention to recently.
>>>
>>> In some ways, DT has made things much harder.  I don't know whether
>>
>> On the other side, DT has made some things much simpler.
>
> Yes, it's made simple things easier, but note the problem I also
> pointed out towards the end of the email (I assume you stopped reading
> it towards the end?)
>

No, not really.

> DT also makes it much easier to make mistakes which take hours to find.
>

Yes, I would agree. Guess to solve this kind of problem you might need
some kind of semantics checker, one that knows all existing properties.

> DT has also made hard things much harder to solve - and because they're
> hard to solve people are hacking around the problem creating their own
> custom solutions, thereby making the problem much worse to solve in the
> future.  That's a disease - "we must have DT and sod everything else"
> is a very bad thing to do.  The bad news is, it *is* happening.
>

For the DRM problem you described in your original e-mail, frankly I don't
have an idea how to solve it. So I'd rather not even try. For the semantics
checking problems, maybe someone with some free time will step up and write
one ... if that is even feasible. But even then I suspect it will always be
easy to make mistakes in property values.

Guenter

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Stephen Warren]

On 10/21/2013 12:44 AM, Guenter Roeck wrote:
> On 10/20/2013 04:11 PM, Russell King - ARM Linux wrote:
>> On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
>>> The only thing we've really moved out of the kernel is the exact IDs of
>>> which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the
>>> simple stuff not the hard stuff. The code hasn't really been simplified
>>> by DT - if anything, it's more complicated since we now have to parse
>>> those values from DT rather than putting them into simple
>>> data-structures.
>>
>> Here's my random thoughts this evening on DT, orientated mostly on a
>> problem area I've been paying attention to recently.
>>
>> In some ways, DT has made things much harder.  I don't know whether
> 
> On the other side, DT has made some things much simpler.
> 
> Problem case: Chip A's interrupt pin is connected to gpio pin of chip B.
> Chip B's interrupt pin is connected to a gpio pin on chip C. Chip C's
> interrupt pin is connected to the interrupt controller. Chips B and C
> are multi-function FPGAs. Exact gpio pins used vary from board to board.
> 
> With DT, this relationship is easy to describe, and none of the chip
> drivers
> really needs to know what is connected to what. Without DT, it would be
> much more complex.

I thought that was very easy with board files. For every chip that gets
instantiated, you tell it which base IRQ ID to use. For every chip that
outputs a IRQ, you tell it which IRQ ID that signal is, simply by adding
the recipient chip's IRQ base and an offset. That seems very simple. If
you don't want to add the base/offset together, we could always have
invented some lookup table similar to what regulators had, and pinctrl
has now, which says for each (device name, IRQ name/number) output,
here's the (device name, IRQ name/number) of the associated input.

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Oct 21, 2013 at 09:05:44PM +0100, Stephen Warren wrote:
> On 10/21/2013 12:44 AM, Guenter Roeck wrote:
> > On 10/20/2013 04:11 PM, Russell King - ARM Linux wrote:
> >> On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
> >>> The only thing we've really moved out of the kernel is the exact IDs of
> >>> which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the
> >>> simple stuff not the hard stuff. The code hasn't really been simplified
> >>> by DT - if anything, it's more complicated since we now have to parse
> >>> those values from DT rather than putting them into simple
> >>> data-structures.
> >>
> >> Here's my random thoughts this evening on DT, orientated mostly on a
> >> problem area I've been paying attention to recently.
> >>
> >> In some ways, DT has made things much harder.  I don't know whether
> > 
> > On the other side, DT has made some things much simpler.
> > 
> > Problem case: Chip A's interrupt pin is connected to gpio pin of chip B.
> > Chip B's interrupt pin is connected to a gpio pin on chip C. Chip C's
> > interrupt pin is connected to the interrupt controller. Chips B and C
> > are multi-function FPGAs. Exact gpio pins used vary from board to board.
> > 
> > With DT, this relationship is easy to describe, and none of the chip
> > drivers
> > really needs to know what is connected to what. Without DT, it would be
> > much more complex.
> 
> I thought that was very easy with board files. For every chip that gets
> instantiated, you tell it which base IRQ ID to use. For every chip that
> outputs a IRQ, you tell it which IRQ ID that signal is, simply by adding
> the recipient chip's IRQ base and an offset. That seems very simple. If
> you don't want to add the base/offset together, we could always have
> invented some lookup table similar to what regulators had, and pinctrl
> has now, which says for each (device name, IRQ name/number) output,
> here's the (device name, IRQ name/number) of the associated input.

Well, DT has certainly increased the level of dynamicity within the
kernel. I for one consider not having to rely on a fixed IRQ or GPIO
base per-chip a good thing. Deferred probing is a very powerful yet
extremely simple tool that was created as part of the DT conversion
effort. There is obviously much more that can be done, but I think
that we have come a long way.

But as you said, that could all have been done even with board files.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131022/148594b1/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Sascha Hauer]

On Mon, Oct 21, 2013 at 12:11:34AM +0100, Russell King - ARM Linux wrote:
> On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
> > The only thing we've really moved out of the kernel is the exact IDs of
> > which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the
> > simple stuff not the hard stuff. The code hasn't really been simplified
> > by DT - if anything, it's more complicated since we now have to parse
> > those values from DT rather than putting them into simple data-structures.
> 
> Here's my random thoughts this evening on DT, orientated mostly on a
> problem area I've been paying attention to recently.
> 
> In some ways, DT has made things much harder.  I don't know whether
> you've taken a look at DRM and the various drivers we have under there,
> it's quite a mess of unreliable code which is trying to bend the DRM
> card based model to a DT based multi-device component based description
> with lots of sub-drivers.
> 
> What DRM currently expects is a certain initialisation order: the main
> drm_device structure is created by the DRM code, and then supplied to
> the DRM driver to populate all the different parts of the "DRM card".
> 
> Once all parts of the card have been setup (the CRTCs, encoders,
> connectors, etc) then some helpers can be initialised.  Once the
> helpers have been initialised, the "dimensions" of the "DRM card"
> become rather fixed until the helper is torn down.
> 
> The problem is this: if you have a multi-driver based card, there is
> no way to prevent any of those sub-drivers from being unbound from
> their drivers at any time.  module refcounts don't save you from this.
> Meanwhile, (at the moment) you can't half-tear down a "DRM card" and
> have it still in a usable state.  The internals just don't allow for
> it at present.
> 
> Yes, work can be put in to solve this problem, but it's being solved
> because of a desire to bend the subsystem to the DT way of doing things.
> That may or may not be the best idea.  However, what I do know is that
> there is now great pressure to "bend stuff so that it works with DT
> at all costs".  Evidence is the Exynos driver and the imx-drm driver.

In fact it was the other way round. We modeled the IPU devicetree
binding after the hardware and bended the driver around it. The DRM
single-card model is the limiting fator here, not the devicetree.

> 
> Now, the flip side to this is that some DRM solutions include an I2C
> device, which is itself a separate driver, and would appear to suffer
> from this same problem.  This is handled via the drm_encoder_slave
> infrastructure.  As it currently is written (ignoring DT) it get
> around the problem by not actually using the driver model "properly".
> If it were to, it would run into this same problem.

Indeed. The drm_encoder_slave stuff depends on the I2C bus driver being
compiled into the kernel. Once the I2C bus driver is modular and the DRM
driver is not it won't work anymore. The drm_encoder_slave only works
properly for PCI/AGP cards which have their own I2C bus master on the
card (which is implemented by the same monolithic DRM driver).

> 
> How would we sort this out pre-DT?  We'd pass a chunk of platform data
> into a driver to describe the various options: eg, whether we wanted
> HDMI output, the I2C bus details of the DDC bus, etc., which results
> in a simpler solution - though traditionally a driver specific solution.
> 
> However, "driver specific solution" is bad - always has been.  What was
> missed is that the platform datas should never have been specific to
> any particular device.  They should have been class specific.  I tried
> to do that with flash_platform_data for example - some people got the
> idea, but the vast majority didn't.

The problem probably was that most people (including me) were simply not
aware of the idea to have class specific platform data.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

ARM topic: Is DT on ARM the solution, or is there something better?

[Russell King - ARM Linux]

On Mon, Oct 21, 2013 at 10:32:42AM +0200, Sascha Hauer wrote:
> On Mon, Oct 21, 2013 at 12:11:34AM +0100, Russell King - ARM Linux wrote:
> > On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
> > > The only thing we've really moved out of the kernel is the exact IDs of
> > > which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the
> > > simple stuff not the hard stuff. The code hasn't really been simplified
> > > by DT - if anything, it's more complicated since we now have to parse
> > > those values from DT rather than putting them into simple data-structures.
> > 
> > Here's my random thoughts this evening on DT, orientated mostly on a
> > problem area I've been paying attention to recently.
> > 
> > In some ways, DT has made things much harder.  I don't know whether
> > you've taken a look at DRM and the various drivers we have under there,
> > it's quite a mess of unreliable code which is trying to bend the DRM
> > card based model to a DT based multi-device component based description
> > with lots of sub-drivers.
> > 
> > What DRM currently expects is a certain initialisation order: the main
> > drm_device structure is created by the DRM code, and then supplied to
> > the DRM driver to populate all the different parts of the "DRM card".
> > 
> > Once all parts of the card have been setup (the CRTCs, encoders,
> > connectors, etc) then some helpers can be initialised.  Once the
> > helpers have been initialised, the "dimensions" of the "DRM card"
> > become rather fixed until the helper is torn down.
> > 
> > The problem is this: if you have a multi-driver based card, there is
> > no way to prevent any of those sub-drivers from being unbound from
> > their drivers at any time.  module refcounts don't save you from this.
> > Meanwhile, (at the moment) you can't half-tear down a "DRM card" and
> > have it still in a usable state.  The internals just don't allow for
> > it at present.
> > 
> > Yes, work can be put in to solve this problem, but it's being solved
> > because of a desire to bend the subsystem to the DT way of doing things.
> > That may or may not be the best idea.  However, what I do know is that
> > there is now great pressure to "bend stuff so that it works with DT
> > at all costs".  Evidence is the Exynos driver and the imx-drm driver.
> 
> In fact it was the other way round. We modeled the IPU devicetree
> binding after the hardware and bended the driver around it. The DRM
> single-card model is the limiting fator here, not the devicetree.

There are several points which I think you failed to understand:

1. DRM vs device tree is an incompatibility.
2. Trying to bend DRM to DT with independent driver solutions such as
   the abomination that is imx-drm creates its own set of problems.

If a subsystem doesn't work well with DT, then the choices are either:

(a) don't use DT with the subsystem
(b) fix the subsystem

The choices do not include:

(c) creating an abomination that is fragile, and is trivially easy to
oops the kernel.

This comes back to the root problem I'm trying to highlight: we are not
trying to strive for DT forsaking everything else.  If moving to DT
means we give up with proper code design, then we've quite literally
lost the plot.

Honestly, I don't see imx-drm ever moving out of drivers/staging except
by deletion or being rewritten.

ARM topic: Is DT on ARM the solution, or is there something better?

[Sascha Hauer]

On Mon, Oct 21, 2013 at 09:48:54AM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 21, 2013 at 10:32:42AM +0200, Sascha Hauer wrote:
> > On Mon, Oct 21, 2013 at 12:11:34AM +0100, Russell King - ARM Linux wrote:
> > 
> > In fact it was the other way round. We modeled the IPU devicetree
> > binding after the hardware and bended the driver around it. The DRM
> > single-card model is the limiting fator here, not the devicetree.
> 
> There are several points which I think you failed to understand:
> 
> 1. DRM vs device tree is an incompatibility.

I do understand that.

> 2. Trying to bend DRM to DT with independent driver solutions such as
>    the abomination that is imx-drm creates its own set of problems.

I also see this.

> 
> If a subsystem doesn't work well with DT, then the choices are either:
> 
> (a) don't use DT with the subsystem

The underlying problem has nothing to do with DT. Multi component
hardware does exist and won't vanish when we stop using DT.

> (b) fix the subsystem

I'd love to do that. Step one to this seems to be to increase the
awareness that there's something wrong with DRM.

> 
> The choices do not include:
> 
> (c) creating an abomination that is fragile, and is trivially easy to
> oops the kernel.
> 
> This comes back to the root problem I'm trying to highlight: we are not
> trying to strive for DT forsaking everything else.  If moving to DT
> means we give up with proper code design, then we've quite literally
> lost the plot.

The imx-drm driver has problems, but I don't see how they can be solved
by not using DT.

I think imx-drm shouldn't be used as a vehicle to show that DT is a
failure.

If you have a better vision how imx-drm can be implemented without
getting crazy I'd love to hear about it. Please also think about the two
IPUs the i.MX6 has, the single one on i.MX5, parallel displays, HDMI
displays, LVDS displays, VGA encoder on i.MX53, external I2C slave
encoders,...

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

ARM topic: Is DT on ARM the solution, or is there something better?

[Russell King - ARM Linux]

On Mon, Oct 21, 2013 at 11:27:30AM +0200, Sascha Hauer wrote:
> If you have a better vision how imx-drm can be implemented without
> getting crazy I'd love to hear about it. Please also think about the two
> IPUs the i.MX6 has, the single one on i.MX5, parallel displays, HDMI
> displays, LVDS displays, VGA encoder on i.MX53, external I2C slave
> encoders,...

Well, the multi-driver solution is just too fragile: the problem
with it is you can never be sure when all the drivers have definitely
finished initialising.  This problem is made much worse should one of
them use deferred probing.

To put it another way - with a multi-driver solution, there is no
definite point you can say "okay, we got everything".

So, as long as a subsystem contains something that needs to be done
once everything is known (such as initialising the fb_helper), there
is a fundamental disconnect between a multi-driver solution and the
subsystem.  To put it another way, a multi-driver solution should
not be used.

The I2C slave encoder problem doesn't really come into this because
it's not really a separate driver - yes, it's modelled by a separate
driver but when analysed, it's not really using the driver model at
all.  The driver model is only really used to locate the required
driver.

Conceptually, the imx-drm hardware is not much different from the the
Armada/Dove display hardware: it too has the problem that there
can be several CRTCs and several display outputs.  In some ways it's
worse there because there isn't the same level of integration found
on i.MX - it just has VGA and parallel outputs.  If you want something
else, you need to stick a chip on the output.  In the case of HDMI,
that's a TDA998x device.

For that, I've opted not to even _try_ to come up with a DT solution
at present, because I know that trying to come up something that
represents the hardware will not work properly with DRM.  That's
exactly what everyone else should have done.

Then the effort would not be spent trying to come up with individual
DT solutions and driver specific hacks, but instead would be spent on
trying to sort out the DRM core to allow it to handle separately
pluggable connectors, encoders and crtcs.

I have been getting is pressure to come up with a fudge for the Armada
DRM to make it work with DT just like everything else: there was even
suggestions that the driver should not be merged because it doesn't
support DT, and as everyone is going DT, it would have very few users.
Quite rightfully, I refuse to fudge the driver and create yet another
abomination.  Thankfully, the subsystem maintainers agree that this
is something that can be worked on independently: it should be, it's
not a specific driver problem, it's a subsystem problem and it needs
solving for everyone.

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Oct 21, 2013 at 10:57:57AM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 21, 2013 at 11:27:30AM +0200, Sascha Hauer wrote:
> > If you have a better vision how imx-drm can be implemented without
> > getting crazy I'd love to hear about it. Please also think about the two
> > IPUs the i.MX6 has, the single one on i.MX5, parallel displays, HDMI
> > displays, LVDS displays, VGA encoder on i.MX53, external I2C slave
> > encoders,...
> 
> Well, the multi-driver solution is just too fragile: the problem
> with it is you can never be sure when all the drivers have definitely
> finished initialising.  This problem is made much worse should one of
> them use deferred probing.
> 
> To put it another way - with a multi-driver solution, there is no
> definite point you can say "okay, we got everything".
> 
> So, as long as a subsystem contains something that needs to be done
> once everything is known (such as initialising the fb_helper), there
> is a fundamental disconnect between a multi-driver solution and the
> subsystem.  To put it another way, a multi-driver solution should
> not be used.

Multi-driver with DRM has worked pretty well for Tegra. Essentially what
I created was a sort of abstraction layer between DRM and the individual
drivers so that each driver can register itself with that layer. Once it
has been determined that all drivers have been probed, that glue layer
can load the DRM driver and call back into the sub-drivers to register
their respective components with DRM.

That even works fairly nicely with deferred probing. Note that the code
currently in Linus' tree has some issues, but I've reworked it since in
linux-next and the final result isn't all that bad. I've even attempted
to make it somewhat generic so that it could potentially be reused by
other drivers. It's not reusable as-is, but perhaps it can be further
improved.

I agree that hotpluggability within DRM might have made things easier,
but it would likely also have made the core more complex. Furthermore
there simply was no need for DRM to provide that kind of flexibility,
simple because no driver has had that need so far. Quite a few ARM SoC
drivers have appeared lately, and hopefully that'll provide more of an
incentive to evolve DRM as needed, but I don't think we can hold it
against anyone that they haven't provided us with the ideal subsystem.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131021/fa70d69c/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Russell King - ARM Linux]

On Mon, Oct 21, 2013 at 12:24:49PM +0200, Thierry Reding wrote:
> Multi-driver with DRM has worked pretty well for Tegra. Essentially what
> I created was a sort of abstraction layer between DRM and the individual
> drivers so that each driver can register itself with that layer. Once it
> has been determined that all drivers have been probed, that glue layer
> can load the DRM driver and call back into the sub-drivers to register
> their respective components with DRM.
> 
> That even works fairly nicely with deferred probing. Note that the code
> currently in Linus' tree has some issues, but I've reworked it since in
> linux-next and the final result isn't all that bad. I've even attempted
> to make it somewhat generic so that it could potentially be reused by
> other drivers. It's not reusable as-is, but perhaps it can be further
> improved.
> 
> I agree that hotpluggability within DRM might have made things easier,
> but it would likely also have made the core more complex. Furthermore
> there simply was no need for DRM to provide that kind of flexibility,
> simple because no driver has had that need so far. Quite a few ARM SoC
> drivers have appeared lately, and hopefully that'll provide more of an
> incentive to evolve DRM as needed, but I don't think we can hold it
> against anyone that they haven't provided us with the ideal subsystem.

Right, so how do you feel about rewriting it again so that everyone
can benefit from it instead of it being specific to just Tegra? :)

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Oct 21, 2013 at 11:30:14AM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 21, 2013 at 12:24:49PM +0200, Thierry Reding wrote:
> > Multi-driver with DRM has worked pretty well for Tegra. Essentially what
> > I created was a sort of abstraction layer between DRM and the individual
> > drivers so that each driver can register itself with that layer. Once it
> > has been determined that all drivers have been probed, that glue layer
> > can load the DRM driver and call back into the sub-drivers to register
> > their respective components with DRM.
> > 
> > That even works fairly nicely with deferred probing. Note that the code
> > currently in Linus' tree has some issues, but I've reworked it since in
> > linux-next and the final result isn't all that bad. I've even attempted
> > to make it somewhat generic so that it could potentially be reused by
> > other drivers. It's not reusable as-is, but perhaps it can be further
> > improved.
> > 
> > I agree that hotpluggability within DRM might have made things easier,
> > but it would likely also have made the core more complex. Furthermore
> > there simply was no need for DRM to provide that kind of flexibility,
> > simple because no driver has had that need so far. Quite a few ARM SoC
> > drivers have appeared lately, and hopefully that'll provide more of an
> > incentive to evolve DRM as needed, but I don't think we can hold it
> > against anyone that they haven't provided us with the ideal subsystem.
> 
> Right, so how do you feel about rewriting it again so that everyone
> can benefit from it instead of it being specific to just Tegra? :)

You are surely aware that by general concensus the responsibility for a
generic implementation falls to the third person to reimplement it from
scratch, which in this case wasn't me for a change... =)

But seriously, I have that somewhere on my TODO list, it's just not top
priority at the moment. I'm also not familiar with what the requirements
are for other SoCs, so I don't have much of an idea what specific areas
require rework.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131021/d8ff1dcf/attachment-0001.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Mark Brown]

On Mon, Oct 21, 2013 at 12:24:49PM +0200, Thierry Reding wrote:

> Multi-driver with DRM has worked pretty well for Tegra. Essentially what
> I created was a sort of abstraction layer between DRM and the individual
> drivers so that each driver can register itself with that layer. Once it
> has been determined that all drivers have been probed, that glue layer
> can load the DRM driver and call back into the sub-drivers to register
> their respective components with DRM.

This is pretty much what ASoC always did, it's been working out
reasonably well.

We do still don't really handle what happens if someone tries to unbind
one of the supporting devices while things are in use sensibly.  Since
generally this would involve someone manually removing the driver for
pracical purposes we're OK now but it's an issue and we probably will
have to deal with systems that trigger this for sensible reasons at some
point.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131022/ea081a26/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Stephen Warren]

On 10/21/2013 10:57 AM, Russell King - ARM Linux wrote:
> On Mon, Oct 21, 2013 at 11:27:30AM +0200, Sascha Hauer wrote:
>> If you have a better vision how imx-drm can be implemented without
>> getting crazy I'd love to hear about it. Please also think about the two
>> IPUs the i.MX6 has, the single one on i.MX5, parallel displays, HDMI
>> displays, LVDS displays, VGA encoder on i.MX53, external I2C slave
>> encoders,...
> 
> Well, the multi-driver solution is just too fragile: the problem
> with it is you can never be sure when all the drivers have definitely
> finished initialising.  This problem is made much worse should one of
> them use deferred probing.

ASoC has a very similar structure; e.g. an I2S controller and DMA
controller within the SoC, an external audio CODEC, and an I2C (or SPI?)
controller to communicate with the CODEC, all make up a "sound card".
ASoC solves this by having a "sound card" device to represent the
aggregation. This translates into a DT node for the "sound card". That
node is slightly virtual in that in some ways it doesn't really
represent specific HW on the board. Yet, in other ways it really does;
at the very least it represents the PCB wiring between all those
different components that it aggregates and the intent of the existence
of all those components in HW to create a sound output feature. Perhaps
something similar can be done for DRM?

ARM topic: Is DT on ARM the solution, or is there something better?

[Sascha Hauer]

On Mon, Oct 21, 2013 at 10:57:57AM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 21, 2013 at 11:27:30AM +0200, Sascha Hauer wrote:
> > If you have a better vision how imx-drm can be implemented without
> > getting crazy I'd love to hear about it. Please also think about the two
> > IPUs the i.MX6 has, the single one on i.MX5, parallel displays, HDMI
> > displays, LVDS displays, VGA encoder on i.MX53, external I2C slave
> > encoders,...
> 
> Well, the multi-driver solution is just too fragile: the problem
> with it is you can never be sure when all the drivers have definitely
> finished initialising.  This problem is made much worse should one of
> them use deferred probing.
> 
> To put it another way - with a multi-driver solution, there is no
> definite point you can say "okay, we got everything".
> 
> So, as long as a subsystem contains something that needs to be done
> once everything is known (such as initialising the fb_helper), there
> is a fundamental disconnect between a multi-driver solution and the
> subsystem.  To put it another way, a multi-driver solution should
> not be used.
> 
> The I2C slave encoder problem doesn't really come into this because
> it's not really a separate driver - yes, it's modelled by a separate
> driver but when analysed, it's not really using the driver model at
> all.  The driver model is only really used to locate the required
> driver.
> 
> Conceptually, the imx-drm hardware is not much different from the the
> Armada/Dove display hardware: it too has the problem that there
> can be several CRTCs and several display outputs.  In some ways it's
> worse there because there isn't the same level of integration found
> on i.MX - it just has VGA and parallel outputs.  If you want something
> else, you need to stick a chip on the output.  In the case of HDMI,
> that's a TDA998x device.
> 
> For that, I've opted not to even _try_ to come up with a DT solution
> at present, because I know that trying to come up something that
> represents the hardware will not work properly with DRM.  That's
> exactly what everyone else should have done.
> 
> Then the effort would not be spent trying to come up with individual
> DT solutions and driver specific hacks, but instead would be spent on
> trying to sort out the DRM core to allow it to handle separately
> pluggable connectors, encoders and crtcs.

Been there, done that:

http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg20927.html

The only relevant reaction I received (from Dave) was frustrating:

> I'm sorry to say I totally hate this on every level. I think I said to
> you before that midlayers are not the answer, and this is a hella big
> midlayer.

With this reaction it became basically impossible to sort out the DRM
core. Now we ended up with variants of the above layer implemented in
each driver, see the Exynos, imx-drm and Tegra drivers.

I hope Laurent has more success with CDF than I had with SDRM. We already
have patches adding CDF support for the imx-drm driver which look
promising.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

ARM topic: Is DT on ARM the solution, or is there something better?

[Rob Clark]

On Mon, Oct 21, 2013 at 5:27 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> If a subsystem doesn't work well with DT, then the choices are either:
>>
>> (a) don't use DT with the subsystem
>
> The underlying problem has nothing to do with DT. Multi component
> hardware does exist and won't vanish when we stop using DT.
>
>> (b) fix the subsystem
>
> I'd love to do that. Step one to this seems to be to increase the
> awareness that there's something wrong with DRM.


Note that I suspect your idea of "fixing drm" is going to break some
userspace assumptions about the hw (ie. userspace isn't expecting
crtcs/encoders/connectors to suddenly appear/disappear.  And the funny
thing is, on all of this hw, that isn't going to happen anyways.

In whatever is done, we need some way to know all the devices in hw
that comprise the "graphics card", so that we can -EPROBE_DEFER until
we have all the bits and pieces.

BR,
-R

ARM topic: Is DT on ARM the solution, or is there something better?

[Sascha Hauer]

On Wed, Oct 23, 2013 at 09:14:17PM -0400, Rob Clark wrote:
> On Mon, Oct 21, 2013 at 5:27 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >> If a subsystem doesn't work well with DT, then the choices are either:
> >>
> >> (a) don't use DT with the subsystem
> >
> > The underlying problem has nothing to do with DT. Multi component
> > hardware does exist and won't vanish when we stop using DT.
> >
> >> (b) fix the subsystem
> >
> > I'd love to do that. Step one to this seems to be to increase the
> > awareness that there's something wrong with DRM.
> 
> 
> Note that I suspect your idea of "fixing drm" is going to break some
> userspace assumptions about the hw (ie. userspace isn't expecting
> crtcs/encoders/connectors to suddenly appear/disappear.  And the funny
> thing is, on all of this hw, that isn't going to happen anyways.

I was talking about all SoC DRM drivers implementing variants of the
same glue between drm and the multidevice nature of the components.

To make that sure: I never had the intention to implement hotplug for
drm. Also what the imx-drm driver does is not for hotplug, but only for
binding different components together.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 09:28:11AM +0200, Sascha Hauer wrote:
> On Wed, Oct 23, 2013 at 09:14:17PM -0400, Rob Clark wrote:
> > On Mon, Oct 21, 2013 at 5:27 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > >> If a subsystem doesn't work well with DT, then the choices are either:
> > >>
> > >> (a) don't use DT with the subsystem
> > >
> > > The underlying problem has nothing to do with DT. Multi component
> > > hardware does exist and won't vanish when we stop using DT.
> > >
> > >> (b) fix the subsystem
> > >
> > > I'd love to do that. Step one to this seems to be to increase the
> > > awareness that there's something wrong with DRM.
> > 
> > 
> > Note that I suspect your idea of "fixing drm" is going to break some
> > userspace assumptions about the hw (ie. userspace isn't expecting
> > crtcs/encoders/connectors to suddenly appear/disappear.  And the funny
> > thing is, on all of this hw, that isn't going to happen anyways.
> 
> I was talking about all SoC DRM drivers implementing variants of the
> same glue between drm and the multidevice nature of the components.
> 
> To make that sure: I never had the intention to implement hotplug for
> drm. Also what the imx-drm driver does is not for hotplug, but only for
> binding different components together.

I think we should be able to solve that problem generically. Essentially
we need some sort of composite device that subdevices can register with.
The composite device can keep track of what devices are needed (this
works well by walking the device tree, looking for nodes that match by
compatible and see if their status property is set to"okay") and once
all of those have been registered do whatever the specific subsystem
requires.

I'm not familiar with what exactly the requirements are for other SoCs,
so I'd be interested in hearing if there's anything beyond the above.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/20e0cd6a/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Sascha Hauer]

On Thu, Oct 24, 2013 at 11:00:56AM +0200, Thierry Reding wrote:
> On Thu, Oct 24, 2013 at 09:28:11AM +0200, Sascha Hauer wrote:
> > On Wed, Oct 23, 2013 at 09:14:17PM -0400, Rob Clark wrote:
> > > On Mon, Oct 21, 2013 at 5:27 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > >> If a subsystem doesn't work well with DT, then the choices are either:
> > > >>
> > > >> (a) don't use DT with the subsystem
> > > >
> > > > The underlying problem has nothing to do with DT. Multi component
> > > > hardware does exist and won't vanish when we stop using DT.
> > > >
> > > >> (b) fix the subsystem
> > > >
> > > > I'd love to do that. Step one to this seems to be to increase the
> > > > awareness that there's something wrong with DRM.
> > > 
> > > 
> > > Note that I suspect your idea of "fixing drm" is going to break some
> > > userspace assumptions about the hw (ie. userspace isn't expecting
> > > crtcs/encoders/connectors to suddenly appear/disappear.  And the funny
> > > thing is, on all of this hw, that isn't going to happen anyways.
> > 
> > I was talking about all SoC DRM drivers implementing variants of the
> > same glue between drm and the multidevice nature of the components.
> > 
> > To make that sure: I never had the intention to implement hotplug for
> > drm. Also what the imx-drm driver does is not for hotplug, but only for
> > binding different components together.
> 
> I think we should be able to solve that problem generically. Essentially
> we need some sort of composite device that subdevices can register with.
> The composite device can keep track of what devices are needed (this
> works well by walking the device tree, looking for nodes that match by
> compatible and see if their status property is set to"okay") and once
> all of those have been registered do whatever the specific subsystem
> requires.

It would be great to have a generic approach to this since subsystems
like ASoC and v4l2 have the same problem.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

ARM topic: Is DT on ARM the solution, or is there something better?

[Rob Clark]

On Thu, Oct 24, 2013 at 3:28 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Wed, Oct 23, 2013 at 09:14:17PM -0400, Rob Clark wrote:
>> On Mon, Oct 21, 2013 at 5:27 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> >> If a subsystem doesn't work well with DT, then the choices are either:
>> >>
>> >> (a) don't use DT with the subsystem
>> >
>> > The underlying problem has nothing to do with DT. Multi component
>> > hardware does exist and won't vanish when we stop using DT.
>> >
>> >> (b) fix the subsystem
>> >
>> > I'd love to do that. Step one to this seems to be to increase the
>> > awareness that there's something wrong with DRM.
>>
>>
>> Note that I suspect your idea of "fixing drm" is going to break some
>> userspace assumptions about the hw (ie. userspace isn't expecting
>> crtcs/encoders/connectors to suddenly appear/disappear.  And the funny
>> thing is, on all of this hw, that isn't going to happen anyways.
>
> I was talking about all SoC DRM drivers implementing variants of the
> same glue between drm and the multidevice nature of the components.
>
> To make that sure: I never had the intention to implement hotplug for
> drm. Also what the imx-drm driver does is not for hotplug, but only for
> binding different components together.

ahh, ok.  Yeah, we do need some way to make this easier, as it is a
too-common pattern.  I do think we do need a way to know if something
is missing because it isn't there vs it hasn't been probed yet.  Ie.
late_initcall() is not the awesome solution.

BR,
-R

> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 05:21:54PM -0400, Rob Clark wrote:
> On Thu, Oct 24, 2013 at 3:28 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Wed, Oct 23, 2013 at 09:14:17PM -0400, Rob Clark wrote:
> >> On Mon, Oct 21, 2013 at 5:27 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >> >> If a subsystem doesn't work well with DT, then the choices are either:
> >> >>
> >> >> (a) don't use DT with the subsystem
> >> >
> >> > The underlying problem has nothing to do with DT. Multi component
> >> > hardware does exist and won't vanish when we stop using DT.
> >> >
> >> >> (b) fix the subsystem
> >> >
> >> > I'd love to do that. Step one to this seems to be to increase the
> >> > awareness that there's something wrong with DRM.
> >>
> >>
> >> Note that I suspect your idea of "fixing drm" is going to break some
> >> userspace assumptions about the hw (ie. userspace isn't expecting
> >> crtcs/encoders/connectors to suddenly appear/disappear.  And the funny
> >> thing is, on all of this hw, that isn't going to happen anyways.
> >
> > I was talking about all SoC DRM drivers implementing variants of the
> > same glue between drm and the multidevice nature of the components.
> >
> > To make that sure: I never had the intention to implement hotplug for
> > drm. Also what the imx-drm driver does is not for hotplug, but only for
> > binding different components together.
> 
> ahh, ok.  Yeah, we do need some way to make this easier, as it is a
> too-common pattern.  I do think we do need a way to know if something
> is missing because it isn't there vs it hasn't been probed yet.  Ie.
> late_initcall() is not the awesome solution.

Yes, that's particularly easy to do with DT because you can walk the
tree looking for status = "okay" to collect which device nodes are
supposed to be enabled and assume that they'll show up eventually. I
have no idea how this could be done without DT, though. Perhaps iterate
over all platform devices and look for matching name.id pairs? Then
again, it seems like this is primarily an issue on ARM, and eventually
all ARM SoCs will move to DT, so perhaps this may become a non-issue.
But it doesn't help with platforms that don't support DT yet.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131025/44eb4bad/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Russell King - ARM Linux]

On Thu, Oct 24, 2013 at 05:21:54PM -0400, Rob Clark wrote:
> ahh, ok.  Yeah, we do need some way to make this easier, as it is a
> too-common pattern.  I do think we do need a way to know if something
> is missing because it isn't there vs it hasn't been probed yet.  Ie.
> late_initcall() is not the awesome solution.

On this topic, I now have a solution to this which is not DRM specific,
nor is it DT specific.

It's a core piece of code which gathers up the struct device pointers,
and a callback for the master device to assemble the components and
indicate when the master is complete.

Here's an example:

        imx-drm {
                compatible = "fsl,drm";
                /* Both CRTCs (can't specify which here) */
                crtcs = <&ipu1>, <&ipu1>;
                connectors = <&hdmi>;
        };

&hdmi {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_carrier1_hdmi>;
        ddc = <&i2c2>;
        status = "okay";
        crtcs = <&ipu1 0>;
};

The HDMI driver's probe and remove functions look like this:

static int imx_hdmi_platform_probe(struct platform_device *pdev)
{
        return component_add(&pdev->dev, &hdmi_ops);
}

static int imx_hdmi_platform_remove(struct platform_device *pdev)
{
        component_del(&pdev->dev, &hdmi_ops);
        return 0;
}

These register the device into the component layer, with a set of
operations for binding and unbinding the device.

The master device (imx-drm) does this:

static const struct component_master_ops imx_drm_ops = {
        .add_components = imx_drm_add_components,
        .bind = imx_drm_bind,
        .unbind = imx_drm_unbind,
};

static int imx_drm_platform_probe(struct platform_device *pdev)
{
        return component_master_add(&pdev->dev, &imx_drm_ops);
}

static int imx_drm_platform_remove(struct platform_device *pdev)
{
        component_master_del(&pdev->dev, &imx_drm_ops);
        return 0;
}

so registering the master device.  imx_drm_add_components() gets called
whenever something gets added, and this function is responsible for
assembling the registered components and indicating when the master is
complete:

static int imx_drm_add_components(struct device *master, struct master *m)
{
        struct device_node *np = master->of_node;
        unsigned i;
        int ret;

        for (i = 0; ; i++) {
                struct device_node *node;

                node = of_parse_phandle(np, "crtcs", i);
                if (!node)
                        break;

                ret = component_master_add_child(m, compare_parent_of, node);
                of_node_put(node);

                if (ret)
                        return ret;
        }

        for (i = 0; ; i++) {
                struct device_node *node;

                node = of_parse_phandle(np, "connectors", i);
                if (!node)
                        break;

                ret = component_master_add_child(m, compare_of, node);
                of_node_put(node);

                if (ret)
                        return ret;
        }
        return 0;
}

When it is complete (iow, this function returns zero), the master is
bound:

static int imx_drm_bind(struct device *dev)
{
        return drm_platform_init(&imx_drm_driver, to_platform_device(dev));
}

This causes DRM to start the construction of a drm_device, and call the
load callback.  In the load callback:

        /* Now try and bind all our sub-components */
        ret = component_bind_all(drm->dev, drm);
        if (ret)
                goto err;

which binds the previously assembled components, with the drm_device
structure as their data - that's drm above:

static int imx_hdmi_bind(struct device *dev, struct device *master, void *data)
{
        struct platform_device *pdev = to_platform_device(dev);
        const struct of_device_id *of_id =
                                of_match_device(imx_hdmi_dt_ids, dev);
        struct drm_device *drm = data;
...
}

This allows the HDMI driver to register with DRM using the passed
struct drm_device pointer.  Other connectors do the same at this moment,
CRTCs also use this same mechanism, but with a higher priority, so CRTCs
get registered before connectors.

Teardown is similar to the above, but it happens in reverse order: when
any bound component or the master goes away, the master DRM device is
unbound, which triggers DRM to call the unload callback.

The unload callback unbinds the components, which triggers an unbind
call to each component in reverse order.

As I say, nothing in the above is specific to DRM; this can be re-used
by any subsystem.  It can also be re-used by non-DT setups as well via
appropriate .add_components callback and appropriate component matching
functions.

This addresses the componentised device problem in a completely generic
way.

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Nov 18, 2013 at 12:45:19PM +0000, Russell King - ARM Linux wrote:
> On Thu, Oct 24, 2013 at 05:21:54PM -0400, Rob Clark wrote:
> > ahh, ok.  Yeah, we do need some way to make this easier, as it is a
> > too-common pattern.  I do think we do need a way to know if something
> > is missing because it isn't there vs it hasn't been probed yet.  Ie.
> > late_initcall() is not the awesome solution.
> 
> On this topic, I now have a solution to this which is not DRM specific,
> nor is it DT specific.
> 
> It's a core piece of code which gathers up the struct device pointers,
> and a callback for the master device to assemble the components and
> indicate when the master is complete.
> 
> Here's an example:
> 
>         imx-drm {
>                 compatible = "fsl,drm";
>                 /* Both CRTCs (can't specify which here) */
>                 crtcs = <&ipu1>, <&ipu1>;
>                 connectors = <&hdmi>;
>         };
> 
> &hdmi {
>         pinctrl-names = "default";
>         pinctrl-0 = <&pinctrl_carrier1_hdmi>;
>         ddc = <&i2c2>;
>         status = "okay";
>         crtcs = <&ipu1 0>;
> };
> 
> The HDMI driver's probe and remove functions look like this:
> 
> static int imx_hdmi_platform_probe(struct platform_device *pdev)
> {
>         return component_add(&pdev->dev, &hdmi_ops);
> }
> 
> static int imx_hdmi_platform_remove(struct platform_device *pdev)
> {
>         component_del(&pdev->dev, &hdmi_ops);
>         return 0;
> }
> 
> These register the device into the component layer, with a set of
> operations for binding and unbinding the device.
> 
> The master device (imx-drm) does this:
> 
> static const struct component_master_ops imx_drm_ops = {
>         .add_components = imx_drm_add_components,
>         .bind = imx_drm_bind,
>         .unbind = imx_drm_unbind,
> };
> 
> static int imx_drm_platform_probe(struct platform_device *pdev)
> {
>         return component_master_add(&pdev->dev, &imx_drm_ops);
> }
> 
> static int imx_drm_platform_remove(struct platform_device *pdev)
> {
>         component_master_del(&pdev->dev, &imx_drm_ops);
>         return 0;
> }
> 
> so registering the master device.  imx_drm_add_components() gets called
> whenever something gets added, and this function is responsible for
> assembling the registered components and indicating when the master is
> complete:
> 
> static int imx_drm_add_components(struct device *master, struct master *m)
> {
>         struct device_node *np = master->of_node;
>         unsigned i;
>         int ret;
> 
>         for (i = 0; ; i++) {
>                 struct device_node *node;
> 
>                 node = of_parse_phandle(np, "crtcs", i);
>                 if (!node)
>                         break;
> 
>                 ret = component_master_add_child(m, compare_parent_of, node);
>                 of_node_put(node);
> 
>                 if (ret)
>                         return ret;
>         }
> 
>         for (i = 0; ; i++) {
>                 struct device_node *node;
> 
>                 node = of_parse_phandle(np, "connectors", i);
>                 if (!node)
>                         break;
> 
>                 ret = component_master_add_child(m, compare_of, node);
>                 of_node_put(node);
> 
>                 if (ret)
>                         return ret;
>         }
>         return 0;
> }
> 
> When it is complete (iow, this function returns zero), the master is
> bound:
> 
> static int imx_drm_bind(struct device *dev)
> {
>         return drm_platform_init(&imx_drm_driver, to_platform_device(dev));
> }
> 
> This causes DRM to start the construction of a drm_device, and call the
> load callback.  In the load callback:
> 
>         /* Now try and bind all our sub-components */
>         ret = component_bind_all(drm->dev, drm);
>         if (ret)
>                 goto err;
> 
> which binds the previously assembled components, with the drm_device
> structure as their data - that's drm above:
> 
> static int imx_hdmi_bind(struct device *dev, struct device *master, void *data)
> {
>         struct platform_device *pdev = to_platform_device(dev);
>         const struct of_device_id *of_id =
>                                 of_match_device(imx_hdmi_dt_ids, dev);
>         struct drm_device *drm = data;
> ...
> }
> 
> This allows the HDMI driver to register with DRM using the passed
> struct drm_device pointer.  Other connectors do the same at this moment,
> CRTCs also use this same mechanism, but with a higher priority, so CRTCs
> get registered before connectors.
> 
> Teardown is similar to the above, but it happens in reverse order: when
> any bound component or the master goes away, the master DRM device is
> unbound, which triggers DRM to call the unload callback.
> 
> The unload callback unbinds the components, which triggers an unbind
> call to each component in reverse order.
> 
> As I say, nothing in the above is specific to DRM; this can be re-used
> by any subsystem.  It can also be re-used by non-DT setups as well via
> appropriate .add_components callback and appropriate component matching
> functions.
> 
> This addresses the componentised device problem in a completely generic
> way.

Very nice. This is in fact very similar to a skeleton I started to
implement locally. The names vary to some degree, but the general
approach is the same.

This also happens to be very similar to what Tegra DRM does, just as a
set of helpers rather than a bus type. I like it a lot.

In particular this gives every driver a good amount of flexibility to
implement the matching in a way that's appropriate. On hardware where
the relationships are hierarchical, a driver can use that to its
advantage. Whenever that's not possible it can be done using phandles
or any other meta data that fits the particular use-case.

Do you have a branch somewhere that I could use to test this with?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/b2d274c7/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Russell King - ARM Linux]

On Mon, Nov 18, 2013 at 04:37:51PM +0100, Thierry Reding wrote:
> Very nice. This is in fact very similar to a skeleton I started to
> implement locally. The names vary to some degree, but the general
> approach is the same.
> 
> This also happens to be very similar to what Tegra DRM does, just as a
> set of helpers rather than a bus type. I like it a lot.
> 
> In particular this gives every driver a good amount of flexibility to
> implement the matching in a way that's appropriate. On hardware where
> the relationships are hierarchical, a driver can use that to its
> advantage. Whenever that's not possible it can be done using phandles
> or any other meta data that fits the particular use-case.

Indeed - I set out to solve the following problems:

- How do we deal with a componentised device such that we can find all
  of its component devices, and know when we have them all?
- How can we probe the master device when we know we have all the
  components?
- How do we tear down the master device when one of the components is
  removed?

I intentionally didn't want the code to answer the question about how
we specify how the components are organised - that's a subject best
left to the subsystem and/or device, since it's something which will
most likely vary.

> Do you have a branch somewhere that I could use to test this with?

Not yet - and there probably won't be, because the code itself is not
large - it's currently less than 500 lines.

The code has evolved over time - with imx-drm as a guinea pig.

The code which I have so far committed (and some people are using in
patch form on the carrier-1 boards) is an earlier version, which just
caters for proper init ordering and making it possible to unbind the
"master" device.  It gets that init ordering by using deferred probing
if there's no connectors, or the CRTCs which the connectors refer to
are missing - it needs no changes to the DT representation.

Since then, I've augmented it as I described and that's currently just
as an additional patch on top which adds the master device idea - which
does need those additional changes.

Logically, it can't stay as two separate patches, because it won't be
possible to "migrate" to it in stages.  So I'm fully intending to
squash that all down to one patch which adds the core code (probably
ultimately into drivers/base).

IOW, watch this space this week. :)

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Nov 18, 2013 at 04:11:51PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 18, 2013 at 04:37:51PM +0100, Thierry Reding wrote:
> > Very nice. This is in fact very similar to a skeleton I started to
> > implement locally. The names vary to some degree, but the general
> > approach is the same.
> > 
> > This also happens to be very similar to what Tegra DRM does, just as a
> > set of helpers rather than a bus type. I like it a lot.
> > 
> > In particular this gives every driver a good amount of flexibility to
> > implement the matching in a way that's appropriate. On hardware where
> > the relationships are hierarchical, a driver can use that to its
> > advantage. Whenever that's not possible it can be done using phandles
> > or any other meta data that fits the particular use-case.
> 
> Indeed - I set out to solve the following problems:
> 
> - How do we deal with a componentised device such that we can find all
>   of its component devices, and know when we have them all?
> - How can we probe the master device when we know we have all the
>   components?
> - How do we tear down the master device when one of the components is
>   removed?
> 
> I intentionally didn't want the code to answer the question about how
> we specify how the components are organised - that's a subject best
> left to the subsystem and/or device, since it's something which will
> most likely vary.
> 
> > Do you have a branch somewhere that I could use to test this with?
> 
> Not yet - and there probably won't be, because the code itself is not
> large - it's currently less than 500 lines.
> 
> The code has evolved over time - with imx-drm as a guinea pig.
> 
> The code which I have so far committed (and some people are using in
> patch form on the carrier-1 boards) is an earlier version, which just
> caters for proper init ordering and making it possible to unbind the
> "master" device.  It gets that init ordering by using deferred probing
> if there's no connectors, or the CRTCs which the connectors refer to
> are missing - it needs no changes to the DT representation.
> 
> Since then, I've augmented it as I described and that's currently just
> as an additional patch on top which adds the master device idea - which
> does need those additional changes.
> 
> Logically, it can't stay as two separate patches, because it won't be
> possible to "migrate" to it in stages.  So I'm fully intending to
> squash that all down to one patch which adds the core code (probably
> ultimately into drivers/base).
> 
> IOW, watch this space this week. :)

Will do! Thanks for doing this.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/7643954e/attachment-0001.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Mark Brown]

On Mon, Nov 18, 2013 at 04:11:51PM +0000, Russell King - ARM Linux wrote:

> Logically, it can't stay as two separate patches, because it won't be
> possible to "migrate" to it in stages.  So I'm fully intending to
> squash that all down to one patch which adds the core code (probably
> ultimately into drivers/base).

> IOW, watch this space this week. :)

Can you CC me on these changes please and I'll have a look at converting
ASoC over to use them?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/1f75b9b6/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Grant Likely]

On Mon, 18 Nov 2013 12:45:19 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, Oct 24, 2013 at 05:21:54PM -0400, Rob Clark wrote:
> > ahh, ok.  Yeah, we do need some way to make this easier, as it is a
> > too-common pattern.  I do think we do need a way to know if something
> > is missing because it isn't there vs it hasn't been probed yet.  Ie.
> > late_initcall() is not the awesome solution.
> 
> On this topic, I now have a solution to this which is not DRM specific,
> nor is it DT specific.
> 
> It's a core piece of code which gathers up the struct device pointers,
> and a callback for the master device to assemble the components and
> indicate when the master is complete.

That's pretty clean. I think that will work nicely.

g.

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Oct 21, 2013 at 09:48:54AM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 21, 2013 at 10:32:42AM +0200, Sascha Hauer wrote:
> > On Mon, Oct 21, 2013 at 12:11:34AM +0100, Russell King - ARM Linux wrote:
> > > On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
> > > > The only thing we've really moved out of the kernel is the exact IDs of
> > > > which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the
> > > > simple stuff not the hard stuff. The code hasn't really been simplified
> > > > by DT - if anything, it's more complicated since we now have to parse
> > > > those values from DT rather than putting them into simple data-structures.
> > > 
> > > Here's my random thoughts this evening on DT, orientated mostly on a
> > > problem area I've been paying attention to recently.
> > > 
> > > In some ways, DT has made things much harder.  I don't know whether
> > > you've taken a look at DRM and the various drivers we have under there,
> > > it's quite a mess of unreliable code which is trying to bend the DRM
> > > card based model to a DT based multi-device component based description
> > > with lots of sub-drivers.
> > > 
> > > What DRM currently expects is a certain initialisation order: the main
> > > drm_device structure is created by the DRM code, and then supplied to
> > > the DRM driver to populate all the different parts of the "DRM card".
> > > 
> > > Once all parts of the card have been setup (the CRTCs, encoders,
> > > connectors, etc) then some helpers can be initialised.  Once the
> > > helpers have been initialised, the "dimensions" of the "DRM card"
> > > become rather fixed until the helper is torn down.
> > > 
> > > The problem is this: if you have a multi-driver based card, there is
> > > no way to prevent any of those sub-drivers from being unbound from
> > > their drivers at any time.  module refcounts don't save you from this.
> > > Meanwhile, (at the moment) you can't half-tear down a "DRM card" and
> > > have it still in a usable state.  The internals just don't allow for
> > > it at present.
> > > 
> > > Yes, work can be put in to solve this problem, but it's being solved
> > > because of a desire to bend the subsystem to the DT way of doing things.
> > > That may or may not be the best idea.  However, what I do know is that
> > > there is now great pressure to "bend stuff so that it works with DT
> > > at all costs".  Evidence is the Exynos driver and the imx-drm driver.
> > 
> > In fact it was the other way round. We modeled the IPU devicetree
> > binding after the hardware and bended the driver around it. The DRM
> > single-card model is the limiting fator here, not the devicetree.
> 
> There are several points which I think you failed to understand:
> 
> 1. DRM vs device tree is an incompatibility.
> 2. Trying to bend DRM to DT with independent driver solutions such as
>    the abomination that is imx-drm creates its own set of problems.
> 
> If a subsystem doesn't work well with DT, then the choices are either:
> 
> (a) don't use DT with the subsystem
> (b) fix the subsystem
> 
> The choices do not include:
> 
> (c) creating an abomination that is fragile, and is trivially easy to
> oops the kernel.
> 
> This comes back to the root problem I'm trying to highlight: we are not
> trying to strive for DT forsaking everything else.  If moving to DT
> means we give up with proper code design, then we've quite literally
> lost the plot.

I'm honestly not sure if we have much of a choice right now. I've only
recently hit the stable ABI wall, which effectively keeps me from adding
new functionality. Even worse, the matter isn't that some patches would
need more work or anything, but the problem is that we can't merge code
until everybody and their cat has acked the patches, or more precisely,
the DT bindings. Typically this is a subsystem maintainer, the port
maintainer and now with DT also the device tree binding maintainers.
That's an awful lot of people you have to convince. In this particular
case these patches were even required to be acked by yet another group
of people.

Now, I can't blame anyone in particular and I certainly made my own set
of mistakes in the process, but the issue is systemic. If you need to
run a set of patches by three or four groups of people, each with their
own set of interests, it becomes very difficult to find any sort of
concensus. And not only that: it also means that every group needs to
find the time to at least look at the patches and to some degree
understand it.

So instead of requiring concensus on the binding from everyone involved,
I went to investigate alternative means to get the code out and provide
new features to our users with the goal to migrate to a proper device
tree binding incrementally. The problem is that we can't expose all the
device nodes in DT because their bindings haven't been acknowledged, but
without a device node there won't be a device for the driver to bind
against. So the obvious solution seemed to be to just create the device
programmatically. Naively I thought: "Well, this won't be pretty, but
it should be easy."

Far from it. It turns out to be very difficult to do. With all the
cross-referencing that DT allows to do so easily, the same is very
cumbersome to do with code. Not only do you need to look up device nodes
by path, but you also need to do things like fixing up phandles because
the DT doesn't contain them for all nodes, yet the kernel needs them to
look up the corresponding devices.

Once you've actually created a device node, you still need to inject it
into what the device tree core created from the DTB at boot time. Turns
out that there's actually some code to do that, but it requires the
OF_DYNAMIC option to be selected. Turning that on triggers a couple of
warnings because code doesn't take and drop references on device nodes
properly.

To round things off there's the problem on how to preserve compatibility
with future device trees where the nodes already exist because we've
finally agreed on a binding...

So unfortunately there is no easy way to mix DT with non-DT. So we can
decide to just merge code that's not supported on DT platforms, but what
good is that if the platform we want to run that code on supports only
DT?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131021/1058d7ca/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Laurent Pinchart]

Hi Russell,

On Monday 21 October 2013 09:48:54 Russell King - ARM Linux wrote:
> On Mon, Oct 21, 2013 at 10:32:42AM +0200, Sascha Hauer wrote:
> > On Mon, Oct 21, 2013 at 12:11:34AM +0100, Russell King - ARM Linux wrote:
> > > On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
> > > > The only thing we've really moved out of the kernel is the exact IDs
> > > > of which GPIOS, interrupts, I2C/SPI ports the devices are connected
> > > > to; the simple stuff not the hard stuff. The code hasn't really been
> > > > simplified by DT - if anything, it's more complicated since we now
> > > > have to parse those values from DT rather than putting them into
> > > > simple data-structures.
> > > 
> > > Here's my random thoughts this evening on DT, orientated mostly on a
> > > problem area I've been paying attention to recently.
> > > 
> > > In some ways, DT has made things much harder.  I don't know whether
> > > you've taken a look at DRM and the various drivers we have under there,
> > > it's quite a mess of unreliable code which is trying to bend the DRM
> > > card based model to a DT based multi-device component based description
> > > with lots of sub-drivers.
> > > 
> > > What DRM currently expects is a certain initialisation order: the main
> > > drm_device structure is created by the DRM code, and then supplied to
> > > the DRM driver to populate all the different parts of the "DRM card".
> > > 
> > > Once all parts of the card have been setup (the CRTCs, encoders,
> > > connectors, etc) then some helpers can be initialised.  Once the
> > > helpers have been initialised, the "dimensions" of the "DRM card"
> > > become rather fixed until the helper is torn down.
> > > 
> > > The problem is this: if you have a multi-driver based card, there is
> > > no way to prevent any of those sub-drivers from being unbound from
> > > their drivers at any time.  module refcounts don't save you from this.
> > > Meanwhile, (at the moment) you can't half-tear down a "DRM card" and
> > > have it still in a usable state.  The internals just don't allow for
> > > it at present.
> > > 
> > > Yes, work can be put in to solve this problem, but it's being solved
> > > because of a desire to bend the subsystem to the DT way of doing things.
> > > That may or may not be the best idea.  However, what I do know is that
> > > there is now great pressure to "bend stuff so that it works with DT
> > > at all costs".  Evidence is the Exynos driver and the imx-drm driver.
> > 
> > In fact it was the other way round. We modeled the IPU devicetree
> > binding after the hardware and bended the driver around it. The DRM
> > single-card model is the limiting fator here, not the devicetree.
> 
> There are several points which I think you failed to understand:
> 
> 1. DRM vs device tree is an incompatibility.
> 2. Trying to bend DRM to DT with independent driver solutions such as
>    the abomination that is imx-drm creates its own set of problems.
> 
> If a subsystem doesn't work well with DT, then the choices are either:
> 
> (a) don't use DT with the subsystem
> (b) fix the subsystem
> 
> The choices do not include:
> 
> (c) creating an abomination that is fragile, and is trivially easy to
> oops the kernel.

I would also add, in the choices I (we?) don't want

(d) custom driver-specific solutions that will break when the next version of 
the SoC is released.

> This comes back to the root problem I'm trying to highlight: we are not
> trying to strive for DT forsaking everything else.  If moving to DT means we
> give up with proper code design, then we've quite literally lost the plot.

I started looking into DT bindings for my DRM drivers more than a year ago. It 
started with the simple task of creating bindings for panels, but it quickly 
became clear (to me at least) that the issue was much bigger than that. This 
is what prompted me to work on the Common Display Framework (CDF) that you 
might have heard about.

Please note that the idea behind CDF isn't DT-centric, its main goal is to 
offer a (hopefully clean and simple) way to handle composite hardware devices 
that are so common in the embedded world, using one driver per chip and/or IP 
core (there's no *requirement* to split the SoC hardware support code in 
multiple drivers in CDF, but it allows doing so when the SoC is made of 
generic IP cores that are reused in different composite devices - a good 
example of that is a video scaler that can be instantiated in a display 
pipeline and a camera pipeline).

I haven't been able to spend as much time on CDF as I would have liked to so 
far, but I haven't given up. I would be more than happy to discuss this during 
ELC-E/KS if you would like.

> Honestly, I don't see imx-drm ever moving out of drivers/staging except by
> deletion or being rewritten.

-- 
Regards,

Laurent Pinchart

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Laurent Pinchart]

Hi Russell,

On Monday 21 October 2013 00:11:34 Russell King - ARM Linux wrote:

[snip]

> Other thoughts on DT... it's a pain in the backside as it's far too
> easy to make a subtle mistake in a DT source file and have it "build"
> to a blob. You can then spend hours trying to debug why something isn't
> working, and it's very simply because you typo'd something.  A recent
> example:
> 
> 	pintctrl-0 = <...>;
> 
> and then you start wondering why aren't I getting signals out from the
> pins you want, and you start chasing around trying to find out if its
> something that you haven't thought of, whether some setting in the
> pin settings is wrong or whatever.  You completely fail to notice the
> additional 't' for hours and hours.  Eventually, you start pasting it
> onto IRC and at that point you spot the error.
> 
> You may laugh at that, but that's exactly what has happened - all
> because the DT compiler is freeform - provided the strings look okay
> to it, that's all it cares about.  Whether the description is correct
> for the device or not is outside of its concern.
> 
> I'm pretty certain that I won't be the only one who has gone through
> this - and I'm probably not going to be the last.
> 
> We already know that "board firmware" has a tendency to be buggy.  Well,
> the DT compiler as it stands today does nothing what so ever to help
> people make sure that what they _think_ they're typing into the DT
> file is actually correct.  All the time that we're have a tool which
> allows typos through we're going to encounter bugs like this.  Not a
> problem when DT is shipped with the kernel, but when it isn't, what
> then...

I just wanted to point to

http://www.spinics.net/lists/devicetree/msg08856.html

The DT compiler (or an external tool) would get the ability the validate the 
DT source against a schema to spot missing properties, extra properties not 
defined in the bindings, or other kind of mistakes. The schema would be 
considered part of the bindings themselves and would be the authoritative 
source of information. It will obviously not solve all issues, but it should 
be a good starting point.

-- 
Regards,

Laurent Pinchart

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Sebastian Hesselbarth]

On 10/21/2013 12:11 AM, Russell King - ARM Linux wrote:
> On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
>> The only thing we've really moved out of the kernel is the exact IDs of
>> which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the
>> simple stuff not the hard stuff. The code hasn't really been simplified
>> by DT - if anything, it's more complicated since we now have to parse
>> those values from DT rather than putting them into simple data-structures.
>
> Here's my random thoughts this evening on DT, orientated mostly on a
> problem area I've been paying attention to recently.
>
> In some ways, DT has made things much harder.  I don't know whether
> you've taken a look at DRM and the various drivers we have under there,
> it's quite a mess of unreliable code which is trying to bend the DRM
> card based model to a DT based multi-device component based description
> with lots of sub-drivers.
>
> What DRM currently expects is a certain initialisation order: the main
> drm_device structure is created by the DRM code, and then supplied to
> the DRM driver to populate all the different parts of the "DRM card".
>
> Once all parts of the card have been setup (the CRTCs, encoders,
> connectors, etc) then some helpers can be initialised.  Once the
> helpers have been initialised, the "dimensions" of the "DRM card"
> become rather fixed until the helper is torn down.
>
> The problem is this: if you have a multi-driver based card, there is
> no way to prevent any of those sub-drivers from being unbound from
> their drivers at any time.  module refcounts don't save you from this.
> Meanwhile, (at the moment) you can't half-tear down a "DRM card" and
> have it still in a usable state.  The internals just don't allow for
> it at present.
>
> Yes, work can be put in to solve this problem, but it's being solved
> because of a desire to bend the subsystem to the DT way of doing things.
> That may or may not be the best idea.  However, what I do know is that
> there is now great pressure to "bend stuff so that it works with DT
> at all costs".  Evidence is the Exynos driver and the imx-drm driver.
>
> Now, the flip side to this is that some DRM solutions include an I2C
> device, which is itself a separate driver, and would appear to suffer
> from this same problem.  This is handled via the drm_encoder_slave
> infrastructure.  As it currently is written (ignoring DT) it get
> around the problem by not actually using the driver model "properly".
> If it were to, it would run into this same problem.
>
> How would we sort this out pre-DT?  We'd pass a chunk of platform data
> into a driver to describe the various options: eg, whether we wanted
> HDMI output, the I2C bus details of the DDC bus, etc., which results
> in a simpler solution - though traditionally a driver specific solution.
>
> However, "driver specific solution" is bad - always has been.  What was
> missed is that the platform datas should never have been specific to
> any particular device.  They should have been class specific.  I tried
> to do that with flash_platform_data for example - some people got the
> idea, but the vast majority didn't.
>
> What is clear to me is that there is no panacea "one size fits all"
> approach to the problem of device driver bindings and turning them into
> generic drivers.  Everyone has their own pet ideas and solutions to
> this.  Some favour DT.  Others favour other solutions.
>
> At the end of the day, the question should be - what is the easiest
> solution.  In the case of DRM, it may well be that the easiest solution
> is to have a translation layer which presents a DT multi-node
> description (note the change in terminology: multi-node not multi-device)
> to DRM as platform data so that DRM can preserve its "single card"
> solution.  Or whatever other translation layer is necessary for whatever
> solution is chosen in the future.
>
> There's much much more to the DRM vs DT problem than the above.  In
> short:
> - we have several driver specific solutions to this same problem
> - on the balance of probabilities, their solutions are buggy in some
>    way, some more buggy than others.
>
> I have one DRM driver which I've recently submitted to David Airlie
> which I have *not* implemented DT support for and that is because I
> don't want to solve this same problem in another driver specific way.
> I'd rather the driver wasn't directly supportable by DT until there's
> proper work in infrastructure than to create yet another driver
> specific solution - or the DT mess is dealt with outside the main
> driver.  (I believe that has already been done by Sebastian...)

IMHO, making a driver DT-aware should never really depend on re-writing
the core driver itself but help the subsystem to build up proper driver-
specific structs from it. When I started to make Armada DRM to work with
DT, I didn't look for places to modify the driver but what it expects
in terms of resources. So, for Armada DRM and most likely most SoC DRM
drivers DT should only be used to build up the platform_data required
for the driver.

IIRC, in the early DT days, everybody of_iomap'ed resources, with
device core translating those to resources you can limit some drivers
to the match table to make it DT aware. I guess this also has to be
done within other subsystems, drm and propably asoc too.

What DT really allows us to do, is describing dependencies between
nodes, i.e. RGB scan-out connected to HDMI transmitter on I2C bus
foo. That is what we really should exploit to build up a proper
representation of the devices used for e.g. a video card. Except some
very IP specific properties, there should be no need to parse the
DT yourself. Of course, there will be over-complicated boards or
designs that make it hard to deal with, but it would have been with or
without DT.

I definitely may have a limited view over the overall complexity
involved especially with non-SoC drivers. Nonetheless, I am looking
forward to meet some of you at ELCE and get more insight in this.

> Other thoughts on DT... it's a pain in the backside as it's far too
> easy to make a subtle mistake in a DT source file and have it "build"
> to a blob. You can then spend hours trying to debug why something isn't
> working, and it's very simply because you typo'd something.  A recent
> example:
>
> 	pintctrl-0 = <...>;

Aren't there proposals for DT schematas that could possibly solve this?

Sebastian

> and then you start wondering why aren't I getting signals out from the
> pins you want, and you start chasing around trying to find out if its
> something that you haven't thought of, whether some setting in the
> pin settings is wrong or whatever.  You completely fail to notice the
> additional 't' for hours and hours.  Eventually, you start pasting it
> onto IRC and at that point you spot the error.
>
> You may laugh at that, but that's exactly what has happened - all
> because the DT compiler is freeform - provided the strings look okay
> to it, that's all it cares about.  Whether the description is correct
> for the device or not is outside of its concern.
>
> I'm pretty certain that I won't be the only one who has gone through
> this - and I'm probably not going to be the last.
>
> We already know that "board firmware" has a tendency to be buggy.  Well,
> the DT compiler as it stands today does nothing what so ever to help
> people make sure that what they _think_ they're typing into the DT
> file is actually correct.  All the time that we're have a tool which
> allows typos through we're going to encounter bugs like this.  Not a
> problem when DT is shipped with the kernel, but when it isn't, what
> then...

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
> IIRC (and perhaps I don't; it was really slightly before my active
> involvement in kernel development) Linus triggered the whole ARM DT
> conversion in response to disliking the volume of changes, and
> conflicts, in board files. The idea of DT conversion being that all the
> board-specific details could be moved out of the kernel and into DT
> files, thus causing him not to have to see it.
> 
> Note: As part of implementing DT on ARM, we've also cleaned up and
> modularized a lot of code, and created new subsystems and APIs. I think
> this is a separate issue, and much of that could have happened
> completely independently from doard->DT conversion.

Perhaps this would even have been enough. It looks to me that we've
created much better, more rigorous processes as a side-effect. I can
easily imagine that if we had done all of that but without moving to DT,
the end result may have been equally good.

I'm not saying that DT is bad. There are a whole lot of good things
about it that I really like. On the other hand, I've recently realized
that it has become increasingly difficult to upstream even the most
trivial functionality because now everybody wants to design the perfect
DT binding with the effect of new features not going anywhere.

But I digress, and I should probably start a separate discussion about
that.

> I wonder if DT is solving the problem at the right level of abstraction?
> The kernel still needs to be aware of all the nitty-gritty details of
> how each board is hooked up different, and have explicit code to deal
> the union of all the different board designs.
> 
> For example, if some boards have a SW-controlled regulator for a device
> but others don't, the kernel still needs to have driver code to actively
> control that regulator, /plus/ the regulator subsystem needs to be able
> to substitute a dummy regulator if it's optional or simply missing from
> the DT.
> 
> Another example: MMC drivers need to support some boards detecting SD
> card presence or write-protect via arbitrary GPIOs, and others via
> dedicated logic in the MMC controller.
> 
> In general, the kernel still needs a complete driver to every last
> device on every strange board, and needs to support every strange way
> some random board hooks all the devices together.

I have some difficulty understanding what you think should've been moved
out of the kernel. There's only so much you can put into data structures
and at some point you need to start writing device specific code for the
peripherals that you want to drive.

> The only thing we've really moved out of the kernel is the exact IDs of
> which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the
> simple stuff not the hard stuff. The code hasn't really been simplified
> by DT - if anything, it's more complicated since we now have to parse
> those values from DT rather than putting them into simple data-structures.
> 
> I wonder if some other solution with a higher level of abstraction
> wouldn't be a better idea? Would it make more sense to define some kind
> of firmware interface that the kernel deals with, so that all HW details
> are hidden behind that firmware interface, and the kernel just deals
> with the firmware interface, which hopefully has less variation than the
> actual HW (or even zero variation).
> 
> * Would UEFI/ACPI/similar fulfill this role?

If I recall correctly, the original OpenFirmware that introduced the DT
concept used to have something similar to UEFI/ACPI. Essentially it was
possible to not only pass the DT to the operating system but also allow
the operating system to call back into the firmware to request service.

Of course this brings up the issue about the degree to which we want to
rely on the firmware to do the right thing. If it's difficult to update
firmware (which it usually is), then we'll likely end up reimplementing
some of the functionality in the kernel because firmware might end up
being buggy and therefore we can't trust it.

On the other hand, one thing that I very much like about the concept is
that DT isn't only used as a way to describe the hardware but also uses
the notion of services provided by nodes. That means that a DT binding
not only defines the properties that characterize hardware but also a
set of operations that can be performed on a compatible node. This does
not only apply on a per-compatible basis but also depending on device
type. A PCI device for instance provides standard services to read the
configuration space.

Most of this applies to Linux already because when a device referred to
by phandle is used by some other device, the phandle needs to be
resolved to some Linux-specific object (regulator, clock, backlight...)
before it can be used and the given subsystem already defines all the
operations that can be performed. So perhaps this isn't really all that
relevant after all...

> * Perhaps a standard virtualization interface could fulfil this role?
> IIUC, there are already standard mechanisms of exposing e.g. disks, USB
> devices, PCI devices, etc. into VMs, and recent ARM HW[1] supports
> virtualization well now. A sticking point might be graphics, but it
> sounds like there's work to transport GL or Gallium command streams over
> the virtualization divide.
> 
> Downsides might be:
> 
> - Overhead, due to invoking the para-virtualized VM host for IO, and
> extra resources to run the host.
> 
> - The host SW still has to address the HW differences. Would it be more
> acceptable to run a vendor kernel as the VM host if it meant that the
> VMs could be a more standardized environment, with a more single-purpose
> upstream kernel? Would it be easier to create a simple VM host than a
> full Linux kernel with a full arbitrary Linux distro, thus allowing the
> HW differences to be addressed in a simple way?
> 
> These techniques would allow distros to target a single HW environment,
> e.g. para-virtualized KVM, rather than many many different SoCs and
> boards each with different bootloaders, bootloader configurations, IO
> peripherals, DT storage locations, etc. Perhaps a solution like this
> would allow distros to easily support a similar environment across a
> range of HW in a way that "just works" for many users, while not
> preventing people with more specific needs crafting more HW-specific
> environments?

That sounds very much like a sledgehammer solution. Also I'm not sure if
it would solve all that many problems. I guess what it could solve is to
move a whole lot of the underlying specifics of the various SoCs to some
other place (the host). It's fundamentally very similar to ACPI, and it
comes with the same set of advantages and disadvantages.

What will likely happen with such a solution is that we'll have to come
up with a standard interface that the guest OS expects. Once that has
been defined, vendors will have to implement that interface. Naturally
most of them will choose Linux as a host OS. What we'll end up with is
unlikely to be any better than the current situation.

Vendor kernels that implement the host OS will effectively become forks
of their own since there's no incentive to upstream code anymore. Linux
upstream becomes a single unified architecture because all interfaces
are now the same. Vendors are back to brewing their own. Except for the
rare occasions where something needs to be added to the guest interface
there won't be much interaction between kernel developers. We will also
need to specify stable interfaces between host and guest and I think
everyone involved with DT lately has some experience as to how painful
that can be. So instead of being able to add new features to the kernel
within a single release cycle, we'll likely end up having to wait for a
few cycles because it needs to be implemented in both guest and host,
which may or may not have the same release cycles.

The above is the worst case scenario, but the alternative would be that
Linux is still forked into host and guest, yet vendors keep working on
one upstream host Linux. In that case, we're not solving anything. All
the same problems that we have now will remain. Well, we might be able
to make it somewhat easier for distributions, but there are a whole lot
of disadvantages to it as well.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131021/91e970ac/attachment-0001.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Stephen Warren]

On 10/21/2013 09:54 AM, Thierry Reding wrote:
> On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
...
>> I wonder if DT is solving the problem at the right level of
>> abstraction? The kernel still needs to be aware of all the
>> nitty-gritty details of how each board is hooked up different,
>> and have explicit code to deal the union of all the different
>> board designs.
>> 
>> For example, if some boards have a SW-controlled regulator for a
>> device but others don't, the kernel still needs to have driver
>> code to actively control that regulator, /plus/ the regulator
>> subsystem needs to be able to substitute a dummy regulator if
>> it's optional or simply missing from the DT.
>> 
>> Another example: MMC drivers need to support some boards
>> detecting SD card presence or write-protect via arbitrary GPIOs,
>> and others via dedicated logic in the MMC controller.
>> 
>> In general, the kernel still needs a complete driver to every
>> last device on every strange board, and needs to support every
>> strange way some random board hooks all the devices together.
> 
> I have some difficulty understanding what you think should've been
> moved out of the kernel. There's only so much you can put into data
> structures and at some point you need to start writing device
> specific code for the peripherals that you want to drive.

My point was that (part of) the intent of adding DT support to the
kernel was to get rid of all the board-specific code/churn in the
kernel. That's not really possible, since DT is just representing the
data about the HW (e.g. which GPIO/IRQ numbers) and not the behaviour.
In order to really remove signifcant board-specific code from the
kernel, you need to move behaviour out of the kernel too, i.e. hide it
behind some kind of firmware or virtualization interface, and hence
have simpler drivers that don't know all the details.

...
>> * Would UEFI/ACPI/similar fulfill this role?
> 
> If I recall correctly, the original OpenFirmware that introduced
> the DT concept used to have something similar to UEFI/ACPI.
> Essentially it was possible to not only pass the DT to the
> operating system but also allow the operating system to call back
> into the firmware to request service.

Yes, OpenFirmware might be another possible firmware interface. I
don't know anything about it...

>> * Perhaps a standard virtualization interface could fulfil this
>> role?
...
> What will likely happen with such a solution is that we'll have to
> come up with a standard interface that the guest OS expects.

I think much of that is already defined for a paravirt KVM guest
though, right?

...
> Vendor kernels that implement the host OS will effectively become
> forks of their own since there's no incentive to upstream code
> anymore. Linux upstream becomes a single unified architecture
> because all interfaces are now the same. Vendors are back to
> brewing their own.

True. Many/most(?) vendors work like that for most *products* though
already...

> ...

(Yes, I fully acknowledge there are many issues with
firmware/virtualization as a platform...)

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Guenter Roeck]

On 10/21/2013 01:19 PM, Stephen Warren wrote:
> On 10/21/2013 09:54 AM, Thierry Reding wrote:
>> On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
> ...
>>> I wonder if DT is solving the problem at the right level of
>>> abstraction? The kernel still needs to be aware of all the
>>> nitty-gritty details of how each board is hooked up different,
>>> and have explicit code to deal the union of all the different
>>> board designs.
>>>
>>> For example, if some boards have a SW-controlled regulator for a
>>> device but others don't, the kernel still needs to have driver
>>> code to actively control that regulator, /plus/ the regulator
>>> subsystem needs to be able to substitute a dummy regulator if
>>> it's optional or simply missing from the DT.
>>>
>>> Another example: MMC drivers need to support some boards
>>> detecting SD card presence or write-protect via arbitrary GPIOs,
>>> and others via dedicated logic in the MMC controller.
>>>
>>> In general, the kernel still needs a complete driver to every
>>> last device on every strange board, and needs to support every
>>> strange way some random board hooks all the devices together.
>>
>> I have some difficulty understanding what you think should've been
>> moved out of the kernel. There's only so much you can put into data
>> structures and at some point you need to start writing device
>> specific code for the peripherals that you want to drive.
>
> My point was that (part of) the intent of adding DT support to the
> kernel was to get rid of all the board-specific code/churn in the
> kernel. That's not really possible, since DT is just representing the
> data about the HW (e.g. which GPIO/IRQ numbers) and not the behaviour.
> In order to really remove signifcant board-specific code from the
> kernel, you need to move behaviour out of the kernel too, i.e. hide it
> behind some kind of firmware or virtualization interface, and hence
> have simpler drivers that don't know all the details.
>

In my opinion, not being able to describe behavior (or what people refer
to as "describe how the hardware is used") is a severe limitation of
devicetree usage in Linux. That is not a devicetree limitation per se,
though, it is simply a matter of choice (or, in some cases, the ability
of those arguing for new bindings to sell those bindings as "hardware
description").

Guenter

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[James Hogan]

On 21/10/13 23:51, Guenter Roeck wrote:
> In my opinion, not being able to describe behavior (or what people refer
> to as "describe how the hardware is used") is a severe limitation of
> devicetree usage in Linux. That is not a devicetree limitation per se,
> though, it is simply a matter of choice (or, in some cases, the ability
> of those arguing for new bindings to sell those bindings as "hardware
> description").

I agree this is a real problem, and I think it hinders upstream
submission, since platform data was permitted to describe behaviour as
well as describe the hardware, and platform data is being replaced with
DT which is only permitted to describe the hardware. How then should we
specify the behaviour to the kernel?

I've already mentioned specific examples of this on the "Clock DT
bindings" thread, and would be very interested if anybody has thoughts
about it:
http://lkml.kernel.org/r/520E1DF5.4030409 at imgtec.com

Cheers
James

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Jonathan Cameron]

James Hogan <james.hogan@imgtec.com> wrote:
>On 21/10/13 23:51, Guenter Roeck wrote:
>> In my opinion, not being able to describe behavior (or what people
>refer
>> to as "describe how the hardware is used") is a severe limitation of
>> devicetree usage in Linux. That is not a devicetree limitation per
>se,
>> though, it is simply a matter of choice (or, in some cases, the
>ability
>> of those arguing for new bindings to sell those bindings as "hardware
>> description").
>
>I agree this is a real problem, and I think it hinders upstream
>submission, since platform data was permitted to describe behaviour as
>well as describe the hardware, and platform data is being replaced with
>DT which is only permitted to describe the hardware. How then should we
>specify the behaviour to the kernel?
>
>I've already mentioned specific examples of this on the "Clock DT
>bindings" thread, and would be very interested if anybody has thoughts
>about it:
>http://lkml.kernel.org/r/520E1DF5.4030409 at imgtec.com

We have run into a kind of similar issue with IIO. We are interested in describing sensors
 adcs,DACs etc and providing both userspace access and in kernel access to other drivers.

 Lots of sensors are used for different
 purposes on different devices. Simple example is free fall detection vs vibration
 analysis vs input for an accelerometer. User space expects data from different
 subsystems. We handle that via 'bridge' drivers.  So need a way to specify which
 bridge driver cares about which channels.
It is not always 'wiring' but it usually is dictated by the product implementation. 
Some aspects of this have been discussed but they only cover the is an ADC wired to an
 accelerometer case rather than the using the same physical hardware for on or more
 unrelated purpose.
Perhaps this case could be pushed into user space but then we just have another board
 specific bit of code...

Just to add that for IIO device tree mostly works pretty well.
>
>Cheers
>James
>
>_______________________________________________
>Ksummit-2013-discuss mailing list
>Ksummit-2013-discuss at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/ksummit-2013-discuss

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Guenter Roeck]

On Tue, Oct 22, 2013 at 05:31:25PM +0100, Jonathan Cameron wrote:
> 
> 
> James Hogan <james.hogan@imgtec.com> wrote:
> >On 21/10/13 23:51, Guenter Roeck wrote:
> >> In my opinion, not being able to describe behavior (or what people
> >refer
> >> to as "describe how the hardware is used") is a severe limitation of
> >> devicetree usage in Linux. That is not a devicetree limitation per
> >se,
> >> though, it is simply a matter of choice (or, in some cases, the
> >ability
> >> of those arguing for new bindings to sell those bindings as "hardware
> >> description").
> >
> >I agree this is a real problem, and I think it hinders upstream
> >submission, since platform data was permitted to describe behaviour as
> >well as describe the hardware, and platform data is being replaced with
> >DT which is only permitted to describe the hardware. How then should we
> >specify the behaviour to the kernel?
> >
> >I've already mentioned specific examples of this on the "Clock DT
> >bindings" thread, and would be very interested if anybody has thoughts
> >about it:
> >http://lkml.kernel.org/r/520E1DF5.4030409 at imgtec.com
> 
> We have run into a kind of similar issue with IIO. We are interested in describing sensors
>  adcs,DACs etc and providing both userspace access and in kernel access to other drivers.
> 
>  Lots of sensors are used for different
>  purposes on different devices. Simple example is free fall detection vs vibration
>  analysis vs input for an accelerometer. User space expects data from different
>  subsystems. We handle that via 'bridge' drivers.  So need a way to specify which
>  bridge driver cares about which channels.
> It is not always 'wiring' but it usually is dictated by the product implementation. 
> Some aspects of this have been discussed but they only cover the is an ADC wired to an
>  accelerometer case rather than the using the same physical hardware for on or more
>  unrelated purpose.
> Perhaps this case could be pushed into user space but then we just have another board
>  specific bit of code...
> 
> Just to add that for IIO device tree mostly works pretty well.

Yes, it does, only the iio-hwmon bridge is one of those cases where we are now
told that "this describes use, not the hardware itself". But how is one supposed
to describe that an ADC on a board is used as voltage sensor ? Does that mean one
would have to have a dedicated voltage sensor (or current sensor, for that
matter) to ensure that the use case is clear ?

Another example is my recent attempt to add dt support to gpio based connectors.
Even though a connector is as much hardware as it can get (or at least one
should think so), that was rejected because it isn't generic enough and,
after all, it describes the _use_ of gpio pins which apparently is already
borderline. So now I have my own out of tree driver (where I can add as many
bindings and as much functionality as I want and see fit, so I am not too
unhappy about that).

That matches Thierry's earlier comments - one is now _forced_ to maintain
out-of-tree code simply because DT bindings are either unacceptable, not generic
enough, or not stable enough to be accepted into the upstream kernel.

So far I have been able to work around that, but I seriously consider dropping
DT use entirely and moving back to platform data ... not the very least because
DT isn't supported on x86 and I have to deal with that situation as well (and,
no, ACPI doesn't solve my problems there either).

Mission accomplished, at least if the mission is to keep the code out
of the mainstream kernel and limiting DT use cases (or to make it unusable
for practical purposes).

Guenter

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Tue, Oct 22, 2013 at 09:49:22AM -0700, Guenter Roeck wrote:
> On Tue, Oct 22, 2013 at 05:31:25PM +0100, Jonathan Cameron wrote:
> > 
> > 
> > James Hogan <james.hogan@imgtec.com> wrote:
> > >On 21/10/13 23:51, Guenter Roeck wrote:
> > >> In my opinion, not being able to describe behavior (or what people
> > >refer
> > >> to as "describe how the hardware is used") is a severe limitation of
> > >> devicetree usage in Linux. That is not a devicetree limitation per
> > >se,
> > >> though, it is simply a matter of choice (or, in some cases, the
> > >ability
> > >> of those arguing for new bindings to sell those bindings as "hardware
> > >> description").
> > >
> > >I agree this is a real problem, and I think it hinders upstream
> > >submission, since platform data was permitted to describe behaviour as
> > >well as describe the hardware, and platform data is being replaced with
> > >DT which is only permitted to describe the hardware. How then should we
> > >specify the behaviour to the kernel?
> > >
> > >I've already mentioned specific examples of this on the "Clock DT
> > >bindings" thread, and would be very interested if anybody has thoughts
> > >about it:
> > >http://lkml.kernel.org/r/520E1DF5.4030409 at imgtec.com
> > 
> > We have run into a kind of similar issue with IIO. We are interested in describing sensors
> >  adcs,DACs etc and providing both userspace access and in kernel access to other drivers.
> > 
> >  Lots of sensors are used for different
> >  purposes on different devices. Simple example is free fall detection vs vibration
> >  analysis vs input for an accelerometer. User space expects data from different
> >  subsystems. We handle that via 'bridge' drivers.  So need a way to specify which
> >  bridge driver cares about which channels.
> > It is not always 'wiring' but it usually is dictated by the product implementation. 
> > Some aspects of this have been discussed but they only cover the is an ADC wired to an
> >  accelerometer case rather than the using the same physical hardware for on or more
> >  unrelated purpose.
> > Perhaps this case could be pushed into user space but then we just have another board
> >  specific bit of code...
> > 
> > Just to add that for IIO device tree mostly works pretty well.
> 
> Yes, it does, only the iio-hwmon bridge is one of those cases where we are now
> told that "this describes use, not the hardware itself". But how is one supposed
> to describe that an ADC on a board is used as voltage sensor ? Does that mean one
> would have to have a dedicated voltage sensor (or current sensor, for that
> matter) to ensure that the use case is clear ?

I'm not sure I understand correctly, but it seems to me like this isn't
actually about behaviour at all. Having something like:

	adc: adc {
		...
	};

	sensor {
		adc = <&adc>;
	};

sounds like an appropriate description of the hardware. Well, I guess it
doesn't quite accurately describe the hardware if one considers the ADC
to actually be the sensor, in which case, yeah, this actually describes
what the ADC is used for.

But on the other hand we do the same with other "resources". GPIOs for
example are rather useless if you don't associate them with specific
functionality. And we actually do that quite often. They are used in
properties such as:

	foo {
		...
		enable-gpios = <&gpio 42 0>;
		...
	};

I don't see how that is different to the ADC/sensor example above.
Perhaps there's no real physical device that is the sensor, but if we
can't even represent simple yet essential things like that in DT, then
we definitely need something better.

We do pretty much the same thing with regulators. We can have fixed
regulators that control a GPIO, yet there's no physical device that one
could associate with such regulators either.

> Another example is my recent attempt to add dt support to gpio based connectors.
> Even though a connector is as much hardware as it can get (or at least one
> should think so), that was rejected because it isn't generic enough and,
> after all, it describes the _use_ of gpio pins which apparently is already
> borderline. So now I have my own out of tree driver (where I can add as many
> bindings and as much functionality as I want and see fit, so I am not too
> unhappy about that).

That's odd. This sounds exactly like a variant of the above. Would you
mind posting the binding (or a usage example here)? I'd be interested to
understand why it would be inappropriate.

> That matches Thierry's earlier comments - one is now _forced_ to maintain
> out-of-tree code simply because DT bindings are either unacceptable, not generic
> enough, or not stable enough to be accepted into the upstream kernel.
> 
> So far I have been able to work around that, but I seriously consider dropping
> DT use entirely and moving back to platform data ...

I've actually been toying with that idea myself. Unfortunately it's very
difficult to do once you run on a platform that's completely moved to DT
because you actually have to manually search the DT in order to find any
references that you need.

> not the very least because DT isn't supported on x86 and I have to deal with
> that situation as well (and, no, ACPI doesn't solve my problems there either).

Actually DT is supported very well on x86. There's at least one platform
in mainline that uses it (arch/x86/platform/ce4100/falconfalls.dts) and
I've ported a platform that I worked on in the past to use DT on x86 as
well.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131022/1b284c60/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Guenter Roeck]

On Tue, Oct 22, 2013 at 10:35:47PM +0200, Thierry Reding wrote:
> On Tue, Oct 22, 2013 at 09:49:22AM -0700, Guenter Roeck wrote:
> > On Tue, Oct 22, 2013 at 05:31:25PM +0100, Jonathan Cameron wrote:
> > > 
> > > 
> > > James Hogan <james.hogan@imgtec.com> wrote:
> > > >On 21/10/13 23:51, Guenter Roeck wrote:
> > > >> In my opinion, not being able to describe behavior (or what people
> > > >refer
> > > >> to as "describe how the hardware is used") is a severe limitation of
> > > >> devicetree usage in Linux. That is not a devicetree limitation per
> > > >se,
> > > >> though, it is simply a matter of choice (or, in some cases, the
> > > >ability
> > > >> of those arguing for new bindings to sell those bindings as "hardware
> > > >> description").
> > > >
> > > >I agree this is a real problem, and I think it hinders upstream
> > > >submission, since platform data was permitted to describe behaviour as
> > > >well as describe the hardware, and platform data is being replaced with
> > > >DT which is only permitted to describe the hardware. How then should we
> > > >specify the behaviour to the kernel?
> > > >
> > > >I've already mentioned specific examples of this on the "Clock DT
> > > >bindings" thread, and would be very interested if anybody has thoughts
> > > >about it:
> > > >http://lkml.kernel.org/r/520E1DF5.4030409 at imgtec.com
> > > 
> > > We have run into a kind of similar issue with IIO. We are interested in describing sensors
> > >  adcs,DACs etc and providing both userspace access and in kernel access to other drivers.
> > > 
> > >  Lots of sensors are used for different
> > >  purposes on different devices. Simple example is free fall detection vs vibration
> > >  analysis vs input for an accelerometer. User space expects data from different
> > >  subsystems. We handle that via 'bridge' drivers.  So need a way to specify which
> > >  bridge driver cares about which channels.
> > > It is not always 'wiring' but it usually is dictated by the product implementation. 
> > > Some aspects of this have been discussed but they only cover the is an ADC wired to an
> > >  accelerometer case rather than the using the same physical hardware for on or more
> > >  unrelated purpose.
> > > Perhaps this case could be pushed into user space but then we just have another board
> > >  specific bit of code...
> > > 
> > > Just to add that for IIO device tree mostly works pretty well.
> > 
> > Yes, it does, only the iio-hwmon bridge is one of those cases where we are now
> > told that "this describes use, not the hardware itself". But how is one supposed
> > to describe that an ADC on a board is used as voltage sensor ? Does that mean one
> > would have to have a dedicated voltage sensor (or current sensor, for that
> > matter) to ensure that the use case is clear ?
> 
> I'm not sure I understand correctly, but it seems to me like this isn't
> actually about behaviour at all. Having something like:
> 
> 	adc: adc {
> 		...
> 	};
> 
> 	sensor {
> 		adc = <&adc>;
> 	};
> 
> sounds like an appropriate description of the hardware. Well, I guess it

One would think so.

> doesn't quite accurately describe the hardware if one considers the ADC
> to actually be the sensor, in which case, yeah, this actually describes
> what the ADC is used for.
> 
... but then there is this point of view. Thinking about it, much of
a hardware description can be seen as "use case", at least when it comes
to gpio pins or adc channels.

> But on the other hand we do the same with other "resources". GPIOs for
> example are rather useless if you don't associate them with specific
> functionality. And we actually do that quite often. They are used in
> properties such as:
> 
> 	foo {
> 		...
> 		enable-gpios = <&gpio 42 0>;
> 		...
> 	};
> 
> I don't see how that is different to the ADC/sensor example above.
> Perhaps there's no real physical device that is the sensor, but if we
> can't even represent simple yet essential things like that in DT, then
> we definitely need something better.
> 
I don't think the issue is "can". After all, the restriction that DT shall only
describe HW and not its use is purely arbitrary.

> We do pretty much the same thing with regulators. We can have fixed
> regulators that control a GPIO, yet there's no physical device that one
> could associate with such regulators either.
> 
> > Another example is my recent attempt to add dt support to gpio based connectors.
> > Even though a connector is as much hardware as it can get (or at least one
> > should think so), that was rejected because it isn't generic enough and,
> > after all, it describes the _use_ of gpio pins which apparently is already
> > borderline. So now I have my own out of tree driver (where I can add as many
> > bindings and as much functionality as I want and see fit, so I am not too
> > unhappy about that).
> 
> That's odd. This sounds exactly like a variant of the above. Would you
> mind posting the binding (or a usage example here)? I'd be interested to
> understand why it would be inappropriate.
> 

Patch 4 and 5 of https://lkml.org/lkml/2013/8/30/23.

The bindings I currently use are actually a bit more complex.
Here is an example.

        pic1 {
            compatible = "jnpr,pic-connector";
            presence-detect-gpios = <&gpio20 36 0x10013>;
            request-button-gpios = <&gpio20 38 0x10013>;
            power-enable-gpios = <&gpio20 42 0x0>;
            power-status-gpios = <&gpio20 39 0x3>;
            reset-gpios = <&gpio20 41 0x10000>;
            power-enable-timeout = <2000>;
            debounce-interval = <1>;
            led-green = <&pic1_green>;
            led-red = <&pic1_red>;

            i2c-bus {
                #address-cells = <1>;
                #size-cells = <0>;

                i2c-parent = <&pic1i2c>;

                eeprom at 55 {
                    compatible = "atmel,24c02";
                    reg = <0x55>;
                    ideeprom;
                };
            };
        };

[ Note this is preliminary, and I expect some of the bindings to change.
  Also, I have no plan to even try to get this code upstream ;) ]

> > That matches Thierry's earlier comments - one is now _forced_ to maintain
> > out-of-tree code simply because DT bindings are either unacceptable, not generic
> > enough, or not stable enough to be accepted into the upstream kernel.
> > 
> > So far I have been able to work around that, but I seriously consider dropping
> > DT use entirely and moving back to platform data ...
> 
> I've actually been toying with that idea myself. Unfortunately it's very
> difficult to do once you run on a platform that's completely moved to DT
> because you actually have to manually search the DT in order to find any
> references that you need.
> 
Yes, I know.

> > not the very least because DT isn't supported on x86 and I have to deal with
> > that situation as well (and, no, ACPI doesn't solve my problems there either).
> 
> Actually DT is supported very well on x86. There's at least one platform
> in mainline that uses it (arch/x86/platform/ce4100/falconfalls.dts) and
> I've ported a platform that I worked on in the past to use DT on x86 as
> well.
> 
But presumably that was DT only, or was it a system that needs to use
DT on top of ACPI ? If so, I would be very interested in that experience,
especially if you had any issues to get it working.

Thanks,
Guenter

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Tue, Oct 22, 2013 at 02:10:00PM -0700, Guenter Roeck wrote:
[...]
> Thinking about it, much of a hardware description can be seen as "use
> case", at least when it comes to gpio pins or adc channels.

There are many more examples where this is the case. Regulators are one
example. A regulator is pretty much useless until you connect it up to
some other device.

The same goes for things like a backlight. Sure we can expose backlights
via sysfs and tell people to use that interface to control the backlight
but that just doesn't always work. Furthermore, backlights don't always
need to be associated with display panels. They can be used together
with keyboards too...

In order to effectively make use of these basic building blocks we need
some way to interconnect them, because they cannot be correlated to each
other without some form of meta data.

> > But on the other hand we do the same with other "resources". GPIOs for
> > example are rather useless if you don't associate them with specific
> > functionality. And we actually do that quite often. They are used in
> > properties such as:
> > 
> > 	foo {
> > 		...
> > 		enable-gpios = <&gpio 42 0>;
> > 		...
> > 	};
> > 
> > I don't see how that is different to the ADC/sensor example above.
> > Perhaps there's no real physical device that is the sensor, but if we
> > can't even represent simple yet essential things like that in DT, then
> > we definitely need something better.
> > 
> I don't think the issue is "can". After all, the restriction that DT shall only
> describe HW and not its use is purely arbitrary.

That's what I was trying to say. "can" in the sense of "not able because
we're arbitrarily restricting what we can express with DT".

Now, I can even understand why it's a good idea to keep Linux-specifics
out of the DT and not encode software policy within it, but all these
examples aren't software policy nor Linux-specifics. In my opinion they
describe hardware. They may not restrict themselves to the bare minimum,
but they give meaning to the hardware so that an operating system can
use it.

If we cannot describe these things in DT but have to come up with some
alternative method to describe it, then any other operating system would
either need to copy that alternative method (in which case there's no
point at all in keeping it separate from DT) or invent yet something
different to describe those relationships.

I've said above that I understand why it can be good to keep DT hardware
specific, but I also think that if that's what we end up deciding, we'll
still need to supplement it with something that can describe software
policy. With our concept of DT right now we're regressing with respect
to board files because some things can no longer be described.

> > We do pretty much the same thing with regulators. We can have fixed
> > regulators that control a GPIO, yet there's no physical device that one
> > could associate with such regulators either.
> > 
> > > Another example is my recent attempt to add dt support to gpio based connectors.
> > > Even though a connector is as much hardware as it can get (or at least one
> > > should think so), that was rejected because it isn't generic enough and,
> > > after all, it describes the _use_ of gpio pins which apparently is already
> > > borderline. So now I have my own out of tree driver (where I can add as many
> > > bindings and as much functionality as I want and see fit, so I am not too
> > > unhappy about that).
> > 
> > That's odd. This sounds exactly like a variant of the above. Would you
> > mind posting the binding (or a usage example here)? I'd be interested to
> > understand why it would be inappropriate.
> > 
> 
> Patch 4 and 5 of https://lkml.org/lkml/2013/8/30/23.
> 
> The bindings I currently use are actually a bit more complex.
> Here is an example.
> 
>         pic1 {
>             compatible = "jnpr,pic-connector";
>             presence-detect-gpios = <&gpio20 36 0x10013>;
>             request-button-gpios = <&gpio20 38 0x10013>;
>             power-enable-gpios = <&gpio20 42 0x0>;
>             power-status-gpios = <&gpio20 39 0x3>;
>             reset-gpios = <&gpio20 41 0x10000>;
>             power-enable-timeout = <2000>;
>             debounce-interval = <1>;
>             led-green = <&pic1_green>;
>             led-red = <&pic1_red>;
> 
>             i2c-bus {
>                 #address-cells = <1>;
>                 #size-cells = <0>;
> 
>                 i2c-parent = <&pic1i2c>;
> 
>                 eeprom at 55 {
>                     compatible = "atmel,24c02";
>                     reg = <0x55>;
>                     ideeprom;
>                 };
>             };
>         };
> 
> [ Note this is preliminary, and I expect some of the bindings to change.
>   Also, I have no plan to even try to get this code upstream ;) ]

This is rather complex, but then, describing relationships within one
board is already difficult, so I'm not surprised that describing
connections between boards is even more difficult. I suspect that the
above could more traditionally be written as:

	pic1i2c: i2c-controller {
		...

		eeprom at 55 {
			/* insert all other properties here */
		};
	};

But that breaks down once you start needing to represent more than just
a single EEPROM behind the connector.

> > > not the very least because DT isn't supported on x86 and I have to deal with
> > > that situation as well (and, no, ACPI doesn't solve my problems there either).
> > 
> > Actually DT is supported very well on x86. There's at least one platform
> > in mainline that uses it (arch/x86/platform/ce4100/falconfalls.dts) and
> > I've ported a platform that I worked on in the past to use DT on x86 as
> > well.
> > 
> But presumably that was DT only, or was it a system that needs to use
> DT on top of ACPI ? If so, I would be very interested in that experience,
> especially if you had any issues to get it working.

I'm not quite sure I understand what you mean by "on top of ACPI". The
device certainly did support ACPI, but I was using DT more as a
supplement to describe what ACPI and PCI couldn't.

To be somewhat more specific, the platform used an FPGA connected to the
chipset using PCIe. That itself was excellent because all of a sudden
devices were actually discoverable. So it was easy to just implement a
GPIO, SPI or I2C controller and whatnot within that FPGA, but once a
device behind SPI or I2C needed to be hooked up, you loose all benefits
from having something like PCI and you're back to square one.

One example where this became essential was that the touchscreen on the
device was controlled by an I2C chip, and the touchscreen controller's
interrupt pin was connected to the GPIO controller on the PCI bus. So
what we ended up with looked roughly something like this:

	pci at 3fc {
		[...bunch of nodes to describe PCI hierarchy...]

		pci at 2,0 {
			/* GPIO expander */
			gpio: pci at 0,0 {
				...
				interrupt-controller;
				...
			};
		};

		[...more nodes...]

		pci at 8,0 {
			/* I2C controller */
			pci at 0,0 {
				touchscreen at 48 {
					...
					interrupt-parent = <&gpio>;
					interrupts = <1 0x8>;
					...
				};
			};
		};
	};

That's a *very* simplified form. The complete device tree is much more
complex because it requires the exact hierarchy of PCI to be represented
in order for the right device nodes to end up attached to the right PCI
devices.

But perhaps that doesn't help you at all with the problems that you've
encountered?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131023/9e6fded2/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Guenter Roeck]

On Wed, Oct 23, 2013 at 09:57:58AM +0200, Thierry Reding wrote:
> On Tue, Oct 22, 2013 at 02:10:00PM -0700, Guenter Roeck wrote:
> [...]
> > Thinking about it, much of a hardware description can be seen as "use
> > case", at least when it comes to gpio pins or adc channels.
> 
> There are many more examples where this is the case. Regulators are one
> example. A regulator is pretty much useless until you connect it up to
> some other device.
> 
> The same goes for things like a backlight. Sure we can expose backlights
> via sysfs and tell people to use that interface to control the backlight
> but that just doesn't always work. Furthermore, backlights don't always
> need to be associated with display panels. They can be used together
> with keyboards too...
> 
> In order to effectively make use of these basic building blocks we need
> some way to interconnect them, because they cannot be correlated to each
> other without some form of meta data.
> 
Yes. I think the problem starts if the interconnect point is not another chip.
It is easy to say "this gpio pin is connected to the interrupt pin of chip X",
but things become murky if you need to express that a gpio pin connects to a
pushbutton or presence detect pin, or if you need to express that an ADC input
pin is used as voltage sensor.

The common theme nowadays seems to be "you can't do that, it is a use case".
It might be more helpful if the feedback was "you can not describe it that way,
let's find another binding that works".

> > > But on the other hand we do the same with other "resources". GPIOs for
> > > example are rather useless if you don't associate them with specific
> > > functionality. And we actually do that quite often. They are used in
> > > properties such as:
> > > 
> > > 	foo {
> > > 		...
> > > 		enable-gpios = <&gpio 42 0>;
> > > 		...
> > > 	};
> > > 
> > > I don't see how that is different to the ADC/sensor example above.
> > > Perhaps there's no real physical device that is the sensor, but if we
> > > can't even represent simple yet essential things like that in DT, then
> > > we definitely need something better.
> > > 
> > I don't think the issue is "can". After all, the restriction that DT shall only
> > describe HW and not its use is purely arbitrary.
> 
> That's what I was trying to say. "can" in the sense of "not able because
> we're arbitrarily restricting what we can express with DT".
> 
ok.

> Now, I can even understand why it's a good idea to keep Linux-specifics
> out of the DT and not encode software policy within it, but all these
> examples aren't software policy nor Linux-specifics. In my opinion they
> describe hardware. They may not restrict themselves to the bare minimum,
> but they give meaning to the hardware so that an operating system can
> use it.
> 
> If we cannot describe these things in DT but have to come up with some
> alternative method to describe it, then any other operating system would
> either need to copy that alternative method (in which case there's no
> point at all in keeping it separate from DT) or invent yet something
> different to describe those relationships.
> 
> I've said above that I understand why it can be good to keep DT hardware
> specific, but I also think that if that's what we end up deciding, we'll
> still need to supplement it with something that can describe software
> policy. With our concept of DT right now we're regressing with respect
> to board files because some things can no longer be described.
> 
Agreed.

> > > We do pretty much the same thing with regulators. We can have fixed
> > > regulators that control a GPIO, yet there's no physical device that one
> > > could associate with such regulators either.
> > > 
> > > > Another example is my recent attempt to add dt support to gpio based connectors.
> > > > Even though a connector is as much hardware as it can get (or at least one
> > > > should think so), that was rejected because it isn't generic enough and,
> > > > after all, it describes the _use_ of gpio pins which apparently is already
> > > > borderline. So now I have my own out of tree driver (where I can add as many
> > > > bindings and as much functionality as I want and see fit, so I am not too
> > > > unhappy about that).
> > > 
> > > That's odd. This sounds exactly like a variant of the above. Would you
> > > mind posting the binding (or a usage example here)? I'd be interested to
> > > understand why it would be inappropriate.
> > > 
> > 
> > Patch 4 and 5 of https://lkml.org/lkml/2013/8/30/23.
> > 
> > The bindings I currently use are actually a bit more complex.
> > Here is an example.
> > 
> >         pic1 {
> >             compatible = "jnpr,pic-connector";
> >             presence-detect-gpios = <&gpio20 36 0x10013>;
> >             request-button-gpios = <&gpio20 38 0x10013>;
> >             power-enable-gpios = <&gpio20 42 0x0>;
> >             power-status-gpios = <&gpio20 39 0x3>;
> >             reset-gpios = <&gpio20 41 0x10000>;
> >             power-enable-timeout = <2000>;
> >             debounce-interval = <1>;
> >             led-green = <&pic1_green>;
> >             led-red = <&pic1_red>;
> > 
> >             i2c-bus {
> >                 #address-cells = <1>;
> >                 #size-cells = <0>;
> > 
> >                 i2c-parent = <&pic1i2c>;
> > 
> >                 eeprom at 55 {
> >                     compatible = "atmel,24c02";
> >                     reg = <0x55>;
> >                     ideeprom;
> >                 };
> >             };
> >         };
> > 
> > [ Note this is preliminary, and I expect some of the bindings to change.
> >   Also, I have no plan to even try to get this code upstream ;) ]
> 
> This is rather complex, but then, describing relationships within one
> board is already difficult, so I'm not surprised that describing
> connections between boards is even more difficult. I suspect that the
> above could more traditionally be written as:
> 
> 	pic1i2c: i2c-controller {
> 		...
> 
> 		eeprom at 55 {
> 			/* insert all other properties here */
> 		};
> 	};
> 
If I add the above to the i2c controller node, the kernel will try to
instantiate the eeprom when the system comes up. If no card is
inserted at that time, this will fail. The above describes the devices
which needs to be instantiated after a card is inserted into the connector,
and only then (and removed when the card is pulled).
In addition, I use the 'ideeprom' property to establish a callback
to be able to read the eeprom contents and trigger loading the DT overlay.

> But that breaks down once you start needing to represent more than just
> a single EEPROM behind the connector.
> 
And if insertion is dynamic, triggered by card insertion.

There are actually several additional i2c devices on the same bus.
To instantiate those I use devicetree overlays, but that is done
after the eeprom is read and I know which overlay to load.

> > > > not the very least because DT isn't supported on x86 and I have to deal with
> > > > that situation as well (and, no, ACPI doesn't solve my problems there either).
> > > 
> > > Actually DT is supported very well on x86. There's at least one platform
> > > in mainline that uses it (arch/x86/platform/ce4100/falconfalls.dts) and
> > > I've ported a platform that I worked on in the past to use DT on x86 as
> > > well.
> > > 
> > But presumably that was DT only, or was it a system that needs to use
> > DT on top of ACPI ? If so, I would be very interested in that experience,
> > especially if you had any issues to get it working.
> 
> I'm not quite sure I understand what you mean by "on top of ACPI". The
> device certainly did support ACPI, but I was using DT more as a
> supplement to describe what ACPI and PCI couldn't.
> 
> To be somewhat more specific, the platform used an FPGA connected to the
> chipset using PCIe. That itself was excellent because all of a sudden
> devices were actually discoverable. So it was easy to just implement a
> GPIO, SPI or I2C controller and whatnot within that FPGA, but once a
> device behind SPI or I2C needed to be hooked up, you loose all benefits
> from having something like PCI and you're back to square one.
> 
> One example where this became essential was that the touchscreen on the
> device was controlled by an I2C chip, and the touchscreen controller's
> interrupt pin was connected to the GPIO controller on the PCI bus. So
> what we ended up with looked roughly something like this:
> 
> 	pci at 3fc {
> 		[...bunch of nodes to describe PCI hierarchy...]
> 
> 		pci at 2,0 {
> 			/* GPIO expander */
> 			gpio: pci at 0,0 {
> 				...
> 				interrupt-controller;
> 				...
> 			};
> 		};
> 
> 		[...more nodes...]
> 
> 		pci at 8,0 {
> 			/* I2C controller */
> 			pci at 0,0 {
> 				touchscreen at 48 {
> 					...
> 					interrupt-parent = <&gpio>;
> 					interrupts = <1 0x8>;
> 					...
> 				};
> 			};
> 		};
> 	};
> 
> That's a *very* simplified form. The complete device tree is much more
> complex because it requires the exact hierarchy of PCI to be represented
> in order for the right device nodes to end up attached to the right PCI
> devices.
> 
> But perhaps that doesn't help you at all with the problems that you've
> encountered?
> 
Actually, the use case sounds pretty similar, so maybe you have solved the
problem at least to some degree. In my case, I'll also need devicetree overlays,
since I also need to be able to handle OIR capable cards, but that is a separate
set of problems.

Was this just a matter of enabling OF on this platform, or do you have an
out-of-tree set of patches ? If the latter, is it available somewhere
to look at (including the complete devicetree from your above example) ?

Thanks,
Guenter

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Wed, Oct 23, 2013 at 09:01:31AM -0700, Guenter Roeck wrote:
> On Wed, Oct 23, 2013 at 09:57:58AM +0200, Thierry Reding wrote:
[...]
> > 	pic1i2c: i2c-controller {
> > 		...
> > 
> > 		eeprom at 55 {
> > 			/* insert all other properties here */
> > 		};
> > 	};
> > 
> If I add the above to the i2c controller node, the kernel will try to
> instantiate the eeprom when the system comes up. If no card is
> inserted at that time, this will fail. The above describes the devices
> which needs to be instantiated after a card is inserted into the connector,
> and only then (and removed when the card is pulled).
> In addition, I use the 'ideeprom' property to establish a callback
> to be able to read the eeprom contents and trigger loading the DT overlay.

That's an interesting setup and a pretty elegant solution.

> > But that breaks down once you start needing to represent more than just
> > a single EEPROM behind the connector.
> > 
> And if insertion is dynamic, triggered by card insertion.
> 
> There are actually several additional i2c devices on the same bus.
> To instantiate those I use devicetree overlays, but that is done
> after the eeprom is read and I know which overlay to load.

Yes, I see why you need something less traditional to pull that off. And
we should be able to describe that kind of setup using DT as well. The
world would of course be much better if this was all discoverable and we
didn't have to describe it in the first place...

> > > > > not the very least because DT isn't supported on x86 and I have to deal with
> > > > > that situation as well (and, no, ACPI doesn't solve my problems there either).
> > > > 
> > > > Actually DT is supported very well on x86. There's at least one platform
> > > > in mainline that uses it (arch/x86/platform/ce4100/falconfalls.dts) and
> > > > I've ported a platform that I worked on in the past to use DT on x86 as
> > > > well.
> > > > 
> > > But presumably that was DT only, or was it a system that needs to use
> > > DT on top of ACPI ? If so, I would be very interested in that experience,
> > > especially if you had any issues to get it working.
> > 
> > I'm not quite sure I understand what you mean by "on top of ACPI". The
> > device certainly did support ACPI, but I was using DT more as a
> > supplement to describe what ACPI and PCI couldn't.
> > 
> > To be somewhat more specific, the platform used an FPGA connected to the
> > chipset using PCIe. That itself was excellent because all of a sudden
> > devices were actually discoverable. So it was easy to just implement a
> > GPIO, SPI or I2C controller and whatnot within that FPGA, but once a
> > device behind SPI or I2C needed to be hooked up, you loose all benefits
> > from having something like PCI and you're back to square one.
> > 
> > One example where this became essential was that the touchscreen on the
> > device was controlled by an I2C chip, and the touchscreen controller's
> > interrupt pin was connected to the GPIO controller on the PCI bus. So
> > what we ended up with looked roughly something like this:
> > 
> > 	pci at 3fc {
> > 		[...bunch of nodes to describe PCI hierarchy...]
> > 
> > 		pci at 2,0 {
> > 			/* GPIO expander */
> > 			gpio: pci at 0,0 {
> > 				...
> > 				interrupt-controller;
> > 				...
> > 			};
> > 		};
> > 
> > 		[...more nodes...]
> > 
> > 		pci at 8,0 {
> > 			/* I2C controller */
> > 			pci at 0,0 {
> > 				touchscreen at 48 {
> > 					...
> > 					interrupt-parent = <&gpio>;
> > 					interrupts = <1 0x8>;
> > 					...
> > 				};
> > 			};
> > 		};
> > 	};
> > 
> > That's a *very* simplified form. The complete device tree is much more
> > complex because it requires the exact hierarchy of PCI to be represented
> > in order for the right device nodes to end up attached to the right PCI
> > devices.
> > 
> > But perhaps that doesn't help you at all with the problems that you've
> > encountered?
> > 
> Actually, the use case sounds pretty similar, so maybe you have solved the
> problem at least to some degree. In my case, I'll also need devicetree overlays,
> since I also need to be able to handle OIR capable cards, but that is a separate
> set of problems.
> 
> Was this just a matter of enabling OF on this platform, or do you have an
> out-of-tree set of patches ? If the latter, is it available somewhere
> to look at (including the complete devicetree from your above example) ?

It was mostly a matter of enabling OF and writing the device tree. Most
of the generic kernel code changes I even got merged, but there were a
few patches that I never got around to merge. Some weren't anywhere
close to a mergeable state either.

I no longer work for the company and don't have access to the patches.
But I can ping a few people and see if I can dig up something for you.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131023/0c67cd55/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Guenter Roeck]

On Wed, Oct 23, 2013 at 11:07:16PM +0200, Thierry Reding wrote:
[ ... ]
> > 
> > Was this just a matter of enabling OF on this platform, or do you have an
> > out-of-tree set of patches ? If the latter, is it available somewhere
> > to look at (including the complete devicetree from your above example) ?
> 
> It was mostly a matter of enabling OF and writing the device tree. Most
> of the generic kernel code changes I even got merged, but there were a
> few patches that I never got around to merge. Some weren't anywhere
> close to a mergeable state either.
> 
> I no longer work for the company and don't have access to the patches.
> But I can ping a few people and see if I can dig up something for you.
> 
That would be great.

Thanks,
Guenter

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Thu, Oct 24, 2013 at 08:18:53AM -0700, Guenter Roeck wrote:
> On Wed, Oct 23, 2013 at 11:07:16PM +0200, Thierry Reding wrote:
> [ ... ]
> > > 
> > > Was this just a matter of enabling OF on this platform, or do you have an
> > > out-of-tree set of patches ? If the latter, is it available somewhere
> > > to look at (including the complete devicetree from your above example) ?
> > 
> > It was mostly a matter of enabling OF and writing the device tree. Most
> > of the generic kernel code changes I even got merged, but there were a
> > few patches that I never got around to merge. Some weren't anywhere
> > close to a mergeable state either.
> > 
> > I no longer work for the company and don't have access to the patches.
> > But I can ping a few people and see if I can dig up something for you.
> > 
> That would be great.

Hi Guenter,

It took some time, but here's the tree:

	https://github.com/avionic-design/linux/commits/medatom/master

The device tree files are in arch/x86/boot/dts (as expected I guess). A
linux-next from over a year ago was used as the base for that branch, so
some of that will be stale, but DT is a stable ABI, so that should still
be valid. =)

If you have any questions, please don't hesitate to ask. Although I have
not been working on that for a while, so my memories about it aren't all
that fresh anymore.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131101/ab3c84f4/attachment.sig>

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Guenter Roeck]

On 11/01/2013 03:36 AM, Thierry Reding wrote:
> On Thu, Oct 24, 2013 at 08:18:53AM -0700, Guenter Roeck wrote:
>> On Wed, Oct 23, 2013 at 11:07:16PM +0200, Thierry Reding wrote:
>> [ ... ]
>>>>
>>>> Was this just a matter of enabling OF on this platform, or do you have an
>>>> out-of-tree set of patches ? If the latter, is it available somewhere
>>>> to look at (including the complete devicetree from your above example) ?
>>>
>>> It was mostly a matter of enabling OF and writing the device tree. Most
>>> of the generic kernel code changes I even got merged, but there were a
>>> few patches that I never got around to merge. Some weren't anywhere
>>> close to a mergeable state either.
>>>
>>> I no longer work for the company and don't have access to the patches.
>>> But I can ping a few people and see if I can dig up something for you.
>>>
>> That would be great.
>
> Hi Guenter,
>
> It took some time, but here's the tree:
>
> 	https://github.com/avionic-design/linux/commits/medatom/master
>
> The device tree files are in arch/x86/boot/dts (as expected I guess). A
> linux-next from over a year ago was used as the base for that branch, so
> some of that will be stale, but DT is a stable ABI, so that should still
> be valid. =)
>
> If you have any questions, please don't hesitate to ask. Although I have
> not been working on that for a while, so my memories about it aren't all
> that fresh anymore.
>
> Thierry
>
Hi Thierry,

that is great - thanks a lot!

Guenter

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Tue, Oct 22, 2013 at 11:27:32AM +0100, James Hogan wrote:
> On 21/10/13 23:51, Guenter Roeck wrote:
> > In my opinion, not being able to describe behavior (or what people refer
> > to as "describe how the hardware is used") is a severe limitation of
> > devicetree usage in Linux. That is not a devicetree limitation per se,
> > though, it is simply a matter of choice (or, in some cases, the ability
> > of those arguing for new bindings to sell those bindings as "hardware
> > description").
> 
> I agree this is a real problem, and I think it hinders upstream
> submission, since platform data was permitted to describe behaviour as
> well as describe the hardware, and platform data is being replaced with
> DT which is only permitted to describe the hardware. How then should we
> specify the behaviour to the kernel?
> 
> I've already mentioned specific examples of this on the "Clock DT
> bindings" thread, and would be very interested if anybody has thoughts
> about it:
> http://lkml.kernel.org/r/520E1DF5.4030409 at imgtec.com

I've certainly run into similar problems. To be specific, one such
instance involved backlight devices. In a nutshell, Linux' backlight
subsystem by default enables a backlight when it is probed (well, the
subsystem doesn't do that, but pretty much every driver does). This
seems to have worked very well, but when you hook up a backlight with
something high-level such as DRM, the fact that you no longer control
when the backlight is turned on becomes a problem. DRM knows very
precisely when a backlight or panel should be turned on, because it's
tightly coupled with when the display controller starts sending data to
the display. If the backlight is turned on by default at some
unpredictable point during the boot process, you end up with a powered
backlight that shows you all sorts of artifacts while the display is
being initialized.

My first attempt at solving this was to add a backlight-boot-off
property to the device tree, which would make the device driver keep the
backlight turned off on boot by default so that the DRM driver would be
able to turn it on only after the display was properly initialized.

Obviously that doesn't represent the hardware but some random bit of
software policy. The bad thing about it is that there's no other place
to put this bit of information. I can't change the default behaviour of
the backlight driver either because it is generic and used by many other
boards. So what's the solution to that? Perhaps duplicate the driver
with only the boot on default changed? Or add a new compatible value
"pwm-backlight-disabled-on-boot"? Guess that won't be acceptable either
because it encodes behaviour. "pwm-backlight-v2" wouldn't encode any
behaviour...

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131022/c67ec51a/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Oct 21, 2013 at 09:19:21PM +0100, Stephen Warren wrote:
> On 10/21/2013 09:54 AM, Thierry Reding wrote:
> > On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
> ...
> >> I wonder if DT is solving the problem at the right level of
> >> abstraction? The kernel still needs to be aware of all the
> >> nitty-gritty details of how each board is hooked up different,
> >> and have explicit code to deal the union of all the different
> >> board designs.
> >> 
> >> For example, if some boards have a SW-controlled regulator for a
> >> device but others don't, the kernel still needs to have driver
> >> code to actively control that regulator, /plus/ the regulator
> >> subsystem needs to be able to substitute a dummy regulator if
> >> it's optional or simply missing from the DT.
> >> 
> >> Another example: MMC drivers need to support some boards
> >> detecting SD card presence or write-protect via arbitrary GPIOs,
> >> and others via dedicated logic in the MMC controller.
> >> 
> >> In general, the kernel still needs a complete driver to every
> >> last device on every strange board, and needs to support every
> >> strange way some random board hooks all the devices together.
> > 
> > I have some difficulty understanding what you think should've been
> > moved out of the kernel. There's only so much you can put into data
> > structures and at some point you need to start writing device
> > specific code for the peripherals that you want to drive.
> 
> My point was that (part of) the intent of adding DT support to the
> kernel was to get rid of all the board-specific code/churn in the
> kernel. That's not really possible, since DT is just representing the
> data about the HW (e.g. which GPIO/IRQ numbers) and not the behaviour.
> In order to really remove signifcant board-specific code from the
> kernel, you need to move behaviour out of the kernel too, i.e. hide it
> behind some kind of firmware or virtualization interface, and hence
> have simpler drivers that don't know all the details.

I think we've done a pretty good job at extracting board-specific code,
though. The majority of drivers has moved to appropriate subsystems and
therefore isn't board-specific at all anymore.

Doesn't anything beyond that involve abstracting away the differences
between SoCs? If I understand correctly what you envision is something
that would abstract the hardware differences of various SoCs and provide
a standard interface to access peripherals. For example, instead of
implementing a kernel driver for an MMC controller per SoC, the firmware
would instead implement a well-defined set of operations that can be
performed on an MMC controller and a generic "firmware" driver within
the Linux kernel would call into the firmware and register the services
with the kernel, so that it could be exposed to userspace in the usual
way.

But in that case we'd just be moving code from kernel to firmware. At
the same time we'd loose all the advantages that come with keeping code
in the kernel.

The kernel already provides a generic interface for devices to implement
by means of the subsystem APIs.

Even on x86 where standardization has been going on for decades I don't
think firmware actually abstracts away at that level. I think I've seen
something similar done for backlight devices that could be controlled
via ACPI, but anything beyond that level of complexity probably becomes
impractical to standardize without loosing much of the hardware
capabilities.

> ...
> >> * Would UEFI/ACPI/similar fulfill this role?
> > 
> > If I recall correctly, the original OpenFirmware that introduced
> > the DT concept used to have something similar to UEFI/ACPI.
> > Essentially it was possible to not only pass the DT to the
> > operating system but also allow the operating system to call back
> > into the firmware to request service.
> 
> Yes, OpenFirmware might be another possible firmware interface. I
> don't know anything about it...

I think it has about the same scope as the virtualization solution that
you propose. It will work fairly well with exposing things such as PCI
configuration space access for each PCI-type device. Where I don't see
it perform very well is for things such as GPUs where it isn't trivial
to find an exhaustive, yet unified, set of services that devices have to
provide.

> >> * Perhaps a standard virtualization interface could fulfil this
> >> role?
> ...
> > What will likely happen with such a solution is that we'll have to
> > come up with a standard interface that the guest OS expects.
> 
> I think much of that is already defined for a paravirt KVM guest
> though, right?

Possibly. I have no complete understanding of how exactly KVM achieves
this.

> ...
> > Vendor kernels that implement the host OS will effectively become
> > forks of their own since there's no incentive to upstream code
> > anymore. Linux upstream becomes a single unified architecture
> > because all interfaces are now the same. Vendors are back to
> > brewing their own.
> 
> True. Many/most(?) vendors work like that for most *products* though
> already...

I agree. But we're having this discussion because that's something we
want to change, right? Eventually I'd like for upstream Linux to become
what vendors use to develop on primarily, while downstream kernels are
merely the (hopefully small) delta of what's not considered good enough
quality for upstream.

> > ...
> 
> (Yes, I fully acknowledge there are many issues with
> firmware/virtualization as a platform...)

Probably the most important issue wouldn't exist with such a solution.
The firmware/host OS would likely be open-source and therefore easy to
fix when broken. At the same time it adds another dependency that we
need to carefully manage, thereby further complicating matters.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131022/60de1293/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Matt Sealey]

On Sun, Oct 20, 2013 at 4:26 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>
> I wonder if DT is solving the problem at the right level of abstraction?
> The kernel still needs to be aware of all the nitty-gritty details of
> how each board is hooked up different, and have explicit code to deal
> the union of all the different board designs.

Indeed, but it's relatively generic and defined, as you discussed later.

The original method was define some custom platform data structure,
pass it to the platform device on init, have that platform device
parse that custom platform data - for each SDHC controller (in your
example) there was a separate and somewhat uniquely typed and named
structure (and sometimes, ridiculously, content-identical to some
other platform).

Now if you want to know the GPIOs for CD/WP or if they're even in use,
you test for the property, use it's value.. and that property and
value is well defined (to some degree). Every driver duplicates this
code, but then it can be cleaned up and made a support call somewhere
(parsing things like dr_mode for USB ports is, as a good example,
already support code, as are properties for Ethernet PHYs)

> For example, if some boards have a SW-controlled regulator for a device
> but others don't, the kernel still needs to have driver code to actively
> control that regulator, /plus/ the regulator subsystem needs to be able
> to substitute a dummy regulator if it's optional or simply missing from
> the DT.

No. The correct way when a device does not have a controllable
regulator is to NOT SPECIFY a regulator. That way the driver should
never attempt control of it.

If the regulator is optional it follows quite nicely that the property
is optional. Any driver that fails probing for an optional property is
broken and needs fixing.

> In general, the kernel still needs a complete driver to every last
> device on every strange board

Pardon my being frank, but.. no shit! Of course you need drivers. The
point of DT isn't to implement drivers, or at least it WAS the point
(to give a structured way to access those drivers) but with a
flattened, non-programmatic model there's nothing to access. What it
does is shore up the other side of the equation - if you wanted a
block device under OpenFirmware, it was there with device_type =
"block" and then you opened a standard block package on it, and then
read data from it through the package calls. You had to instruct it
WHICH block device to use if you wanted specific data from a specific
block device...

The DT here is simply a way to find which block device (by path into
the tree) you want to open.

In the flattened model, it describes where that device exists so a
driver can attach to it and provide it's own standardized block layer.

The reason OF wasn't an option for the people lauding FDT, is because
you needed two drivers - one for firmware, one for the OS. FDT lets
you get one driver, in the OS. Of course, this is based on the
assumption that your OS kernel is almost directly bootstrapped from
bare metal, which is fairly difficult to achieve on most systems, on
power-on. You will need a dynamic, driver-full bootloader to get the
most flexible Linux boot and for a desktop system where there may be
many boot sources this is the way to do it. Of course, there are ways
around it, but they make for very, very expensive systems in
comparison. Most ARM SoCs have external pins to strap on boot to
direct it to a special bootable media process, but most users are not
going to flip DIP switches..

> and needs to support every strange way some random board hooks all the devices together.

Most of them are not strange, but very well defined. Electrically
there are only so many ways.. there are only so many pads on the
bottom of your SoC packaging. There are only so many peripheral
controllers to attach, most of them following very well defined
standards and buses and protocols.

> by DT - if anything, it's more complicated since we now have to parse
> those values from DT rather than putting them into simple data-structures.

As above, where this code is duplicated it can be moved into support code.

> * Would UEFI/ACPI/similar fulfill this role?

In the sense that it would require, yet again, a two-driver-model
implementation.. no, not for the FDT guys. That said, there's no
reason you couldn't use FDT to control the EFI driver binding protocol
Supported() function, or supply Device Paths. Nothing in the EFI spec
says those paths need to be ACPI paths or Windows-like filesystem
paths (except the odd expectation of backslashes).

ACPI would be a good fix, but you'd have to spend a year ratifying the
same kinds of bindings through the ACPI-CA. Which may come out wrong.
ACPI isn't as stable as it seems, and it's just as easy to get your
DSDT wrong as an FDT, or do something super-screwy in your AML for a
device.

> * Perhaps a standard virtualization interface could fulfil this role?
> IIUC, there are already standard mechanisms of exposing e.g. disks, USB
> devices, PCI devices, etc. into VMs, and recent ARM HW[1] supports
> virtualization well now. A sticking point might be graphics, but it
> sounds like there's work to transport GL or Gallium command streams over
> the virtualization divide.

For power state, there's ARM PSCI - this abstracts bringing cores up
and down, and possibly in the future some voltage and frequency
scaling, since this can get EXTREMELY hairy in multi-core,
multi-cluster environments. Depending on the myriad cluster
configurations, core implementations possible and the buses wiring
them together - and that is just the ARM part of it, frequency scaling
and power regulation is vendor-implementation-specific - it would end
up with the kernel having to know EXTREMELY nitty gritty details about
the underlying hardware and configuration which ends up being far too
dynamic to put into a binding that makes any sense (essentially, doing
it the DT way means having a special processor binding for every
IMPLEMENTATION of a standard ARM core).

For everything else, there's the SMC calling convention PSCI is based
on, and while this allows exactly what you're asking for, it requires
someone to code it on the platform.

So there are the following things to keep in mind:

* You can easily abstract, say, an SD controller which has a very well
defined card register set and protocol (that is the important bit),
and a very well defined physical layer, and you would hide the
implementation details. There are standard voltage levels, standard IO
practices, and very few real implementation differences, otherwise no
one SD card would work with every SD card controller.

* You can do the same for SATA or USB where the controller is very
well defined host register set and behavior on the device side. This
is the "perfect storm" of abstraction, and it's why libata works.

* You can abstract serial ports - up to a point - and byte-transfer
buses in general, and byte-transfer buses with addressing (i2c and
spi, i2c uses protocol and spi uses chipselects which is almost
addressing) and those that support block transfers (multiplexing large
amounts of data through a narrower bus) and hide most of the details
here without even knowing it's i2c or spi or qspi or sdio - but every
device would have to support every possible implementation detail of
every kind, meaning the abstraction grows to an enormous size. An
abstraction for an SPI bus with a single device (no chaining or
bypass) and a single chipselect is easy to conceptualize. But it
doesn't do parity, flow control.. etc. Every SPI abstraction would
need to implement these though. Alternatively, you abstract buses per
protocol/transfer mechanism but that means 100 abstractions, and more
to come.

* You can somewhat abstract regulators. Up to a point. You can
guarantee there will be a voltage value somewhere, and a lot of things
like the kind of regulation, it's input, current limits can be hidden
or abstracted, and then new technology comes along and the abstraction
needs to be updated. The same problem hits with batteries - go read
the Smart Battery Specification (SBS) for a great way of abstracting
batteries, but this kind of abstraction of the data means some data is
never filled by certain controllers (since it has no ability to set or
measure, or report this information even if it does allow it) and the
software abstraction then ALSO needs significant hardware
modifications and choices. That, and it's already defined as a spec
(ACPI also has a battery abstraction, and SBS is a well-used variant
of it).

* If you are going this far, why not abstract CPU maintenance
operations? Here's one technological foible - using SMC or HVC, you
enter a whole other exception level where the page tables, caches may
not actually be the same as where you came from. Flushing the "normal"
world cache from "secure" world isn't fun.. secure world in TZ can
even have a completely separate physical address space.

Linux already abstracts all of these pretty well - page tables are
essentially handled via abstraction both in structure and in
maintenance (both in handling TLBs and in setting mapping memory
properties). Defining another abstraction means Linux abstracts an
abstraction to provide a usable interface. This is a lot of overhead.

> - Overhead, due to invoking the para-virtualized VM host for IO, and
> extra resources to run the host.

As before, Linux already does abstract and 'virtualize' certain
functionality so you would be doing it twice.

Actually *invoking* the secure monitor or hypervisor call interface is
pretty cheap, all told. You don't need to turn off caches or MMU or
anything, which is a HUGE benefit compared to the OF CIF or UEFI
Runtime, which specifies this expensive behavior as a capitulation to
code re-use from clumsy, old, non-reentrant, unsafe crap.

> - The host SW still has to address the HW differences. Would it be more
> acceptable to run a vendor kernel as the VM host if it meant that the
> VMs could be a more standardized environment, with a more single-purpose
> upstream kernel? Would it be easier to create a simple VM host than a
> full Linux kernel with a full arbitrary Linux distro, thus allowing the
> HW differences to be addressed in a simple way?

No. I can't really articulate why that is an awful idea, but it is.
There are security concerns - the vendor kernel, while still Linux,
could be particularly old. It may do things that have bugs, and need
updating. You'd be doing things twice again... that's the main reason.

> Note: This is all just slightly random thinking that came to me while I
> couldn't sleep last night, so apologies if it isn't fully coherent. It's
> certainly not a proposal, just perhaps something to mull over.

Your mail and the discussion it caused did the same thing, I didn't
sleep a lot because I have a lot of DT foibles on my mind and you've
stirred up a hornet's nest ;)

> [1] All /recent/ consumer-grade ARM laptop or desktop HW that I'm aware
> of that's shipped has Cortex A15 cores that support virtualization.

As above, any ARM core with security extensions can implement much the
same thing, so there's no restriction.. but even said, that doesn't
make it a great idea.

What we really need here is less of an incremental development model
where device drivers are written, then bindings are engineered to try
and push the weird differences to a DT, then bindings are changed over
and over as drivers change to make up for the initial flaws in the
original bindings.

What made OF work - and what makes UEFI work in industry - is multiple
implementations all satisfying a core specification requirement. OF
had the IEEE ratify the standard, and there was a Working Group of
interested, affected industry players looking to make sure that they
would not end up with a lackluster solution. Of course, they let the
standard lapse, but they did a lot of the ground work, which ended up
in things like CHRP and RTAS (which did quite well apart from the fact
that barely anyone but Apple used it, and then turned around and
destroyed the concept by not allowing cloning), PAPR (successor to OF,
for Power Architecture, spec seems kind of private but there aren't
that many differences), FDT which got codified into ePAPR.. there are
at least 5 'good' OF implementations in the wild (Firmworks, Codegen,
Apple, Sun, IBM SLOF) and ePAPR tried to bridge the gap without
requiring significant firmware development. However, it did not turn
out so well because it WAS based on FDT which WASN'T such a mature
idea at the time.

UEFI had Intel and partners work together and then a standards
organization to design and implement the technology. There are at
least 4 UEFI implementations in the real world, some based on Intel's
BSD code (TianoCore/EDK/whatever, that's one) - Intel have their
proprietary spin that EDK is based on, Phoenix have one, Insyde have
one, Apple have one.

How many vendors "implement" flattened device trees? None (actually
Altera do in their SoC modelling tools, but that's umm.. different.
Their hard SoC core and IP blocks are pretty fixed and writing an FPGA
block means writing a binding and a snippet for that block and
including it in the tree magically when you build your FPGA payload.
What they do is ship a device tree that works with their hard SoC
core..)

But they won't do this as a whole if there's no solidification or
standardization - billion dollar companies have billion dollar
customers, real release cycles and standardized (as in, accepted)
project management, which do not lend well to the Linux development
model where the world can change between commits and merge windows.
You can't pull the rug from under a chip designer on a deadline by
making him update his software over and over and over.

There's a reason, for instance, SPI/SDHC controllers have GPIO
specifications in the DT, and that is because either the IP blocks are
buggy and a driver or a binding was defined to cover the normal use
case (controller works, can control it's own pins or successfully poll
for the cd and wp pins, or toggle it's chipselects correctly) and then
essentially, it doesn't work, so there's a workaround. That workaround
- since it is implemented at a board level - has to go in the DT. If
it involves doing something that MAY require some special work (maybe
different use of a bit in a register, or a different sequence of code
to avoid the erratum) then to cover the fact that it may be fixed in
future, broadly compatible IP, the quirk is listed as a property in
the DT (or predicated on the compatible property, which should be the
real way of doing it). I'm not sure what is so bad about this.

I can think of several reasons using FDT sucks right now, all of them
i.MX related (since that's what I gave a crap about until recently);

* Pinmuxing is done in the kernel, which is not only anywhere between
a few milliseconds and a few seconds way too late for some electrical
connections (potentially driving output on a line which a peripheral
is driving too), but also redundant since the bootloader does this
anyway for the vast majority of board designs. At some point it was
deemed necessary to enforce passing pinmux data with every driver - it
is NOT an optional property. This is "wah the bootloader may not do
the right thing" paranoia that has to stop. Pin multiplexing should be
*OPTIONAL*, as above, same as regulators. If you do not pass a
regulator, or ways to pinmux, don't fail! If the peripheral doesn't
work, then this is totally bootloader error on the part of the people
who wrote the support.

* Overuse of global SoC includes (imx51.dtsi for example) means a lot
of SoC peripherals - and their generic, multi-use pinmux data - is
dragged into every device tree. "status = disabled" does nothing to
DTC output. That entry stays in the DT. For an example, putting in
ONLY the required pinmuxing not done by the bootloader (which should
be *Z E R O*)  and ONLY the devices possible to be muxed out or even
used on the board reduces a device tree from 19KiB to 8Kib. That's
11KiB  of stuff that *isn't even used*. If the node you're looking for
is deeply nested at the bottom of the tree, that's extra parsing
time..

* The very fact that "status = disabled" in a node still includes it
in the tree!

* Some bindings (pinmuxing again) have been changed multiple times.

* The most recent bindings are written with the new preprocessor
support in the DT compile process in mind, and are therefore - as
output data - completely unintuitive and mind-boggling. They are
defined as - and always have been since vendor kernels - a register
location and a value pair. The current binding is

    <register1> <register2> <register3> <value1> <value3> <value2>

Just so that it can be written as

    VERY_EASY_MNEMONIC_DESCRIPTION  some_setting_commonly_changed

Russell bitched about this, I *wholeheartedly* agree with him on it.
Here are the problems with it:

- It is entirely obvious that the order of the register/value pairs
has been contrived SOLELY to make writing a dumb preprocessor
definition easier to implement.

- Bits from value1 are stuffed into value2 in the binding such that
they are easier to modify as per preprocessor support above. The
driver takes them out and puts them in the right place if they exist.

- There is a magic bit for "don't touch this register" which is better
done by not specifying it at all

- Not to mention none of this was documented properly..

- Half the easy mnemonics are taken from an old Linux driver, which
was based on RTL descriptions, and hasn't matched a public release
manual *ever*. It didn't even match the pre-release manuals sent to
alpha customers to go with their early access silicon.. so looking at
the manuals to cross-reference ends up in searching a 3500-page PDF
for something that does not exist. Poo to that.

* Don't get me <expletive> started on clock providers, using an array
index inside the OS (ARGH) was the main flaw of the original pinmux
binding for i.MX. It's being used on *EVERY* ARM platform right now. I
don't understand why.. or why...

- Clocks are all registered at once in Linux init code, with special
hacks to get around parents that won't exist if done in device tree
order rather than clock tree order. Check out
mach-imx/clk-imx51-imx53.c or clk-imx6q.c and prepare for your brain
to explode.

- Why clocks are registered at all if they are never referenced or
used by the DT or drivers... every driver has to call "clk_get" with a
clock name, why can't it go off, parse the tree, find the parents,
register them in top down order at runtime?

- Why, given an inherent tree structure to clock subsystems, they are
defined as arbitrary numbers, as peers with each other, with explicit
parentage by PHANDLE, and not *as a <deity>-loving tree*. Most clocks
are very simply defined as dividers or gates or muxes, which can be
very easily implemented in a device tree. Here's a hint to DT binding
authors and people writing drivers - "flattened device tree" does not
mean "everything is a peer" - every node can have child nodes. We
already do something like

clocks {


}

In the root of the tree. So we know the start point. So, parse the
children of clocks.. now you know all the children. Now, parse the
children of the first child. Keep going down the tree.. now you have
all the clocks. Now you also *don't ever need to give a phandle to the
clock's parent inside the child*.

There is so much crap here, and to comply with Linus' "OMG CHURN"
complaints, maintainers are reluctant to change what's broken for the
sake of easier device tree authorship or even existing specifications
(OF, CHRP, PAPR, ePAPR, even UEFI protocol bindings would be a good
reference..)

Ta,
Matt Sealey <neko@bakuhatsu.net>

ARM topic: Is DT on ARM the solution, or is there something better?

[Peter Maydell]

On 22 October 2013 22:44, Matt Sealey <neko@bakuhatsu.net> wrote:
> Any driver that fails probing for an optional property is
> broken and needs fixing.

I agree, but I note that by this rule all the primecell peripheral
drivers are broken, because the binding docs say that the
"clocks" and "clock-names" properties are optional but if you
omit them from the dt node then the kernel refuses to even
call the driver's probe code. (This is specifically irritating for
QEMU because it means we have to create a dummy clock
node in our device tree just to placate the kernel sufficiently
that we can get it to talk to a PL011 UART model.)

-- PMM

[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Rob Herring]

On Wed, Oct 23, 2013 at 6:41 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 22 October 2013 22:44, Matt Sealey <neko@bakuhatsu.net> wrote:
>> Any driver that fails probing for an optional property is
>> broken and needs fixing.
>
> I agree, but I note that by this rule all the primecell peripheral
> drivers are broken, because the binding docs say that the
> "clocks" and "clock-names" properties are optional but if you
> omit them from the dt node then the kernel refuses to even
> call the driver's probe code. (This is specifically irritating for
> QEMU because it means we have to create a dummy clock
> node in our device tree just to placate the kernel sufficiently
> that we can get it to talk to a PL011 UART model.)

I agree this is broken. The amba bus code should allow for
non-existent clocks. I thought it did, but maybe this changed or my
memory is just broken as well.

Rob

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
[...]
> In general, the kernel still needs a complete driver to every last
> device on every strange board, and needs to support every strange way
> some random board hooks all the devices together.
[...]

This may only be slightly related and it doesn't address all the points
you brought up here, but for lack of a better place, here goes.

I've had an interesting discussion with a friend over the weekend which
eventually turned to a similar topic. With all the recent discussions
about how to push board-specific details out into firmware, perhaps a
more drastic measure would be to push for standardization of hardware
interfaces.

For instance, one of the reason we have so much code in the kernel is
because every driver needs to talk to hardware through a slightly
different set of registers. Perhaps it would be possible to get some
discussion going about standardizing register interfaces for various
components. This has already been done for 16550 UART and the same
should be possible for a wide variety of other controllers such as I2C
or SPI.

There have been some attempts at creating reusable IP blocks, I think
ARM does have quite a few which can be licensed. At the same time, many
vendors may already have their own IP so it makes little sense for them
to license third party IP just to provide a standard interface for
drivers. However it might be easy in many cases to support the standard
interface using custom IP blocks.

I suspect something similar could be done for much of the clock, power
and reset requirements of IP blocks. Now I know little about how exactly
an SoC is designed these days, but I can imagine that it would be easy
to move out some of the complexity into hardware by defining something
like a standard register to enable a block. If each block has that
standard register it becomes trivial to write driver and SoC support. It
essentially becomes a matter of calling a platform_device_enable()
function, analogous to pci_enable_device(). There would no longer be a
need for the kind of intra-SoC glue that's taking up a significant
amount of code these days.

Obviously an effort such as the above is on a completely different scale
and would require many vendors to sit together and work something out.
But this isn't new either. After all there are committees and consortia
that already do this in some areas (Khronos). Many of these working
groups seem to focus mostly on software specifications, but what would
prevent them from doing something similar on a hardware interface level?

There are of course some dangers to this as well. Since much of the
complexity is moved into hardware, bugs can no longer be fixed or easily
worked around in software. However to some degree the same is true for
scenarios where a lot of the complexity is moved into firmware instead,
since that's typically not easily replaceable or fixable either.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/99620774/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Grant Likely]

On Mon, 18 Nov 2013 13:26:46 +0100, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote:
> [...]
> > In general, the kernel still needs a complete driver to every last
> > device on every strange board, and needs to support every strange way
> > some random board hooks all the devices together.
> [...]
> 
> This may only be slightly related and it doesn't address all the points
> you brought up here, but for lack of a better place, here goes.
> 
> I've had an interesting discussion with a friend over the weekend which
> eventually turned to a similar topic. With all the recent discussions
> about how to push board-specific details out into firmware, perhaps a
> more drastic measure would be to push for standardization of hardware
> interfaces.

Some hardware does that. That's what OHCI, EHCI, UHCI, XHCI, SDHCI, and
similar are all about. It always helps when well understood hardware
follows a register interface. It doesn't work for everything, but I
agree it would be good to have preferred hw interfaces for SPI & I2C.

g.

ARM topic: Is DT on ARM the solution, or is there something better?

[Mark Brown]

On Mon, Nov 18, 2013 at 01:40:22PM +0000, Grant Likely wrote:

> Some hardware does that. That's what OHCI, EHCI, UHCI, XHCI, SDHCI, and
> similar are all about. It always helps when well understood hardware
> follows a register interface. It doesn't work for everything, but I
> agree it would be good to have preferred hw interfaces for SPI & I2C.

You'd need something class based like USB, there's such massive
variation in what the hardware is trying to do and the tradeoffs.  A big
issue is that especially with I2C many of the devices are primarily
analogue devices implemnted in larger processes where the cost of adding
additional digital logic can have a noticeable effect on the area and
hence cost of the silicon.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/adb8ad80/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Nov 18, 2013 at 01:57:27PM +0000, Mark Brown wrote:
> On Mon, Nov 18, 2013 at 01:40:22PM +0000, Grant Likely wrote:
> 
> > Some hardware does that. That's what OHCI, EHCI, UHCI, XHCI, SDHCI, and
> > similar are all about. It always helps when well understood hardware
> > follows a register interface. It doesn't work for everything, but I
> > agree it would be good to have preferred hw interfaces for SPI & I2C.
> 
> You'd need something class based like USB, there's such massive
> variation in what the hardware is trying to do and the tradeoffs.  A big
> issue is that especially with I2C many of the devices are primarily
> analogue devices implemnted in larger processes where the cost of adding
> additional digital logic can have a noticeable effect on the area and
> hence cost of the silicon.

My comments were mostly regarding the interface controllers. Those which
generate the same bus transactions but need different drivers on every
SoC. I suspect that the same costs don't apply (or at least not to the
same extent) to SoCs.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/b0016586/attachment-0001.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Mark Brown]

On Mon, Nov 18, 2013 at 04:29:21PM +0100, Thierry Reding wrote:
> On Mon, Nov 18, 2013 at 01:57:27PM +0000, Mark Brown wrote:

> > You'd need something class based like USB, there's such massive
> > variation in what the hardware is trying to do and the tradeoffs.  A big
> > issue is that especially with I2C many of the devices are primarily
> > analogue devices implemnted in larger processes where the cost of adding
> > additional digital logic can have a noticeable effect on the area and
> > hence cost of the silicon.

> My comments were mostly regarding the interface controllers. Those which
> generate the same bus transactions but need different drivers on every
> SoC. I suspect that the same costs don't apply (or at least not to the
> same extent) to SoCs.

Oh, right.  In that space I suspect you'd face apathy on the part of
vendors for switching away from their existing validated and deployed
IPs - probably the best shot would be a freely licensed reference
implementation that people could pick up if they wanted.  It's plausible
that some of the vendors might do so for SPI where there are a bunch of
chips that don't have DMA/FIFOs yet and so could possibly benefit from
performance and feature gains but without that sort of benefit it's hard
to see what would be persuasive for the vendors.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/82c19a4f/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Nov 18, 2013 at 03:50:22PM +0000, Mark Brown wrote:
> On Mon, Nov 18, 2013 at 04:29:21PM +0100, Thierry Reding wrote:
> > On Mon, Nov 18, 2013 at 01:57:27PM +0000, Mark Brown wrote:
> 
> > > You'd need something class based like USB, there's such massive
> > > variation in what the hardware is trying to do and the tradeoffs.  A big
> > > issue is that especially with I2C many of the devices are primarily
> > > analogue devices implemnted in larger processes where the cost of adding
> > > additional digital logic can have a noticeable effect on the area and
> > > hence cost of the silicon.
> 
> > My comments were mostly regarding the interface controllers. Those which
> > generate the same bus transactions but need different drivers on every
> > SoC. I suspect that the same costs don't apply (or at least not to the
> > same extent) to SoCs.
> 
> Oh, right.  In that space I suspect you'd face apathy on the part of
> vendors for switching away from their existing validated and deployed
> IPs - probably the best shot would be a freely licensed reference
> implementation that people could pick up if they wanted.  It's plausible
> that some of the vendors might do so for SPI where there are a bunch of
> chips that don't have DMA/FIFOs yet and so could possibly benefit from
> performance and feature gains but without that sort of benefit it's hard
> to see what would be persuasive for the vendors.

Part of my point was that you could possibly still use the same IP with
only a modified (standard) register interface. That way no licensing of
third party IP would be needed. You'd only need to rewrite parts of the
IP to make it look (and behave) like the standard one.

That's exactly how 16550-compatible UARTs work, isn't it? Or even the
way that USB (EHCI, ...) work. There's a standardize register interface,
possibly with a way for vendor-specific extensions, but the interface
itself doesn't need to be licensed, so there are no additional costs to
supporting the standard interface. There are only the advantages of
being able to reuse a well-tested body of code.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/212df139/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Stephen Warren]

On 11/18/2013 09:06 AM, Thierry Reding wrote:
...
> Part of my point was that you could possibly still use the same IP
> with only a modified (standard) register interface. That way no
> licensing of third party IP would be needed. You'd only need to
> rewrite parts of the IP to make it look (and behave) like the
> standard one.
> 
> That's exactly how 16550-compatible UARTs work, isn't it? Or even
> the way that USB (EHCI, ...) work. There's a standardize register
> interface, possibly with a way for vendor-specific extensions, but
> the interface itself doesn't need to be licensed, so there are no
> additional costs to supporting the standard interface. There are
> only the advantages of being able to reuse a well-tested body of
> code.

Your idea would be great if it could be made to work in practice. I'm
not convinced how possible this would be, without ARM mandating it in
their contractual licensing terms, or large customers mandating it in
order to use SoCs for their flagship designs.

The one fly in the ointment is that even in cases where there are
standard register interfaces, there are always quirks in how vendors
implement those interfaces, so HW ends up being 90-99.5% compliant
with the interface, but with subtle differences. Take a look at
Tegra's SDHCI, EHCI and PCIe controllers for examples! Still, I
suppose that even with that caveat, having a 90% identical driver
compared to a 0% identical driver would be better than where we are today.

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Nov 18, 2013 at 10:16:13AM -0700, Stephen Warren wrote:
> On 11/18/2013 09:06 AM, Thierry Reding wrote:
> ...
> > Part of my point was that you could possibly still use the same IP
> > with only a modified (standard) register interface. That way no
> > licensing of third party IP would be needed. You'd only need to
> > rewrite parts of the IP to make it look (and behave) like the
> > standard one.
> > 
> > That's exactly how 16550-compatible UARTs work, isn't it? Or even
> > the way that USB (EHCI, ...) work. There's a standardize register
> > interface, possibly with a way for vendor-specific extensions, but
> > the interface itself doesn't need to be licensed, so there are no
> > additional costs to supporting the standard interface. There are
> > only the advantages of being able to reuse a well-tested body of
> > code.
> 
> Your idea would be great if it could be made to work in practice.

This wasn't really my idea, so I can't take all the credit for it. =)

> I'm not convinced how possible this would be, without ARM mandating it
> in their contractual licensing terms, or large customers mandating it
> in order to use SoCs for their flagship designs.

I don't think ARM mandating this is necessary. In the end it boils down
to faster time to market, doesn't it? I mean if you have a device that
exposes a standard set of registers and a driver for that standard set
already exists, then it's very little work to get the device working
with it. You also save a lot of work on validation.

The 16550 UART register set wasn't mandated by anyone as far as I know,
but still the majority of UART devices implement it. I guess the same is
true of EHCI or SDHCI.

Some aspects could possibly be solved by making them parts of a bus
specification I guess. If bus specifications made some provisions for
controlling the power, reset, clocking and other aspects of the IP on
that bus, that would make quite a few things easier. That isn't a new
idea of course, it's been done in other systems, such as PCI, before.

> The one fly in the ointment is that even in cases where there are
> standard register interfaces, there are always quirks in how vendors
> implement those interfaces, so HW ends up being 90-99.5% compliant
> with the interface, but with subtle differences. Take a look at
> Tegra's SDHCI, EHCI and PCIe controllers for examples! Still, I
> suppose that even with that caveat, having a 90% identical driver
> compared to a 0% identical driver would be better than where we are
> today.

Yes, that's true. The Linux 8250 driver, while generally dealing with
the same register set, still requires an awful amount of code and data
tables to make it work on the myriad of devices out there. And the set
of registers is pretty small compared to other types of hardware.

I guess in the end it boils down to a redistribution of the workload.
While I think we're doing a pretty good job with adding hardware support
in the Linux kernel, we're still struggling to keep up with new hardware
being continually added. One solution to that problem is to keep adding
massive amounts of software engineers to keep up with the changes in
hardware. Typically this has the side-effect of making the delta between
upstream and downstream kernels larger, unfortunately.

Another solution, the one discussed here, is to move more complexity
into hardware, therefore reducing the workload of software engineers by
making the job of hardware engineers harder.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131119/9df466d4/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Stephen Warren]

On 11/19/2013 02:35 AM, Thierry Reding wrote:
> On Mon, Nov 18, 2013 at 10:16:13AM -0700, Stephen Warren wrote:
>> On 11/18/2013 09:06 AM, Thierry Reding wrote: ...
>>> Part of my point was that you could possibly still use the same
>>> IP with only a modified (standard) register interface. That way
>>> no licensing of third party IP would be needed. You'd only need
>>> to rewrite parts of the IP to make it look (and behave) like
>>> the standard one.
>>> 
>>> That's exactly how 16550-compatible UARTs work, isn't it? Or
>>> even the way that USB (EHCI, ...) work. There's a standardize
>>> register interface, possibly with a way for vendor-specific
>>> extensions, but the interface itself doesn't need to be
>>> licensed, so there are no additional costs to supporting the
>>> standard interface. There are only the advantages of being able
>>> to reuse a well-tested body of code.
>> 
>> Your idea would be great if it could be made to work in
>> practice.
> 
> This wasn't really my idea, so I can't take all the credit for it.
> =)
> 
>> I'm not convinced how possible this would be, without ARM
>> mandating it in their contractual licensing terms, or large
>> customers mandating it in order to use SoCs for their flagship
>> designs.
> 
> I don't think ARM mandating this is necessary. In the end it boils
> down to faster time to market, doesn't it? I mean if you have a
> device that exposes a standard set of registers and a driver for
> that standard set already exists, then it's very little work to get
> the device working with it. You also save a lot of work on
> validation.

I get the impression that many silicon vendors simply do what they
want when there aren't constraints that dictate otherwise. The
benefits of upstream SW aren't valued by everyone, let alone the
benefits of the HW equivalent - the standardized registers we're
talking about. As such, without some force pushing for
standardization, people won't do it. That force would need to be
either ARM, or the customers/partners/ecosystem consuming the SoCs.

And note that we already have drivers in our product kernels (and
simplified drivers upstream) for all this HW already, so switching
register interface would actually be more work at least in the short term.

Likely the best way to drive this forward is to talk to our silicon
engineers and try and drive this through them. If you can persuade
them, perhaps it can trickle back up to ARM and across other vendors.
If you as an NVIDIA employee can't persuade the NVIDIA HW designers, I
don't expect you could persuade other HW vendors:-)

> The 16550 UART register set wasn't mandated by anyone as far as I
> know, but still the majority of UART devices implement it. I guess
> the same is true of EHCI or SDHCI.

IIUC, the situation is a little different.

A platform existed that used the 8250/16550. That product got into the
market first (or created a new market). Others wanted to be compatible
with the product, so had to implement compatible registers. Thus,
everyone made their motherboard/chipset UARTs work the same.

However, with ARM SoCs, there are multiple tens of vendors all
developing products at once, and even for different markets, so the
whole "must be compatible with this existing thing" driving force
simply doesn't exist, simply because there is no one single "existing
thing". Systems are also larger, and there are many more SW developers
employed, so there's a bit more ability to deal with different HW too.
It may not scale infinitely, but probably better than it did 30 years ago.

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Tue, Nov 19, 2013 at 10:27:40AM -0700, Stephen Warren wrote:
> On 11/19/2013 02:35 AM, Thierry Reding wrote:
> > On Mon, Nov 18, 2013 at 10:16:13AM -0700, Stephen Warren wrote:
> >> On 11/18/2013 09:06 AM, Thierry Reding wrote: ...
> >>> Part of my point was that you could possibly still use the same
> >>> IP with only a modified (standard) register interface. That way
> >>> no licensing of third party IP would be needed. You'd only need
> >>> to rewrite parts of the IP to make it look (and behave) like
> >>> the standard one.
> >>> 
> >>> That's exactly how 16550-compatible UARTs work, isn't it? Or
> >>> even the way that USB (EHCI, ...) work. There's a standardize
> >>> register interface, possibly with a way for vendor-specific
> >>> extensions, but the interface itself doesn't need to be
> >>> licensed, so there are no additional costs to supporting the
> >>> standard interface. There are only the advantages of being able
> >>> to reuse a well-tested body of code.
> >> 
> >> Your idea would be great if it could be made to work in
> >> practice.
> > 
> > This wasn't really my idea, so I can't take all the credit for it.
> > =)
> > 
> >> I'm not convinced how possible this would be, without ARM
> >> mandating it in their contractual licensing terms, or large
> >> customers mandating it in order to use SoCs for their flagship
> >> designs.
> > 
> > I don't think ARM mandating this is necessary. In the end it boils
> > down to faster time to market, doesn't it? I mean if you have a
> > device that exposes a standard set of registers and a driver for
> > that standard set already exists, then it's very little work to get
> > the device working with it. You also save a lot of work on
> > validation.
> 
> I get the impression that many silicon vendors simply do what they
> want when there aren't constraints that dictate otherwise. The
> benefits of upstream SW aren't valued by everyone, let alone the
> benefits of the HW equivalent - the standardized registers we're
> talking about. As such, without some force pushing for
> standardization, people won't do it. That force would need to be
> either ARM, or the customers/partners/ecosystem consuming the SoCs.
> 
> And note that we already have drivers in our product kernels (and
> simplified drivers upstream) for all this HW already, so switching
> register interface would actually be more work at least in the short
> term.

Yeah, if this could be made to work I'd expect this to only pay off in
the really long term. Even if people were convinced that this needed to
be done now I suspect that it could easily be a decade before the
benefits could be reaped.

In some ways it would be fundamental shift in how the industry works,
and quite probably not everyone will be convinced to tag along.

> Likely the best way to drive this forward is to talk to our silicon
> engineers and try and drive this through them. If you can persuade
> them, perhaps it can trickle back up to ARM and across other vendors.
> If you as an NVIDIA employee can't persuade the NVIDIA HW designers, I
> don't expect you could persuade other HW vendors:-)

It sounds pretty daunting. I don't feel like I personally have enough
experience or knowledge to drive something like this. Realistically this
would need investigating the myriads of register interfaces in existence
and extract the commonalities into something that could be made to work
on all hardware.

Then again, perhaps higher-level software abstractions could serve as a
good template. After all, the subsystem-level APIs in the Linux kernel
are already catered to supporting most of the hardware out there.

> > The 16550 UART register set wasn't mandated by anyone as far as I
> > know, but still the majority of UART devices implement it. I guess
> > the same is true of EHCI or SDHCI.
> 
> IIUC, the situation is a little different.
> 
> A platform existed that used the 8250/16550. That product got into the
> market first (or created a new market). Others wanted to be compatible
> with the product, so had to implement compatible registers. Thus,
> everyone made their motherboard/chipset UARTs work the same.
> 
> However, with ARM SoCs, there are multiple tens of vendors all
> developing products at once, and even for different markets, so the
> whole "must be compatible with this existing thing" driving force
> simply doesn't exist, simply because there is no one single "existing
> thing". Systems are also larger, and there are many more SW developers
> employed, so there's a bit more ability to deal with different HW too.
> It may not scale infinitely, but probably better than it did 30 years ago.

Perhaps pursuing this isn't such a good idea after all. If things really
ended up going in that direction many of us might turn out unemployed...

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131120/9f2f8852/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Mark Brown]

On Mon, Nov 18, 2013 at 05:06:28PM +0100, Thierry Reding wrote:

> Part of my point was that you could possibly still use the same IP with
> only a modified (standard) register interface. That way no licensing of
> third party IP would be needed. You'd only need to rewrite parts of the
> IP to make it look (and behave) like the standard one.

> That's exactly how 16550-compatible UARTs work, isn't it? Or even the
> way that USB (EHCI, ...) work. There's a standardize register interface,
> possibly with a way for vendor-specific extensions, but the interface
> itself doesn't need to be licensed, so there are no additional costs to
> supporting the standard interface. There are only the advantages of
> being able to reuse a well-tested body of code.

My (potentially flawed) understanding here is that the register
interfaces for this sort of thing tend to be very thin - perhaps more
true for SPI which is extremely simple electrically.  Adding a new
interface therefore ends up being more invasive than it could appear
since assumptions in the design and validation tend to appear in the
registers and so changing the register map propagates through.

I do agree that it'd be nice to get some standardisation at some level,
I just fear that it's a bit late.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/84293f9c/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Mon, Nov 18, 2013 at 06:35:02PM +0000, Mark Brown wrote:
> On Mon, Nov 18, 2013 at 05:06:28PM +0100, Thierry Reding wrote:
> 
> > Part of my point was that you could possibly still use the same IP with
> > only a modified (standard) register interface. That way no licensing of
> > third party IP would be needed. You'd only need to rewrite parts of the
> > IP to make it look (and behave) like the standard one.
> 
> > That's exactly how 16550-compatible UARTs work, isn't it? Or even the
> > way that USB (EHCI, ...) work. There's a standardize register interface,
> > possibly with a way for vendor-specific extensions, but the interface
> > itself doesn't need to be licensed, so there are no additional costs to
> > supporting the standard interface. There are only the advantages of
> > being able to reuse a well-tested body of code.
> 
> My (potentially flawed) understanding here is that the register
> interfaces for this sort of thing tend to be very thin - perhaps more
> true for SPI which is extremely simple electrically.  Adding a new
> interface therefore ends up being more invasive than it could appear
> since assumptions in the design and validation tend to appear in the
> registers and so changing the register map propagates through.
> 
> I do agree that it'd be nice to get some standardisation at some level,
> I just fear that it's a bit late.

It certainly won't be easy, but I don't think it's too late. Hardware
used to be simple, and operating systems used to be simple. But that's
no longer true. There is a reason why we're trying to come up with ways
to move some of the complexity out of the kernel. We know that things
aren't going to scale well if the rate of change and increase in
complexity continue at the same pace.

Isn't that the reason why PSCI and similar have been conceived? Even DT
is a byproduct of those developments. What we've been doing so far is to
come up with ways to solve all these problems with additional layers of
software. But I don't think we can go on doing that endlessly. Doing so
also makes it increasingly complicated to build a complete open-source
stack for a device. If you have to rely on all sorts of firmware to boot
a device to a usable state that can very easily become really messy.

While it might already be late now, it will certainly be much later a
few years down the road.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131119/899dc0d4/attachment.sig>

ARM topic: Is DT on ARM the solution, or is there something better?

[Mark Brown]

On Tue, Nov 19, 2013 at 10:11:42AM +0100, Thierry Reding wrote:

> Isn't that the reason why PSCI and similar have been conceived? Even DT
> is a byproduct of those developments. What we've been doing so far is to

Right, but notice that PSCI is getting introduce along with ARMv8 -
nobody is deploying it on ARMv7 and below.  The new CPU architecture
gave a pressing reason to switch and ate the cost of doing so.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131119/532b57e6/attachment.sig>