diff mbox series

[v2,5/9] dt-bindings: iio: dac: add ad3552r axi-dac compatible

Message ID 20240905-wip-bl-ad3552r-axi-v0-iio-testing-v2-5-87d669674c00@baylibre.com (mailing list archive)
State Changes Requested
Headers show
Series iio: add support for the ad3552r AXI DAC IP | expand

Commit Message

Angelo Dureghello Sept. 5, 2024, 3:17 p.m. UTC
From: Angelo Dureghello <adureghello@baylibre.com>

Add a new compatible for the ad3552r variant of the generic DAC IP.

The ad3552r DAC IP variant is very similar to the generic DAC IP,
register map is the same, but some register fields are specific to
this IP, and also, a DDR QSPI bus has been included in the IP.

Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
 Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
 1 file changed, 1 insertion(+)

Comments

Rob Herring Sept. 5, 2024, 4:28 p.m. UTC | #1
On Thu, 05 Sep 2024 17:17:35 +0200, Angelo Dureghello wrote:
> From: Angelo Dureghello <adureghello@baylibre.com>
> 
> Add a new compatible for the ad3552r variant of the generic DAC IP.
> 
> The ad3552r DAC IP variant is very similar to the generic DAC IP,
> register map is the same, but some register fields are specific to
> this IP, and also, a DDR QSPI bus has been included in the IP.
> 
> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
> ---
>  Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.example.dtb: axi_dac@44a70000: 'dac' does not match any of the regexes: 'pinctrl-[0-9]+'
	from schema $id: http://devicetree.org/schemas/iio/dac/adi,axi-dac.yaml#

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240905-wip-bl-ad3552r-axi-v0-iio-testing-v2-5-87d669674c00@baylibre.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
David Lechner Sept. 5, 2024, 9:08 p.m. UTC | #2
On 9/5/24 10:17 AM, Angelo Dureghello wrote:
> From: Angelo Dureghello <adureghello@baylibre.com>
> 
> Add a new compatible for the ad3552r variant of the generic DAC IP.
> 
> The ad3552r DAC IP variant is very similar to the generic DAC IP,
> register map is the same, but some register fields are specific to
> this IP, and also, a DDR QSPI bus has been included in the IP.
> 
> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
> ---
>  Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> index a55e9bfc66d7..c0cccb7a99a4 100644
> --- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> @@ -24,6 +24,7 @@ properties:
>    compatible:
>      enum:
>        - adi,axi-dac-9.1.b
> +      - adi,axi-dac-ad3552r
>  
>    reg:
>      maxItems: 1
> 

I think we will also need more for child nodes:

patternProperties:
  "^dac@[0-9a-f]+$":
    type: object
    additionalProperties: true

    reg:
      # add more rules for reg here

    required:
      - compatible
      - reg

allOf:
  - if:
      not:
        properties:
          compatible:
            contains:
              - adi,axi-dac-ad3552r
    then:
      patternProperties:
        "^dac@[0-9a-f]+$": false

---

Or use existing SPI bindings.
Krzysztof Kozlowski Sept. 6, 2024, 7:22 a.m. UTC | #3
On Thu, Sep 05, 2024 at 05:17:35PM +0200, Angelo Dureghello wrote:
> From: Angelo Dureghello <adureghello@baylibre.com>
> 
> Add a new compatible for the ad3552r variant of the generic DAC IP.
> 
> The ad3552r DAC IP variant is very similar to the generic DAC IP,
> register map is the same, but some register fields are specific to
> this IP, and also, a DDR QSPI bus has been included in the IP.
> 
> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
> ---
>  Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> index a55e9bfc66d7..c0cccb7a99a4 100644
> --- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> @@ -24,6 +24,7 @@ properties:
>    compatible:
>      enum:
>        - adi,axi-dac-9.1.b
> +      - adi,axi-dac-ad3552r

I am sorry, but what is the product here? It looks like either wrong
order or even completely redundant. What is ad3552r?

And why versions are mixed with real products but without any
compatibility. What does the version express in such case?

Best regards,
Krzysztof
Angelo Dureghello Sept. 6, 2024, 9:11 a.m. UTC | #4
Hi Krzysztof,

On 06/09/24 9:22 AM, Krzysztof Kozlowski wrote:
> On Thu, Sep 05, 2024 at 05:17:35PM +0200, Angelo Dureghello wrote:
>> From: Angelo Dureghello <adureghello@baylibre.com>
>>
>> Add a new compatible for the ad3552r variant of the generic DAC IP.
>>
>> The ad3552r DAC IP variant is very similar to the generic DAC IP,
>> register map is the same, but some register fields are specific to
>> this IP, and also, a DDR QSPI bus has been included in the IP.
>>
>> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
>> ---
>>   Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>> index a55e9bfc66d7..c0cccb7a99a4 100644
>> --- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>> +++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>> @@ -24,6 +24,7 @@ properties:
>>     compatible:
>>       enum:
>>         - adi,axi-dac-9.1.b
>> +      - adi,axi-dac-ad3552r
> I am sorry, but what is the product here? It looks like either wrong
> order or even completely redundant. What is ad3552r?
>
> And why versions are mixed with real products but without any
> compatibility. What does the version express in such case?

dac-ad3552r IP (fpga) is a variant of the dac IP, very similar,
about the version, it still reads as 9.1.b

so i can eventually change it to:

adi,axi-dac-ad3552-9.1.b

Should be more correct.

