All of lore.kernel.org
 help / color / mirror / Atom feed
From: sf84@laposte.net (Sebastian Frias)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM, SoC: About the use DT-defined properties by 3rd-party drivers
Date: Mon, 12 Sep 2016 18:29:06 +0200	[thread overview]
Message-ID: <57D6D7D2.7030507@laposte.net> (raw)
In-Reply-To: <CANCZdfri+T59FA4XTaH5JbW0BaJHt3w5eaSkpD8NrJn6nZrZbA@mail.gmail.com>

Hi Warner,

On 09/12/2016 04:26 PM, Warner Losh wrote:
> On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>>> Since the question seems understood, do you have an example of other SoC's
>>> doing something similar?
>>
>> I do not have an example. I know that others are using DT for data
>> beyond what Linux or another OS requires, but it's my understanding that
>> that is typically in a separate DTB.
> 
> Just to clarify: FreeBSD uses, for the most part, the DTB's that the
> 'vendor' ships, which is quite often the same ones included in Linux.
> There's some exceptions where the bindings weren't really hardware
> independent, or where the abstraction model was really Linux specific
> (for things like the HDMI stack).
> 
> However, with the advent of overlays, one would think that a vendor
> could easily include an overlay with the DTB data for the devices they
> don't wish to, or cannot for other reasons release. It seems like the
> perfect mechanism to comply with the rules about inclusion of nodes in
> the DTS. Vendors are free to document these nodes and don't require
> the Linux kernel include them in the Documents directory to do so.
> There have been recent efforts to move this documentation to a third
> party to maintain.

This is very interesting, do you have a more concrete example of such
usage?

The overlay technique could be a solution, but so is forking and
distributing a non-documented DT. That's why I'd put this solution a
little bit lower than just exposing the entire HW description through
the DT.

Best regards,

Sebastian

WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Frias <sf84@laposte.net>
To: Warner Losh <imp@bsdimp.com>, Mark Rutland <mark.rutland@arm.com>
Cc: devicetree <devicetree@vger.kernel.org>,
	Mason <slash.tmp@free.fr>, Timur Tabi <timur@tabi.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers
Date: Mon, 12 Sep 2016 18:29:06 +0200	[thread overview]
Message-ID: <57D6D7D2.7030507@laposte.net> (raw)
In-Reply-To: <CANCZdfri+T59FA4XTaH5JbW0BaJHt3w5eaSkpD8NrJn6nZrZbA@mail.gmail.com>

Hi Warner,

On 09/12/2016 04:26 PM, Warner Losh wrote:
> On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>>> Since the question seems understood, do you have an example of other SoC's
>>> doing something similar?
>>
>> I do not have an example. I know that others are using DT for data
>> beyond what Linux or another OS requires, but it's my understanding that
>> that is typically in a separate DTB.
> 
> Just to clarify: FreeBSD uses, for the most part, the DTB's that the
> 'vendor' ships, which is quite often the same ones included in Linux.
> There's some exceptions where the bindings weren't really hardware
> independent, or where the abstraction model was really Linux specific
> (for things like the HDMI stack).
> 
> However, with the advent of overlays, one would think that a vendor
> could easily include an overlay with the DTB data for the devices they
> don't wish to, or cannot for other reasons release. It seems like the
> perfect mechanism to comply with the rules about inclusion of nodes in
> the DTS. Vendors are free to document these nodes and don't require
> the Linux kernel include them in the Documents directory to do so.
> There have been recent efforts to move this documentation to a third
> party to maintain.

This is very interesting, do you have a more concrete example of such
usage?

The overlay technique could be a solution, but so is forking and
distributing a non-documented DT. That's why I'd put this solution a
little bit lower than just exposing the entire HW description through
the DT.

Best regards,

