于 2020年11月23日 GMT+08:00 下午7:15:12, Maxime Ripard <[email protected]> 写到:
>Hi!
>
>On Fri, Nov 20, 2020 at 08:51:48PM -0600, Samuel Holland wrote:
>> On 11/20/20 5:30 PM, Icenowy Zheng wrote:
>> >>>>>>> +/ {
>> >>>>>>> + model = "PineTab Developer Sample";
>> >>>>>>> + compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> >>>>>>> +};
>> >>>>>>
>> >>>>>> Changing the DT and the compatible half-way through it isn't
>ok. Please
>> >>>>>> add a new DT with the newer revision like we did for the
>pinephone
>> >>>>>
>> >>>>> We did this on Pine H64.
>> >>>>
>> >>>> What are you referring to? I couldn't find a commit where we did
>what
>> >>>> you suggested in that patch to the pine H64.
>> >>>
>> >>> Oh the situation is complex. On Pine H64, we didn't specify
>anything at
>> >>> start (which is the same here), the DT is originally
>version-neutral
>> >>> but then transitioned to model B, then reverted to model A. Here
>the DT is always
>> >>> for the sample.
>> >>>
>> >>> However, for Pine H64 there's model A/B names, but for PineTab
>there's no
>> >>> any samples that are sold, thus except who got the samples, all
>PineTab
>> >>> owners simply owns a "PineTab", not a "PineTab xxx version".
>> >>
>> >> It's fairly simple really, we can't really predict the future, so
>any DT
>> >> submitted is for the current version of whatever board there is.
>This is
>>
>> I don't think that was the intention at all. The DT was submitted for
>a
>> future product, whatever that future product ends up being at the
>time
>> of its release. Since there are necessarily no users until the
>product
>> ships, there is no chance of breaking users by modifying the DT.
>
>There was no indication of that in the commit though
>
>> >> what we (somewhat messily) did for the PineH64, for the pinephone,
>or
>> >> really any other board that has several revisions
>>
>> Surely a non-public prototype doesn't count as a separate revision!
>This
>> sort of policy strongly discourages ever shipping a board with
>> out-of-the-box mainline Linux support. Because if there any hardware
>> bugs fixed between initial upstreaming and production, the
>manufacture
>> must come up with a new DT name.
>>
>> This is hostile to the users as well, because the "canonical" DT name
>no
>> longer matches the "canonical" (read: the only one ever available)
>> version of the hardware.
>>
>> Do you want manufacturers to submit their initial board DT as
>> "$BOARD-prototype.dts", just in case they have to make a change
>before
>> production? And only after the board is shipped (with out-of-tree
>> patches, of course, to use $BOARD.dts, since the shipped board is
>*not*
>> the prototype) submit a "$BOARD.dts" to mainline?
>>
>> Maxime, can you clarify specifically what the line is where a device
>> tree is "locked down" and further changes to the hardware require a
>new
>> name? First sample leaves the factory? $NUMBER units produced? First
>> sold to the public for money?
>
>The first board that is shipped to a user. From the wiki, the version
>supported here (I guess?) has been shipped to around 100 people, so it
>doesn't really qualify for the "non-public prototype". We still have to
>support these users, whether we like it or not.
>
>> Without some guidance, or a change in policy, this problem is going
>to
>> keep coming up again and again.
>
>There's a few things that are interleaved here. First, there's two hard
>rules: never change the DT name and never change the compatible of a
>board.
>
>The former would break any build system, boot script or documentation,
>and the latter would break the DT compatibility.
>
>Aside from this, things get a bit blurrier since it's mostly about the
>intent. I'm fine with having a DT for a non-public prototype if it's
>clear from day one that it is. In this particular case, the DT just
>stated that support for the pinetab was added. I guess anyone would
>make
>the assumption without any context that this would be for the (or a)
>final design.
>
>Finally, I'd also advise against submitting the parts that are still
>not
>finalized though, because this is also fairly bad for the users. Let's
>take the current situation as the example: from what I understand, the
>screen changed half-way through the process, and the first one was
>upstreamed. This means that any user that would use a kernel with that
>bugfix would have the display working, while rolling back to 5.9 would
>break the display, even though everyone claimed it was supported
>out-of-the-box in mainline. This is a worse situation than not
>supporting the display in the first place here.
>
>> You'll note that so far it has mostly affected Pine devices, and I
>don't
>> think that's because they make more board revisions than other
>> manufacturers.
>
>Yes definitely. Pine devices may be worse though because of their
>policy
>of making their prototypes public. I guess most of the issues we had
>also were due to poor communication: context on what were the Pine
>intentions were missing, and thus we couldn't catch things that turned
>out to be bad later on during review.
>
>> It's because they're actively involved in getting their
>> boards supported upstream. For other manufacturers, it's some user
>> sending in a device tree months after the hardware ships to the
>public
>> -- of course the hardware is more stable at that point.
>
>I mean, it's not black and white either. One could very well send the
>DT
>once the final design is done and that would still be upstreamed way
>before reaching the first user.
>
>> I think Pine's behavior is something we want to encourage, not
>> penalize.
>
>For the DT in particular, yes
>
>> > Okay. But I'm not satisfied with a non-public sample occupies
>> > the pinetab name. Is rename it to pinetab-dev and add a
>> > pinetab-retail okay?
>>
>> To me, naming the production version anything but "pinetab" isn't
>> satisfying either.
>
>I understand where you're coming from, but the point I was making my
>previous mail is precisely that it's not really possible.
>
>You want to name the early adopter version _the_ production version.
>Let's assume the hardware changes again between the early adopter and
>mass-production version. Which one will be _the_ production version?
>The
>early-adopter or the mass-produced one?
>
>There's really no good answer here, and both would suck in their own
>way. The only way to deal with this is to simply avoid defining one
>version as the one true board, and just loading the proper DT in u-boot
>based on whatever clue we have of the hardware revision.
Then will it be okay to rename current pinetab DT to pinetab-sample and
then introduce new DTs all with suffixes?
>
>Maxime
On Mon, Nov 23, 2020 at 07:25:47PM +0800, Icenowy Zheng wrote:
>
>
> 于 2020年11月23日 GMT+08:00 下午7:15:12, Maxime Ripard <[email protected]> 写到:
> >Hi!
> >
> >On Fri, Nov 20, 2020 at 08:51:48PM -0600, Samuel Holland wrote:
> >> On 11/20/20 5:30 PM, Icenowy Zheng wrote:
> >> >>>>>>> +/ {
> >> >>>>>>> + model = "PineTab Developer Sample";
> >> >>>>>>> + compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
> >> >>>>>>> +};
> >> >>>>>>
> >> >>>>>> Changing the DT and the compatible half-way through it isn't
> >ok. Please
> >> >>>>>> add a new DT with the newer revision like we did for the
> >pinephone
> >> >>>>>
> >> >>>>> We did this on Pine H64.
> >> >>>>
> >> >>>> What are you referring to? I couldn't find a commit where we did
> >what
> >> >>>> you suggested in that patch to the pine H64.
> >> >>>
> >> >>> Oh the situation is complex. On Pine H64, we didn't specify
> >anything at
> >> >>> start (which is the same here), the DT is originally
> >version-neutral
> >> >>> but then transitioned to model B, then reverted to model A. Here
> >the DT is always
> >> >>> for the sample.
> >> >>>
> >> >>> However, for Pine H64 there's model A/B names, but for PineTab
> >there's no
> >> >>> any samples that are sold, thus except who got the samples, all
> >PineTab
> >> >>> owners simply owns a "PineTab", not a "PineTab xxx version".
> >> >>
> >> >> It's fairly simple really, we can't really predict the future, so
> >any DT
> >> >> submitted is for the current version of whatever board there is.
> >This is
> >>
> >> I don't think that was the intention at all. The DT was submitted for
> >a
> >> future product, whatever that future product ends up being at the
> >time
> >> of its release. Since there are necessarily no users until the
> >product
> >> ships, there is no chance of breaking users by modifying the DT.
> >
> >There was no indication of that in the commit though
> >
> >> >> what we (somewhat messily) did for the PineH64, for the pinephone,
> >or
> >> >> really any other board that has several revisions
> >>
> >> Surely a non-public prototype doesn't count as a separate revision!
> >This
> >> sort of policy strongly discourages ever shipping a board with
> >> out-of-the-box mainline Linux support. Because if there any hardware
> >> bugs fixed between initial upstreaming and production, the
> >manufacture
> >> must come up with a new DT name.
> >>
> >> This is hostile to the users as well, because the "canonical" DT name
> >no
> >> longer matches the "canonical" (read: the only one ever available)
> >> version of the hardware.
> >>
> >> Do you want manufacturers to submit their initial board DT as
> >> "$BOARD-prototype.dts", just in case they have to make a change
> >before
> >> production? And only after the board is shipped (with out-of-tree
> >> patches, of course, to use $BOARD.dts, since the shipped board is
> >*not*
> >> the prototype) submit a "$BOARD.dts" to mainline?
> >>
> >> Maxime, can you clarify specifically what the line is where a device
> >> tree is "locked down" and further changes to the hardware require a
> >new
> >> name? First sample leaves the factory? $NUMBER units produced? First
> >> sold to the public for money?
> >
> >The first board that is shipped to a user. From the wiki, the version
> >supported here (I guess?) has been shipped to around 100 people, so it
> >doesn't really qualify for the "non-public prototype". We still have to
> >support these users, whether we like it or not.
> >
> >> Without some guidance, or a change in policy, this problem is going
> >to
> >> keep coming up again and again.
> >
> >There's a few things that are interleaved here. First, there's two hard
> >rules: never change the DT name and never change the compatible of a
> >board.
> >
> >The former would break any build system, boot script or documentation,
> >and the latter would break the DT compatibility.
> >
> >Aside from this, things get a bit blurrier since it's mostly about the
> >intent. I'm fine with having a DT for a non-public prototype if it's
> >clear from day one that it is. In this particular case, the DT just
> >stated that support for the pinetab was added. I guess anyone would
> >make
> >the assumption without any context that this would be for the (or a)
> >final design.
> >
> >Finally, I'd also advise against submitting the parts that are still
> >not
> >finalized though, because this is also fairly bad for the users. Let's
> >take the current situation as the example: from what I understand, the
> >screen changed half-way through the process, and the first one was
> >upstreamed. This means that any user that would use a kernel with that
> >bugfix would have the display working, while rolling back to 5.9 would
> >break the display, even though everyone claimed it was supported
> >out-of-the-box in mainline. This is a worse situation than not
> >supporting the display in the first place here.
> >
> >> You'll note that so far it has mostly affected Pine devices, and I
> >don't
> >> think that's because they make more board revisions than other
> >> manufacturers.
> >
> >Yes definitely. Pine devices may be worse though because of their
> >policy
> >of making their prototypes public. I guess most of the issues we had
> >also were due to poor communication: context on what were the Pine
> >intentions were missing, and thus we couldn't catch things that turned
> >out to be bad later on during review.
> >
> >> It's because they're actively involved in getting their
> >> boards supported upstream. For other manufacturers, it's some user
> >> sending in a device tree months after the hardware ships to the
> >public
> >> -- of course the hardware is more stable at that point.
> >
> >I mean, it's not black and white either. One could very well send the
> >DT
> >once the final design is done and that would still be upstreamed way
> >before reaching the first user.
> >
> >> I think Pine's behavior is something we want to encourage, not
> >> penalize.
> >
> >For the DT in particular, yes
> >
> >> > Okay. But I'm not satisfied with a non-public sample occupies
> >> > the pinetab name. Is rename it to pinetab-dev and add a
> >> > pinetab-retail okay?
> >>
> >> To me, naming the production version anything but "pinetab" isn't
> >> satisfying either.
> >
> >I understand where you're coming from, but the point I was making my
> >previous mail is precisely that it's not really possible.
> >
> >You want to name the early adopter version _the_ production version.
> >Let's assume the hardware changes again between the early adopter and
> >mass-production version. Which one will be _the_ production version?
> >The
> >early-adopter or the mass-produced one?
> >
> >There's really no good answer here, and both would suck in their own
> >way. The only way to deal with this is to simply avoid defining one
> >version as the one true board, and just loading the proper DT in u-boot
> >based on whatever clue we have of the hardware revision.
>
> Then will it be okay to rename current pinetab DT to pinetab-sample and
> then introduce new DTs all with suffixes?
No. From my previous mail:
> > there's two hard rules: never change the DT name and never change
> > the compatible of a board.
> >
> > The former would break any build system, boot script or
> > documentation, and the latter would break the DT compatibility.
Maxime
于 2020年11月23日 GMT+08:00 下午8:53:32, Maxime Ripard <[email protected]> 写到:
>On Mon, Nov 23, 2020 at 07:25:47PM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2020年11月23日 GMT+08:00 下午7:15:12, Maxime Ripard <[email protected]>
>写到:
>> >Hi!
>> >
>> >On Fri, Nov 20, 2020 at 08:51:48PM -0600, Samuel Holland wrote:
>> >> On 11/20/20 5:30 PM, Icenowy Zheng wrote:
>> >> >>>>>>> +/ {
>> >> >>>>>>> + model = "PineTab Developer Sample";
>> >> >>>>>>> + compatible = "pine64,pinetab-dev",
>"allwinner,sun50i-a64";
>> >> >>>>>>> +};
>> >> >>>>>>
>> >> >>>>>> Changing the DT and the compatible half-way through it
>isn't
>> >ok. Please
>> >> >>>>>> add a new DT with the newer revision like we did for the
>> >pinephone
>> >> >>>>>
>> >> >>>>> We did this on Pine H64.
>> >> >>>>
>> >> >>>> What are you referring to? I couldn't find a commit where we
>did
>> >what
>> >> >>>> you suggested in that patch to the pine H64.
>> >> >>>
>> >> >>> Oh the situation is complex. On Pine H64, we didn't specify
>> >anything at
>> >> >>> start (which is the same here), the DT is originally
>> >version-neutral
>> >> >>> but then transitioned to model B, then reverted to model A.
>Here
>> >the DT is always
>> >> >>> for the sample.
>> >> >>>
>> >> >>> However, for Pine H64 there's model A/B names, but for PineTab
>> >there's no
>> >> >>> any samples that are sold, thus except who got the samples,
>all
>> >PineTab
>> >> >>> owners simply owns a "PineTab", not a "PineTab xxx version".
>> >> >>
>> >> >> It's fairly simple really, we can't really predict the future,
>so
>> >any DT
>> >> >> submitted is for the current version of whatever board there
>is.
>> >This is
>> >>
>> >> I don't think that was the intention at all. The DT was submitted
>for
>> >a
>> >> future product, whatever that future product ends up being at the
>> >time
>> >> of its release. Since there are necessarily no users until the
>> >product
>> >> ships, there is no chance of breaking users by modifying the DT.
>> >
>> >There was no indication of that in the commit though
>> >
>> >> >> what we (somewhat messily) did for the PineH64, for the
>pinephone,
>> >or
>> >> >> really any other board that has several revisions
>> >>
>> >> Surely a non-public prototype doesn't count as a separate
>revision!
>> >This
>> >> sort of policy strongly discourages ever shipping a board with
>> >> out-of-the-box mainline Linux support. Because if there any
>hardware
>> >> bugs fixed between initial upstreaming and production, the
>> >manufacture
>> >> must come up with a new DT name.
>> >>
>> >> This is hostile to the users as well, because the "canonical" DT
>name
>> >no
>> >> longer matches the "canonical" (read: the only one ever available)
>> >> version of the hardware.
>> >>
>> >> Do you want manufacturers to submit their initial board DT as
>> >> "$BOARD-prototype.dts", just in case they have to make a change
>> >before
>> >> production? And only after the board is shipped (with out-of-tree
>> >> patches, of course, to use $BOARD.dts, since the shipped board is
>> >*not*
>> >> the prototype) submit a "$BOARD.dts" to mainline?
>> >>
>> >> Maxime, can you clarify specifically what the line is where a
>device
>> >> tree is "locked down" and further changes to the hardware require
>a
>> >new
>> >> name? First sample leaves the factory? $NUMBER units produced?
>First
>> >> sold to the public for money?
>> >
>> >The first board that is shipped to a user. From the wiki, the
>version
>> >supported here (I guess?) has been shipped to around 100 people, so
>it
>> >doesn't really qualify for the "non-public prototype". We still have
>to
>> >support these users, whether we like it or not.
>> >
>> >> Without some guidance, or a change in policy, this problem is
>going
>> >to
>> >> keep coming up again and again.
>> >
>> >There's a few things that are interleaved here. First, there's two
>hard
>> >rules: never change the DT name and never change the compatible of a
>> >board.
>> >
>> >The former would break any build system, boot script or
>documentation,
>> >and the latter would break the DT compatibility.
>> >
>> >Aside from this, things get a bit blurrier since it's mostly about
>the
>> >intent. I'm fine with having a DT for a non-public prototype if it's
>> >clear from day one that it is. In this particular case, the DT just
>> >stated that support for the pinetab was added. I guess anyone would
>> >make
>> >the assumption without any context that this would be for the (or a)
>> >final design.
>> >
>> >Finally, I'd also advise against submitting the parts that are still
>> >not
>> >finalized though, because this is also fairly bad for the users.
>Let's
>> >take the current situation as the example: from what I understand,
>the
>> >screen changed half-way through the process, and the first one was
>> >upstreamed. This means that any user that would use a kernel with
>that
>> >bugfix would have the display working, while rolling back to 5.9
>would
>> >break the display, even though everyone claimed it was supported
>> >out-of-the-box in mainline. This is a worse situation than not
>> >supporting the display in the first place here.
>> >
>> >> You'll note that so far it has mostly affected Pine devices, and I
>> >don't
>> >> think that's because they make more board revisions than other
>> >> manufacturers.
>> >
>> >Yes definitely. Pine devices may be worse though because of their
>> >policy
>> >of making their prototypes public. I guess most of the issues we had
>> >also were due to poor communication: context on what were the Pine
>> >intentions were missing, and thus we couldn't catch things that
>turned
>> >out to be bad later on during review.
>> >
>> >> It's because they're actively involved in getting their
>> >> boards supported upstream. For other manufacturers, it's some user
>> >> sending in a device tree months after the hardware ships to the
>> >public
>> >> -- of course the hardware is more stable at that point.
>> >
>> >I mean, it's not black and white either. One could very well send
>the
>> >DT
>> >once the final design is done and that would still be upstreamed way
>> >before reaching the first user.
>> >
>> >> I think Pine's behavior is something we want to encourage, not
>> >> penalize.
>> >
>> >For the DT in particular, yes
>> >
>> >> > Okay. But I'm not satisfied with a non-public sample occupies
>> >> > the pinetab name. Is rename it to pinetab-dev and add a
>> >> > pinetab-retail okay?
>> >>
>> >> To me, naming the production version anything but "pinetab" isn't
>> >> satisfying either.
>> >
>> >I understand where you're coming from, but the point I was making my
>> >previous mail is precisely that it's not really possible.
>> >
>> >You want to name the early adopter version _the_ production version.
>> >Let's assume the hardware changes again between the early adopter
>and
>> >mass-production version. Which one will be _the_ production version?
>> >The
>> >early-adopter or the mass-produced one?
>> >
>> >There's really no good answer here, and both would suck in their own
>> >way. The only way to deal with this is to simply avoid defining one
>> >version as the one true board, and just loading the proper DT in
>u-boot
>> >based on whatever clue we have of the hardware revision.
>>
>> Then will it be okay to rename current pinetab DT to pinetab-sample
>and
>> then introduce new DTs all with suffixes?
>
>No. From my previous mail:
It can be seen as dropping the PineTab DT and introduce new DTs with suffix.
Do we have rule that we cannot drop boards?
>
>> > there's two hard rules: never change the DT name and never change
>> > the compatible of a board.
>> >
>> > The former would break any build system, boot script or
>> > documentation, and the latter would break the DT compatibility.
>
>Maxime
On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote:
> >> >> > Okay. But I'm not satisfied with a non-public sample occupies
> >> >> > the pinetab name. Is rename it to pinetab-dev and add a
> >> >> > pinetab-retail okay?
> >> >>
> >> >> To me, naming the production version anything but "pinetab" isn't
> >> >> satisfying either.
> >> >
> >> >I understand where you're coming from, but the point I was making my
> >> >previous mail is precisely that it's not really possible.
> >> >
> >> >You want to name the early adopter version _the_ production
> >> >version. Let's assume the hardware changes again between the early
> >> >adopter and mass-production version. Which one will be _the_
> >> >production version? The early-adopter or the mass-produced one?
> >> >
> >> >There's really no good answer here, and both would suck in their
> >> >own way. The only way to deal with this is to simply avoid
> >> >defining one version as the one true board, and just loading the
> >> >proper DT in u-boot based on whatever clue we have of the hardware
> >> >revision.
> >
> > > Then will it be okay to rename current pinetab DT to
> > > pinetab-sample and then introduce new DTs all with suffixes?
> >
> > No. From my previous mail:
>
> It can be seen as dropping the PineTab DT and introduce new DTs with
> suffix.
>
> Do we have rule that we cannot drop boards?
Are you really arguing that removing a DT and then adding an identical
one under a different name is not renaming it?