> Best regards,
> Krzysztof
>
Krzysztof Kozlowski Sept. 6, 2024, 9:37 a.m. UTC | #5
On 06/09/2024 11:11, Angelo Dureghello wrote:
> Hi Krzysztof,
> 
> On 06/09/24 9:22 AM, Krzysztof Kozlowski wrote:
>> On Thu, Sep 05, 2024 at 05:17:35PM +0200, Angelo Dureghello wrote:
>>> From: Angelo Dureghello <adureghello@baylibre.com>
>>>
>>> Add a new compatible for the ad3552r variant of the generic DAC IP.
>>>
>>> The ad3552r DAC IP variant is very similar to the generic DAC IP,
>>> register map is the same, but some register fields are specific to
>>> this IP, and also, a DDR QSPI bus has been included in the IP.
>>>
>>> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
>>> ---
>>>   Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>> index a55e9bfc66d7..c0cccb7a99a4 100644
>>> --- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>> +++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>> @@ -24,6 +24,7 @@ properties:
>>>     compatible:
>>>       enum:
>>>         - adi,axi-dac-9.1.b
>>> +      - adi,axi-dac-ad3552r
>> I am sorry, but what is the product here? It looks like either wrong
>> order or even completely redundant. What is ad3552r?
>>
>> And why versions are mixed with real products but without any
>> compatibility. What does the version express in such case?
> 
> dac-ad3552r IP (fpga) is a variant of the dac IP, very similar,
> about the version, it still reads as 9.1.b
> 
> so i can eventually change it to:
> 
> adi,axi-dac-ad3552-9.1.b
> 
> Should be more correct.

No. First ad3552r is the product, so axi-dac is redundant. Second why
adding versions if you have product names? Versioning was allowed
because apparently that's how these are called, but now it turns out it
is not version but names.

Third, versions are useless if you do not use them as fallbacks.

Something this is really broken and I don't know if the binding or this
patch.

Best regards,
Krzysztof
Nuno Sá Sept. 6, 2024, 11:53 a.m. UTC | #6
On Fri, 2024-09-06 at 11:37 +0200, Krzysztof Kozlowski wrote:
> On 06/09/2024 11:11, Angelo Dureghello wrote:
> > Hi Krzysztof,
> > 
> > On 06/09/24 9:22 AM, Krzysztof Kozlowski wrote:
> > > On Thu, Sep 05, 2024 at 05:17:35PM +0200, Angelo Dureghello wrote:
> > > > From: Angelo Dureghello <adureghello@baylibre.com>
> > > > 
> > > > Add a new compatible for the ad3552r variant of the generic DAC IP.
> > > > 
> > > > The ad3552r DAC IP variant is very similar to the generic DAC IP,
> > > > register map is the same, but some register fields are specific to
> > > > this IP, and also, a DDR QSPI bus has been included in the IP.
> > > > 
> > > > Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
> > > > ---
> > > >   Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
> > > >   1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> > > > b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> > > > index a55e9bfc66d7..c0cccb7a99a4 100644
> > > > --- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> > > > +++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> > > > @@ -24,6 +24,7 @@ properties:
> > > >     compatible:
> > > >       enum:
> > > >         - adi,axi-dac-9.1.b
> > > > +      - adi,axi-dac-ad3552r
> > > I am sorry, but what is the product here? It looks like either wrong
> > > order or even completely redundant. What is ad3552r?
> > > 
> > > And why versions are mixed with real products but without any
> > > compatibility. What does the version express in such case?
> > 
> > dac-ad3552r IP (fpga) is a variant of the dac IP, very similar,
> > about the version, it still reads as 9.1.b
> > 
> > so i can eventually change it to:
> > 
> > adi,axi-dac-ad3552-9.1.b
> > 
> > Should be more correct.
> 
> No. First ad3552r is the product, so axi-dac is redundant. Second why
> adding versions if you have product names? Versioning was allowed
> because apparently that's how these are called, but now it turns out it
> is not version but names.
> 

Let me try to explain on how this whole thing works...

We have a generic FPGA IP called axi-dac (same story is true for the other axi-adc
IP) which adds some basic and generic capabilities like DDS (Direct digital
synthesis) and the generic one is the compatible existing now. This IP is a so called
IIO backend because it then connects to a real converter (in this case DACs)
extending it's capabilities and also serving as an interface between another block
(typical DMA as this is used for really high speed stuff) and the device. Now,
depending on the actual device, we may need to add/modify some features of the IP and
this is what's happening for the ad3552r DAC (it's still build on top of the base
generic axi-adc). And in this design the IP is also acting as a qspi controller for
actually controlling the configuration of the device while, typically, IIO backends
are meant to only care about the dataplane. With all of this, there are discussions
still happening on the RFC (Angelo was too fast with this version) between using
different properties or new compatibles for changes so significant like this on the
generic IP. See the thread where Conor is also involved.

> Third, versions are useless if you do not use them as fallbacks.
> 

In this particular case we can't use the generic IP as a fallback since without the
bus controller feature the device can't really work. But it can happen we increase
the version on the generic core and use the existing version as fallback 

> Something this is really broken and I don't know if the binding or this
> patch.

Having said the above, I'm really not sure if what we have is the best approach but
these are also early days (upstream) for this so we should still be able to change
things if we need too. I'm fairly sure there's still no one relying on this so we
should be able to change things in a breaking way (if we need to be that extreme).

Thanks!
- Nuno Sá
Krzysztof Kozlowski Sept. 6, 2024, 12:13 p.m. UTC | #7
On 06/09/2024 13:53, Nuno Sá wrote:
> On Fri, 2024-09-06 at 11:37 +0200, Krzysztof Kozlowski wrote:
>> On 06/09/2024 11:11, Angelo Dureghello wrote:
>>> Hi Krzysztof,
>>>
>>> On 06/09/24 9:22 AM, Krzysztof Kozlowski wrote:
>>>> On Thu, Sep 05, 2024 at 05:17:35PM +0200, Angelo Dureghello wrote:
>>>>> From: Angelo Dureghello <adureghello@baylibre.com>
>>>>>
>>>>> Add a new compatible for the ad3552r variant of the generic DAC IP.
>>>>>
>>>>> The ad3552r DAC IP variant is very similar to the generic DAC IP,
>>>>> register map is the same, but some register fields are specific to
>>>>> this IP, and also, a DDR QSPI bus has been included in the IP.
>>>>>
>>>>> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
>>>>> ---
>>>>>   Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
>>>>>   1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>> b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>> index a55e9bfc66d7..c0cccb7a99a4 100644
>>>>> --- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>> +++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>> @@ -24,6 +24,7 @@ properties:
>>>>>     compatible:
>>>>>       enum:
>>>>>         - adi,axi-dac-9.1.b
>>>>> +      - adi,axi-dac-ad3552r
>>>> I am sorry, but what is the product here? It looks like either wrong
>>>> order or even completely redundant. What is ad3552r?
>>>>
>>>> And why versions are mixed with real products but without any
>>>> compatibility. What does the version express in such case?
>>>
>>> dac-ad3552r IP (fpga) is a variant of the dac IP, very similar,
>>> about the version, it still reads as 9.1.b
>>>
>>> so i can eventually change it to:
>>>
>>> adi,axi-dac-ad3552-9.1.b
>>>
>>> Should be more correct.
>>
>> No. First ad3552r is the product, so axi-dac is redundant. Second why
>> adding versions if you have product names? Versioning was allowed
>> because apparently that's how these are called, but now it turns out it
>> is not version but names.
>>
> 
> Let me try to explain on how this whole thing works...
> 
> We have a generic FPGA IP called axi-dac (same story is true for the other axi-adc
> IP) which adds some basic and generic capabilities like DDS (Direct digital
> synthesis) and the generic one is the compatible existing now. This IP is a so called
> IIO backend because it then connects to a real converter (in this case DACs)
> extending it's capabilities and also serving as an interface between another block
> (typical DMA as this is used for really high speed stuff) and the device. Now,
> depending on the actual device, we may need to add/modify some features of the IP and
> this is what's happening for the ad3552r DAC (it's still build on top of the 

What is "ad3552"? DAC right? Then as I said axi-dac is redundant. We do
not call ti,tmp451 a ti,sensor-tmp451, right?

If ad3552 is something else, then the order of naming is not correct.
Product name is always the first.


> generic axi-adc). And in this design the IP is also acting as a qspi controller for
> actually controlling the configuration of the device while, typically, IIO backends
> are meant to only care about the dataplane. With all of this, there are discussions
> still happening on the RFC (Angelo was too fast with this version) between using
> different properties or new compatibles for changes so significant like this on the
> generic IP. See the thread where Conor is also involved.

1. Then what does it mean for "adi,axi-dac-9.1.b"?

2. Is there any real customer product which uses this compatible alone?

If you need to come up with customized compatibles, it means versioned
one is not enough.

If this is 9.1.b but not usable as 9.1.b ("for changes so significant
like this on"), then I claim 9.1.b compatible is useless.

> 
>> Third, versions are useless if you do not use them as fallbacks.
>>
> 
> In this particular case we can't use the generic IP as a fallback since without the
> bus controller feature the device can't really work. But it can happen we increase
> the version on the generic core and use the existing version as fallback 
> 
>> Something this is really broken and I don't know if the binding or this
>> patch.
> 
> Having said the above, I'm really not sure if what we have is the best approach but
> these are also early days (upstream) for this so we should still be able to change
> things if we need too. I'm fairly sure there's still no one relying on this so we
> should be able to change things in a breaking way (if we need to be that extreme).

DT maintainers consistently (before someone here calls me inconsistent)
propose not to use versioned compatibles if they map one-to-one to
products or if they cannot be used alone. Several generic IP blocks like
Synopsys or Cadence, match the latter - the customization from customer
is needed, thus snps/cdns IP-block compatible is not usable.

Best regards,
Krzysztof
Nuno Sá Sept. 6, 2024, 1:52 p.m. UTC | #8
On Fri, 2024-09-06 at 14:13 +0200, Krzysztof Kozlowski wrote:
> On 06/09/2024 13:53, Nuno Sá wrote:
> > On Fri, 2024-09-06 at 11:37 +0200, Krzysztof Kozlowski wrote:
> > > On 06/09/2024 11:11, Angelo Dureghello wrote:
> > > > Hi Krzysztof,
> > > > 
> > > > On 06/09/24 9:22 AM, Krzysztof Kozlowski wrote:
> > > > > On Thu, Sep 05, 2024 at 05:17:35PM +0200, Angelo Dureghello wrote:
> > > > > > From: Angelo Dureghello <adureghello@baylibre.com>
> > > > > > 
> > > > > > Add a new compatible for the ad3552r variant of the generic DAC IP.
> > > > > > 
> > > > > > The ad3552r DAC IP variant is very similar to the generic DAC IP,
> > > > > > register map is the same, but some register fields are specific to
> > > > > > this IP, and also, a DDR QSPI bus has been included in the IP.
> > > > > > 
> > > > > > Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
> > > > > > ---
> > > > > >   Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
> > > > > >   1 file changed, 1 insertion(+)
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> > > > > > b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> > > > > > index a55e9bfc66d7..c0cccb7a99a4 100644
> > > > > > --- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
> > > > > > @@ -24,6 +24,7 @@ properties:
> > > > > >     compatible:
> > > > > >       enum:
> > > > > >         - adi,axi-dac-9.1.b
> > > > > > +      - adi,axi-dac-ad3552r
> > > > > I am sorry, but what is the product here? It looks like either wrong
> > > > > order or even completely redundant. What is ad3552r?
> > > > > 
> > > > > And why versions are mixed with real products but without any
> > > > > compatibility. What does the version express in such case?
> > > > 
> > > > dac-ad3552r IP (fpga) is a variant of the dac IP, very similar,
> > > > about the version, it still reads as 9.1.b
> > > > 
> > > > so i can eventually change it to:
> > > > 
> > > > adi,axi-dac-ad3552-9.1.b
> > > > 
> > > > Should be more correct.
> > > 
> > > No. First ad3552r is the product, so axi-dac is redundant. Second why
> > > adding versions if you have product names? Versioning was allowed
> > > because apparently that's how these are called, but now it turns out it
> > > is not version but names.
> > > 
> > 
> > Let me try to explain on how this whole thing works...
> > 
> > We have a generic FPGA IP called axi-dac (same story is true for the other axi-
> > adc
> > IP) which adds some basic and generic capabilities like DDS (Direct digital
> > synthesis) and the generic one is the compatible existing now. This IP is a so
> > called
> > IIO backend because it then connects to a real converter (in this case DACs)
> > extending it's capabilities and also serving as an interface between another
> > block
> > (typical DMA as this is used for really high speed stuff) and the device. Now,
> > depending on the actual device, we may need to add/modify some features of the IP
> > and
> > this is what's happening for the ad3552r DAC (it's still build on top of the 
> 
> What is "ad3552"? DAC right? Then as I said axi-dac is redundant. We do
> not call ti,tmp451 a ti,sensor-tmp451, right?
> 

Yes, I agree the DAC part is redundant. But I think the axi prefix (or suffix) is
meaningful to differentiate it from the bindings for the device itself.

> If ad3552 is something else, then the order of naming is not correct.
> Product name is always the first.
> 
> 
> > generic axi-adc). And in this design the IP is also acting as a qspi controller
> > for
> > actually controlling the configuration of the device while, typically, IIO
> > backends
> > are meant to only care about the dataplane. With all of this, there are
> > discussions
> > still happening on the RFC (Angelo was too fast with this version) between using
> > different properties or new compatibles for changes so significant like this on
> > the
> > generic IP. See the thread where Conor is also involved.
> 
> 1. Then what does it mean for "adi,axi-dac-9.1.b"?
> 

