Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 04:51 PM, Mark Rutland wrote: > Hi, > > On Tue, Sep 13, 2016 at 04:22:09PM +0200, Sebastian Frias wrote: >> On 09/13/2016 03:12 PM, Mark Rutland wrote: > > [context was deleted, TL;DR: binding review is necessary, and takes > effort, regardless of presence/absence of a

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 04:51 PM, Mark Rutland wrote: > Hi, > > On Tue, Sep 13, 2016 at 04:22:09PM +0200, Sebastian Frias wrote: >> On 09/13/2016 03:12 PM, Mark Rutland wrote: > > [context was deleted, TL;DR: binding review is necessary, and takes > effort, regardless of presence/absence of a

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 05:47 PM, Mark Rutland wrote: >>> If you believe that the bindings don't matter, then there is absolutely >>> no reason for them to exist in the first place. >>> >>> If those binding matter to *anyone*, then those collating the bindings >>> have some responsibility of

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 05:47 PM, Mark Rutland wrote: >>> If you believe that the bindings don't matter, then there is absolutely >>> no reason for them to exist in the first place. >>> >>> If those binding matter to *anyone*, then those collating the bindings >>> have some responsibility of

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On Tue, Sep 13, 2016 at 04:55:59PM +0200, Sebastian Frias wrote: > On 09/13/2016 03:12 PM, Mark Rutland wrote: > >> Exactly, that is why I was thinking it would take less "review" time. > >> Indeed, if there is no driver, why would it matter what those bindings > >> are? > > > > If you believe

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On Tue, Sep 13, 2016 at 04:55:59PM +0200, Sebastian Frias wrote: > On 09/13/2016 03:12 PM, Mark Rutland wrote: > >> Exactly, that is why I was thinking it would take less "review" time. > >> Indeed, if there is no driver, why would it matter what those bindings > >> are? > > > > If you believe

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi, On Tue, Sep 13, 2016 at 04:22:09PM +0200, Sebastian Frias wrote: > On 09/13/2016 03:12 PM, Mark Rutland wrote: [context was deleted, TL;DR: binding review is necessary, and takes effort, regardless of presence/absence of a driver] > >> Only for bindings for which there is a driver. > > > >

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi, On Tue, Sep 13, 2016 at 04:22:09PM +0200, Sebastian Frias wrote: > On 09/13/2016 03:12 PM, Mark Rutland wrote: [context was deleted, TL;DR: binding review is necessary, and takes effort, regardless of presence/absence of a driver] > >> Only for bindings for which there is a driver. > > > >

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 03:12 PM, Mark Rutland wrote: >> Exactly, that is why I was thinking it would take less "review" time. >> Indeed, if there is no driver, why would it matter what those bindings >> are? > > If you believe that the bindings don't matter, then there is absolutely > no reason

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 03:12 PM, Mark Rutland wrote: >> Exactly, that is why I was thinking it would take less "review" time. >> Indeed, if there is no driver, why would it matter what those bindings >> are? > > If you believe that the bindings don't matter, then there is absolutely > no reason

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 03:12 PM, Mark Rutland wrote: >> Exactly, that is why I was thinking it would take less "review" time. >> Indeed, if there is no driver, why would it matter what those bindings >> are? > > If you believe that the bindings don't matter, then there is absolutely > no reason

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 03:12 PM, Mark Rutland wrote: >> Exactly, that is why I was thinking it would take less "review" time. >> Indeed, if there is no driver, why would it matter what those bindings >> are? > > If you believe that the bindings don't matter, then there is absolutely > no reason

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Timur, On Tue, Sep 13, 2016 at 06:37:16AM -0500, Timur Tabi wrote: > Sebastian Frias wrote: > >Let's make an abstraction of the word 'binding', 'create a binding', etc. and > >just focus on this: > >- Somebody submits a DT file that contains properties and nodes that are > >*not used* by any

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Timur, On Tue, Sep 13, 2016 at 06:37:16AM -0500, Timur Tabi wrote: > Sebastian Frias wrote: > >Let's make an abstraction of the word 'binding', 'create a binding', etc. and > >just focus on this: > >- Somebody submits a DT file that contains properties and nodes that are > >*not used* by any

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On Tue, Sep 13, 2016 at 12:04:07PM +0200, Sebastian Frias wrote: > Hi Mark, > > On 09/12/2016 06:56 PM, Mark Rutland wrote: > > The latter is extremely difficult to judge when you just > > get a binding document with little or no additional context. > > Exactly, that is why I was thinking it

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On Tue, Sep 13, 2016 at 12:04:07PM +0200, Sebastian Frias wrote: > Hi Mark, > > On 09/12/2016 06:56 PM, Mark Rutland wrote: > > The latter is extremely difficult to judge when you just > > get a binding document with little or no additional context. > > Exactly, that is why I was thinking it

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Sebastian Frias wrote: Let's make an abstraction of the word 'binding', 'create a binding', etc. and just focus on this: - Somebody submits a DT file that contains properties and nodes that are *not used* by any Linux driver. - Said properties and nodes serve as HW description for HW blocks for

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Sebastian Frias wrote: Let's make an abstraction of the word 'binding', 'create a binding', etc. and just focus on this: - Somebody submits a DT file that contains properties and nodes that are *not used* by any Linux driver. - Said properties and nodes serve as HW description for HW blocks for

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/12/2016 06:56 PM, Mark Rutland wrote: >> Exactly, that's why to I'm having trouble to understand why there is so much >> insistence on "getting the DT 100% right", since a HW change could imply >> that what made 100% sense yesterday, does not today. >> Since that is a possibility

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/12/2016 06:56 PM, Mark Rutland wrote: >> Exactly, that's why to I'm having trouble to understand why there is so much >> insistence on "getting the DT 100% right", since a HW change could imply >> that what made 100% sense yesterday, does not today. >> Since that is a possibility

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi, On Mon, Sep 12, 2016 at 10:45:37AM -0600, Warner Losh wrote: > Do I have more examples where FreeBSD has to deviate because the DT is > actually Linux specific and does a poor job of modeling the hardware > and instead reflects the Linux driver model? I have plenty of those... I guess you

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi, On Mon, Sep 12, 2016 at 10:45:37AM -0600, Warner Losh wrote: > Do I have more examples where FreeBSD has to deviate because the DT is > actually Linux specific and does a poor job of modeling the hardware > and instead reflects the Linux driver model? I have plenty of those... I guess you

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On Mon, Sep 12, 2016 at 11:49:07AM -0500, Timur Tabi wrote: > Warner Losh wrote: > >Do I have more examples > >where FreeBSD has to deviate because the DT is actually Linux > >specific and does a poor job of modeling the hardware and instead > >reflects the Linux driver model? I have plenty of

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On Mon, Sep 12, 2016 at 11:49:07AM -0500, Timur Tabi wrote: > Warner Losh wrote: > >Do I have more examples > >where FreeBSD has to deviate because the DT is actually Linux > >specific and does a poor job of modeling the hardware and instead > >reflects the Linux driver model? I have plenty of

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On Mon, Sep 12, 2016 at 06:07:05PM +0200, Sebastian Frias wrote: > On 09/12/2016 04:01 PM, Mark Rutland wrote: > > Few devices these says are entirely independent, and most devices can be > > instantiated multiple times (even if there happens to only be a single > > instance in practice). For the

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On Mon, Sep 12, 2016 at 06:07:05PM +0200, Sebastian Frias wrote: > On 09/12/2016 04:01 PM, Mark Rutland wrote: > > Few devices these says are entirely independent, and most devices can be > > instantiated multiple times (even if there happens to only be a single > > instance in practice). For the

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Warner Losh wrote: Do I have more examples where FreeBSD has to deviate because the DT is actually Linux specific and does a poor job of modeling the hardware and instead reflects the Linux driver model? I have plenty of those... I think it would be a great idea if the FreeBSD and Linux DT

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Warner Losh wrote: Do I have more examples where FreeBSD has to deviate because the DT is actually Linux specific and does a poor job of modeling the hardware and instead reflects the Linux driver model? I have plenty of those... I think it would be a great idea if the FreeBSD and Linux DT

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On Mon, Sep 12, 2016 at 10:29 AM, Sebastian Frias wrote: > Hi Warner, > > On 09/12/2016 04:26 PM, Warner Losh wrote: >> On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland wrote: Since the question seems understood, do you have an example of other SoC's

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On Mon, Sep 12, 2016 at 10:29 AM, Sebastian Frias wrote: > Hi Warner, > > On 09/12/2016 04:26 PM, Warner Losh wrote: >> On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland wrote: Since the question seems understood, do you have an example of other SoC's doing something similar? >>> >>> I do

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Warner, On 09/12/2016 04:26 PM, Warner Losh wrote: > On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland 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

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Warner, On 09/12/2016 04:26 PM, Warner Losh wrote: > On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland 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 >>

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On 09/12/2016 06:07 PM, Sebastian Frias wrote: > Hi Mark, > > On 09/12/2016 04:01 PM, Mark Rutland wrote: >>> 3rd parties could choose to write a driver (as opposed to use say, a >>> user-mode >>> library) if it fits their programming model better, if they think they would >>> have better

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On 09/12/2016 06:07 PM, Sebastian Frias wrote: > Hi Mark, > > On 09/12/2016 04:01 PM, Mark Rutland wrote: >>> 3rd parties could choose to write a driver (as opposed to use say, a >>> user-mode >>> library) if it fits their programming model better, if they think they would >>> have better

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Sebastian Frias wrote: You're not changing the code, but you are creating a binding. Bindings are intended to be stable (i.e. a working DTB from today should continue to work in future), and thus there are ramifications. Ok, but who is responsible for such guarantee? The developers who

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Sebastian Frias wrote: You're not changing the code, but you are creating a binding. Bindings are intended to be stable (i.e. a working DTB from today should continue to work in future), and thus there are ramifications. Ok, but who is responsible for such guarantee? The developers who

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/12/2016 04:01 PM, Mark Rutland wrote: >> 3rd parties could choose to write a driver (as opposed to use say, a >> user-mode >> library) if it fits their programming model better, if they think they would >> have better performance, or other reasons. > > A vendor can always choose

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/12/2016 04:01 PM, Mark Rutland wrote: >> 3rd parties could choose to write a driver (as opposed to use say, a >> user-mode >> library) if it fits their programming model better, if they think they would >> have better performance, or other reasons. > > A vendor can always choose

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland 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,

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland 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

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi, On Mon, Sep 12, 2016 at 03:15:00PM +0200, Sebastian Frias wrote: > On 09/12/2016 02:38 PM, Mark Rutland wrote: > >> > >> 3rd party users of said SoC could then write kernel modules for such HW > >> blocks using the DT description. The DT would thus become the authoritative > >> source of

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi, On Mon, Sep 12, 2016 at 03:15:00PM +0200, Sebastian Frias wrote: > On 09/12/2016 02:38 PM, Mark Rutland wrote: > >> > >> 3rd party users of said SoC could then write kernel modules for such HW > >> blocks using the DT description. The DT would thus become the authoritative > >> source of

Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers

Sebastian Frias wrote: 3rd parties could choose to write a driver (as opposed to use say, a user-mode library) if it fits their programming model better, if they think they would have better performance, or other reasons. The main idea is to make DT the authoritative source of HW description.

Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers

Sebastian Frias wrote: 3rd parties could choose to write a driver (as opposed to use say, a user-mode library) if it fits their programming model better, if they think they would have better performance, or other reasons. The main idea is to make DT the authoritative source of HW description.

Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/12/2016 02:38 PM, Mark Rutland wrote: >> >> 3rd party users of said SoC could then write kernel modules for such HW >> blocks using the DT description. The DT would thus become the authoritative >> source of information regarding register programming for the SoC. > > I don't

Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/12/2016 02:38 PM, Mark Rutland wrote: >> >> 3rd party users of said SoC could then write kernel modules for such HW >> blocks using the DT description. The DT would thus become the authoritative >> source of information regarding register programming for the SoC. > > I don't

Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers

On Mon, Sep 12, 2016 at 02:29:37PM +0200, Sebastian Frias wrote: > My question is about submitting DT properties/nodes (describing some HW) for > which there is no Linux driver. Like register addresses for HW blocks, > including HW capabilities of said HW blocks, which may or may not be setup > by

Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers

On Mon, Sep 12, 2016 at 02:29:37PM +0200, Sebastian Frias wrote: > My question is about submitting DT properties/nodes (describing some HW) for > which there is no Linux driver. Like register addresses for HW blocks, > including HW capabilities of said HW blocks, which may or may not be setup > by

Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers

Hi Timur, On 08/28/2016 10:36 PM, Timur Tabi wrote: > On Wed, Aug 24, 2016 at 9:29 AM, Sebastian Frias wrote: >> >> If this is really not possible, it forces the SoC manufacturer to expose >> those properties in a different way, thus wasting a (seemingly) perfectly >> fine way

Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers

Hi Timur, On 08/28/2016 10:36 PM, Timur Tabi wrote: > On Wed, Aug 24, 2016 at 9:29 AM, Sebastian Frias wrote: >> >> If this is really not possible, it forces the SoC manufacturer to expose >> those properties in a different way, thus wasting a (seemingly) perfectly >> fine way of doing so: the

Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers

On Wed, Aug 24, 2016 at 9:29 AM, Sebastian Frias wrote: > > If this is really not possible, it forces the SoC manufacturer to expose > those properties in a different way, thus wasting a (seemingly) perfectly > fine way of doing so: the DT and its documentation. When you submit

Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers

On Wed, Aug 24, 2016 at 9:29 AM, Sebastian Frias wrote: > > If this is really not possible, it forces the SoC manufacturer to expose > those properties in a different way, thus wasting a (seemingly) perfectly > fine way of doing so: the DT and its documentation. When you submit a new driver

ARM,SoC: About the use DT-defined properties by 3rd-party drivers

Hi, Given a SoC and its SDK, 3rd party users of said SoC (customers of the SoC's manufacturer) may need/want to write kernel modules. Since the DT describes the HW, it would make sense to expose some HW properties through the DT, and have 3rd party users rely on them to write their drivers in a

ARM,SoC: About the use DT-defined properties by 3rd-party drivers

Hi, Given a SoC and its SDK, 3rd party users of said SoC (customers of the SoC's manufacturer) may need/want to write kernel modules. Since the DT describes the HW, it would make sense to expose some HW properties through the DT, and have 3rd party users rely on them to write their drivers in a