[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e6bd5a48-1ba2-4a01-af75-fbf74a0de3c3@baylibre.com>
Date: Thu, 9 Jan 2025 12:04:54 -0600
From: David Lechner <dlechner@...libre.com>
To: Angelo Dureghello <adureghello@...libre.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>,
Michael Hennerich <Michael.Hennerich@...log.com>,
Jonathan Cameron <jic23@...nel.org>,
Mihail Chindris <mihail.chindris@...log.com>, Nuno Sa <nuno.sa@...log.com>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 6/9] iio: dac: ad3552r-hs: use instruction mode for
configuration
On 1/9/25 11:25 AM, Angelo Dureghello wrote:
> Hi,
>
> On 08.01.2025 15:16, David Lechner wrote:
>> On 1/8/25 11:29 AM, Angelo Dureghello wrote:
>>> From: Angelo Dureghello <adureghello@...libre.com>
>>>
>>> Use "instruction" mode over initial configuration and all other
>>> non-streaming operations.
>>>
>>> DAC boots in streaming mode as default, and the driver is not
>>> changing this mode.
>>>
>>> Instruction r/w is still working becouse instruction is processed
>>
>> s/becouse/because/
>>
>>> from the DAC after chip select is deasserted, this works until
>>> loop mode is 0 or greater than the instruction size.
>>>
>>> All initial operations should be more safely done in instruction
>>> mode, a mode provided for this.
>>
>> I'm not sure it is really "safer". The way I read the datasheet, this just
>> enables bulk reads of multiple registers. So unless we need to do bulk reads
>> it seems like this is just adding extra complexity to the driver without a
>> tangible benefit.
>>
>
> this change was initially requested from the HDL team to stay aligned with
> the HDL side streaming/non streaming mode, and later, applied since seems
> a safer way to operate.
>
> I see that for the driver and DAC point of view, this is "functionally"
> not needed, but streaming mode for configuration or raw read/write works
> until STREAM_MODE register is set to 0 or to a value >= to the register
> size to be accessed, since the _CS deasserting completes the transaction.
>
> I.e., a transaction with a STREAM_MODE set to 1 would fail in case of
> a 16bit r/w access. Staying into streaming mode seems to me a bit tricky,
> and setting to instruction mode may be safer since in this mode the
> STREAM_MODE value is not important anymore.
>
> For me is the same, i can remove related code. As you prefer.
>
If it really does make a difference, I'm OK to keep it.
Powered by blists - more mailing lists