Sebastian

  reply	other threads:[~2016-09-12 16:29 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-24 14:29 ARM,SoC: About the use DT-defined properties by 3rd-party drivers Sebastian Frias
2016-08-24 14:29 ` Sebastian Frias
2016-08-28 20:36 ` ARM, SoC: " Timur Tabi
2016-08-28 20:36   ` ARM,SoC: " Timur Tabi
2016-08-28 20:36   ` ARM, SoC: " Timur Tabi
2016-09-12 12:29   ` Sebastian Frias
2016-09-12 12:29     ` ARM,SoC: " Sebastian Frias
2016-09-12 12:38     ` ARM, SoC: " Mark Rutland
2016-09-12 12:38       ` ARM,SoC: " Mark Rutland
2016-09-12 12:38       ` Mark Rutland
2016-09-12 13:15       ` ARM, SoC: " Sebastian Frias
2016-09-12 13:15         ` ARM,SoC: " Sebastian Frias
2016-09-12 13:23         ` ARM, SoC: " Timur Tabi
2016-09-12 13:23           ` ARM,SoC: " Timur Tabi
2016-09-12 14:01         ` ARM, SoC: " Mark Rutland
2016-09-12 14:01           ` Mark Rutland
2016-09-12 14:26           ` Warner Losh
2016-09-12 14:26             ` Warner Losh
2016-09-12 14:26             ` Warner Losh
2016-09-12 16:29             ` Sebastian Frias [this message]
2016-09-12 16:29               ` Sebastian Frias
2016-09-12 16:45               ` Warner Losh
2016-09-12 16:45                 ` Warner Losh
2016-09-12 16:49                 ` Timur Tabi
2016-09-12 16:49                   ` Timur Tabi
2016-09-12 17:07                   ` Mark Rutland
2016-09-12 17:07                     ` Mark Rutland
2016-09-12 17:06                 ` Mark Rutland
2016-09-12 17:06                   ` Mark Rutland
2016-09-12 17:06                   ` Mark Rutland
2016-09-12 16:07           ` Sebastian Frias
2016-09-12 16:07             ` Sebastian Frias
2016-09-12 16:07             ` Sebastian Frias
2016-09-12 16:21             ` Timur Tabi
2016-09-12 16:21               ` Timur Tabi
2016-09-12 16:21               ` Timur Tabi
2016-09-12 16:26             ` Sebastian Frias
2016-09-12 16:26               ` Sebastian Frias
2016-09-12 16:26               ` Sebastian Frias
2016-09-12 16:56             ` Mark Rutland
2016-09-12 16:56               ` Mark Rutland
2016-09-12 16:56               ` Mark Rutland
2016-09-13 10:04               ` Sebastian Frias
2016-09-13 10:04                 ` Sebastian Frias
2016-09-13 10:04                 ` Sebastian Frias
2016-09-13 11:37                 ` Timur Tabi
2016-09-13 11:37                   ` Timur Tabi
2016-09-13 11:37                   ` Timur Tabi
2016-09-13 13:23                   ` Mark Rutland
2016-09-13 13:23                     ` Mark Rutland
2016-09-13 13:23                     ` Mark Rutland
2016-09-13 13:12                 ` Mark Rutland
2016-09-13 13:12                   ` Mark Rutland
2016-09-13 13:12                   ` Mark Rutland
2016-09-13 14:22                   ` Sebastian Frias
2016-09-13 14:22                     ` Sebastian Frias
2016-09-13 14:22                     ` Sebastian Frias
2016-09-13 14:51                     ` Mark Rutland
2016-09-13 14:51                       ` Mark Rutland
2016-09-13 14:51                       ` Mark Rutland
2016-09-14  8:32                       ` Sebastian Frias
2016-09-14  8:32                         ` Sebastian Frias
2016-09-14  8:32                         ` Sebastian Frias
2016-09-13 14:55                   ` Sebastian Frias
2016-09-13 14:55                     ` Sebastian Frias
2016-09-13 14:55                     ` Sebastian Frias
2016-09-13 15:47                     ` Mark Rutland
2016-09-13 15:47                       ` Mark Rutland
2016-09-13 15:47                       ` Mark Rutland
2016-09-14  8:24                       ` Sebastian Frias
2016-09-14  8:24                         ` Sebastian Frias

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=57D6D7D2.7030507@laposte.net \
    --to=sf84@laposte.net \
    --cc=linux-arm-kernel@lists.infradead.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.