sndif: add explicit back and front synchronization
v2 cover sndif: add explicit back and front synchronization
From: Oleksandr Andrushchenko <[email protected]>
Hello, all!
In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol:
- bump protocol version to 2
- add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS)
- introduce trigger events for playback control: start/stop/pause/resume
- add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events
Changes since v1:
1. Changed protocol version definition from string to integer, so it can easily be used in comparisons.
Konrad, I have removed your r-b tag for the reason of this change.
2. In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol:
add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used.
Parameters supported by this request/response:
- format mask
- sample rate interval
- number of channels interval
- buffer size, interval, frames
- period size, interval, frames
Thank you,
Oleksandr Andrushchenko
Oleksandr Andrushchenko (3):
sndif: Introduce protocol version
sndif: Add explicit back and front synchronization
sndif: Add explicit back and front parameter negotiation
xen/include/public/io/sndif.h | 295 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 286 insertions(+), 9 deletions(-)
Signature · 1 line
2.7.4
PATCH v2 1/3 sndif: Introduce protocol version
From: Oleksandr Andrushchenko <[email protected]>
Protocol version was referenced in the protocol description, but missed its definition. Fix this by adding a constant for current protocol version.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
--- xen/include/public/io/sndif.h | 7 +++++++ 1 file changed, 7 insertions(+)
xen/include/public/io/sndif.h +7 -0
@@ -38,6 +38,13 @@/* ****************************************************************************** +* Protocol version +****************************************************************************** +*/ +#define XENSND_PROTOCOL_VERSION 1 + +/* +****************************************************************************** * Feature and Parameter Negotiation ****************************************************************************** *
Signature · 1 line
2.7.4
Re: [Xen-devel][PATCH v2 1/3] sndif: Introduce protocol version
Quoted 7 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Protocol version was referenced in the protocol description, but missed its definition. Fix this by adding a constant for current protocol version.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
Reviewed-by Konrad Rzeszutek Wilk <[email protected]>
Thank you!
Quoted 25 lines
--- xen/include/public/io/sndif.h | 7 +++++++ 1 file changed, 7 insertions(+)xen/include/public/io/sndif.h +7
-0@@ -38,6 +38,13 @@/* ****************************************************************************** +* Protocol version +****************************************************************************** +*/ +#define XENSND_PROTOCOL_VERSION 1 + +/* +****************************************************************************** * Feature and Parameter Negotiation ****************************************************************************** * Signature · 1 line
2.7.4
Re: [PATCH v2 1/3] sndif: Introduce protocol version
In reply to Oleksandr AndrushchenkoQuoted 7 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Protocol version was referenced in the protocol description, but missed its definition. Fix this by adding a constant for current protocol version.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
Reviewed-by Konrad Rzeszutek Wilk <[email protected]>
Thank you!
Quoted 25 lines
--- xen/include/public/io/sndif.h | 7 +++++++ 1 file changed, 7 insertions(+)xen/include/public/io/sndif.h +7
-0@@ -38,6 +38,13 @@/* ****************************************************************************** +* Protocol version +****************************************************************************** +*/ +#define XENSND_PROTOCOL_VERSION 1 + +/* +****************************************************************************** * Feature and Parameter Negotiation ****************************************************************************** * Signature · 1 line
2.7.4
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v2 1/3 sndif: Introduce protocol version
In reply to Oleksandr AndrushchenkoFrom: Oleksandr Andrushchenko <[email protected]>
Protocol version was referenced in the protocol description, but missed its definition. Fix this by adding a constant for current protocol version.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
--- xen/include/public/io/sndif.h | 7 +++++++ 1 file changed, 7 insertions(+)
xen/include/public/io/sndif.h +7 -0
@@ -38,6 +38,13 @@/* ****************************************************************************** +* Protocol version +****************************************************************************** +*/ +#define XENSND_PROTOCOL_VERSION 1 + +/* +****************************************************************************** * Feature and Parameter Negotiation ****************************************************************************** *
Signature · 7 lines
2.7.4 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v2 2/3 sndif: Add explicit back and front synchronization
In reply to Oleksandr AndrushchenkoFrom: Oleksandr Andrushchenko <[email protected]>
In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol:
- bump protocol version to 2
- add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS)
- introduce trigger events for playback control: start/stop/pause/resume
- add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events
Signed-off-by Oleksandr Andrushchenko <[email protected]>
Signed-off-by Oleksandr Grytsov <[email protected]>
Cc Konrad Rzeszutek Wilk <[email protected]>
Cc Takashi Iwai <[email protected]>
Cc Takashi Sakamoto <[email protected]>
Cc Clemens Ladisch <[email protected]>
--- xen/include/public/io/sndif.h | 168 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 164 insertions(+), 4 deletions(-)
xen/include/public/io/sndif.h +164 -4
@@ -41,7 +41,7 @@* Protocol version ****************************************************************************** */ -#define XENSND_PROTOCOL_VERSION 1 +#define XENSND_PROTOCOL_VERSION 2/* ******************************************************************************
@@ -113,6 +113,8 @@* * /local/domain/1/device/vsnd/0/0/0/ring-ref = "386" * /local/domain/1/device/vsnd/0/0/0/event-channel = "15" +* /local/domain/1/device/vsnd/0/0/0/evt-ring-ref = "1386" +* /local/domain/1/device/vsnd/0/0/0/evt-event-channel = "215" * *------------------------------ Stream 1, capture ---------------------------- *
@@ -122,6 +124,8 @@* * /local/domain/1/device/vsnd/0/0/1/ring-ref = "384" * /local/domain/1/device/vsnd/0/0/1/event-channel = "13" +* /local/domain/1/device/vsnd/0/0/1/evt-ring-ref = "1384" +* /local/domain/1/device/vsnd/0/0/1/evt-event-channel = "213" * *------------------------------- PCM device 1 -------------------------------- *
@@ -135,6 +139,8 @@* * /local/domain/1/device/vsnd/0/1/0/ring-ref = "387" * /local/domain/1/device/vsnd/0/1/0/event-channel = "151" +* /local/domain/1/device/vsnd/0/1/0/evt-ring-ref = "1387" +* /local/domain/1/device/vsnd/0/1/0/evt-event-channel = "351" * *------------------------------- PCM device 2 -------------------------------- *
@@ -147,6 +153,8 @@* * /local/domain/1/device/vsnd/0/2/0/ring-ref = "389" * /local/domain/1/device/vsnd/0/2/0/event-channel = "152" +* /local/domain/1/device/vsnd/0/2/0/evt-ring-ref = "1389" +* /local/domain/1/device/vsnd/0/2/0/evt-event-channel = "452" * ****************************************************************************** * Backend XenBus Nodes
@@ -292,6 +300,23 @@* The Xen grant reference granting permission for the backend to map * a sole page in a single page sized ring buffer. * +*--------------------- Stream Event Transport Parameters --------------------- +* +* This communication path is used to deliver asynchronous events from backend +* to frontend, set up per stream. +* +* evt-event-channel +* Values: <uint32_t> +* +* The identifier of the Xen event channel used to signal activity +* in the ring buffer. +* +* evt-ring-ref +* Values: <uint32_t> +* +* The Xen grant reference granting permission for the backend to map +* a sole page in a single page sized ring buffer. +* ****************************************************************************** * STATE DIAGRAMS ******************************************************************************
@@ -439,6 +464,19 @@#define XENSND_OP_GET_VOLUME 5#define XENSND_OP_MUTE 6#define XENSND_OP_UNMUTE 7 +#define XENSND_OP_TRIGGER 8 + +#define XENSND_OP_TRIGGER_START 0 +#define XENSND_OP_TRIGGER_PAUSE 1 +#define XENSND_OP_TRIGGER_STOP 2 +#define XENSND_OP_TRIGGER_RESUME 3 + +/* +****************************************************************************** +* EVENT CODES +****************************************************************************** +*/ +#define XENSND_EVT_CUR_POS 0/* ******************************************************************************
@@ -455,6 +493,8 @@#define XENSND_FIELD_VCARD_LONG_NAME "long-name"#define XENSND_FIELD_RING_REF "ring-ref"#define XENSND_FIELD_EVT_CHNL "event-channel" +#define XENSND_FIELD_EVT_RING_REF "evt-ring-ref" +#define XENSND_FIELD_EVT_EVT_CHNL "evt-event-channel"#define XENSND_FIELD_DEVICE_NAME "name"#define XENSND_FIELD_TYPE "type"#define XENSND_FIELD_STREAM_UNIQUE_ID "unique-id"
@@ -566,9 +606,7 @@* +----------------+----------------+----------------+----------------+ * | gref_directory | 24 * +----------------+----------------+----------------+----------------+ -* | reserved | 28 -* +----------------+----------------+----------------+----------------+ -* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| +* | period_sz | 28 * +----------------+----------------+----------------+----------------+ * | reserved | 32 * +----------------+----------------+----------------+----------------+
@@ -578,6 +616,14 @@* pcm_channels - uint8_t, number of channels of this stream, * [channels-min; channels-max] * buffer_sz - uint32_t, buffer size to be allocated, octets +* period_sz - uint32_t, event period size, octets +* This is the requested value of the period at which frontend would +* like to receive XENSND_EVT_CUR_POS notifications from the backend when +* stream position advances during playback/capture. +* It shows how many octets are expected to be played/captured before +* sending such an event. +* If set to 0 no XENSND_EVT_CUR_POS events are sent by the backend. +* * gref_directory - grant_ref_t, a reference to the first shared page * describing shared buffer references. At least one page exists. If shared * buffer size (buffer_sz) exceeds what can be addressed by this single page,
@@ -592,6 +638,7 @@ struct xensnd_open_req {uint16_t reserved;uint32_t buffer_sz;grant_ref_t gref_directory; +uint32_t period_sz; };/*
@@ -750,8 +797,36 @@ struct xensnd_rw_req {* * The 'struct xensnd_rw_req' is also used for XENSND_OP_SET_VOLUME, * XENSND_OP_GET_VOLUME, XENSND_OP_MUTE, XENSND_OP_UNMUTE. +* +* Request stream running state change - trigger PCM stream running state +* to start, stop, pause or resume: +* +* 0 1 2 3 octet +* +----------------+----------------+----------------+----------------+ +* | id | _OP_TRIGGER | reserved | 4 +* +----------------+----------------+----------------+----------------+ +* | reserved | 8 +* +----------------+----------------+----------------+----------------+ +* | type | reserved | 12 +* +----------------+----------------+----------------+----------------+ +* | reserved | 16 +* +----------------+----------------+----------------+----------------+ +* | reserved | 20 +* +----------------+----------------+----------------+----------------+ +* | reserved | 24 +* +----------------+----------------+----------------+----------------+ +* | reserved | 28 +* +----------------+----------------+----------------+----------------+ +* | reserved | 32 +* +----------------+----------------+----------------+----------------+ +* +* type - uint8_t, XENSND_OP_TRIGGER_XXX value */ +struct xensnd_trigger_req { +uint8_t type; +}; +/* *---------------------------------- Responses -------------------------------- *
@@ -774,8 +849,51 @@ struct xensnd_rw_req {* id - uint16_t, copied from the request * operation - uint8_t, XENSND_OP_* - copied from request * status - int32_t, response status, zero on success and -XEN_EXX on failure +* +*----------------------------------- Events ---------------------------------- +* +* Events are sent via a shared page allocated by the front and propagated by +* evt-event-channel/evt-ring-ref XenStore entries +* All event packets have the same length (32 octets) +* All event packets have common header: +* 0 1 2 3 octet +* +----------------+----------------+----------------+----------------+ +* | id | type | reserved | 4 +* +----------------+----------------+----------------+----------------+ +* | reserved | 8 +* +----------------+----------------+----------------+----------------+ +* +* id - uint16_t, event id, may be used by front +* type - uint8_t, type of the event +* +* +* Current stream position - event from back to front when stream's +* playback/capture position has advanced: +* 0 1 2 3 octet +* +----------------+----------------+----------------+----------------+ +* | id | _EVT_CUR_POS | reserved | 4 +* +----------------+----------------+----------------+----------------+ +* | reserved | 8 +* +----------------+----------------+----------------+----------------+ +* | position low 32-bit | 12 +* +----------------+----------------+----------------+----------------+ +* | position high 32-bit | 16 +* +----------------+----------------+----------------+----------------+ +* | reserved | 20 +* +----------------+----------------+----------------+----------------+ +* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| +* +----------------+----------------+----------------+----------------+ +* | reserved | 32 +* +----------------+----------------+----------------+----------------+ +* +* position - current value of stream's playback/capture position, octets +* */ +struct xensnd_cur_pos_evt { +uint64_t position; +}; +struct xensnd_req {uint16_t id;uint8_t operation;
@@ -783,6 +901,7 @@ struct xensnd_req {union {struct xensnd_open_req open;struct xensnd_rw_req rw; +struct xensnd_trigger_req trigger;uint8_t reserved[24 ]; } op; };
@@ -795,8 +914,49 @@ struct xensnd_resp {uint8_t reserved1[24 ]; }; +struct xensnd_evt { +uint16_t id; +uint8_t type; +uint8_t reserved[5 ]; +union { +struct xensnd_cur_pos_evt cur_pos; +uint8_t reserved[24 ]; + } op; +}; + DEFINE_RING_TYPES(xen_sndif, struct xensnd_req, struct xensnd_resp); +/* +****************************************************************************** +* Back to front events delivery +****************************************************************************** +* In order to deliver asynchronous events from back to front a shared page is +* allocated by front and its granted reference propagated to back via +* XenStore entries (evt-ring-ref/evt-event-channel). +* This page has a common header used by both front and back to synchronize +* access and control event's ring buffer, while back being a producer of the +* events and front being a consumer. The rest of the page after the header +* is used for event packets. +* +* Upon reception of an event(s) front may confirm its reception +* for either each event, group of events or none. +*/ + +struct xensnd_event_page { +uint32_t in_cons; +uint32_t in_prod; +uint8_t reserved[24 ]; +}; + +#define XENSND_EVENT_PAGE_SIZE 4096 +#define XENSND_IN_RING_OFFS (sizeof(struct xensnd_event_page)) +#define XENSND_IN_RING_SIZE (XENSND_EVENT_PAGE_SIZE - XENSND_IN_RING_OFFS) +#define XENSND_IN_RING_LEN (XENSND_IN_RING_SIZE / sizeof(struct xensnd_evt)) +#define XENSND_IN_RING (page) \ + ((struct xensnd_evt *)((char *)(page) + XENSND_IN_RING_OFFS)) +#define XENSND_IN_RING_REF (page, idx) \ + (XENSND_IN_RING((page))[(idx) % XENSND_IN_RING_LEN]) +#endif /* __XEN_PUBLIC_IO_SNDIF_H__ */ /*
Signature · 1 line
2.7.4
Re: [Xen-devel][PATCH v2 2/3] sndif: Add explicit back and front synchronization
Quoted 14 lines
+ ******************************************************************************
+ * Back to front events delivery
+ ******************************************************************************
+ * In order to deliver asynchronous events from back to front a shared page is
+ * allocated by front and its granted reference propagated to back via
+ * XenStore entries (evt-ring-ref/evt-event-channel).
+ * This page has a common header used by both front and back to synchronize
+ * access and control event's ring buffer, while back being a producer of the
+ * events and front being a consumer. The rest of the page after the header
+ * is used for event packets.
+ *
+ * Upon reception of an event(s) front may confirm its reception
+ * for either each event, group of events or none.
+ */
xen/include/public/io/sndif.h struct xensnd_resp { · line 948
Quoted 5 lines
xen/include/public/io/sndif.h +5
-0+ +struct xensnd_event_page { +uint32_t in_cons; +uint32_t in_prod; +uint8_t reserved[24 ];
Could this be aligned at 64 bytes?
Quoted 2 lines
(quoted diff) +2
-0+}; +
Re: [Xen-devel][PATCH v2 2/3] sndif: Add explicit back and front synchronization
Quoted 12 lines · Konrad Rzeszutek Wilk
Quoted 12 lines
+ ******************************************************************************
+ * Back to front events delivery
+ ******************************************************************************
+ * In order to deliver asynchronous events from back to front a shared page is
+ * allocated by front and its granted reference propagated to back via
+ * XenStore entries (evt-ring-ref/evt-event-channel).
+ * This page has a common header used by both front and back to synchronize
+ * access and control event's ring buffer, while back being a producer of the
+ * events and front being a consumer. The rest of the page after the header
+ * is used for event packets.
+ *
+ * Upon reception of an event(s) front may confirm its reception
Quoted 8 lines
xen/include/public/io/sndif.h struct xensnd_resp { · line 948
Quoted 7 lines
+ * for either each event, group of events or none.
+ */xen/include/public/io/sndif.h +5
-0+ +struct xensnd_event_page { +uint32_t in_cons; +uint32_t in_prod; +uint8_t reserved[24 ];Could this be aligned at 64 bytes?
Sure, will make the struct 64 bytes
Quoted 2 lines
Quoted 2 lines
(quoted diff) +2
-0+}; +
Re: [PATCH v2 2/3] sndif: Add explicit back and front synchronization
In reply to Konrad Rzeszutek WilkQuoted 12 lines · Konrad Rzeszutek Wilk
Quoted 12 lines
+ ******************************************************************************
+ * Back to front events delivery
+ ******************************************************************************
+ * In order to deliver asynchronous events from back to front a shared page is
+ * allocated by front and its granted reference propagated to back via
+ * XenStore entries (evt-ring-ref/evt-event-channel).
+ * This page has a common header used by both front and back to synchronize
+ * access and control event's ring buffer, while back being a producer of the
+ * events and front being a consumer. The rest of the page after the header
+ * is used for event packets.
+ *
+ * Upon reception of an event(s) front may confirm its reception
Quoted 8 lines
xen/include/public/io/sndif.h struct xensnd_resp { · line 948
Quoted 7 lines
+ * for either each event, group of events or none.
+ */xen/include/public/io/sndif.h +5
-0+ +struct xensnd_event_page { +uint32_t in_cons; +uint32_t in_prod; +uint8_t reserved[24 ];Could this be aligned at 64 bytes?
Sure, will make the struct 64 bytes
Quoted 2 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+}; +
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [PATCH v2 2/3] sndif: Add explicit back and front synchronization
In reply to Oleksandr AndrushchenkoQuoted 14 lines
+ ******************************************************************************
+ * Back to front events delivery
+ ******************************************************************************
+ * In order to deliver asynchronous events from back to front a shared page is
+ * allocated by front and its granted reference propagated to back via
+ * XenStore entries (evt-ring-ref/evt-event-channel).
+ * This page has a common header used by both front and back to synchronize
+ * access and control event's ring buffer, while back being a producer of the
+ * events and front being a consumer. The rest of the page after the header
+ * is used for event packets.
+ *
+ * Upon reception of an event(s) front may confirm its reception
+ * for either each event, group of events or none.
+ */
xen/include/public/io/sndif.h struct xensnd_resp { · line 948
Quoted 5 lines
xen/include/public/io/sndif.h +5
-0+ +struct xensnd_event_page { +uint32_t in_cons; +uint32_t in_prod; +uint8_t reserved[24 ];
Could this be aligned at 64 bytes?
Review
Quoted 2 lines
(quoted diff) +2
-0+}; +
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v2 2/3 sndif: Add explicit back and front synchronization
In reply to Oleksandr AndrushchenkoFrom: Oleksandr Andrushchenko <[email protected]>
In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol:
- bump protocol version to 2
- add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS)
- introduce trigger events for playback control: start/stop/pause/resume
- add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events
Signed-off-by Oleksandr Andrushchenko <[email protected]>
Signed-off-by Oleksandr Grytsov <[email protected]>
Cc Konrad Rzeszutek Wilk <[email protected]>
Cc Takashi Iwai <[email protected]>
Cc Takashi Sakamoto <[email protected]>
Cc Clemens Ladisch <[email protected]>
--- xen/include/public/io/sndif.h | 168 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 164 insertions(+), 4 deletions(-)
xen/include/public/io/sndif.h +164 -4
@@ -41,7 +41,7 @@* Protocol version ****************************************************************************** */ -#define XENSND_PROTOCOL_VERSION 1 +#define XENSND_PROTOCOL_VERSION 2/* ******************************************************************************
@@ -113,6 +113,8 @@* * /local/domain/1/device/vsnd/0/0/0/ring-ref = "386" * /local/domain/1/device/vsnd/0/0/0/event-channel = "15" +* /local/domain/1/device/vsnd/0/0/0/evt-ring-ref = "1386" +* /local/domain/1/device/vsnd/0/0/0/evt-event-channel = "215" * *------------------------------ Stream 1, capture ---------------------------- *
@@ -122,6 +124,8 @@* * /local/domain/1/device/vsnd/0/0/1/ring-ref = "384" * /local/domain/1/device/vsnd/0/0/1/event-channel = "13" +* /local/domain/1/device/vsnd/0/0/1/evt-ring-ref = "1384" +* /local/domain/1/device/vsnd/0/0/1/evt-event-channel = "213" * *------------------------------- PCM device 1 -------------------------------- *
@@ -135,6 +139,8 @@* * /local/domain/1/device/vsnd/0/1/0/ring-ref = "387" * /local/domain/1/device/vsnd/0/1/0/event-channel = "151" +* /local/domain/1/device/vsnd/0/1/0/evt-ring-ref = "1387" +* /local/domain/1/device/vsnd/0/1/0/evt-event-channel = "351" * *------------------------------- PCM device 2 -------------------------------- *
@@ -147,6 +153,8 @@* * /local/domain/1/device/vsnd/0/2/0/ring-ref = "389" * /local/domain/1/device/vsnd/0/2/0/event-channel = "152" +* /local/domain/1/device/vsnd/0/2/0/evt-ring-ref = "1389" +* /local/domain/1/device/vsnd/0/2/0/evt-event-channel = "452" * ****************************************************************************** * Backend XenBus Nodes
@@ -292,6 +300,23 @@* The Xen grant reference granting permission for the backend to map * a sole page in a single page sized ring buffer. * +*--------------------- Stream Event Transport Parameters --------------------- +* +* This communication path is used to deliver asynchronous events from backend +* to frontend, set up per stream. +* +* evt-event-channel +* Values: <uint32_t> +* +* The identifier of the Xen event channel used to signal activity +* in the ring buffer. +* +* evt-ring-ref +* Values: <uint32_t> +* +* The Xen grant reference granting permission for the backend to map +* a sole page in a single page sized ring buffer. +* ****************************************************************************** * STATE DIAGRAMS ******************************************************************************
@@ -439,6 +464,19 @@#define XENSND_OP_GET_VOLUME 5#define XENSND_OP_MUTE 6#define XENSND_OP_UNMUTE 7 +#define XENSND_OP_TRIGGER 8 + +#define XENSND_OP_TRIGGER_START 0 +#define XENSND_OP_TRIGGER_PAUSE 1 +#define XENSND_OP_TRIGGER_STOP 2 +#define XENSND_OP_TRIGGER_RESUME 3 + +/* +****************************************************************************** +* EVENT CODES +****************************************************************************** +*/ +#define XENSND_EVT_CUR_POS 0/* ******************************************************************************
@@ -455,6 +493,8 @@#define XENSND_FIELD_VCARD_LONG_NAME "long-name"#define XENSND_FIELD_RING_REF "ring-ref"#define XENSND_FIELD_EVT_CHNL "event-channel" +#define XENSND_FIELD_EVT_RING_REF "evt-ring-ref" +#define XENSND_FIELD_EVT_EVT_CHNL "evt-event-channel"#define XENSND_FIELD_DEVICE_NAME "name"#define XENSND_FIELD_TYPE "type"#define XENSND_FIELD_STREAM_UNIQUE_ID "unique-id"
@@ -566,9 +606,7 @@* +----------------+----------------+----------------+----------------+ * | gref_directory | 24 * +----------------+----------------+----------------+----------------+ -* | reserved | 28 -* +----------------+----------------+----------------+----------------+ -* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| +* | period_sz | 28 * +----------------+----------------+----------------+----------------+ * | reserved | 32 * +----------------+----------------+----------------+----------------+
@@ -578,6 +616,14 @@* pcm_channels - uint8_t, number of channels of this stream, * [channels-min; channels-max] * buffer_sz - uint32_t, buffer size to be allocated, octets +* period_sz - uint32_t, event period size, octets +* This is the requested value of the period at which frontend would +* like to receive XENSND_EVT_CUR_POS notifications from the backend when +* stream position advances during playback/capture. +* It shows how many octets are expected to be played/captured before +* sending such an event. +* If set to 0 no XENSND_EVT_CUR_POS events are sent by the backend. +* * gref_directory - grant_ref_t, a reference to the first shared page * describing shared buffer references. At least one page exists. If shared * buffer size (buffer_sz) exceeds what can be addressed by this single page,
@@ -592,6 +638,7 @@ struct xensnd_open_req {uint16_t reserved;uint32_t buffer_sz;grant_ref_t gref_directory; +uint32_t period_sz; };/*
@@ -750,8 +797,36 @@ struct xensnd_rw_req {* * The 'struct xensnd_rw_req' is also used for XENSND_OP_SET_VOLUME, * XENSND_OP_GET_VOLUME, XENSND_OP_MUTE, XENSND_OP_UNMUTE. +* +* Request stream running state change - trigger PCM stream running state +* to start, stop, pause or resume: +* +* 0 1 2 3 octet +* +----------------+----------------+----------------+----------------+ +* | id | _OP_TRIGGER | reserved | 4 +* +----------------+----------------+----------------+----------------+ +* | reserved | 8 +* +----------------+----------------+----------------+----------------+ +* | type | reserved | 12 +* +----------------+----------------+----------------+----------------+ +* | reserved | 16 +* +----------------+----------------+----------------+----------------+ +* | reserved | 20 +* +----------------+----------------+----------------+----------------+ +* | reserved | 24 +* +----------------+----------------+----------------+----------------+ +* | reserved | 28 +* +----------------+----------------+----------------+----------------+ +* | reserved | 32 +* +----------------+----------------+----------------+----------------+ +* +* type - uint8_t, XENSND_OP_TRIGGER_XXX value */ +struct xensnd_trigger_req { +uint8_t type; +}; +/* *---------------------------------- Responses -------------------------------- *
@@ -774,8 +849,51 @@ struct xensnd_rw_req {* id - uint16_t, copied from the request * operation - uint8_t, XENSND_OP_* - copied from request * status - int32_t, response status, zero on success and -XEN_EXX on failure +* +*----------------------------------- Events ---------------------------------- +* +* Events are sent via a shared page allocated by the front and propagated by +* evt-event-channel/evt-ring-ref XenStore entries +* All event packets have the same length (32 octets) +* All event packets have common header: +* 0 1 2 3 octet +* +----------------+----------------+----------------+----------------+ +* | id | type | reserved | 4 +* +----------------+----------------+----------------+----------------+ +* | reserved | 8 +* +----------------+----------------+----------------+----------------+ +* +* id - uint16_t, event id, may be used by front +* type - uint8_t, type of the event +* +* +* Current stream position - event from back to front when stream's +* playback/capture position has advanced: +* 0 1 2 3 octet +* +----------------+----------------+----------------+----------------+ +* | id | _EVT_CUR_POS | reserved | 4 +* +----------------+----------------+----------------+----------------+ +* | reserved | 8 +* +----------------+----------------+----------------+----------------+ +* | position low 32-bit | 12 +* +----------------+----------------+----------------+----------------+ +* | position high 32-bit | 16 +* +----------------+----------------+----------------+----------------+ +* | reserved | 20 +* +----------------+----------------+----------------+----------------+ +* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| +* +----------------+----------------+----------------+----------------+ +* | reserved | 32 +* +----------------+----------------+----------------+----------------+ +* +* position - current value of stream's playback/capture position, octets +* */ +struct xensnd_cur_pos_evt { +uint64_t position; +}; +struct xensnd_req {uint16_t id;uint8_t operation;
@@ -783,6 +901,7 @@ struct xensnd_req {union {struct xensnd_open_req open;struct xensnd_rw_req rw; +struct xensnd_trigger_req trigger;uint8_t reserved[24 ]; } op; };
@@ -795,8 +914,49 @@ struct xensnd_resp {uint8_t reserved1[24 ]; }; +struct xensnd_evt { +uint16_t id; +uint8_t type; +uint8_t reserved[5 ]; +union { +struct xensnd_cur_pos_evt cur_pos; +uint8_t reserved[24 ]; + } op; +}; + DEFINE_RING_TYPES(xen_sndif, struct xensnd_req, struct xensnd_resp); +/* +****************************************************************************** +* Back to front events delivery +****************************************************************************** +* In order to deliver asynchronous events from back to front a shared page is +* allocated by front and its granted reference propagated to back via +* XenStore entries (evt-ring-ref/evt-event-channel). +* This page has a common header used by both front and back to synchronize +* access and control event's ring buffer, while back being a producer of the +* events and front being a consumer. The rest of the page after the header +* is used for event packets. +* +* Upon reception of an event(s) front may confirm its reception +* for either each event, group of events or none. +*/ + +struct xensnd_event_page { +uint32_t in_cons; +uint32_t in_prod; +uint8_t reserved[24 ]; +}; + +#define XENSND_EVENT_PAGE_SIZE 4096 +#define XENSND_IN_RING_OFFS (sizeof(struct xensnd_event_page)) +#define XENSND_IN_RING_SIZE (XENSND_EVENT_PAGE_SIZE - XENSND_IN_RING_OFFS) +#define XENSND_IN_RING_LEN (XENSND_IN_RING_SIZE / sizeof(struct xensnd_evt)) +#define XENSND_IN_RING (page) \ + ((struct xensnd_evt *)((char *)(page) + XENSND_IN_RING_OFFS)) +#define XENSND_IN_RING_REF (page, idx) \ + (XENSND_IN_RING((page))[(idx) % XENSND_IN_RING_LEN]) +#endif /* __XEN_PUBLIC_IO_SNDIF_H__ */ /*
Signature · 7 lines
2.7.4 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v2 3/3 sndif: Add explicit back and front parameter negotiation
In reply to Oleksandr AndrushchenkoFrom: Oleksandr Andrushchenko <[email protected]>
In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol:
add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used.
Parameters supported by this request/response:
- format mask
- sample rate interval
- number of channels interval
- buffer size, interval, frames
- period size, interval, frames
Signed-off-by Oleksandr Andrushchenko <[email protected]>
Cc Konrad Rzeszutek Wilk <[email protected]>
Cc Takashi Iwai <[email protected]>
--- xen/include/public/io/sndif.h | 124 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 117 insertions(+), 7 deletions(-)
xen/include/public/io/sndif.h +117 -7
@@ -465,12 +465,19 @@#define XENSND_OP_MUTE 6#define XENSND_OP_UNMUTE 7#define XENSND_OP_TRIGGER 8 +#define XENSND_OP_HW_PARAM_QUERY 9#define XENSND_OP_TRIGGER_START 0#define XENSND_OP_TRIGGER_PAUSE 1#define XENSND_OP_TRIGGER_STOP 2#define XENSND_OP_TRIGGER_RESUME 3 +#define XENSND_OP_HW_PARAM_FORMAT 0 +#define XENSND_OP_HW_PARAM_RATE 1 +#define XENSND_OP_HW_PARAM_BUFFER 2 +#define XENSND_OP_HW_PARAM_PERIOD 3 +#define XENSND_OP_HW_PARAM_CHANNELS 4 +/* ****************************************************************************** * EVENT CODES
@@ -828,28 +835,127 @@ struct xensnd_trigger_req { };/* +* Request stream configuration parameter range: request interval or +* bit mask of the supported values for the parameter given. +* +* Sound device configuration for a particular stream is a limited subset +* of the multidimensional configuration available on XenStore, for instance, +* once frame rate has been selected there is a limited supported range +* for sample rates becomes available (which might be the same set configured +* on XenStore or less). For example, selecting 96kHz sample rate may limit +* number of channels available for such configuration from 4 to 2 etc. +* Thus, each call to XENSND_OP_HW_PARAM_QUERY will reduce configuration +* space making it possible to iteratively get the final stream configuration, +* used in XENSND_OP_OPEN request. +* +* See response format for this request. +* +* 0 1 2 3 octet +* +----------------+----------------+----------------+----------------+ +* | id | _HW_PARAM_QUERY| reserved | 4 +* +----------------+----------------+----------------+----------------+ +* | reserved | 8 +* +----------------+----------------+----------------+----------------+ +* | param | reserved | 12 +* +----------------+----------------+----------------+----------------+ +* | min or mask low 32-bit | 16 +* +----------------+----------------+----------------+----------------+ +* | max or mask high 32-bit | 20 +* +----------------+----------------+----------------+----------------+ +* | reserved | 24 +* +----------------+----------------+----------------+----------------+ +* | reserved | 28 +* +----------------+----------------+----------------+----------------+ +* | reserved | 32 +* +----------------+----------------+----------------+----------------+ +* +* param - uint8_t, XENSND_OP_HW_PARAM_XXX value +* +* The following parameters' payload treated as interval: +* XENSND_OP_HW_PARAM_RATE +* XENSND_OP_HW_PARAM_BUFFER +* XENSND_OP_HW_PARAM_PERIOD +* XENSND_OP_HW_PARAM_CHANNELS +* +* For interval parameters the payload of the request: +* min - uint32_t, minimum value of the parameter +* max - uint32_t, maximum value of the parameter +* +* For the following parameters their min and max values are expressed in +* frames: +* XENSND_OP_HW_PARAM_BUFFER +* XENSND_OP_HW_PARAM_PERIOD +* where frame is defined as a product of the number of channels by the +* number of octets per one sample. +* +* The following parameters' payload treated as a bit mask: +* XENSND_OP_HW_PARAM_FORMAT +* +* For mask parameters the payload of the request: +* mask - uint64_t, bit mask representing values of the parameter +*/ + +struct xensnd_query_hw_param_req { +uint8_t param; +uint8_t reserved[3 ]; +union { +struct { +uint32_t min; +uint32_t max; + } interval; +uint64_t mask; + } val; +}; + +/* *---------------------------------- Responses -------------------------------- * * All response packets have the same length (32 octets) * -* Response for all requests: +* All response packets have common header: +* 0 1 2 3 octet +* +----------------+----------------+----------------+----------------+ +* | id | operation | reserved | 4 +* +----------------+----------------+----------------+----------------+ +* | status | 8 +* +----------------+----------------+----------------+----------------+ +* +* id - uint16_t, copied from the request +* operation - uint8_t, XENSND_OP_* - copied from request +* status - int32_t, response status, zero on success and -XEN_EXX on failure +* +* +* HW parameter query response - response for XENSND_OP_HW_PARAM_QUERY: * 0 1 2 3 octet * +----------------+----------------+----------------+----------------+ * | id | operation | reserved | 4 * +----------------+----------------+----------------+----------------+ * | status | 8 * +----------------+----------------+----------------+----------------+ -* | reserved | 12 +* | min or mask low 32-bit | 12 +* +----------------+----------------+----------------+----------------+ +* | max or mask high 32-bit | 16 +* +----------------+----------------+----------------+----------------+ +* | reserved | 20 * +----------------+----------------+----------------+----------------+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| * +----------------+----------------+----------------+----------------+ * | reserved | 32 * +----------------+----------------+----------------+----------------+ * -* id - uint16_t, copied from the request -* operation - uint8_t, XENSND_OP_* - copied from request -* status - int32_t, response status, zero on success and -XEN_EXX on failure -* +* The payload meaning is the same as in the corresponing HW parameter +* request: see XENSND_OP_HW_PARAM_QUERY for details. +*/ + +union xensnd_query_hw_param_resp { +struct { +uint32_t min; +uint32_t max; + } interval; +uint64_t mask; +}; + +/* *----------------------------------- Events ---------------------------------- * * Events are sent via a shared page allocated by the front and propagated by
@@ -902,6 +1008,7 @@ struct xensnd_req {struct xensnd_open_req open;struct xensnd_rw_req rw;struct xensnd_trigger_req trigger; +struct xensnd_query_hw_param_req hw_param;uint8_t reserved[24 ]; } op; };
@@ -911,7 +1018,10 @@ struct xensnd_resp {uint8_t operation;uint8_t reserved;int32_t status; -uint8_t reserved1[24 ]; +union { +union xensnd_query_hw_param_resp hw_param; +uint8_t reserved1[24 ]; + } resp; };struct xensnd_evt {
Signature · 1 line
2.7.4
PATCH v2 3/3 sndif: Add explicit back and front parameter negotiation
In reply to Oleksandr AndrushchenkoFrom: Oleksandr Andrushchenko <[email protected]>
In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol:
add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used.
Parameters supported by this request/response:
- format mask
- sample rate interval
- number of channels interval
- buffer size, interval, frames
- period size, interval, frames
Signed-off-by Oleksandr Andrushchenko <[email protected]>
Cc Konrad Rzeszutek Wilk <[email protected]>
Cc Takashi Iwai <[email protected]>
--- xen/include/public/io/sndif.h | 124 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 117 insertions(+), 7 deletions(-)
xen/include/public/io/sndif.h +117 -7
@@ -465,12 +465,19 @@#define XENSND_OP_MUTE 6#define XENSND_OP_UNMUTE 7#define XENSND_OP_TRIGGER 8 +#define XENSND_OP_HW_PARAM_QUERY 9#define XENSND_OP_TRIGGER_START 0#define XENSND_OP_TRIGGER_PAUSE 1#define XENSND_OP_TRIGGER_STOP 2#define XENSND_OP_TRIGGER_RESUME 3 +#define XENSND_OP_HW_PARAM_FORMAT 0 +#define XENSND_OP_HW_PARAM_RATE 1 +#define XENSND_OP_HW_PARAM_BUFFER 2 +#define XENSND_OP_HW_PARAM_PERIOD 3 +#define XENSND_OP_HW_PARAM_CHANNELS 4 +/* ****************************************************************************** * EVENT CODES
@@ -828,28 +835,127 @@ struct xensnd_trigger_req { };/* +* Request stream configuration parameter range: request interval or +* bit mask of the supported values for the parameter given. +* +* Sound device configuration for a particular stream is a limited subset +* of the multidimensional configuration available on XenStore, for instance, +* once frame rate has been selected there is a limited supported range +* for sample rates becomes available (which might be the same set configured +* on XenStore or less). For example, selecting 96kHz sample rate may limit +* number of channels available for such configuration from 4 to 2 etc. +* Thus, each call to XENSND_OP_HW_PARAM_QUERY will reduce configuration +* space making it possible to iteratively get the final stream configuration, +* used in XENSND_OP_OPEN request. +* +* See response format for this request. +* +* 0 1 2 3 octet +* +----------------+----------------+----------------+----------------+ +* | id | _HW_PARAM_QUERY| reserved | 4 +* +----------------+----------------+----------------+----------------+ +* | reserved | 8 +* +----------------+----------------+----------------+----------------+ +* | param | reserved | 12 +* +----------------+----------------+----------------+----------------+ +* | min or mask low 32-bit | 16 +* +----------------+----------------+----------------+----------------+ +* | max or mask high 32-bit | 20 +* +----------------+----------------+----------------+----------------+ +* | reserved | 24 +* +----------------+----------------+----------------+----------------+ +* | reserved | 28 +* +----------------+----------------+----------------+----------------+ +* | reserved | 32 +* +----------------+----------------+----------------+----------------+ +* +* param - uint8_t, XENSND_OP_HW_PARAM_XXX value +* +* The following parameters' payload treated as interval: +* XENSND_OP_HW_PARAM_RATE +* XENSND_OP_HW_PARAM_BUFFER +* XENSND_OP_HW_PARAM_PERIOD +* XENSND_OP_HW_PARAM_CHANNELS +* +* For interval parameters the payload of the request: +* min - uint32_t, minimum value of the parameter +* max - uint32_t, maximum value of the parameter +* +* For the following parameters their min and max values are expressed in +* frames: +* XENSND_OP_HW_PARAM_BUFFER +* XENSND_OP_HW_PARAM_PERIOD +* where frame is defined as a product of the number of channels by the +* number of octets per one sample. +* +* The following parameters' payload treated as a bit mask: +* XENSND_OP_HW_PARAM_FORMAT +* +* For mask parameters the payload of the request: +* mask - uint64_t, bit mask representing values of the parameter +*/ + +struct xensnd_query_hw_param_req { +uint8_t param; +uint8_t reserved[3 ]; +union { +struct { +uint32_t min; +uint32_t max; + } interval; +uint64_t mask; + } val; +}; + +/* *---------------------------------- Responses -------------------------------- * * All response packets have the same length (32 octets) * -* Response for all requests: +* All response packets have common header: +* 0 1 2 3 octet +* +----------------+----------------+----------------+----------------+ +* | id | operation | reserved | 4 +* +----------------+----------------+----------------+----------------+ +* | status | 8 +* +----------------+----------------+----------------+----------------+ +* +* id - uint16_t, copied from the request +* operation - uint8_t, XENSND_OP_* - copied from request +* status - int32_t, response status, zero on success and -XEN_EXX on failure +* +* +* HW parameter query response - response for XENSND_OP_HW_PARAM_QUERY: * 0 1 2 3 octet * +----------------+----------------+----------------+----------------+ * | id | operation | reserved | 4 * +----------------+----------------+----------------+----------------+ * | status | 8 * +----------------+----------------+----------------+----------------+ -* | reserved | 12 +* | min or mask low 32-bit | 12 +* +----------------+----------------+----------------+----------------+ +* | max or mask high 32-bit | 16 +* +----------------+----------------+----------------+----------------+ +* | reserved | 20 * +----------------+----------------+----------------+----------------+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| * +----------------+----------------+----------------+----------------+ * | reserved | 32 * +----------------+----------------+----------------+----------------+ * -* id - uint16_t, copied from the request -* operation - uint8_t, XENSND_OP_* - copied from request -* status - int32_t, response status, zero on success and -XEN_EXX on failure -* +* The payload meaning is the same as in the corresponing HW parameter +* request: see XENSND_OP_HW_PARAM_QUERY for details. +*/ + +union xensnd_query_hw_param_resp { +struct { +uint32_t min; +uint32_t max; + } interval; +uint64_t mask; +}; + +/* *----------------------------------- Events ---------------------------------- * * Events are sent via a shared page allocated by the front and propagated by
@@ -902,6 +1008,7 @@ struct xensnd_req {struct xensnd_open_req open;struct xensnd_rw_req rw;struct xensnd_trigger_req trigger; +struct xensnd_query_hw_param_req hw_param;uint8_t reserved[24 ]; } op; };
@@ -911,7 +1018,10 @@ struct xensnd_resp {uint8_t operation;uint8_t reserved;int32_t status; -uint8_t reserved1[24 ]; +union { +union xensnd_query_hw_param_resp hw_param; +uint8_t reserved1[24 ]; + } resp; };struct xensnd_evt {
Signature · 7 lines
2.7.4 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel