Messages in this thread | | | Subject | Re: [PATCH 1/2] Documentation: bindings: adi,axi-tdd.yaml: Add new TDD engine driver | From | Nuno Sá <> | Date | Thu, 27 Jul 2023 13:40:31 +0200 |
| |
On Thu, 2023-07-27 at 09:46 +0000, Balas, Eliza wrote: > > > > -----Original Message----- > > From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > Sent: Thursday, July 27, 2023 12:27 > > To: Balas, Eliza <Eliza.Balas@analog.com> > > Cc: Rob Herring <robh+dt@kernel.org>; Krzysztof Kozlowski > > <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley > > <conor+dt@kernel.org>; Derek Kiernan <derek.kiernan@amd.com>; Dragan Cvetic > > <dragan.cvetic@amd.com>; Arnd Bergmann > > <arnd@arndb.de>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; > > linux-kernel@vger.kernel.org; devicetree@vger.kernel.org > > Subject: Re: [PATCH 1/2] Documentation: bindings: adi,axi-tdd.yaml: Add new TDD > > engine driver > > > > [External] > > > > On 27/07/2023 11:05, Balas, Eliza wrote: > > > > > > > -----Original Message----- > > > > From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > > Sent: Wednesday, July 26, 2023 21:35 > > > > To: Balas, Eliza <Eliza.Balas@analog.com> > > > > Cc: Rob Herring <robh+dt@kernel.org>; Krzysztof Kozlowski > > > > <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley > > > > <conor+dt@kernel.org>; Derek Kiernan <derek.kiernan@amd.com>; Dragan Cvetic > > > > <dragan.cvetic@amd.com>; Arnd Bergmann > > > > <arnd@arndb.de>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; > > > > linux-kernel@vger.kernel.org; > > devicetree@vger.kernel.org > > > > Subject: Re: [PATCH 1/2] Documentation: bindings: adi,axi-tdd.yaml: Add new > > > > TDD engine driver > > > > > > > > [External] > > > > > > > > On 26/07/2023 09:11, Eliza Balas wrote: > > > > > Add device tree documentation for the AXI TDD Core. > > > > > The generic TDD controller is in essence a waveform generator capable > > > > > of addressing RF applications which require Time Division Duplexing, > > > > > as well as controlling other modules of general applications through > > > > > its dedicated 32 channel outputs. > > > > > > > > > > The reason of creating the generic TDD controller was to reduce the > > > > > naming confusion around the existing repurposed TDD core built for > > > > > AD9361, as well as expanding its number of output channels for systems > > > > > which require more than six controlling signals. > > > > > > > > Please use subject prefixes matching the subsystem. You can get them for > > > > example with `git log --oneline -- DIRECTORY_OR_FILE` > > on > > > > the directory your patch is touching. > > > > > > > > Subject: drop driver. Bindings are for hardware, not drivers... unless driver > > > > is here a hardware term? > > > > > > It is not a hardware term in this case, I will make the changes. > > > > > > > > > > > > > Signed-off-by: Eliza Balas <eliza.balas@analog.com> > > > > > --- > > > > > .../devicetree/bindings/misc/adi,axi-tdd.yaml | 51 +++++++++++++++++++ > > > > > MAINTAINERS | 7 +++ > > > > > 2 files changed, 58 insertions(+) > > > > > create mode 100644 > > > > > Documentation/devicetree/bindings/misc/adi,axi-tdd.yaml > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/misc/adi,axi-tdd.yaml > > > > > b/Documentation/devicetree/bindings/misc/adi,axi-tdd.yaml > > > > > new file mode 100644 > > > > > index 000000000000..1894c1c34d4f > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/misc/adi,axi-tdd.yaml > > > > > > > > Why is this in misc? No suitable directory? > > > > > > I chose misc because I don't know where it should fit, I did not find a > > > suitable > > > subsystem to include this driver because this is a driver for an FPGA IP core. > > > Do you have an idea where I should put it? > > > > Directory based on what this device does. Whether some device is > > implemented as FPGA core or dedicated circuitry, it does not matter. Few > > Time Division Multiplexing devices are related to audio, so they are in > > sound. I don't know if TDD is something else than TDM. If nothing fits, > > can be misc, but again - just because device does no fit, not the drivers. > > This device resembles a bit with an IIO device (we are dealing with channels and > the > sysfs interface follows the IIO specification), but is not registered into the IIO > device tree, > and does not rely on IIO kernel APIs. > Do you think this device is a better fit into the IIO subsystem? >
We do have tons of specific attributes (non IIO ones) for this device. The ones resembling IIO is likely because it feels familiar to us in ADI. Anyways, I have my doubts this fits (at least as IIO stands right now) but maybe Jonathan thinks otherwise.
+cc Jonathan...
- Nuno Sá
| |