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]