[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v2 5/6] mmio: map common notifications terminology to MMIO
On Mon, 11 Jun 2018 18:11:57 +0200 Halil Pasic <pasic@linux.ibm.com> wrote: > The various notifications are introduced and specified in the common > (i.e. transport agnostic) portion of this specification. How > notifications are realised for a given transport is something each > transport has to specify. > > Let's make the relationship between the virtio over MIIO terms and the > common terms more obvious. > > Signed-off-by: Halil Pasic <pasic@linux.ibm.com> > --- > content.tex | 26 ++++++++++++++------------ > 1 files changed, 14 insertions(+), 12 deletions(-) > > diff --git a/content.tex b/content.tex > index 98efdd2..213ecdf 100644 > --- a/content.tex > +++ b/content.tex (...) > @@ -1716,26 +1716,28 @@ The driver will typically initialize the virtual queue in the following way: > \item Write 0x1 to \field{QueueReady}. > \end{enumerate} > > -\subsubsection{Notifying The Device}\label{sec:Virtio Transport Options / Virtio Over MMIO / MMIO-specific Initialization And Device Operation / Notifying The Device} > +\subsubsection{Available Buffer Notifications}\label{sec:Virtio Transport Options / Virtio Over MMIO / MMIO-specific Initialization And Device Operation / Available Buffer Notifications} > > -The driver notifies the device about new buffers being available in > -a queue by writing the index of the updated queue to \field{QueueNotify}. > +The driver sends an available buffer notification to the device by > +writing the index of the queue to \field{QueueNotify} to be notified. That reads a bit awkward. "...by writing the index of the queue to be notified to \field{QueueNotify}."? > > \subsubsection{Notifications From The Device}\label{sec:Virtio Transport Options / Virtio Over MMIO / MMIO-specific Initialization And Device Operation / Notifications From The Device} > > The memory mapped virtio device is using a single, dedicated > interrupt signal, which is asserted when at least one of the > bits described in the description of \field{InterruptStatus} > -is set. This is how the device notifies the > -driver about a new used buffer being available in the queue > -or about a change in the device configuration. > +is set. This is how the device sends a used buffer notification > +or a configuration change notification to the device. > > \drivernormative{\paragraph}{Notifications From The Device}{Virtio Transport Options / Virtio Over MMIO / MMIO-specific Initialization And Device Operation / Notifications From The Device} > After receiving an interrupt, the driver MUST read > -\field{InterruptStatus} to check what caused the interrupt > -(see the register description). After the interrupt is handled, > -the driver MUST acknowledge it by writing a bit mask > -corresponding to the handled events to the InterruptACK register. > + Extra empty line? > +\field{InterruptStatus} to check what caused the interrupt (see the > +register description). The used buffer notification bit being set > +SHOULD be interpreted as a used buffer notification for each active > +virtqueue. After the interrupt is handled, the driver MUST acknowledge > +it by writing a bit mask corresponding to the handled events to the > +InterruptACK register. > > \subsection{Legacy interface}\label{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface} >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]