Re: [virtio-dev][PATCH V9 2/2] virtio-spi: add the device specification

Haixu Cui <[email protected]>
Newsgroups dev.linux.lists.virtio-dev,dev.linux.lists.virtio-comment
Message-ID <[email protected]>
Hi Cornelia,

On 12/21/2023 4:44 PM, Cornelia Huck wrote:
> On Thu, Dec 21 2023, Haixu Cui <[email protected]> wrote:
> 
>> Hi Cornelia,
>>       Much appreciated for your comments and please refer to my response.
>>
>> On 12/18/2023 7:04 PM, Cornelia Huck wrote:
>>> On Tue, Dec 12 2023, Haixu Cui <[email protected]> wrote:
>>>
>>> [BTW: A changelog would be useful, either in the patch or in the cover
>>> letter.]
>>
>> Sure, I summarize the major changes between these versions and will add
>> in next patch:
>>
>> changelog:
>> v8->v9:
>> - add explanation of bits_per_word_mask in config space
>> v7->v8:
>> - change device to host
>> v6->v7:
>> - fix the format problem, syntax problem
>> v5->v6:
>> - use driver/device instead guest/host
>> - add the definition of some terminologies
>> - use controller instead of master throughout the spec
>> - add buffer length validation for full-duplex transfer
>> v4->v5:
>> - use controller instead of master
>> - fix indentation issue
>> - extend the config space to expose the backend supported features
>> - add another result value to indicate parameter error
>> - add device and driver requirement about parameter checkig
>> v3->v4:
>> - fix the spell error
>> - bus_num is not SOC-specific, remove it
>> - add driver requirement to deal with the situation that the cs delay
>> parameters are not 0 but the backend doesn't support cs timing setting
>> v2->v3
>> - remove unnecessary statements and driver implimentation details
>> - add the parameters about cs timing delay and transfer delay
>> - use "le32" instead of "u32"
>> - swap the rx_buf and tx_buf in the request format
>> - add the parameters about transfer bit width
>> v1->v2:
>> - explain SPI when it is firstly used
>> - update the ambiguous expression of virtqueue
>> v0->v1:
>> - add definition of abbreviation SPI
>> - remove the ID
> 
> Thanks. Might be best to add this in the cover letter.
> 

In next patch I will add it in cover letter.

>> ---
>>
>>>
>>>> The Virtio SPI (Serial Peripheral Interface) device is a virtual
>>>> SPI controller that allows the driver to operate and use the SPI
>>>> controller under the control of the host.
>>>>
>>>> This patch adds the specification for virtio-spi.
>>>>
>>>> Signed-off-by: Haixu Cui <[email protected]>
>>>> Reviewed-by: Viresh Kumar <[email protected]>
>>>> ---
>>>>    device-types/spi/description.tex        | 281 ++++++++++++++++++++++++
>>>>    device-types/spi/device-conformance.tex |   7 +
>>>>    device-types/spi/driver-conformance.tex |   7 +
>>>>    3 files changed, 295 insertions(+)
>>>>    create mode 100644 device-types/spi/description.tex
>>>>    create mode 100644 device-types/spi/device-conformance.tex
>>>>    create mode 100644 device-types/spi/driver-conformance.tex
>>>>
>>>> diff --git a/device-types/spi/description.tex b/device-types/spi/description.tex
>>>
>>> Please move inclusion of this new file into content.tex here, instead of
>>> including a not-yet-existing file in the previous patch.
>>>
>>> (...)
>>
>>
>> Sorry, I don't quite understand here. Maybe I should not add the
>> following line in content.tex, is that so?
>>
>> \input{device-types/spi/description.tex}
> 
> No, please add this line; but do so in this patch instead of the
> previous one that only changes the wording.

I am not clear where to put this line? In the commit message or in the 
main text, e.g. at the start of the description.tex? As follows:

diff --git a/device-types/spi/description.tex 
b/device-types/spi/description.tex
new file mode 100644
index 0000000..b76258c
--- /dev/null
+++ b/device-types/spi/description.tex
@@ -0,0 +1,281 @@
+\input{device-types/spi/description.tex}
+\section{SPI Controller Device}\label{sec:Device Types / SPI Controller 
Device}
+
...

> 
>>
>>>
>>>> +\field{mode_func_supported} indicates whether the following features are supported or not:
>>>> +        bit 0-1: CPHA feature,
>>>> +            0b00: invalid, must support as least one CPHA setting.
>>>> +            0b01: supports CPHA=0 only;
>>>> +            0b10: supports CPHA=1 only;
>>>> +            0b11: supports CPHA=0 and CPHA=1;
>>>> +
>>>> +        bit 2-3: CPOL feature,
>>>> +            0b00: invalid, must support as least one CPOL setting.
>>>> +            0b01: supports CPOL=0 only;
>>>> +            0b10: supports CPOL=1 only;
>>>> +            0b11: supports CPOL=0 and CPOL=1;
>>>> +
>>>> +        bit 4: chipselect active high feature, 0 for unsupported and 1 for supported,
>>>> +            chipselect active low must always be supported.
>>>> +
>>>> +        bit 5: LSB first feature, 0 for unsupported and 1 for supported, MSB first must always be
>>>> +            supported.
>>>> +
>>>> +        bit 6: loopback mode feature, 0 for unsupported and 1 for supported, normal mode
>>>> +            must always be supported.
>>>> +
>>>> +Note: CPOL is clock polarity and CPHA is clock phase. If CPOL is 0, the clock idles at the logical
>>>> +low voltage, otherwise it idles at the logical high voltage. CPHA determines how data is outputted
>>>> +and sampled.
>>>
>>> Shouldn't you also specify what CPHA==0 and CPHA==1 mean?
>>>
>>
>> Yes, I will add the following explanation:
>>
>> If CPHA is 0, the first bit is outputted immediately when chipselect is
>> active and subsequent bits are outputted on the clock edges when clock
> 
> s/when clock/when the clock/
> 
>> transitions from active level to idle level. Data is sampled on the
>> clock edges when clock transitions from idle level to active level.
> 
> same
> 
>>
>> If CPHA is 1, the first bit is outputted on the fist clock edge after
>> chipselect is active, subsequent bits are outputted on the clock edges
>> when clock transitions from idle level to active level. Data is sampled
> 
> same
> 
>> on the clock edges when clock transitions from active level to idle level.
> 
> same
> 
Ok, will update.

Thank you so much.

Thanks
Haixu Cui

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.