virtio-comment

 View Only
Expand all | Collapse all

[PATCH v4] virtio-i2c: add the device specification

  • 1.  [PATCH v4] virtio-i2c: add the device specification

    Posted 11-10-2020 07:31
    virtio-i2c is a virtual I2C adapter device. It provides a way
    to ?exibly communicate with the I2C slave devices from the guest.

    This patch adds the specification for this device.

    Signed-off-by: Jie Deng <jie.deng@intel.com>
    ---
    conformance.tex | 28 +++++++++++--
    content.tex | 1 +
    introduction.tex | 3 ++
    virtio-i2c.tex | 117 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
    4 files changed, 145 insertions(+), 4 deletions(-)
    create mode 100644 virtio-i2c.tex

    diff --git a/conformance.tex b/conformance.tex
    index f1f23a8..12bce3a 100644
    --- a/conformance.tex
    +++ b/conformance.tex
    @@ -27,8 +27,10 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
    \ref{sec:Conformance / Driver Conformance / Socket Driver Conformance},
    \ref{sec:Conformance / Driver Conformance / RPMB Driver Conformance},
    \ref{sec:Conformance / Driver Conformance / IOMMU Driver Conformance},
    -\ref{sec:Conformance / Driver Conformance / Sound Driver Conformance} or
    -\ref{sec:Conformance / Driver Conformance / Memory Driver Conformance}.
    +\ref{sec:Conformance / Driver Conformance / Sound Driver Conformance}
    +\ref{sec:Conformance / Driver Conformance / Memory Driver Conformance} or
    +\ref{sec:Conformance / Driver Conformance / I2C Adapter Driver Conformance}.
    +
    \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
    \end{itemize}
    \item[Device] A device MUST conform to four conformance clauses:
    @@ -47,8 +49,10 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
    \ref{sec:Conformance / Device Conformance / Socket Device Conformance},
    \ref{sec:Conformance / Device Conformance / RPMB Device Conformance},
    \ref{sec:Conformance / Device Conformance / IOMMU Device Conformance},
    -\ref{sec:Conformance / Device Conformance / Sound Device Conformance} or
    -\ref{sec:Conformance / Device Conformance / Memory Device Conformance}.
    +\ref{sec:Conformance / Device Conformance / Sound Device Conformance}
    +\ref{sec:Conformance / Device Conformance / Memory Device Conformance} or
    +\ref{sec:Conformance / Device Conformance / I2C Adapter Device Conformance}.
    +
    \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
    \end{itemize}
    \end{description}
    @@ -261,6 +265,14 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
    \item \ref{drivernormative:Device Types / Memory Device / Device Operation / STATE request}
    \end{itemize}

    +\conformance{\subsection}{I2C Adapter Driver Conformance}\label{sec:Conformance / Driver Conformance / I2C Adapter Driver Conformance}
    +
    +An I2C Adapter driver MUST conform to the following normative statements:
    +
    +\begin{itemize}
    +\item \ref{drivernormative:Device Types / I2C Adapter Device / Device Operation}
    +\end{itemize}
    +
    \conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}

    A device MUST conform to the following normative statements:
    @@ -477,6 +489,14 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
    \item \ref{devicenormative:Device Types / Memory Device / Device Operation / STATE request}
    \end{itemize}

    +\conformance{\subsection}{I2C Adapter Device Conformance}\label{sec:Conformance / Device Conformance / I2C Adapter Device Conformance}
    +
    +An I2C Adapter device MUST conform to the following normative statements:
    +
    +\begin{itemize}
    +\item \ref{devicenormative:Device Types / I2C Adapter Device / Device Operation}
    +\end{itemize}
    +
    \conformance{\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}
    A conformant implementation MUST be either transitional or
    non-transitional, see \ref{intro:Legacy
    diff --git a/content.tex b/content.tex
    index 91855b4..95e2ed8 100644
    --- a/content.tex
    +++ b/content.tex
    @@ -6200,6 +6200,7 @@ \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
    \input{virtio-iommu.tex}
    \input{virtio-sound.tex}
    \input{virtio-mem.tex}
    +\input{virtio-i2c.tex}

    \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}

    diff --git a/introduction.tex b/introduction.tex
    index cc38e29..9f016d5 100644
    --- a/introduction.tex
    +++ b/introduction.tex
    @@ -73,6 +73,9 @@ \section{Normative References}\label{sec:Normative References}
    \phantomsection\label{intro:HDA}\textbf{[HDA]} &
    High Definition Audio Specification,
    \newline\url{https://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/high-definition-audio-specification.pdf}\\
    + \phantomsection\label{intro:I2C}\textbf{[I2C]} &
    + I2C-bus specification and user manual,
    + \newline\url{https://www.nxp.com.cn/docs/en/user-guide/UM10204.pdf}\\

    \end{longtable}

    diff --git a/virtio-i2c.tex b/virtio-i2c.tex
    new file mode 100644
    index 0000000..0eb2a4e
    --- /dev/null
    +++ b/virtio-i2c.tex
    @@ -0,0 +1,117 @@
    +\section{I2C Adapter Device}\label{sec:Device Types / I2C Adapter Device}
    +
    +virtio-i2c is a virtual I2C adapter device. It provides a way to flexibly
    +organize and manage I2C slave devices from the guest. By attaching ACPI
    +I2C slave nodes to the virtual I2C adapter device, the guest can
    +communicate with them without changing or adding extra drivers for these
    +slave I2C devices.
    +
    +\subsection{Device ID}\label{sec:Device Types / I2C Adapter Device / Device ID}
    +34
    +
    +\subsection{Virtqueues}\label{sec:Device Types / I2C Adapter Device / Virtqueues}
    +
    +\begin{description}
    +\item[0] requestq
    +\end{description}
    +
    +\subsection{Feature bits}\label{sec:Device Types / I2C Adapter Device / Feature bits}
    +
    +None currently defined.
    +
    +\subsection{Device configuration layout}\label{sec:Device Types / I2C Adapter Device / Device configuration layout}
    +
    +None currently defined.
    +
    +\subsection{Device Initialization}\label{sec:Device Types / I2C Adapter Device / Device Initialization}
    +
    +\begin{enumerate}
    +\item The virtqueue is initialized.
    +\end{enumerate}
    +
    +\subsection{Device Operation}\label{sec:Device Types / I2C Adapter Device / Device Operation}
    +
    +\subsubsection{Device Operation: Request Queue}\label{sec:Device Types / I2C Adapter Device / Device Operation: Request Queue}
    +
    +The driver queues requests to the virtqueue, and they are used by the
    +device. The request is the representation of one segment of an I2C
    +transaction. Each request is of form:
    +
    +\begin{lstlisting}
    +struct virtio_i2c_req {
    + le16 addr;
    + le16 len;
    + u8 buf[];
    + u8 status;
    +};
    +\end{lstlisting}
    +
    +The \field{addr} of the request is the address of the I2C slave device.
    +
    +The \field{len} of the request is the number of data bytes in the \field{buf}
    +being read from or written to the I2C slave address.
    +
    +The \field{buf} of the request contains one segment of an I2C transaction.
    +For a read request, it contains one segment of an I2C transaction being read
    +from the device, for a write request, it contains one segment of an
    +I2C transaction being written to the device.
    +
    +The final \field{status} byte of the request is written by the device: either
    +VIRTIO_I2C_MSG_OK for success or VIRTIO_I2C_MSG_ERR for error.
    +
    +\begin{lstlisting}
    +#define VIRTIO_I2C_MSG_OK 0
    +#define VIRTIO_I2C_MSG_ERR 1
    +\end{lstlisting}
    +
    +A driver may kick one request or multiple requests to the device at a time.
    +If multiple requests are sent at a time, they MUST be queued and processed
    +in order.
    +
    +\subsubsection{Device Operation: Operation Status}\label{sec:Device Types / I2C Adapter Device / Device Operation: Operation Status}
    +
    +If a driver kicks multiple requests at a time and a device fails to process
    +some of them, then the first failed request MUST have its \field{status}
    +being set to VIRTIO_I2C_MSG_ERR by the device and the requests after the first
    +failed one MUST also be treated as VIRTIO_I2C_MSG_ERR by the driver,
    +no matter what \field{status} of them. In this case, the number of successfully
    +sent requests this time is the number of the last request being successfully
    +processed.
    +
    +\drivernormative{\subsubsection}{Device Operation}{Device Types / I2C Adapter Device / Device Operation}
    +
    +A driver MUST set \field{addr} and \field{len} before sending the request.
    +
    +A driver MUST place one segment of an I2C transaction into \field{buf} if it
    +is a write request.
    +
    +A driver MUST NOT use \field{addr}, \field{len} and \field{buf} if the final
    +\field{status} returned from the device is VIRTIO_I2C_MSG_ERR.
    +
    +A driver MAY queue one request or multiple requests at a time.
    +
    +A driver MUST queue the requests in order if multiple requests are going to
    +be sent at a time.
    +
    +If multiple requests are sent at a time and some of them returned from the
    +device have the \field{status} being VIRTIO_I2C_MSG_ERR, a driver MUST treat
    +the first failed request and the requests after the first failed one as
    +VIRTIO_I2C_MSG_ERR.
    +
    +\devicenormative{\subsubsection}{Device Operation}{Device Types / I2C Adapter Device / Device Operation}
    +
    +A device SHOULD keep consistent behaviors with the hardware as described in
    +\hyperref[intro:I2C]{I2C}.
    +
    +A device MUST NOT change the value of \field{addr} and \field{len}.
    +
    +A device MUST place one segment of an I2C transaction into \field{buf} if it
    +is a read request.
    +
    +A device MUST guarantee the requests being processed in order if multiple requests
    +are received at a time.
    +
    +If multiple requests are received at a time and some of them being processed failed,
    +a device MUST set the \field{status} of the first failed request to be
    +VIRTIO_I2C_MSG_ERR and MAY set the \field{status} of the requests after
    +the first failed one to be VIRTIO_I2C_MSG_ERR.
    --
    2.7.4




  • 2.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-10-2020 08:06
    On 10/11/20 08:31, Jie Deng wrote:
    > virtio-i2c is a virtual I2C adapter device. It provides a way to
    > ?exibly communicate with the I2C slave devices from the guest. This
    > patch adds the specification for this device.

    Sorry I didn't reply last week, but I really would prefer if virtio-i2c
    supported write-read transactions.

    Paolo




  • 3.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-10-2020 10:33
    On Tue, Nov 10, 2020 at 09:05:47AM +0100, Paolo Bonzini wrote:
    > On 10/11/20 08:31, Jie Deng wrote:
    > > virtio-i2c is a virtual I2C adapter device. It provides a way to ?exibly
    > > communicate with the I2C slave devices from the guest. This patch adds
    > > the specification for this device.
    >
    > Sorry I didn't reply last week, but I really would prefer if virtio-i2c
    > supported write-read transactions.
    >
    > Paolo

    And I think an easier way is to allow multi-segment transactions
    probably using the stop flag.

    --
    MST




  • 4.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-10-2020 10:33
    On Tue, Nov 10, 2020 at 09:05:47AM +0100, Paolo Bonzini wrote:
    > On 10/11/20 08:31, Jie Deng wrote:
    > > virtio-i2c is a virtual I2C adapter device. It provides a way to ?exibly
    > > communicate with the I2C slave devices from the guest. This patch adds
    > > the specification for this device.
    >
    > Sorry I didn't reply last week, but I really would prefer if virtio-i2c
    > supported write-read transactions.
    >
    > Paolo

    And I think an easier way is to allow multi-segment transactions
    probably using the stop flag.

    --
    MST




  • 5.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-10-2020 11:00
    On 10/11/20 11:33, Michael S. Tsirkin wrote:
    >> Sorry I didn't reply last week, but I really would prefer if virtio-i2c
    >> supported write-read transactions.
    >
    > And I think an easier way is to allow multi-segment transactions
    > probably using the stop flag.

    You cannot always be sure that the host would support them (with the
    exception of write+read transactions, which are pretty much universal),
    so you would also need to describe what the host features are.

    Paolo




  • 6.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-12-2020 01:51

    On 2020/11/10 18:59, Paolo Bonzini wrote:
    > On 10/11/20 11:33, Michael S. Tsirkin wrote:
    >>> Sorry I didn't reply last week, but I really would prefer if virtio-i2c
    >>> supported write-read transactions.
    >>
    >> And I think an easier way is to allow multi-segment transactions
    >> probably using the stop flag.
    >
    > You cannot always be sure that the host would support them (with the
    > exception of write+read transactions, which are pretty much
    > universal), so you would also need to describe what the host features
    > are.
    >
    > Paolo
    >
    Then I will send v5 to support write+read transactions using Paolo's
    proposal.
    I think we may have a simple version merged first and then improve it
    according
    to the actual needs.

    Thank you.




  • 7.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-12-2020 01:51

    On 2020/11/10 18:59, Paolo Bonzini wrote:
    > On 10/11/20 11:33, Michael S. Tsirkin wrote:
    >>> Sorry I didn't reply last week, but I really would prefer if virtio-i2c
    >>> supported write-read transactions.
    >>
    >> And I think an easier way is to allow multi-segment transactions
    >> probably using the stop flag.
    >
    > You cannot always be sure that the host would support them (with the
    > exception of write+read transactions, which are pretty much
    > universal), so you would also need to describe what the host features
    > are.
    >
    > Paolo
    >
    Then I will send v5 to support write+read transactions using Paolo's
    proposal.
    I think we may have a simple version merged first and then improve it
    according
    to the actual needs.

    Thank you.




  • 8.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-12-2020 08:55
    On Thu, Nov 12, 2020 at 09:51:17AM +0800, Jie Deng wrote:
    >
    > On 2020/11/10 18:59, Paolo Bonzini wrote:
    > > On 10/11/20 11:33, Michael S. Tsirkin wrote:
    > > > > Sorry I didn't reply last week, but I really would prefer if virtio-i2c
    > > > > supported write-read transactions.
    > > >
    > > > And I think an easier way is to allow multi-segment transactions
    > > > probably using the stop flag.
    > >
    > > You cannot always be sure that the host would support them (with the
    > > exception of write+read transactions, which are pretty much universal),
    > > so you would also need to describe what the host features are.
    > >
    > > Paolo
    > >
    > Then I will send v5 to support write+read transactions using Paolo's
    > proposal.
    > I think we may have a simple version merged first and then improve it
    > according
    > to the actual needs.
    >
    > Thank you.

    I frankly don't get it, you put read/write flags there even though they
    are not needed, saying it's intended to mirror Linux, then don't want to
    put STOP there even though this is exactly what Linux has ...

    --
    MST




  • 9.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-13-2020 02:39

    On 2020/11/12 16:54, Michael S. Tsirkin wrote:
    > On Thu, Nov 12, 2020 at 09:51:17AM +0800, Jie Deng wrote:
    >> On 2020/11/10 18:59, Paolo Bonzini wrote:
    >>> On 10/11/20 11:33, Michael S. Tsirkin wrote:
    >>>>> Sorry I didn't reply last week, but I really would prefer if virtio-i2c
    >>>>> supported write-read transactions.
    >>>> And I think an easier way is to allow multi-segment transactions
    >>>> probably using the stop flag.
    >>> You cannot always be sure that the host would support them (with the
    >>> exception of write+read transactions, which are pretty much universal),
    >>> so you would also need to describe what the host features are.
    >>>
    >>> Paolo
    >>>
    >> Then I will send v5 to support write+read transactions using Paolo's
    >> proposal.
    >> I think we may have a simple version merged first and then improve it
    >> according
    >> to the actual needs.
    >>
    >> Thank you.
    > I frankly don't get it, you put read/write flags there even though they
    > are not needed, saying it's intended to mirror Linux, then don't want to
    > put STOP there even though this is exactly what Linux has ...

    Personally, I intended to mirror the Linux  "i2c_msg" to have following
    interface.

    struct virtio_i2c_req {
            le16 addr;
            le16 flags;
            le16 len;
            u8 buf[];
            u8 status;

    };

    I intended to implement the standard rules for I2C transactions
    (no I2C_FUNC_PROTOCOL_MANGLING) for the first step. So in the
    v1~v3 only the "I2C_M_RD" was used and other bits of the flags were
    reserved.
    (I2C_M_STOP requires I2C_FUNC_PROTOCOL_MANGLING).

    For me, I intend to mirror the "i2c_msg" from the Linux completely.

    I learned about Michael also intends to keep above interface but want to
    remove some unnecessary bit (e.g. I2C_M_RD) from the flags (Correct me
    if not right).

    Paolo prefers following interface without flags.

    struct virtio_i2c_req {
    le16 addr;
    le16 written;
    le16 read;
    u8 bufwrite[];
    u8 status;
    u8 bufread[];
    };

    So Michael and Paolo, I hope we can agree on the interface first.

    Any suggestions ?

    Thanks.




  • 10.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-13-2020 02:39

    On 2020/11/12 16:54, Michael S. Tsirkin wrote:
    > On Thu, Nov 12, 2020 at 09:51:17AM +0800, Jie Deng wrote:
    >> On 2020/11/10 18:59, Paolo Bonzini wrote:
    >>> On 10/11/20 11:33, Michael S. Tsirkin wrote:
    >>>>> Sorry I didn't reply last week, but I really would prefer if virtio-i2c
    >>>>> supported write-read transactions.
    >>>> And I think an easier way is to allow multi-segment transactions
    >>>> probably using the stop flag.
    >>> You cannot always be sure that the host would support them (with the
    >>> exception of write+read transactions, which are pretty much universal),
    >>> so you would also need to describe what the host features are.
    >>>
    >>> Paolo
    >>>
    >> Then I will send v5 to support write+read transactions using Paolo's
    >> proposal.
    >> I think we may have a simple version merged first and then improve it
    >> according
    >> to the actual needs.
    >>
    >> Thank you.
    > I frankly don't get it, you put read/write flags there even though they
    > are not needed, saying it's intended to mirror Linux, then don't want to
    > put STOP there even though this is exactly what Linux has ...

    Personally, I intended to mirror the Linux  "i2c_msg" to have following
    interface.

    struct virtio_i2c_req {
            le16 addr;
            le16 flags;
            le16 len;
            u8 buf[];
            u8 status;

    };

    I intended to implement the standard rules for I2C transactions
    (no I2C_FUNC_PROTOCOL_MANGLING) for the first step. So in the
    v1~v3 only the "I2C_M_RD" was used and other bits of the flags were
    reserved.
    (I2C_M_STOP requires I2C_FUNC_PROTOCOL_MANGLING).

    For me, I intend to mirror the "i2c_msg" from the Linux completely.

    I learned about Michael also intends to keep above interface but want to
    remove some unnecessary bit (e.g. I2C_M_RD) from the flags (Correct me
    if not right).

    Paolo prefers following interface without flags.

    struct virtio_i2c_req {
    le16 addr;
    le16 written;
    le16 read;
    u8 bufwrite[];
    u8 status;
    u8 bufread[];
    };

    So Michael and Paolo, I hope we can agree on the interface first.

    Any suggestions ?

    Thanks.




  • 11.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-16-2020 02:12
    Hi Michael and Paolo,

    Have you reached an agreement on the design of "virtio_i2c_req" ?

    Personally, I think the design in v4 can already handle the
    multi-segment transactions between frontend and backend.

    Fore example, the frontend may kick the sequence "write read read ..."
    to the backend at a time.

    The segments can be aggregated into "i2c_msg list" and sent to the
    hardware at a time by the backend.

    The host native drivers will finally send these segments using the
    methods they support.

    Does this make sense ?

    Thanks.


    On 2020/11/13 10:39, Jie Deng wrote:
    >
    > On 2020/11/12 16:54, Michael S. Tsirkin wrote:
    >> On Thu, Nov 12, 2020 at 09:51:17AM +0800, Jie Deng wrote:
    >>> On 2020/11/10 18:59, Paolo Bonzini wrote:
    >>>> On 10/11/20 11:33, Michael S. Tsirkin wrote:
    >>>>>> Sorry I didn't reply last week, but I really would prefer if
    >>>>>> virtio-i2c
    >>>>>> supported write-read transactions.
    >>>>> And I think an easier way is to allow multi-segment transactions
    >>>>> probably using the stop flag.
    >>>> You cannot always be sure that the host would support them (with the
    >>>> exception of write+read transactions, which are pretty much
    >>>> universal),
    >>>> so you would also need to describe what the host features are.
    >>>>
    >>>> Paolo
    >>>>
    >>> Then I will send v5 to support write+read transactions using Paolo's
    >>> proposal.
    >>> I think we may have a simple version merged first and then improve it
    >>> according
    >>> to the actual needs.
    >>>
    >>> Thank you.
    >> I frankly don't get it, you put read/write flags there even though they
    >> are not needed, saying it's intended to mirror Linux, then don't want to
    >> put STOP there even though this is exactly what Linux has ...
    >
    > Personally, I intended to mirror the Linux  "i2c_msg" to have
    > following interface.
    >
    > struct virtio_i2c_req {
    >         le16 addr;
    >         le16 flags;
    >         le16 len;
    >         u8 buf[];
    >         u8 status;
    >
    > };
    >
    > I intended to implement the standard rules for I2C transactions
    > (no I2C_FUNC_PROTOCOL_MANGLING) for the first step. So in the
    > v1~v3 only the "I2C_M_RD" was used and other bits of the flags were
    > reserved.
    > (I2C_M_STOP requires I2C_FUNC_PROTOCOL_MANGLING).
    >
    > For me, I intend to mirror the "i2c_msg" from the Linux completely.
    >
    > I learned about Michael also intends to keep above interface but want to
    > remove some unnecessary bit (e.g. I2C_M_RD) from the flags (Correct me
    > if not right).
    >
    > Paolo prefers following interface without flags.
    >
    > struct virtio_i2c_req {
    >     le16 addr;
    >     le16 written;
    >     le16 read;
    >     u8 bufwrite[];
    >     u8 status;
    >     u8 bufread[];
    > };
    >
    > So Michael and Paolo, I hope we can agree on the interface first.
    >
    > Any suggestions ?
    >
    > Thanks.
    >



  • 12.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-16-2020 08:16
    On 16/11/20 03:12, Jie Deng wrote:
    > Fore example, the frontend may kick the sequence "write read read ..."
    > to the backend at a time.
    >
    > The segments can be aggregated into "i2c_msg list" and sent to the
    > hardware at a time by the backend.
    >
    > The host native drivers will finally send these segments using the
    > methods they support.

    If so, the spec needs to specify what the backend must/should/may
    aggregate into a single host-side transaction.

    What my proposal does is essentially saying that the backend MUST
    aggregate a write and a read segment into a single transaction if it is
    sent with a single virtio-i2c request.

    Paolo




  • 13.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-17-2020 06:55

    On 2020/11/16 16:16, Paolo Bonzini wrote:
    > On 16/11/20 03:12, Jie Deng wrote:
    >> Fore example, the frontend may kick the sequence "write read read
    >> ..." to the backend at a time.
    >>
    >> The segments can be aggregated into "i2c_msg list" and sent to the
    >> hardware at a time by the backend.
    >>
    >> The host native drivers will finally send these segments using the
    >> methods they support.
    >
    > If so, the spec needs to specify what the backend must/should/may
    > aggregate into a single host-side transaction.
    >
    > What my proposal does is essentially saying that the backend MUST
    > aggregate a write and a read segment into a single transaction if it
    > is sent with a single virtio-i2c request.
    >
    > Paolo
    >
    This may depend on the host hardware. I can add a host feature bit to
    indicate it.

    Thanks.




  • 14.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-17-2020 06:55

    On 2020/11/16 16:16, Paolo Bonzini wrote:
    > On 16/11/20 03:12, Jie Deng wrote:
    >> Fore example, the frontend may kick the sequence "write read read
    >> ..." to the backend at a time.
    >>
    >> The segments can be aggregated into "i2c_msg list" and sent to the
    >> hardware at a time by the backend.
    >>
    >> The host native drivers will finally send these segments using the
    >> methods they support.
    >
    > If so, the spec needs to specify what the backend must/should/may
    > aggregate into a single host-side transaction.
    >
    > What my proposal does is essentially saying that the backend MUST
    > aggregate a write and a read segment into a single transaction if it
    > is sent with a single virtio-i2c request.
    >
    > Paolo
    >
    This may depend on the host hardware. I can add a host feature bit to
    indicate it.

    Thanks.




  • 15.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-17-2020 08:24
    On Tue, Nov 17, 2020 at 02:55:14PM +0800, Jie Deng wrote:
    >
    > On 2020/11/16 16:16, Paolo Bonzini wrote:
    > > On 16/11/20 03:12, Jie Deng wrote:
    > > > Fore example, the frontend may kick the sequence "write read read
    > > > ..." to the backend at a time.
    > > >
    > > > The segments can be aggregated into "i2c_msg list" and sent to the
    > > > hardware at a time by the backend.
    > > >
    > > > The host native drivers will finally send these segments using the
    > > > methods they support.
    > >
    > > If so, the spec needs to specify what the backend must/should/may
    > > aggregate into a single host-side transaction.
    > >
    > > What my proposal does is essentially saying that the backend MUST
    > > aggregate a write and a read segment into a single transaction if it is
    > > sent with a single virtio-i2c request.
    > >
    > > Paolo
    > >
    > This may depend on the host hardware. I can add a host feature bit to
    > indicate it.

    That is not enough. You also need that for the transactions. If the
    driver sends a write and a read message the device needs to know
    whenever that is one or two transactions. So if you want continue
    with the i2c_msg list idea you need some way to group your messages
    into transactions.

    Or you go with paolos idea which looks simpler to me.

    take care,
    Gerd




  • 16.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-17-2020 08:24
    On Tue, Nov 17, 2020 at 02:55:14PM +0800, Jie Deng wrote:
    >
    > On 2020/11/16 16:16, Paolo Bonzini wrote:
    > > On 16/11/20 03:12, Jie Deng wrote:
    > > > Fore example, the frontend may kick the sequence "write read read
    > > > ..." to the backend at a time.
    > > >
    > > > The segments can be aggregated into "i2c_msg list" and sent to the
    > > > hardware at a time by the backend.
    > > >
    > > > The host native drivers will finally send these segments using the
    > > > methods they support.
    > >
    > > If so, the spec needs to specify what the backend must/should/may
    > > aggregate into a single host-side transaction.
    > >
    > > What my proposal does is essentially saying that the backend MUST
    > > aggregate a write and a read segment into a single transaction if it is
    > > sent with a single virtio-i2c request.
    > >
    > > Paolo
    > >
    > This may depend on the host hardware. I can add a host feature bit to
    > indicate it.

    That is not enough. You also need that for the transactions. If the
    driver sends a write and a read message the device needs to know
    whenever that is one or two transactions. So if you want continue
    with the i2c_msg list idea you need some way to group your messages
    into transactions.

    Or you go with paolos idea which looks simpler to me.

    take care,
    Gerd




  • 17.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-17-2020 16:00
    On 17/11/20 09:23, Gerd Hoffmann wrote:
    > That is not enough. You also need that for the transactions. If the
    > driver sends a write and a read message the device needs to know
    > whenever that is one or two transactions. So if you want continue
    > with the i2c_msg list idea you need some way to group your messages
    > into transactions.
    >
    > Or you go with paolos idea which looks simpler to me.

    Yeah, that seems the simplest. You can also add a flags u32 that must
    be zero, in order to simplify future extensibility.

    Paolo




  • 18.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-18-2020 01:24

    On 2020/11/17 23:59, Paolo Bonzini wrote:
    > On 17/11/20 09:23, Gerd Hoffmann wrote:
    >> That is not enough.  You also need that for the transactions.  If the
    >> driver sends a write and a read message the device needs to know
    >> whenever that is one or two transactions.  So if you want continue
    >> with the i2c_msg list idea you need some way to group your messages
    >> into transactions.
    >>
    >> Or you go with paolos idea which looks simpler to me.
    >
    > Yeah, that seems the simplest.  You can also add a flags u32 that must
    > be zero, in order to simplify future extensibility.
    >
    > Paolo
    >
    Sure, I will do that. Thank you.



  • 19.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-18-2020 01:24

    On 2020/11/17 23:59, Paolo Bonzini wrote:
    > On 17/11/20 09:23, Gerd Hoffmann wrote:
    >> That is not enough.  You also need that for the transactions.  If the
    >> driver sends a write and a read message the device needs to know
    >> whenever that is one or two transactions.  So if you want continue
    >> with the i2c_msg list idea you need some way to group your messages
    >> into transactions.
    >>
    >> Or you go with paolos idea which looks simpler to me.
    >
    > Yeah, that seems the simplest.  You can also add a flags u32 that must
    > be zero, in order to simplify future extensibility.
    >
    > Paolo
    >
    Sure, I will do that. Thank you.



  • 20.  Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-17-2020 16:00
    On 17/11/20 09:23, Gerd Hoffmann wrote:
    > That is not enough. You also need that for the transactions. If the
    > driver sends a write and a read message the device needs to know
    > whenever that is one or two transactions. So if you want continue
    > with the i2c_msg list idea you need some way to group your messages
    > into transactions.
    >
    > Or you go with paolos idea which looks simpler to me.

    Yeah, that seems the simplest. You can also add a flags u32 that must
    be zero, in order to simplify future extensibility.

    Paolo




  • 21.  Re: [virtio-dev] Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-18-2020 02:07

    On 2020/11/17 16:23, Gerd Hoffmann wrote:
    > On Tue, Nov 17, 2020 at 02:55:14PM +0800, Jie Deng wrote:
    >> On 2020/11/16 16:16, Paolo Bonzini wrote:
    >>> On 16/11/20 03:12, Jie Deng wrote:
    >>>> Fore example, the frontend may kick the sequence "write read read
    >>>> ..." to the backend at a time.
    >>>>
    >>>> The segments can be aggregated into "i2c_msg list" and sent to the
    >>>> hardware at a time by the backend.
    >>>>
    >>>> The host native drivers will finally send these segments using the
    >>>> methods they support.
    >>> If so, the spec needs to specify what the backend must/should/may
    >>> aggregate into a single host-side transaction.
    >>>
    >>> What my proposal does is essentially saying that the backend MUST
    >>> aggregate a write and a read segment into a single transaction if it is
    >>> sent with a single virtio-i2c request.
    >>>
    >>> Paolo
    >>>
    >> This may depend on the host hardware. I can add a host feature bit to
    >> indicate it.
    > That is not enough. You also need that for the transactions. If the
    > driver sends a write and a read message the device needs to know
    > whenever that is one or two transactions. So if you want continue
    > with the i2c_msg list idea you need some way to group your messages
    > into transactions.
    Can the "kick" be used for grouping ?  I mean when a write and a read
    are sent
    by one kick at a time, they will be treated as one transaction by
    default if the host
    has such a feature bit.

    Thanks.


    > Or you go with paolos idea which looks simpler to me.
    >
    > take care,
    > Gerd
    >
    >
    > ---------------------------------------------------------------------
    > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
    > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
    >



  • 22.  Re: [virtio-dev] Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-18-2020 08:22
    On 18/11/20 03:06, Jie Deng wrote:
    > Can the "kick" be used for grouping ? I mean when a write and a read
    > are sent by one kick at a time, they will be treated as one
    > transaction by default if the host has such a feature bit.

    No, the kick is only an advice. The device is allowed to poll on the
    ring and ignore kicks completely, for example.

    Paolo




  • 23.  Re: [virtio-dev] Re: [virtio-comment] [PATCH v4] virtio-i2c: add the device specification

    Posted 11-19-2020 01:42