All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <info@metux.net>
To: Frank Rowand <frowand.list@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	"Enrico Weigelt, metux IT consult" <info@metux.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	devicetree@vger.kernel.org, Johan Hovold <johan@kernel.org>
Subject: Re: RFC: oftree based setup of composite board devices
Date: Wed, 24 Feb 2021 14:00:12 +0100	[thread overview]
Message-ID: <44b9b561-5e0d-6a1c-ca5d-4e9f6000884c@metux.net> (raw)
In-Reply-To: <76bf0f7c-9477-f370-8fbd-ce8ef15188b1@gmail.com>

On 15.02.21 02:12, Frank Rowand wrote:

> Why not compile in ACPI data (tables?) instead of devicetree description?

The problem is a bit more complex than it might seem.

Let's take the APU2/37/4 boards as an example. They've got some aux
devices, eg. some gpio controller, and some things (leds, keys, reset
lines, etc) attached to it.

Now we've got lots of different bios versions in the field,
enumerating only some of the devices. For example, older ones didn't
even contain the gpio, later ones added just gpio, other ones just
added LEDs (with different names than the Linux driver already mainlined
and field-deployed at that time), but still other lines unhandled, etc, 
etc. etc.

A big mess :( And I can't ask everybody to do bios uprade on devices far
out in the field (litterally open field, sometimes offshore, ...). So, I
need a usable solution, that's also maintainable, w/o testing each
single combination of board, bios, etc. IOW: without relying on bios
(except for board identification)

OTOH, I'm also looking for a solution get rid writing those kind of
relatively huge board drivers, that pretty are much like old fashioned
board files from pre-DT times - just made up of lots of tables and
a few trivial register-something calls. Sounds pretty much like the
original use case of oftree.

The primary difference between classic oftree and this scanario:
* this is additional to existing platform information, which is
   incomplete or even incorrect (and that can't be fixed)
* extra carrier boards that are detected by other means, but no
   enumeration of the devices on it.

>> This is something I've wanted to see for a while. There's use cases
>> for DT based systems too. The example I'd like to see supported are
>> USB serial adapters with downstream serdev, GPIO, I2C, SPI, etc. Then
>> plug more than one of those in.
> 
> My understanding from the past is that the experts (those who understand both
> devicetree and ACPI) regard trying to mix devicetree and ACPI in a single
> running Linux kernel image is insanity, or at least likely to be confusing,
> difficult, and problematic.

Well, mixing different, overlapping data sources tends to be tricky. The
same problem exists with the classic approach of hand-written board
drivers. So there have to be clear border lines.

In my case (eg. apu2+ boards), the overlap is only that some bios
versions enumerate the gpio chip, others even some of the gpio-based
devices. I'm attempting to solve this by just kicking out those
duplicate devices, if they exist. The alternative could be leaving them
in an trying to bind the missing ones to them. But that would be really
complicatd and needs to be well crafted for lots of different board and
bios versions - a kind of complexity we wanna avoid.

My use cases are actually a bit easier than the average dt overlay
cases, as I have almost no interactions with already existing devices
(except that some specific devices have to be moved out of the way)

The original DT overlay use case, arbitrary expansion boards (eg. on
raspi), are trickier, if the overlays shall be generic over a wider
range of base boards (eg. same overlay for any raspi or odroid).
This is something calling for an own (pseudo-)bus type that handles
the correct probing ... I've hacked up something similar for the APU2+'s
combined msata/usb/mpcie ports.

BTW: I've already been thinking of ways for internally transforming ACPI
tables into DT data structures (struct device_node) at an early point,
before probing. But that would be another research project with unknown
outcome, and most likely a HUGE change. Not what I'm talking about now.

> From the devicetree side, I expect nightmares for me if devicetree and ACPI
> are mixed in a single running kernel image.

Note that I'm not talking about arbitrary configurations. Just re-using
existing device tree code to express things that are currently open
coded C into DT.

It's NOT trying to boot an ACPI-based machine with DT. (which would be
yet another research project)

> Multiple root nodes and disjoint trees both seem problematic.  Existing
> subsystems and drivers expect a single cohesive tree.  Changing that
> architecture looks to me to be a painful exercise.

Yes, it's not entirely trivial, but managable. My experiments seemed to
work so far, and I couldn't see general blockers yet. Drivers usually
expect certain sub-nodes, but haven't found any that expect their node
being embedded in some other one. (maybe there really are some, but the
likehood that they're applicable in these use cases looks pretty low).


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

  parent reply	other threads:[~2021-02-24 14:19 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08 22:21 RFC: oftree based setup of composite board devices Enrico Weigelt, metux IT consult
2021-02-08 22:21 ` [RFC PATCH 01/12] of: base: improve error message in of_phandle_iterator_next() Enrico Weigelt, metux IT consult
2021-02-08 22:21 ` [RFC PATCH 02/12] of: base: introduce of_find_node_by_phandle_from() Enrico Weigelt, metux IT consult
2021-02-08 22:21 ` [RFC PATCH 03/12] of: base: record root node in interator and use it for phandle lookup Enrico Weigelt, metux IT consult
2021-02-08 22:21 ` [RFC PATCH 04/12] of: base: introduce of_match_string() Enrico Weigelt, metux IT consult
2021-02-08 23:52   ` Rob Herring
2021-02-08 22:21 ` [RFC PATCH 05/12] of: kobj: __of_attach_node_sysfs(): add optional basename parameter Enrico Weigelt, metux IT consult
2021-02-08 22:21 ` [RFC PATCH 06/12] of: kobj: introduce of_attach_tree_sysfs() Enrico Weigelt, metux IT consult
2021-02-08 22:21 ` [RFC PATCH 07/12] gpio: amd-fch: add oftree probing support Enrico Weigelt, metux IT consult
2021-02-09  3:46   ` kernel test robot
2021-02-11  9:57   ` Bartosz Golaszewski
2021-02-13  4:26   ` kernel test robot
2021-03-01 14:51   ` Linus Walleij
2021-03-11 10:17     ` Enrico Weigelt, metux IT consult
2021-03-11 10:42       ` Andy Shevchenko
2021-03-18  8:00         ` Enrico Weigelt, metux IT consult
2021-03-25  9:09           ` Linus Walleij
2021-02-08 22:21 ` [RFC PATCH 08/12] drivers: base: introduce bus_remove_device_by_name() Enrico Weigelt, metux IT consult
2021-02-08 22:22 ` [RFC PATCH 09/12] drivers: base: reintroduce find_bus() Enrico Weigelt, metux IT consult
2021-02-13 10:20   ` Greg KH
2021-02-23 20:13     ` Enrico Weigelt, metux IT consult
2021-02-24  8:00       ` Greg KH
2021-02-24 15:30         ` Enrico Weigelt, metux IT consult
2021-02-24 16:28           ` Greg KH
2021-02-08 22:22 ` [RFC PATCH 10/12] export bus_get() / bus_put() Enrico Weigelt, metux IT consult
2021-02-08 22:22 ` [RFC PATCH 11/12] platform/x86: skeleton for oftree based board device initialization Enrico Weigelt, metux IT consult
2021-02-10 10:32   ` Andy Shevchenko
2021-02-12  9:58   ` Linus Walleij
2021-02-12 11:54     ` Enrico Weigelt, metux IT consult
2021-02-15  1:18       ` Frank Rowand
2021-02-23 20:41         ` Enrico Weigelt, metux IT consult
2021-03-02 13:33       ` Linus Walleij
2021-02-08 22:22 ` [RFC PATCH 12/12] platform/x86/of: add support for PC Engines APU v2/3/4 boards Enrico Weigelt, metux IT consult
2021-02-09  0:06   ` Rob Herring
2021-02-11 13:15     ` Enrico Weigelt, metux IT consult
2021-03-01 14:55   ` Linus Walleij
2021-02-08 23:48 ` RFC: oftree based setup of composite board devices Rob Herring
2021-02-10 22:13   ` Enrico Weigelt, metux IT consult
2021-02-15  1:12   ` Frank Rowand
2021-02-15 15:35     ` Andy Shevchenko
2021-02-24 13:00     ` Enrico Weigelt, metux IT consult [this message]
2021-02-24 23:14       ` Frank Rowand
2021-03-05 18:29         ` Rob Herring
2021-02-10 10:30 ` Andy Shevchenko
2021-02-11 11:08   ` Enrico Weigelt, metux IT consult
2021-02-11 11:41     ` Andy Shevchenko
2021-02-11 17:01       ` Enrico Weigelt, metux IT consult

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44b9b561-5e0d-6a1c-ca5d-4e9f6000884c@metux.net \
    --to=info@metux.net \
    --cc=bgolaszewski@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=johan@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pantelis.antoniou@konsulko.com \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.