On Tue, 1 Oct 2024 10:35:17 +0200
Angelo Dureghello <adureghello@xxxxxxxxxxxx> wrote:
> On 01.10.2024 10:14, Nuno Sá wrote:
> > On Mon, 2024-09-30 at 14:25 -0500, David Lechner wrote:
> > > On 9/29/24 6:05 AM, Jonathan Cameron wrote:
> > > > On Thu, 19 Sep 2024 11:20:01 +0200
> > > > Angelo Dureghello <adureghello@xxxxxxxxxxxx> wrote:
> > > >
> > > > > From: Angelo Dureghello <adureghello@xxxxxxxxxxxx>
> > > > >
> > > > > Extend backend features with new calls needed later on this
> > > > > patchset from axi version of ad3552r.
> > > > >
> > > > > The follwoing calls are added:
> > > > >
> > > > > iio_backend_ext_sync_enable
> > > > > enable synchronize channels on external trigger
> > > > > iio_backend_ext_sync_disable
> > > > > disable synchronize channels on external trigger
> > > > > iio_backend_ddr_enable
> > > > > enable ddr bus transfer
> > > > > iio_backend_ddr_disable
> > > > > disable ddr bus transfer
> > > > > iio_backend_set_bus_mode
> > > > > select the type of bus, so that specific read / write
> > > > > operations are performed accordingly
> > > > > iio_backend_buffer_enable
> > > > > enable buffer
> > > > > iio_backend_buffer_disable
> > > > > disable buffer
> > > > > iio_backend_data_transfer_addr
> > > > > define the target register address where the DAC sample
> > > > > will be written.
> > > > >
> > > > > Signed-off-by: Angelo Dureghello <adureghello@xxxxxxxxxxxx>
> > > > Hi Angelo,
> > > > A few trivial comments inline.
> > > >
> > > > > ---
> > > > > drivers/iio/industrialio-backend.c | 111
> > > > > +++++++++++++++++++++++++++++++++++++
> > > > > include/linux/iio/backend.h | 23 ++++++++
> > > > > 2 files changed, 134 insertions(+)
> > > > >
> > > > > diff --git a/drivers/iio/industrialio-backend.c
> > > > > b/drivers/iio/industrialio-backend.c
> > > > > index 20b3b5212da7..f4802c422dbf 100644
> > > > > --- a/drivers/iio/industrialio-backend.c
> > > > > +++ b/drivers/iio/industrialio-backend.c
> > > > > @@ -718,6 +718,117 @@ static int __devm_iio_backend_get(struct device
> > > > > *dev, struct iio_backend *back)
> > > > ...
> > > >
> > > > > +/**
> > > > > + * iio_backend_ddr_disable - Disable interface DDR (Double Data Rate)
> > > > > mode
> > > > > + * @back: Backend device
> > > > > + *
> > > > > + * Disabling DDR data is generated byt the IP at rising or falling front
> > > >
> > > > Spell check your comments.
> > > >
> > > > > + * of the interface clock signal (SDR, Single Data Rate).
> > > > > + *
> > > > > + * RETURNS:
> > > > > + * 0 on success, negative error number on failure.
> > > > > + */
> > > > > +int iio_backend_ddr_disable(struct iio_backend *back)
> > > > > +{
> > > > > + return iio_backend_op_call(back, ddr_disable);
> > > > > +}
> > > > > +EXPORT_SYMBOL_NS_GPL(iio_backend_ddr_disable, IIO_BACKEND);
> > > > struct fwnode_handle *fwnode)
> > > > > {
> > > > > diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
> > > > > index 37d56914d485..41619b803cd6 100644
> > > > > --- a/include/linux/iio/backend.h
> > > > > +++ b/include/linux/iio/backend.h
> > > > > @@ -14,12 +14,14 @@ struct iio_dev;
> > > > > enum iio_backend_data_type {
> > > > > IIO_BACKEND_TWOS_COMPLEMENT,
> > > > > IIO_BACKEND_OFFSET_BINARY,
> > > > > + IIO_BACKEND_DATA_UNSIGNED,
> > > > > IIO_BACKEND_DATA_TYPE_MAX
> > > > > };
> > > > >
> > > > > enum iio_backend_data_source {
> > > > > IIO_BACKEND_INTERNAL_CONTINUOUS_WAVE,
> > > > > IIO_BACKEND_EXTERNAL,
> > > > > + IIO_BACKEND_INTERNAL_RAMP_16BIT,
> > > > > IIO_BACKEND_DATA_SOURCE_MAX
> > > > > };
> > > > >
> > > > > @@ -89,6 +91,13 @@ enum iio_backend_sample_trigger {
> > > > > * @read_raw: Read a channel attribute from a backend device
> > > > > * @debugfs_print_chan_status: Print channel status into a buffer.
> > > > > * @debugfs_reg_access: Read or write register value of backend.
> > > > > + * @ext_sync_enable: Enable external synchronization.
> > > > > + * @ext_sync_disable: Disable external synchronization.
> > > > > + * @ddr_enable: Enable interface DDR (Double Data Rate) mode.
> > > > > + * @ddr_disable: Disable interface DDR (Double Data Rate) mode.
> > > > > + * @buffer_enable: Enable data buffer.
> > > > > + * @buffer_disable: Disable data buffer.
> > > >
> > > > This needs more specific text. What buffer? I think this came
> > > > up earlier but it needs to say something about the fact it's enabling
> > > > or disabling the actual capture of data into the DMA buffers that
> > > > userspace will read.
> > > >
> > > > > + * @data_transfer_addr: Set data address.
> > > > > **/
> > > > > struct iio_backend_ops {
> > > > > int (*enable)(struct iio_backend *back);
> > > > > @@ -129,6 +138,13 @@ struct iio_backend_ops {
> > > > > size_t len);
> > > > > int (*debugfs_reg_access)(struct iio_backend *back, unsigned int
> > > > > reg,
> > > > > unsigned int writeval, unsigned int
> > > > > *readval);
> > > > > + int (*ext_sync_enable)(struct iio_backend *back);
> > > > I know we've done it this way for existing items, but I wonder if we should
> > > > squish down the ops slightly and have new enable/disable pairs as
> > > > single functions.
> > > > int (*ext_sync_set_state)(struct iio_backend *back, bool enable);
> > > > etc. If nothing else reduces how many things need documentation ;)
> > > >
> > > > Nuno, what do you think? Worth squashing these pairs into single
> > > > callbacks?
> > >
> > > I'm not a fan of combining enable and disable functions into one function.
> > >
> > > The implementation will pretty much always be:
> > >
> > > if (enabled) {
> > > /* so stuff */
> > > } else {
> > > /* do other stuff */
> > > }
> > >
> > > Which just adds indent and makes code harder to read.
> > >
> >
> > Hi Jonathan and David,
> >
> > Yeah, I have this on my todo list and to be fair with Angelo, he already had
> > something like you're suggesting. I kind of asked him to postpone that so we
> > don't have mixed styles in the file for now. Then I would convert them all. My
> > plan would be to squash the .ops into one and then have inline
> > enable()/disable() helpers (at least for the current users in order to keep
> > things easier to convert).
> >
> > As for David's comment, I see your point but one can always improve things a bit
> >
> > if (enable) {
> > /* do stuff */
> > return;
> > }
> >
> > /* do disable stuff */
> > return 0
> >
> > I'm aware the above is always not that straight... but I do think there's always
> > ways to rearrange things a bit to make it better. Because even with the
> > enable()/disable() approach, if you start to have a lot of common code, likely
> > you'll add an helper function. In some cases, one can even add the helper right
> > away with an 'enable' argument effectively doing what is being suggested in
> > here. It always depends on the person implementing the ops :)
> >
> > Anyways, I really don't have a strong feeling about this. I had in my mind to do
> > something like this. It feels that Jonathan would already be ok with it. If it's
> > not that awful for David, I'll eventually send the patches (unless Angelo wants
> > to take care if it in this series).
> >
>
> I agree a single function for enable/disable may be good, reducing the calls and
> also the code size should benefit of some few bytes.
Normally I'd be on David's side on this but I don't really want to end up
with hundreds of callbacks (vs a single hundred). Thinking more about it, maybe
I don't care about keeping them split.
>
> Honestly, i would not do this in this patchset since i am a bit in difficulties
> to have this job accepted as is, and also cannot retest all of them properly
> right now.
That's fine given it's an open question on whether it is even a good idea
and not really related to your work here.
Jonathan
>
> > - Nuno Sá
> > >
>
