| Message ID | 20240826144352.3026980-2-niklas.soderlund+renesas@ragnatech.se |
|---|---|
| State | Superseded |
| Headers | show |
| Series | rcar-isp: Add support for R-Car V4M | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/patch-applied | success | |
| robh/dtbs-check | warning | build log |
| robh/dt-meta-schema | success |
On Mon, Aug 26, 2024 at 04:43:47PM +0200, Niklas Söderlund wrote: > The ISP Channel Selector IP is the same for all current Gen4 devices. > This was not known when adding support for V3U and V4H and a single SoC > specific compatible was used. > > Before adding more SoC specific bindings for V4M add a family compatible > fallback for Gen4. That way the driver only needs to be updated once for > Gen4, and we still have the option to fix any problems in the driver if > any testable differences between the SoCs are found. > > There are already DTS files using the V3U and V4H compatibles which > needs to be updated to not produce a warning for DTS checks. The driver > also needs to kept the compatible values to be backward compatible , but > for new Gen4 SoCs such as V4M we can avoid this. > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > --- > * Changes since v1 > - New in v2. > --- > Documentation/devicetree/bindings/media/renesas,isp.yaml | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml > index 33650a1ea034..730c86f2d7b1 100644 > --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml > +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml > @@ -22,6 +22,7 @@ properties: > - enum: > - renesas,r8a779a0-isp # V3U > - renesas,r8a779g0-isp # V4H > + - const: renesas,rcar-gen4-isp # Generic R-Car Gen4 Adding generic fallback post-factum is odd, does not feel reliable. Instead use specific compatibles as fallbacks. Best regards, Krzysztof
On 2024-08-27 08:31:22 +0200, Krzysztof Kozlowski wrote: > On Mon, Aug 26, 2024 at 04:43:47PM +0200, Niklas Söderlund wrote: > > The ISP Channel Selector IP is the same for all current Gen4 devices. > > This was not known when adding support for V3U and V4H and a single SoC > > specific compatible was used. > > > > Before adding more SoC specific bindings for V4M add a family compatible > > fallback for Gen4. That way the driver only needs to be updated once for > > Gen4, and we still have the option to fix any problems in the driver if > > any testable differences between the SoCs are found. > > > > There are already DTS files using the V3U and V4H compatibles which > > needs to be updated to not produce a warning for DTS checks. The driver > > also needs to kept the compatible values to be backward compatible , but > > for new Gen4 SoCs such as V4M we can avoid this. > > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > --- > > * Changes since v1 > > - New in v2. > > --- > > Documentation/devicetree/bindings/media/renesas,isp.yaml | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml > > index 33650a1ea034..730c86f2d7b1 100644 > > --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml > > +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml > > @@ -22,6 +22,7 @@ properties: > > - enum: > > - renesas,r8a779a0-isp # V3U > > - renesas,r8a779g0-isp # V4H > > + - const: renesas,rcar-gen4-isp # Generic R-Car Gen4 > > Adding generic fallback post-factum is odd, does not feel reliable. > Instead use specific compatibles as fallbacks. I agree, it feels a bit odd. But this was the road we hammered out at great pain for how to be able to move forward with this issue for the other IP block involved in video capture for R-Car Gen4, VIN [1]. This just mirrors that long discussion decision for the R-Car CSISP. I would hate to have different solutions for the two. 1. [PATCH v5 0/6] rcar-vin: Add support for R-Car V4M https://lore.kernel.org/all/20240704161620.1425409-1-niklas.soderlund+renesas@ragnatech.se/
On Tue, Aug 27, 2024 at 10:12:33AM +0200, Niklas Söderlund wrote: > On 2024-08-27 08:31:22 +0200, Krzysztof Kozlowski wrote: > > On Mon, Aug 26, 2024 at 04:43:47PM +0200, Niklas Söderlund wrote: > > > The ISP Channel Selector IP is the same for all current Gen4 devices. > > > This was not known when adding support for V3U and V4H and a single SoC > > > specific compatible was used. > > > > > > Before adding more SoC specific bindings for V4M add a family compatible > > > fallback for Gen4. That way the driver only needs to be updated once for > > > Gen4, and we still have the option to fix any problems in the driver if > > > any testable differences between the SoCs are found. > > > > > > There are already DTS files using the V3U and V4H compatibles which > > > needs to be updated to not produce a warning for DTS checks. The driver > > > also needs to kept the compatible values to be backward compatible , but > > > for new Gen4 SoCs such as V4M we can avoid this. > > > > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > > --- > > > * Changes since v1 > > > - New in v2. > > > --- > > > Documentation/devicetree/bindings/media/renesas,isp.yaml | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml > > > index 33650a1ea034..730c86f2d7b1 100644 > > > --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml > > > +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml > > > @@ -22,6 +22,7 @@ properties: > > > - enum: > > > - renesas,r8a779a0-isp # V3U > > > - renesas,r8a779g0-isp # V4H > > > + - const: renesas,rcar-gen4-isp # Generic R-Car Gen4 > > > > Adding generic fallback post-factum is odd, does not feel reliable. > > Instead use specific compatibles as fallbacks. > > I agree, it feels a bit odd. But this was the road we hammered out at > great pain for how to be able to move forward with this issue for the > other IP block involved in video capture for R-Car Gen4, VIN [1]. This > just mirrors that long discussion decision for the R-Car CSISP. > > I would hate to have different solutions for the two. > > 1. [PATCH v5 0/6] rcar-vin: Add support for R-Car V4M > https://lore.kernel.org/all/20240704161620.1425409-1-niklas.soderlund+renesas@ragnatech.se/ The compatible fallback for VIN has been added following a request from Conor and Rob, so it would be nice if the three of you could agree to achieve consistency in the bindings :-)
On 27/08/2024 23:34, Laurent Pinchart wrote: > On Tue, Aug 27, 2024 at 10:12:33AM +0200, Niklas Söderlund wrote: >> On 2024-08-27 08:31:22 +0200, Krzysztof Kozlowski wrote: >>> On Mon, Aug 26, 2024 at 04:43:47PM +0200, Niklas Söderlund wrote: >>>> The ISP Channel Selector IP is the same for all current Gen4 devices. >>>> This was not known when adding support for V3U and V4H and a single SoC >>>> specific compatible was used. >>>> >>>> Before adding more SoC specific bindings for V4M add a family compatible >>>> fallback for Gen4. That way the driver only needs to be updated once for >>>> Gen4, and we still have the option to fix any problems in the driver if >>>> any testable differences between the SoCs are found. >>>> >>>> There are already DTS files using the V3U and V4H compatibles which >>>> needs to be updated to not produce a warning for DTS checks. The driver >>>> also needs to kept the compatible values to be backward compatible , but >>>> for new Gen4 SoCs such as V4M we can avoid this. >>>> >>>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> >>>> --- >>>> * Changes since v1 >>>> - New in v2. >>>> --- >>>> Documentation/devicetree/bindings/media/renesas,isp.yaml | 3 ++- >>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml >>>> index 33650a1ea034..730c86f2d7b1 100644 >>>> --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml >>>> +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml >>>> @@ -22,6 +22,7 @@ properties: >>>> - enum: >>>> - renesas,r8a779a0-isp # V3U >>>> - renesas,r8a779g0-isp # V4H >>>> + - const: renesas,rcar-gen4-isp # Generic R-Car Gen4 >>> >>> Adding generic fallback post-factum is odd, does not feel reliable. >>> Instead use specific compatibles as fallbacks. >> >> I agree, it feels a bit odd. But this was the road we hammered out at >> great pain for how to be able to move forward with this issue for the >> other IP block involved in video capture for R-Car Gen4, VIN [1]. This >> just mirrors that long discussion decision for the R-Car CSISP. >> >> I would hate to have different solutions for the two. >> >> 1. [PATCH v5 0/6] rcar-vin: Add support for R-Car V4M >> https://lore.kernel.org/all/20240704161620.1425409-1-niklas.soderlund+renesas@ragnatech.se/ > > The compatible fallback for VIN has been added following a request from > Conor and Rob, so it would be nice if the three of you could agree to > achieve consistency in the bindings :-) Don't twist our answers. You need fallback, but specific, not family. There was a countless number of answers from Rob that specific compatibles are preferred. Look, Conor's reply: https://lore.kernel.org/all/20240620-gating-coherent-af984389b2d7@spud/ Do you see family fallback? I think "r8a779g0" is SoC. Look here: https://lore.kernel.org/all/20240610-screen-wolverine-78370c66d40f@spud/ Or here https://lore.kernel.org/all/20240624-rented-danger-300652ab8eeb@wendy/ where Conor agrees against! So let me actually NAK it - you got multiple comments on VIN to use specific compatible. Best regards, Krzysztof
On Mon, Aug 26, 2024 at 4:44 PM Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> wrote: > The ISP Channel Selector IP is the same for all current Gen4 devices. > This was not known when adding support for V3U and V4H and a single SoC > specific compatible was used. > > Before adding more SoC specific bindings for V4M add a family compatible > fallback for Gen4. That way the driver only needs to be updated once for > Gen4, and we still have the option to fix any problems in the driver if > any testable differences between the SoCs are found. > > There are already DTS files using the V3U and V4H compatibles which > needs to be updated to not produce a warning for DTS checks. The driver > also needs to kept the compatible values to be backward compatible , but > for new Gen4 SoCs such as V4M we can avoid this. > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > --- > * Changes since v1 > - New in v2. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> This is in line with Section 2.3.1 ("Standard Properties / Compatible") of the Devicetree Specification, Release v0.4, as it is used "to express compatibility with a family of similar devices". Note that this does deviate slightly from the recommended format in the specification ("manufacturer,model"), as the fallback "model" specifies a family, not a model number. As such I think this is fine, and consistent with lots of other existing family-specific compatible values. Gr{oetje,eeting}s, Geert
On Wed, Aug 28, 2024 at 07:36:35AM +0200, Krzysztof Kozlowski wrote: > On 27/08/2024 23:34, Laurent Pinchart wrote: > > On Tue, Aug 27, 2024 at 10:12:33AM +0200, Niklas Söderlund wrote: > >> On 2024-08-27 08:31:22 +0200, Krzysztof Kozlowski wrote: > >>> On Mon, Aug 26, 2024 at 04:43:47PM +0200, Niklas Söderlund wrote: > >>>> The ISP Channel Selector IP is the same for all current Gen4 devices. > >>>> This was not known when adding support for V3U and V4H and a single SoC > >>>> specific compatible was used. > >>>> > >>>> Before adding more SoC specific bindings for V4M add a family compatible > >>>> fallback for Gen4. That way the driver only needs to be updated once for > >>>> Gen4, and we still have the option to fix any problems in the driver if > >>>> any testable differences between the SoCs are found. > >>>> > >>>> There are already DTS files using the V3U and V4H compatibles which > >>>> needs to be updated to not produce a warning for DTS checks. The driver > >>>> also needs to kept the compatible values to be backward compatible , but > >>>> for new Gen4 SoCs such as V4M we can avoid this. > >>>> > >>>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > >>>> --- > >>>> * Changes since v1 > >>>> - New in v2. > >>>> --- > >>>> Documentation/devicetree/bindings/media/renesas,isp.yaml | 3 ++- > >>>> 1 file changed, 2 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml > >>>> index 33650a1ea034..730c86f2d7b1 100644 > >>>> --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml > >>>> +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml > >>>> @@ -22,6 +22,7 @@ properties: > >>>> - enum: > >>>> - renesas,r8a779a0-isp # V3U > >>>> - renesas,r8a779g0-isp # V4H > >>>> + - const: renesas,rcar-gen4-isp # Generic R-Car Gen4 > >>> > >>> Adding generic fallback post-factum is odd, does not feel reliable. > >>> Instead use specific compatibles as fallbacks. > >> > >> I agree, it feels a bit odd. But this was the road we hammered out at > >> great pain for how to be able to move forward with this issue for the > >> other IP block involved in video capture for R-Car Gen4, VIN [1]. This > >> just mirrors that long discussion decision for the R-Car CSISP. > >> > >> I would hate to have different solutions for the two. > >> > >> 1. [PATCH v5 0/6] rcar-vin: Add support for R-Car V4M > >> https://lore.kernel.org/all/20240704161620.1425409-1-niklas.soderlund+renesas@ragnatech.se/ > > > > The compatible fallback for VIN has been added following a request from > > Conor and Rob, so it would be nice if the three of you could agree to > > achieve consistency in the bindings :-) > > Don't twist our answers. You need fallback, but specific, not family. > There was a countless number of answers from Rob that specific > compatibles are preferred. > > Look, Conor's reply: > > https://lore.kernel.org/all/20240620-gating-coherent-af984389b2d7@spud/ > Do you see family fallback? I think "r8a779g0" is SoC. > > Look here: > https://lore.kernel.org/all/20240610-screen-wolverine-78370c66d40f@spud/ > > Or here > https://lore.kernel.org/all/20240624-rented-danger-300652ab8eeb@wendy/ > where Conor agrees against! > > So let me actually NAK it - you got multiple comments on VIN to use > specific compatible. Krzysztof, this tone is not acceptable, regardless of the technical argument. Period. Rob, could you please mediate this ?
On 28/08/2024 12:50, Laurent Pinchart wrote: > On Wed, Aug 28, 2024 at 07:36:35AM +0200, Krzysztof Kozlowski wrote: >> On 27/08/2024 23:34, Laurent Pinchart wrote: >>> On Tue, Aug 27, 2024 at 10:12:33AM +0200, Niklas Söderlund wrote: >>>> On 2024-08-27 08:31:22 +0200, Krzysztof Kozlowski wrote: >>>>> On Mon, Aug 26, 2024 at 04:43:47PM +0200, Niklas Söderlund wrote: >>>>>> The ISP Channel Selector IP is the same for all current Gen4 devices. >>>>>> This was not known when adding support for V3U and V4H and a single SoC >>>>>> specific compatible was used. >>>>>> >>>>>> Before adding more SoC specific bindings for V4M add a family compatible >>>>>> fallback for Gen4. That way the driver only needs to be updated once for >>>>>> Gen4, and we still have the option to fix any problems in the driver if >>>>>> any testable differences between the SoCs are found. >>>>>> >>>>>> There are already DTS files using the V3U and V4H compatibles which >>>>>> needs to be updated to not produce a warning for DTS checks. The driver >>>>>> also needs to kept the compatible values to be backward compatible , but >>>>>> for new Gen4 SoCs such as V4M we can avoid this. >>>>>> >>>>>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> >>>>>> --- >>>>>> * Changes since v1 >>>>>> - New in v2. >>>>>> --- >>>>>> Documentation/devicetree/bindings/media/renesas,isp.yaml | 3 ++- >>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml >>>>>> index 33650a1ea034..730c86f2d7b1 100644 >>>>>> --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml >>>>>> +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml >>>>>> @@ -22,6 +22,7 @@ properties: >>>>>> - enum: >>>>>> - renesas,r8a779a0-isp # V3U >>>>>> - renesas,r8a779g0-isp # V4H >>>>>> + - const: renesas,rcar-gen4-isp # Generic R-Car Gen4 >>>>> >>>>> Adding generic fallback post-factum is odd, does not feel reliable. >>>>> Instead use specific compatibles as fallbacks. >>>> >>>> I agree, it feels a bit odd. But this was the road we hammered out at >>>> great pain for how to be able to move forward with this issue for the >>>> other IP block involved in video capture for R-Car Gen4, VIN [1]. This >>>> just mirrors that long discussion decision for the R-Car CSISP. >>>> >>>> I would hate to have different solutions for the two. >>>> >>>> 1. [PATCH v5 0/6] rcar-vin: Add support for R-Car V4M >>>> https://lore.kernel.org/all/20240704161620.1425409-1-niklas.soderlund+renesas@ragnatech.se/ >>> >>> The compatible fallback for VIN has been added following a request from >>> Conor and Rob, so it would be nice if the three of you could agree to >>> achieve consistency in the bindings :-) >> >> Don't twist our answers. You need fallback, but specific, not family. >> There was a countless number of answers from Rob that specific >> compatibles are preferred. >> >> Look, Conor's reply: >> >> https://lore.kernel.org/all/20240620-gating-coherent-af984389b2d7@spud/ >> Do you see family fallback? I think "r8a779g0" is SoC. >> >> Look here: >> https://lore.kernel.org/all/20240610-screen-wolverine-78370c66d40f@spud/ >> >> Or here >> https://lore.kernel.org/all/20240624-rented-danger-300652ab8eeb@wendy/ >> where Conor agrees against! >> >> So let me actually NAK it - you got multiple comments on VIN to use >> specific compatible. > > Krzysztof, this tone is not acceptable, regardless of the technical > argument. Period. Except elevated arguments I don't think the tone is not acceptable. Anyway, please provide references supporting your statement that Conor and Rob encouraged using generic (not specific) fallback compatible. I provided what I found, so I keep the discussion based on facts. I expect the same from you. Best regards, Krzysztof
On 27/08/2024 23:34, Laurent Pinchart wrote: > On Tue, Aug 27, 2024 at 10:12:33AM +0200, Niklas Söderlund wrote: >> On 2024-08-27 08:31:22 +0200, Krzysztof Kozlowski wrote: >>> On Mon, Aug 26, 2024 at 04:43:47PM +0200, Niklas Söderlund wrote: >>>> The ISP Channel Selector IP is the same for all current Gen4 devices. >>>> This was not known when adding support for V3U and V4H and a single SoC >>>> specific compatible was used. >>>> >>>> Before adding more SoC specific bindings for V4M add a family compatible >>>> fallback for Gen4. That way the driver only needs to be updated once for >>>> Gen4, and we still have the option to fix any problems in the driver if >>>> any testable differences between the SoCs are found. >>>> >>>> There are already DTS files using the V3U and V4H compatibles which >>>> needs to be updated to not produce a warning for DTS checks. The driver >>>> also needs to kept the compatible values to be backward compatible , but >>>> for new Gen4 SoCs such as V4M we can avoid this. >>>> >>>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> >>>> --- >>>> * Changes since v1 >>>> - New in v2. >>>> --- >>>> Documentation/devicetree/bindings/media/renesas,isp.yaml | 3 ++- >>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml >>>> index 33650a1ea034..730c86f2d7b1 100644 >>>> --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml >>>> +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml >>>> @@ -22,6 +22,7 @@ properties: >>>> - enum: >>>> - renesas,r8a779a0-isp # V3U >>>> - renesas,r8a779g0-isp # V4H >>>> + - const: renesas,rcar-gen4-isp # Generic R-Car Gen4 >>> >>> Adding generic fallback post-factum is odd, does not feel reliable. >>> Instead use specific compatibles as fallbacks. >> >> I agree, it feels a bit odd. But this was the road we hammered out at >> great pain for how to be able to move forward with this issue for the >> other IP block involved in video capture for R-Car Gen4, VIN [1]. This >> just mirrors that long discussion decision for the R-Car CSISP. >> >> I would hate to have different solutions for the two. >> >> 1. [PATCH v5 0/6] rcar-vin: Add support for R-Car V4M >> https://lore.kernel.org/all/20240704161620.1425409-1-niklas.soderlund+renesas@ragnatech.se/ > > The compatible fallback for VIN has been added following a request from > Conor and Rob, so it would be nice if the three of you could agree to > achieve consistency in the bindings :-) We are consistent. Above snarky comment is not helping, so please keep it civilized. Best regards, Krzysztof
On Wed, Aug 28, 2024 at 07:36:35AM +0200, Krzysztof Kozlowski wrote: > On 27/08/2024 23:34, Laurent Pinchart wrote: > > On Tue, Aug 27, 2024 at 10:12:33AM +0200, Niklas Söderlund wrote: > >> On 2024-08-27 08:31:22 +0200, Krzysztof Kozlowski wrote: > >>> On Mon, Aug 26, 2024 at 04:43:47PM +0200, Niklas Söderlund wrote: > >>>> The ISP Channel Selector IP is the same for all current Gen4 devices. > >>>> This was not known when adding support for V3U and V4H and a single SoC > >>>> specific compatible was used. > >>>> > >>>> Before adding more SoC specific bindings for V4M add a family compatible > >>>> fallback for Gen4. That way the driver only needs to be updated once for > >>>> Gen4, and we still have the option to fix any problems in the driver if > >>>> any testable differences between the SoCs are found. > >>>> > >>>> There are already DTS files using the V3U and V4H compatibles which > >>>> needs to be updated to not produce a warning for DTS checks. The driver > >>>> also needs to kept the compatible values to be backward compatible , but > >>>> for new Gen4 SoCs such as V4M we can avoid this. > >>>> > >>>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > >>>> --- > >>>> * Changes since v1 > >>>> - New in v2. > >>>> --- > >>>> Documentation/devicetree/bindings/media/renesas,isp.yaml | 3 ++- > >>>> 1 file changed, 2 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml > >>>> index 33650a1ea034..730c86f2d7b1 100644 > >>>> --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml > >>>> +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml > >>>> @@ -22,6 +22,7 @@ properties: > >>>> - enum: > >>>> - renesas,r8a779a0-isp # V3U > >>>> - renesas,r8a779g0-isp # V4H > >>>> + - const: renesas,rcar-gen4-isp # Generic R-Car Gen4 > >>> > >>> Adding generic fallback post-factum is odd, does not feel reliable. > >>> Instead use specific compatibles as fallbacks. > >> > >> I agree, it feels a bit odd. But this was the road we hammered out at > >> great pain for how to be able to move forward with this issue for the > >> other IP block involved in video capture for R-Car Gen4, VIN [1]. This > >> just mirrors that long discussion decision for the R-Car CSISP. > >> > >> I would hate to have different solutions for the two. > >> > >> 1. [PATCH v5 0/6] rcar-vin: Add support for R-Car V4M > >> https://lore.kernel.org/all/20240704161620.1425409-1-niklas.soderlund+renesas@ragnatech.se/ > > > > The compatible fallback for VIN has been added following a request from > > Conor and Rob, so it would be nice if the three of you could agree to > > achieve consistency in the bindings :-) > > Don't twist our answers. You need fallback, but specific, not family. > There was a countless number of answers from Rob that specific > compatibles are preferred. Preferred, definitely. But preferred is not absolute. The Renesas bindings have consistently followed the above style for some time. For the most part that has worked out it seems (based on Geert's slides linked in one of the threads). If you want to continue that here, it's not something I care to argue about. However, I have to agree that adding the fallback after the fact is not ideal. Why design it where you have to carry renesas,r8a779g0-isp and renesas,rcar-gen4-isp in the driver forever when you could have 0 driver changes instead? The problem with genericish fallbacks is you have to know the future. Am I going to have a family of chips with the same block? It's much easier to just say "oh, this new chip is compatible with this old chip". > Look, Conor's reply: > > https://lore.kernel.org/all/20240620-gating-coherent-af984389b2d7@spud/ > Do you see family fallback? I think "r8a779g0" is SoC. > > Look here: > https://lore.kernel.org/all/20240610-screen-wolverine-78370c66d40f@spud/ > > Or here > https://lore.kernel.org/all/20240624-rented-danger-300652ab8eeb@wendy/ > where Conor agrees against! But he ultimately Acked it. > > So let me actually NAK it - you got multiple comments on VIN to use > specific compatible. This doesn't help anything. You've made your point without it. Rob
On Wed, Aug 28, 2024 at 01:06:37PM +0200, Krzysztof Kozlowski wrote: > On 28/08/2024 12:50, Laurent Pinchart wrote: > > On Wed, Aug 28, 2024 at 07:36:35AM +0200, Krzysztof Kozlowski wrote: > >> On 27/08/2024 23:34, Laurent Pinchart wrote: > >>> On Tue, Aug 27, 2024 at 10:12:33AM +0200, Niklas Söderlund wrote: > >>>> On 2024-08-27 08:31:22 +0200, Krzysztof Kozlowski wrote: > >>>>> On Mon, Aug 26, 2024 at 04:43:47PM +0200, Niklas Söderlund wrote: > >>>>>> The ISP Channel Selector IP is the same for all current Gen4 devices. > >>>>>> This was not known when adding support for V3U and V4H and a single SoC > >>>>>> specific compatible was used. > >>>>>> > >>>>>> Before adding more SoC specific bindings for V4M add a family compatible > >>>>>> fallback for Gen4. That way the driver only needs to be updated once for > >>>>>> Gen4, and we still have the option to fix any problems in the driver if > >>>>>> any testable differences between the SoCs are found. > >>>>>> > >>>>>> There are already DTS files using the V3U and V4H compatibles which > >>>>>> needs to be updated to not produce a warning for DTS checks. The driver > >>>>>> also needs to kept the compatible values to be backward compatible , but > >>>>>> for new Gen4 SoCs such as V4M we can avoid this. > >>>>>> > >>>>>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > >>>>>> --- > >>>>>> * Changes since v1 > >>>>>> - New in v2. > >>>>>> --- > >>>>>> Documentation/devicetree/bindings/media/renesas,isp.yaml | 3 ++- > >>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) > >>>>>> > >>>>>> diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml > >>>>>> index 33650a1ea034..730c86f2d7b1 100644 > >>>>>> --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml > >>>>>> +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml > >>>>>> @@ -22,6 +22,7 @@ properties: > >>>>>> - enum: > >>>>>> - renesas,r8a779a0-isp # V3U > >>>>>> - renesas,r8a779g0-isp # V4H > >>>>>> + - const: renesas,rcar-gen4-isp # Generic R-Car Gen4 > >>>>> > >>>>> Adding generic fallback post-factum is odd, does not feel reliable. > >>>>> Instead use specific compatibles as fallbacks. > >>>> > >>>> I agree, it feels a bit odd. But this was the road we hammered out at > >>>> great pain for how to be able to move forward with this issue for the > >>>> other IP block involved in video capture for R-Car Gen4, VIN [1]. This > >>>> just mirrors that long discussion decision for the R-Car CSISP. > >>>> > >>>> I would hate to have different solutions for the two. > >>>> > >>>> 1. [PATCH v5 0/6] rcar-vin: Add support for R-Car V4M > >>>> https://lore.kernel.org/all/20240704161620.1425409-1-niklas.soderlund+renesas@ragnatech.se/ > >>> > >>> The compatible fallback for VIN has been added following a request from > >>> Conor and Rob, so it would be nice if the three of you could agree to > >>> achieve consistency in the bindings :-) > >> > >> Don't twist our answers. You need fallback, but specific, not family. > >> There was a countless number of answers from Rob that specific > >> compatibles are preferred. > >> > >> Look, Conor's reply: > >> > >> https://lore.kernel.org/all/20240620-gating-coherent-af984389b2d7@spud/ > >> Do you see family fallback? I think "r8a779g0" is SoC. > >> > >> Look here: > >> https://lore.kernel.org/all/20240610-screen-wolverine-78370c66d40f@spud/ > >> > >> Or here > >> https://lore.kernel.org/all/20240624-rented-danger-300652ab8eeb@wendy/ > >> where Conor agrees against! > >> > >> So let me actually NAK it - you got multiple comments on VIN to use > >> specific compatible. > > > > Krzysztof, this tone is not acceptable, regardless of the technical > > argument. Period. > > Except elevated arguments I don't think the tone is not acceptable. You cannot control nor change how someone interprets your tone, so there is little point in arguing about it. But it would be worthwhile to reflect on the comment. > Anyway, please provide references supporting your statement that Conor > and Rob encouraged using generic (not specific) fallback compatible. Encouraged? Certainly not, but tolerated or allowed, yes. Every other Renesas binding reflects that. Rob
On Wed, Aug 28, 2024 at 09:46:44AM -0500, Rob Herring wrote: > On Wed, Aug 28, 2024 at 07:36:35AM +0200, Krzysztof Kozlowski wrote: > > On 27/08/2024 23:34, Laurent Pinchart wrote: > > > On Tue, Aug 27, 2024 at 10:12:33AM +0200, Niklas Söderlund wrote: > > >> On 2024-08-27 08:31:22 +0200, Krzysztof Kozlowski wrote: > > >>> On Mon, Aug 26, 2024 at 04:43:47PM +0200, Niklas Söderlund wrote: > > >>>> The ISP Channel Selector IP is the same for all current Gen4 devices. > > >>>> This was not known when adding support for V3U and V4H and a single SoC > > >>>> specific compatible was used. > > >>>> > > >>>> Before adding more SoC specific bindings for V4M add a family compatible > > >>>> fallback for Gen4. That way the driver only needs to be updated once for > > >>>> Gen4, and we still have the option to fix any problems in the driver if > > >>>> any testable differences between the SoCs are found. > > >>>> > > >>>> There are already DTS files using the V3U and V4H compatibles which > > >>>> needs to be updated to not produce a warning for DTS checks. The driver > > >>>> also needs to kept the compatible values to be backward compatible , but > > >>>> for new Gen4 SoCs such as V4M we can avoid this. > > >>>> > > >>>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > >>>> --- > > >>>> * Changes since v1 > > >>>> - New in v2. > > >>>> --- > > >>>> Documentation/devicetree/bindings/media/renesas,isp.yaml | 3 ++- > > >>>> 1 file changed, 2 insertions(+), 1 deletion(-) > > >>>> > > >>>> diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml > > >>>> index 33650a1ea034..730c86f2d7b1 100644 > > >>>> --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml > > >>>> +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml > > >>>> @@ -22,6 +22,7 @@ properties: > > >>>> - enum: > > >>>> - renesas,r8a779a0-isp # V3U > > >>>> - renesas,r8a779g0-isp # V4H > > >>>> + - const: renesas,rcar-gen4-isp # Generic R-Car Gen4 > > >>> > > >>> Adding generic fallback post-factum is odd, does not feel reliable. > > >>> Instead use specific compatibles as fallbacks. > > >> > > >> I agree, it feels a bit odd. But this was the road we hammered out at > > >> great pain for how to be able to move forward with this issue for the > > >> other IP block involved in video capture for R-Car Gen4, VIN [1]. This > > >> just mirrors that long discussion decision for the R-Car CSISP. > > >> > > >> I would hate to have different solutions for the two. > > >> > > >> 1. [PATCH v5 0/6] rcar-vin: Add support for R-Car V4M > > >> https://lore.kernel.org/all/20240704161620.1425409-1-niklas.soderlund+renesas@ragnatech.se/ > > > > > > The compatible fallback for VIN has been added following a request from > > > Conor and Rob, so it would be nice if the three of you could agree to > > > achieve consistency in the bindings :-) > > > > Don't twist our answers. You need fallback, but specific, not family. > > There was a countless number of answers from Rob that specific > > compatibles are preferred. > > Preferred, definitely. But preferred is not absolute. The Renesas > bindings have consistently followed the above style for some time. For > the most part that has worked out it seems (based on Geert's slides > linked in one of the threads). If you want to continue that here, it's > not something I care to argue about. > > However, I have to agree that adding the fallback after the fact is not > ideal. Why design it where you have to carry renesas,r8a779g0-isp and > renesas,rcar-gen4-isp in the driver forever when you could have 0 driver > changes instead? The problem with genericish fallbacks is you have to > know the future. Am I going to have a family of chips with the same > block? It's much easier to just say "oh, this new chip is compatible > with this old chip". Yep, that's what I said pretty much. When I acked it I did so with the comment: | Same caveat here. Using the g model as a fallback is, as we already | discussed, an option too and would be less disruptive. | (at https://lore.kernel.org/all/20240626-unnatural-ember-26ae8895c008@spud/) But... > > Look, Conor's reply: > > > > https://lore.kernel.org/all/20240620-gating-coherent-af984389b2d7@spud/ > > Do you see family fallback? I think "r8a779g0" is SoC. > > > > Look here: > > https://lore.kernel.org/all/20240610-screen-wolverine-78370c66d40f@spud/ > > > > Or here > > https://lore.kernel.org/all/20240624-rented-danger-300652ab8eeb@wendy/ > > where Conor agrees against! > > But he ultimately Acked it. ...since Geert was happy enough with taking the modifications to existing devicetrees, and well aware of the pros/cons of each approach, I figured I had argued it enough and let it be.
On Wed, Aug 28, 2024 at 4:46 PM Rob Herring <robh@kernel.org> wrote: > On Wed, Aug 28, 2024 at 07:36:35AM +0200, Krzysztof Kozlowski wrote: > > On 27/08/2024 23:34, Laurent Pinchart wrote: > > > On Tue, Aug 27, 2024 at 10:12:33AM +0200, Niklas Söderlund wrote: > > >> On 2024-08-27 08:31:22 +0200, Krzysztof Kozlowski wrote: > > >>> On Mon, Aug 26, 2024 at 04:43:47PM +0200, Niklas Söderlund wrote: > > >>>> The ISP Channel Selector IP is the same for all current Gen4 devices. > > >>>> This was not known when adding support for V3U and V4H and a single SoC > > >>>> specific compatible was used. > > >>>> > > >>>> Before adding more SoC specific bindings for V4M add a family compatible > > >>>> fallback for Gen4. That way the driver only needs to be updated once for > > >>>> Gen4, and we still have the option to fix any problems in the driver if > > >>>> any testable differences between the SoCs are found. > > >>>> > > >>>> There are already DTS files using the V3U and V4H compatibles which > > >>>> needs to be updated to not produce a warning for DTS checks. The driver > > >>>> also needs to kept the compatible values to be backward compatible , but > > >>>> for new Gen4 SoCs such as V4M we can avoid this. > > >>>> > > >>>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > >>>> --- > > >>>> * Changes since v1 > > >>>> - New in v2. > > >>>> --- > > >>>> Documentation/devicetree/bindings/media/renesas,isp.yaml | 3 ++- > > >>>> 1 file changed, 2 insertions(+), 1 deletion(-) > > >>>> > > >>>> diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml > > >>>> index 33650a1ea034..730c86f2d7b1 100644 > > >>>> --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml > > >>>> +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml > > >>>> @@ -22,6 +22,7 @@ properties: > > >>>> - enum: > > >>>> - renesas,r8a779a0-isp # V3U > > >>>> - renesas,r8a779g0-isp # V4H > > >>>> + - const: renesas,rcar-gen4-isp # Generic R-Car Gen4 > > >>> > > >>> Adding generic fallback post-factum is odd, does not feel reliable. > > >>> Instead use specific compatibles as fallbacks. > > >> > > >> I agree, it feels a bit odd. But this was the road we hammered out at > > >> great pain for how to be able to move forward with this issue for the > > >> other IP block involved in video capture for R-Car Gen4, VIN [1]. This > > >> just mirrors that long discussion decision for the R-Car CSISP. > > >> > > >> I would hate to have different solutions for the two. > > >> > > >> 1. [PATCH v5 0/6] rcar-vin: Add support for R-Car V4M > > >> https://lore.kernel.org/all/20240704161620.1425409-1-niklas.soderlund+renesas@ragnatech.se/ > > > > > > The compatible fallback for VIN has been added following a request from > > > Conor and Rob, so it would be nice if the three of you could agree to > > > achieve consistency in the bindings :-) > > > > Don't twist our answers. You need fallback, but specific, not family. > > There was a countless number of answers from Rob that specific > > compatibles are preferred. > > Preferred, definitely. But preferred is not absolute. The Renesas > bindings have consistently followed the above style for some time. For > the most part that has worked out it seems (based on Geert's slides > linked in one of the threads). If you want to continue that here, it's > not something I care to argue about. > > However, I have to agree that adding the fallback after the fact is not > ideal. Why design it where you have to carry renesas,r8a779g0-isp and > renesas,rcar-gen4-isp in the driver forever when you could have 0 driver > changes instead? The problem with genericish fallbacks is you have to > know the future. Am I going to have a family of chips with the same > block? It's much easier to just say "oh, this new chip is compatible > with this old chip". I agree it is not ideal, but it worked well for us. R-Car Gen4 was a bit special, as its first member was named R-Car V3U, and at that time it wasn't clear whether R-Car V3U was some sort of one-off intermediate between Gen3 and Gen4, or the real thing. In addition, the second Gen4 SoC (R-Car S4-8) is network-oriented, and doesn't have any media support at all. So we had to wait for R-Car V4H and V4M to get a better picture of media commonalities. Note that unlike on R-Car Gen2, R-Car Gen3 Video-In uses only SoC-specific compatible values, as the VIN module on Gen3 had SoC-specific routings, and a generic compatible value thus couldn't work. Hence for R-Car Gen4, we also started with only SoC-specific compatible values, which turned out not needed (so far ;-) due to the introduction of a new player in the pipeline (the ISP). Gr{oetje,eeting}s, Geert
diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml index 33650a1ea034..730c86f2d7b1 100644 --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml @@ -22,6 +22,7 @@ properties: - enum: - renesas,r8a779a0-isp # V3U - renesas,r8a779g0-isp # V4H + - const: renesas,rcar-gen4-isp # Generic R-Car Gen4 reg: maxItems: 1 @@ -116,7 +117,7 @@ examples: #include <dt-bindings/power/r8a779a0-sysc.h> isp1: isp@fed20000 { - compatible = "renesas,r8a779a0-isp"; + compatible = "renesas,r8a779a0-isp", "renesas,rcar-gen4-isp"; reg = <0xfed20000 0x10000>; interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 613>;
The ISP Channel Selector IP is the same for all current Gen4 devices. This was not known when adding support for V3U and V4H and a single SoC specific compatible was used. Before adding more SoC specific bindings for V4M add a family compatible fallback for Gen4. That way the driver only needs to be updated once for Gen4, and we still have the option to fix any problems in the driver if any testable differences between the SoCs are found. There are already DTS files using the V3U and V4H compatibles which needs to be updated to not produce a warning for DTS checks. The driver also needs to kept the compatible values to be backward compatible , but for new Gen4 SoCs such as V4M we can avoid this. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> --- * Changes since v1 - New in v2. --- Documentation/devicetree/bindings/media/renesas,isp.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)