IIUC, it means that the generic IP cannot really be used with the ad3552r DAC given
the qspi specific bits.

> 2. Is there any real customer product which uses this compatible alone?
> 

Yes, we do have devices that can work with the generic IP.

> If you need to come up with customized compatibles, it means versioned
> one is not enough.
> 

Note this was something that was suggested to Angelo. There's also the option to just
use typical FW properties like the original RFC to describe the HW changes in the IP.
But Conor made some good points on using different compatibles when changes go this
far as being also a bus controller...

> If this is 9.1.b but not usable as 9.1.b ("for changes so significant
> like this on"), then I claim 9.1.b compatible is useless.
> 

The 9.1.b versioning refers to the generic IP version and the custom design for
interfacing with the ad3552r DAC is also based on that version of the generic IP. It
already happened (for non upstream versions of the IP) for the HW folks to increase
the versioning (major) of the generic IP with some breaking change and then new
designs will be based on the newer version. On the driver we use the major number to
detect mismatches between driver expectations and what we really have in HW.

> > 
> > > Third, versions are useless if you do not use them as fallbacks.
> > > 
> > 
> > In this particular case we can't use the generic IP as a fallback since without
> > the
> > bus controller feature the device can't really work. But it can happen we
> > increase
> > the version on the generic core and use the existing version as fallback 
> > 
> > > Something this is really broken and I don't know if the binding or this
> > > patch.
> > 
> > Having said the above, I'm really not sure if what we have is the best approach
> > but
> > these are also early days (upstream) for this so we should still be able to
> > change
> > things if we need too. I'm fairly sure there's still no one relying on this so we
> > should be able to change things in a breaking way (if we need to be that
> > extreme).
> 
> DT maintainers consistently (before someone here calls me inconsistent)
> propose not to use versioned compatibles if they map one-to-one to
> products or if they cannot be used alone. Several generic IP blocks like
> Synopsys or Cadence, match the latter - the customization from customer
> is needed, thus snps/cdns IP-block compatible is not usable.
> 

Given what you're saying above (and IIUC) one thing I can see we doing would be to
forget about the version and assume the generic compatible cannot be used alone (so
adi,axi-dac). I mean, it always has to connect to real device. So we could use the
device name in the compatible and code the expected version for that project (instead
of being part of the compatible name). I guess it's similar on what's happening on
the macb driver? But in that case we do have a cdns,macb compatible that can be used
alone I think.

Only problem I could see with this is that if we have a project adi,axi-foo based on
version 9.1.b and then HW folks move on and introduce 10.0.a and re-do axi-foo on top
of the new core version. Would it then be ok to come up with a compatible like axi-
foo-v2 or axi-foo-10-0-a?

Not sure if any of the above makes much sense...

- Nuno Sá
David Lechner Sept. 6, 2024, 2:04 p.m. UTC | #9
On 9/6/24 8:52 AM, Nuno Sá wrote:
> On Fri, 2024-09-06 at 14:13 +0200, Krzysztof Kozlowski wrote:
>> On 06/09/2024 13:53, Nuno Sá wrote:
>>> On Fri, 2024-09-06 at 11:37 +0200, Krzysztof Kozlowski wrote:
>>>> On 06/09/2024 11:11, Angelo Dureghello wrote:
>>>>> Hi Krzysztof,
>>>>>
>>>>> On 06/09/24 9:22 AM, Krzysztof Kozlowski wrote:
>>>>>> On Thu, Sep 05, 2024 at 05:17:35PM +0200, Angelo Dureghello wrote:
>>>>>>> From: Angelo Dureghello <adureghello@baylibre.com>
>>>>>>>
>>>>>>> Add a new compatible for the ad3552r variant of the generic DAC IP.
>>>>>>>
>>>>>>> The ad3552r DAC IP variant is very similar to the generic DAC IP,
>>>>>>> register map is the same, but some register fields are specific to
>>>>>>> this IP, and also, a DDR QSPI bus has been included in the IP.
>>>>>>>
>>>>>>> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
>>>>>>> ---
>>>>>>>   Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
>>>>>>>   1 file changed, 1 insertion(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>> b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>> index a55e9bfc66d7..c0cccb7a99a4 100644
>>>>>>> --- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>> +++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>> @@ -24,6 +24,7 @@ properties:
>>>>>>>     compatible:
>>>>>>>       enum:
>>>>>>>         - adi,axi-dac-9.1.b
>>>>>>> +      - adi,axi-dac-ad3552r
>>>>>> I am sorry, but what is the product here? It looks like either wrong
>>>>>> order or even completely redundant. What is ad3552r?
>>>>>>
>>>>>> And why versions are mixed with real products but without any
>>>>>> compatibility. What does the version express in such case?
>>>>>
>>>>> dac-ad3552r IP (fpga) is a variant of the dac IP, very similar,
>>>>> about the version, it still reads as 9.1.b
>>>>>
>>>>> so i can eventually change it to:
>>>>>
>>>>> adi,axi-dac-ad3552-9.1.b
>>>>>
>>>>> Should be more correct.
>>>>
>>>> No. First ad3552r is the product, so axi-dac is redundant. Second why
>>>> adding versions if you have product names? Versioning was allowed
>>>> because apparently that's how these are called, but now it turns out it
>>>> is not version but names.
>>>>
>>>
>>> Let me try to explain on how this whole thing works...
>>>
>>> We have a generic FPGA IP called axi-dac (same story is true for the other axi-
>>> adc
>>> IP) which adds some basic and generic capabilities like DDS (Direct digital
>>> synthesis) and the generic one is the compatible existing now. This IP is a so
>>> called
>>> IIO backend because it then connects to a real converter (in this case DACs)
>>> extending it's capabilities and also serving as an interface between another
>>> block
>>> (typical DMA as this is used for really high speed stuff) and the device. Now,
>>> depending on the actual device, we may need to add/modify some features of the IP
>>> and
>>> this is what's happening for the ad3552r DAC (it's still build on top of the 
>>
>> What is "ad3552"? DAC right? Then as I said axi-dac is redundant. We do
>> not call ti,tmp451 a ti,sensor-tmp451, right?
>>
> 
> Yes, I agree the DAC part is redundant. But I think the axi prefix (or suffix) is
> meaningful to differentiate it from the bindings for the device itself.
> 
The binding is for this [1] IP core. The documentation calls the core
"AXI AD3552R", so I agree that "adi,axi-ad2552r" is the most sensible
compatible name.

http://analogdevicesinc.github.io/hdl/library/axi_ad3552r/index.html
Krzysztof Kozlowski Sept. 6, 2024, 4:36 p.m. UTC | #10
On 06/09/2024 16:04, David Lechner wrote:
> On 9/6/24 8:52 AM, Nuno Sá wrote:
>> On Fri, 2024-09-06 at 14:13 +0200, Krzysztof Kozlowski wrote:
>>> On 06/09/2024 13:53, Nuno Sá wrote:
>>>> On Fri, 2024-09-06 at 11:37 +0200, Krzysztof Kozlowski wrote:
>>>>> On 06/09/2024 11:11, Angelo Dureghello wrote:
>>>>>> Hi Krzysztof,
>>>>>>
>>>>>> On 06/09/24 9:22 AM, Krzysztof Kozlowski wrote:
>>>>>>> On Thu, Sep 05, 2024 at 05:17:35PM +0200, Angelo Dureghello wrote:
>>>>>>>> From: Angelo Dureghello <adureghello@baylibre.com>
>>>>>>>>
>>>>>>>> Add a new compatible for the ad3552r variant of the generic DAC IP.
>>>>>>>>
>>>>>>>> The ad3552r DAC IP variant is very similar to the generic DAC IP,
>>>>>>>> register map is the same, but some register fields are specific to
>>>>>>>> this IP, and also, a DDR QSPI bus has been included in the IP.
>>>>>>>>
>>>>>>>> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
>>>>>>>> ---
>>>>>>>>   Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
>>>>>>>>   1 file changed, 1 insertion(+)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>>> b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>>> index a55e9bfc66d7..c0cccb7a99a4 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>>> +++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>>> @@ -24,6 +24,7 @@ properties:
>>>>>>>>     compatible:
>>>>>>>>       enum:
>>>>>>>>         - adi,axi-dac-9.1.b
>>>>>>>> +      - adi,axi-dac-ad3552r
>>>>>>> I am sorry, but what is the product here? It looks like either wrong
>>>>>>> order or even completely redundant. What is ad3552r?
>>>>>>>
>>>>>>> And why versions are mixed with real products but without any
>>>>>>> compatibility. What does the version express in such case?
>>>>>>
>>>>>> dac-ad3552r IP (fpga) is a variant of the dac IP, very similar,
>>>>>> about the version, it still reads as 9.1.b
>>>>>>
>>>>>> so i can eventually change it to:
>>>>>>
>>>>>> adi,axi-dac-ad3552-9.1.b
>>>>>>
>>>>>> Should be more correct.
>>>>>
>>>>> No. First ad3552r is the product, so axi-dac is redundant. Second why
>>>>> adding versions if you have product names? Versioning was allowed
>>>>> because apparently that's how these are called, but now it turns out it
>>>>> is not version but names.
>>>>>
>>>>
>>>> Let me try to explain on how this whole thing works...
>>>>
>>>> We have a generic FPGA IP called axi-dac (same story is true for the other axi-
>>>> adc
>>>> IP) which adds some basic and generic capabilities like DDS (Direct digital
>>>> synthesis) and the generic one is the compatible existing now. This IP is a so
>>>> called
>>>> IIO backend because it then connects to a real converter (in this case DACs)
>>>> extending it's capabilities and also serving as an interface between another
>>>> block
>>>> (typical DMA as this is used for really high speed stuff) and the device. Now,
>>>> depending on the actual device, we may need to add/modify some features of the IP
>>>> and
>>>> this is what's happening for the ad3552r DAC (it's still build on top of the 
>>>
>>> What is "ad3552"? DAC right? Then as I said axi-dac is redundant. We do
>>> not call ti,tmp451 a ti,sensor-tmp451, right?
>>>
>>
>> Yes, I agree the DAC part is redundant. But I think the axi prefix (or suffix) is
>> meaningful to differentiate it from the bindings for the device itself.
>>
> The binding is for this [1] IP core. The documentation calls the core
> "AXI AD3552R", so I agree that "adi,axi-ad2552r" is the most sensible
> compatible name.
> 
> http://analogdevicesinc.github.io/hdl/library/axi_ad3552r/index.html

I don't see any AXI here:
https://www.analog.com/en/products/ad3552r.html
Neither here:
https://www.analog.com/media/en/technical-documentation/data-sheets/ad3552r.pdf

Are these different?

Best regards,
Krzysztof
David Lechner Sept. 6, 2024, 4:42 p.m. UTC | #11
On 9/6/24 11:36 AM, Krzysztof Kozlowski wrote:
> On 06/09/2024 16:04, David Lechner wrote:
>> On 9/6/24 8:52 AM, Nuno Sá wrote:
>>> On Fri, 2024-09-06 at 14:13 +0200, Krzysztof Kozlowski wrote:
>>>> On 06/09/2024 13:53, Nuno Sá wrote:
>>>>> On Fri, 2024-09-06 at 11:37 +0200, Krzysztof Kozlowski wrote:
>>>>>> On 06/09/2024 11:11, Angelo Dureghello wrote:
>>>>>>> Hi Krzysztof,
>>>>>>>
>>>>>>> On 06/09/24 9:22 AM, Krzysztof Kozlowski wrote:
>>>>>>>> On Thu, Sep 05, 2024 at 05:17:35PM +0200, Angelo Dureghello wrote:
>>>>>>>>> From: Angelo Dureghello <adureghello@baylibre.com>
>>>>>>>>>
>>>>>>>>> Add a new compatible for the ad3552r variant of the generic DAC IP.
>>>>>>>>>
>>>>>>>>> The ad3552r DAC IP variant is very similar to the generic DAC IP,
>>>>>>>>> register map is the same, but some register fields are specific to
>>>>>>>>> this IP, and also, a DDR QSPI bus has been included in the IP.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
>>>>>>>>> ---
>>>>>>>>>   Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
>>>>>>>>>   1 file changed, 1 insertion(+)
>>>>>>>>>
>>>>>>>>> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>>>> b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>>>> index a55e9bfc66d7..c0cccb7a99a4 100644
>>>>>>>>> --- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>>>> +++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>>>> @@ -24,6 +24,7 @@ properties:
>>>>>>>>>     compatible:
>>>>>>>>>       enum:
>>>>>>>>>         - adi,axi-dac-9.1.b
>>>>>>>>> +      - adi,axi-dac-ad3552r
>>>>>>>> I am sorry, but what is the product here? It looks like either wrong
>>>>>>>> order or even completely redundant. What is ad3552r?
>>>>>>>>
>>>>>>>> And why versions are mixed with real products but without any
>>>>>>>> compatibility. What does the version express in such case?
>>>>>>>
>>>>>>> dac-ad3552r IP (fpga) is a variant of the dac IP, very similar,
>>>>>>> about the version, it still reads as 9.1.b
>>>>>>>
>>>>>>> so i can eventually change it to:
>>>>>>>
>>>>>>> adi,axi-dac-ad3552-9.1.b
>>>>>>>
>>>>>>> Should be more correct.
>>>>>>
>>>>>> No. First ad3552r is the product, so axi-dac is redundant. Second why
>>>>>> adding versions if you have product names? Versioning was allowed
>>>>>> because apparently that's how these are called, but now it turns out it
>>>>>> is not version but names.
>>>>>>
>>>>>
>>>>> Let me try to explain on how this whole thing works...
>>>>>
>>>>> We have a generic FPGA IP called axi-dac (same story is true for the other axi-
>>>>> adc
>>>>> IP) which adds some basic and generic capabilities like DDS (Direct digital
>>>>> synthesis) and the generic one is the compatible existing now. This IP is a so
>>>>> called
>>>>> IIO backend because it then connects to a real converter (in this case DACs)
>>>>> extending it's capabilities and also serving as an interface between another
>>>>> block
>>>>> (typical DMA as this is used for really high speed stuff) and the device. Now,
>>>>> depending on the actual device, we may need to add/modify some features of the IP
>>>>> and
>>>>> this is what's happening for the ad3552r DAC (it's still build on top of the 
>>>>
>>>> What is "ad3552"? DAC right? Then as I said axi-dac is redundant. We do
>>>> not call ti,tmp451 a ti,sensor-tmp451, right?
>>>>
>>>
>>> Yes, I agree the DAC part is redundant. But I think the axi prefix (or suffix) is
>>> meaningful to differentiate it from the bindings for the device itself.
>>>
>> The binding is for this [1] IP core. The documentation calls the core
>> "AXI AD3552R", so I agree that "adi,axi-ad2552r" is the most sensible
>> compatible name.
>>
>> http://analogdevicesinc.github.io/hdl/library/axi_ad3552r/index.html
> 
> I don't see any AXI here:
> https://www.analog.com/en/products/ad3552r.html
> Neither here:
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad3552r.pdf
> 
> Are these different?


Yes, they are different. AD2553R is the DAC chip itself. But "AXI AD2553R" is an
FPGA IP block designed specifically for use with that chip.
Krzysztof Kozlowski Sept. 6, 2024, 4:43 p.m. UTC | #12
On 06/09/2024 15:52, Nuno Sá wrote:
>>>
>>> We have a generic FPGA IP called axi-dac (same story is true for the other axi-
>>> adc
>>> IP) which adds some basic and generic capabilities like DDS (Direct digital
>>> synthesis) and the generic one is the compatible existing now. This IP is a so
>>> called
>>> IIO backend because it then connects to a real converter (in this case DACs)
>>> extending it's capabilities and also serving as an interface between another
>>> block
>>> (typical DMA as this is used for really high speed stuff) and the device. Now,
>>> depending on the actual device, we may need to add/modify some features of the IP
>>> and
>>> this is what's happening for the ad3552r DAC (it's still build on top of the 
>>
>> What is "ad3552"? DAC right? Then as I said axi-dac is redundant. We do
>> not call ti,tmp451 a ti,sensor-tmp451, right?
>>
> 
> Yes, I agree the DAC part is redundant. But I think the axi prefix (or suffix) is
> meaningful to differentiate it from the bindings for the device itself.

I don't understand: what are the bindings for the device itself? What is
this patch/binding if not device itself?

> 
>> If ad3552 is something else, then the order of naming is not correct.
>> Product name is always the first.
>>
>>
>>> generic axi-adc). And in this design the IP is also acting as a qspi controller
>>> for
>>> actually controlling the configuration of the device while, typically, IIO
>>> backends
>>> are meant to only care about the dataplane. With all of this, there are
>>> discussions
>>> still happening on the RFC (Angelo was too fast with this version) between using
>>> different properties or new compatibles for changes so significant like this on
>>> the
>>> generic IP. See the thread where Conor is also involved.
>>
>> 1. Then what does it mean for "adi,axi-dac-9.1.b"?
>>
> 
> IIUC, it means that the generic IP cannot really be used with the ad3552r DAC given
> the qspi specific bits.

ok

> 
>> 2. Is there any real customer product which uses this compatible alone?
>>
> 
> Yes, we do have devices that can work with the generic IP.

Where are they? There is nothing in the upstream, so maybe that's just
misconfigured downstream DTS?

Or maybe these are just some sort of IP core designs which cannot be
used in real case alone/directly.

> 
>> If you need to come up with customized compatibles, it means versioned
>> one is not enough.
>>
> 
> Note this was something that was suggested to Angelo. There's also the option to just
> use typical FW properties like the original RFC to describe the HW changes in the IP.
> But Conor made some good points on using different compatibles when changes go this
> far as being also a bus controller...
> 
>> If this is 9.1.b but not usable as 9.1.b ("for changes so significant
>> like this on"), then I claim 9.1.b compatible is useless.
>>
> 
> The 9.1.b versioning refers to the generic IP version and the custom design for
> interfacing with the ad3552r DAC is also based on that version of the generic IP. It
> already happened (for non upstream versions of the IP) for the HW folks to increase
> the versioning (major) of the generic IP with some breaking change and then new
> designs will be based on the newer version. On the driver we use the major number to
> detect mismatches between driver expectations and what we really have in HW.
> 
>>>
>>>> Third, versions are useless if you do not use them as fallbacks.
>>>>
>>>
>>> In this particular case we can't use the generic IP as a fallback since without
>>> the
>>> bus controller feature the device can't really work. But it can happen we
>>> increase
>>> the version on the generic core and use the existing version as fallback 
>>>
>>>> Something this is really broken and I don't know if the binding or this
>>>> patch.
>>>
>>> Having said the above, I'm really not sure if what we have is the best approach
>>> but
>>> these are also early days (upstream) for this so we should still be able to
>>> change
>>> things if we need too. I'm fairly sure there's still no one relying on this so we
>>> should be able to change things in a breaking way (if we need to be that
>>> extreme).
>>
>> DT maintainers consistently (before someone here calls me inconsistent)
>> propose not to use versioned compatibles if they map one-to-one to
>> products or if they cannot be used alone. Several generic IP blocks like
>> Synopsys or Cadence, match the latter - the customization from customer
>> is needed, thus snps/cdns IP-block compatible is not usable.
>>
> 
> Given what you're saying above (and IIUC) one thing I can see we doing would be to
> forget about the version and assume the generic compatible cannot be used alone (so
> adi,axi-dac). I mean, it always has to connect to real device. So we could use the
> device name in the compatible and code the expected version for that project (instead
> of being part of the compatible name). I guess it's similar on what's happening on
> the macb driver? But in that case we do have a cdns,macb compatible that can be used
> alone I think.
> 
> Only problem I could see with this is that if we have a project adi,axi-foo based on
> version 9.1.b and then HW folks move on and introduce 10.0.a and re-do axi-foo on top
> of the new core version. Would it then be ok to come up with a compatible like axi-
> foo-v2 or axi-foo-10-0-a?
> 
> Not sure if any of the above makes much sense...

None of above make sense because they are again versioned or generic.
Use final product names, assuming they are such.

Best regards,
Krzysztof
Krzysztof Kozlowski Sept. 6, 2024, 4:44 p.m. UTC | #13
On 06/09/2024 18:42, David Lechner wrote:
> On 9/6/24 11:36 AM, Krzysztof Kozlowski wrote:
>> On 06/09/2024 16:04, David Lechner wrote:
>>> On 9/6/24 8:52 AM, Nuno Sá wrote:
>>>> On Fri, 2024-09-06 at 14:13 +0200, Krzysztof Kozlowski wrote:
>>>>> On 06/09/2024 13:53, Nuno Sá wrote:
>>>>>> On Fri, 2024-09-06 at 11:37 +0200, Krzysztof Kozlowski wrote:
>>>>>>> On 06/09/2024 11:11, Angelo Dureghello wrote:
>>>>>>>> Hi Krzysztof,
>>>>>>>>
>>>>>>>> On 06/09/24 9:22 AM, Krzysztof Kozlowski wrote:
>>>>>>>>> On Thu, Sep 05, 2024 at 05:17:35PM +0200, Angelo Dureghello wrote:
>>>>>>>>>> From: Angelo Dureghello <adureghello@baylibre.com>
>>>>>>>>>>
>>>>>>>>>> Add a new compatible for the ad3552r variant of the generic DAC IP.
>>>>>>>>>>
>>>>>>>>>> The ad3552r DAC IP variant is very similar to the generic DAC IP,
>>>>>>>>>> register map is the same, but some register fields are specific to
>>>>>>>>>> this IP, and also, a DDR QSPI bus has been included in the IP.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
>>>>>>>>>> ---
>>>>>>>>>>   Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml | 1 +
>>>>>>>>>>   1 file changed, 1 insertion(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>>>>> b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>>>>> index a55e9bfc66d7..c0cccb7a99a4 100644
>>>>>>>>>> --- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>>>>> +++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
>>>>>>>>>> @@ -24,6 +24,7 @@ properties:
>>>>>>>>>>     compatible:
>>>>>>>>>>       enum:
>>>>>>>>>>         - adi,axi-dac-9.1.b
>>>>>>>>>> +      - adi,axi-dac-ad3552r
>>>>>>>>> I am sorry, but what is the product here? It looks like either wrong
>>>>>>>>> order or even completely redundant. What is ad3552r?
>>>>>>>>>
>>>>>>>>> And why versions are mixed with real products but without any
>>>>>>>>> compatibility. What does the version express in such case?
>>>>>>>>
>>>>>>>> dac-ad3552r IP (fpga) is a variant of the dac IP, very similar,
>>>>>>>> about the version, it still reads as 9.1.b
>>>>>>>>
>>>>>>>> so i can eventually change it to:
>>>>>>>>
>>>>>>>> adi,axi-dac-ad3552-9.1.b
>>>>>>>>
>>>>>>>> Should be more correct.
>>>>>>>
>>>>>>> No. First ad3552r is the product, so axi-dac is redundant. Second why
>>>>>>> adding versions if you have product names? Versioning was allowed
>>>>>>> because apparently that's how these are called, but now it turns out it
>>>>>>> is not version but names.
>>>>>>>
>>>>>>
>>>>>> Let me try to explain on how this whole thing works...
>>>>>>
>>>>>> We have a generic FPGA IP called axi-dac (same story is true for the other axi-
>>>>>> adc
>>>>>> IP) which adds some basic and generic capabilities like DDS (Direct digital
>>>>>> synthesis) and the generic one is the compatible existing now. This IP is a so
>>>>>> called
>>>>>> IIO backend because it then connects to a real converter (in this case DACs)
>>>>>> extending it's capabilities and also serving as an interface between another
>>>>>> block
>>>>>> (typical DMA as this is used for really high speed stuff) and the device. Now,
>>>>>> depending on the actual device, we may need to add/modify some features of the IP
>>>>>> and
>>>>>> this is what's happening for the ad3552r DAC (it's still build on top of the 
>>>>>
>>>>> What is "ad3552"? DAC right? Then as I said axi-dac is redundant. We do
>>>>> not call ti,tmp451 a ti,sensor-tmp451, right?
>>>>>
>>>>
>>>> Yes, I agree the DAC part is redundant. But I think the axi prefix (or suffix) is
>>>> meaningful to differentiate it from the bindings for the device itself.
>>>>
>>> The binding is for this [1] IP core. The documentation calls the core
>>> "AXI AD3552R", so I agree that "adi,axi-ad2552r" is the most sensible
>>> compatible name.
>>>
>>> http://analogdevicesinc.github.io/hdl/library/axi_ad3552r/index.html
>>
>> I don't see any AXI here:
>> https://www.analog.com/en/products/ad3552r.html
>> Neither here:
>> https://www.analog.com/media/en/technical-documentation/data-sheets/ad3552r.pdf
>>
>> Are these different?
> 
> 
> Yes, they are different. AD2553R is the DAC chip itself. But "AXI AD2553R" is an
> FPGA IP block designed specifically for use with that chip.

OK, this makes sense now. The commit msg said nothing about it. No
distinction and rather confusing "The ad3552r DAC IP".

Best regards,
Krzysztof
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
index a55e9bfc66d7..c0cccb7a99a4 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
@@ -24,6 +24,7 @@  properties:
   compatible:
     enum:
       - adi,axi-dac-9.1.b
+      - adi,axi-dac-ad3552r
 
   reg:
     maxItems: 1