Re: [PATCH 05/10] ALSA: axd: add buffers manipulation files
On Mon, Sep 14, 2015 at 10:11:58AM +0100, Qais Yousef wrote: > I didn't write an rproc driver before, if there's anything that you think I > need to be aware of when writing an rproc based *ALSA* driver I'd appreciate > pointing it out. I'm not aware of anything, the biggest driver currently communicating with a DSP is the Intel one. signature.asc Description: Digital signature
Re: [PATCH 05/10] ALSA: axd: add buffers manipulation files
On 09/03/2015 01:32 PM, Mark Brown wrote: On Tue, Sep 01, 2015 at 11:00:42AM +0100, Qais Yousef wrote: On 08/29/2015 10:47 AM, Mark Brown wrote: Please delete unneeded context from replies, it makes it easier to find the new content you have added. Please also leave blank lines between paragraphs, it makes it much easier to read messages. Sorry about that and for the delayed response. I added one more blank line now, hopefully this looks better. to the driver that it can reuse it, there's no guarantee that this returned buffer is in the same order it was sent. If that's the case I'm not sure the code is correct - it seemed to have assumptions that the buffers were going to be retired in the order. What this code is trying to do is the same as what vring do. I'll move this driver to be rproc based which hopefully should make things simpler and trim all of this out and address your other review comments as well. I didn't write an rproc driver before, if there's anything that you think I need to be aware of when writing an rproc based *ALSA* driver I'd appreciate pointing it out. Thanks, Qais -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/10] ALSA: axd: add buffers manipulation files
On Tue, Sep 01, 2015 at 11:00:42AM +0100, Qais Yousef wrote: > On 08/29/2015 10:47 AM, Mark Brown wrote: Please delete unneeded context from replies, it makes it easier to find the new content you have added. Please also leave blank lines between paragraphs, it makes it much easier to read messages. > >>What this code is trying to do is make a contiguous memory area behave as a > >>ring buffer. Then this ring buffer behave as a queue. We use semaphore > >>counts to control how many are available to take/put. rd_idx and wr_idx > >>should always point at the next location to take/put from/to. > >>Does this help answering your question? > >No. Why are we doing this? Essentially all ALSA buffers are ring > >buffers handled in blocks, why does this one need this complex locking > >scheme? > There are 2 sides to this. The ALSA/driver iface and the driver/firmware > one. The ALSA/driver iface is called from ALSA ops but the driver/firmware > is handled by the interrupt and workqueues. The code is trying to deal with > this concurrency. Also once AXD consumed a buffer it sends back an interrupt This is just the same as any other ALSA device... > to the driver that it can reuse it, there's no guarantee that this returned > buffer is in the same order it was sent. If that's the case I'm not sure the code is correct - it seemed to have assumptions that the buffers were going to be retired in the order. signature.asc Description: Digital signature
Re: [PATCH 05/10] ALSA: axd: add buffers manipulation files
On 08/29/2015 10:47 AM, Mark Brown wrote:
On Thu, Aug 27, 2015 at 03:21:17PM +0100, Qais Yousef wrote:
On 08/26/2015 07:43 PM, Mark Brown wrote:
On Mon, Aug 24, 2015 at 01:39:14PM +0100, Qais Yousef wrote:
+ /*
+* must ensure we have one access at a time to the queue and rd_idx
+* to be preemption and SMP safe
+* Sempahores will ensure that we will only read after a complete write
+* has finished, so we will never read and write from the same location.
+*/
In what way will sempahores ensure that we will only read after a
complete write?
This comment needs fixing. What it is trying to say is that if we reached
this point of the code then we're certainly allowed to modify the buffer
queue and {rd, wr}_idx because the semaphore would have gone to sleep
otherwise if the queue is full/empty.
Should I just remove the reference to Semaphores from the comment or worth
rephrasing it?
Any comments need to be comprehensible.
Would it be better to rename {rd, wr}_{idx, sem} to {take, put}_{idx, sem}?
I'm not sure that helps to be honest, the main issue is that the scheme
is fairly complex and unexplained.
+ buf = bufferq->queue[bufferq->rd_idx];
So buffers are always retired in the same order that they are acquired?
I don't think I get you here. axd_bufferq_take() and axd_bufferq_put() could
be called in any order.
Retiring buffers in the order they are acquired means that buffers are
always freed in the same order they are acquired, you can't free one
buffer before another that was acquired first.
What this code is trying to do is make a contiguous memory area behave as a
ring buffer. Then this ring buffer behave as a queue. We use semaphore
counts to control how many are available to take/put. rd_idx and wr_idx
should always point at the next location to take/put from/to.
Does this help answering your question?
No. Why are we doing this? Essentially all ALSA buffers are ring
buffers handled in blocks, why does this one need this complex locking
scheme?
There are 2 sides to this. The ALSA/driver iface and the driver/firmware
one. The ALSA/driver iface is called from ALSA ops but the
driver/firmware is handled by the interrupt and workqueues. The code is
trying to deal with this concurrency. Also once AXD consumed a buffer it
sends back an interrupt to the driver that it can reuse it, there's no
guarantee that this returned buffer is in the same order it was sent.
I hear you though. Let me see how I can simplify this :-)
+void axd_bufferq_abort_put(struct axd_bufferq *bufferq)
+{
+ if (axd_bufferq_is_full(bufferq)) {
+ bufferq->abort_put = 1;
+ up(&bufferq->wr_sem);
+ }
+}
These look *incredibly* racy. Why are they here and why are they safe?
If we want to restart the firmware we will need to abort any blocking reads
or writes for the user space to react. I also needed that to implement
I'm not questioning what the functionns are doing, I'm questioning their
implementation - it doesn't look like they are safe or reliable. They
just set a flag, relying on something else to notice that the flag has
been set and act appropriately before it goes on and corrupts data.
That just screams concurrency issues.
OK. I'll see how I can rework the code to address all of your comments.
Thanks,
Qais
nonblocking access in user space when this was a sysfs based driver. It was
important then to implement omx IL component correctly.
Nobody cares about OMX ILs in mainline or sysfs based interfaces.
Do I need to support nonblock reads and writes in ALSA? If I use SIGKILL as
you suggested in the other email when restarting and nonblock is not
important then I can remove this.
It would be better to support non blocking access.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/10] ALSA: axd: add buffers manipulation files
On Thu, Aug 27, 2015 at 03:21:17PM +0100, Qais Yousef wrote:
> On 08/26/2015 07:43 PM, Mark Brown wrote:
> >On Mon, Aug 24, 2015 at 01:39:14PM +0100, Qais Yousef wrote:
> >>+ /*
> >>+* must ensure we have one access at a time to the queue and rd_idx
> >>+* to be preemption and SMP safe
> >>+* Sempahores will ensure that we will only read after a complete write
> >>+* has finished, so we will never read and write from the same location.
> >>+*/
> >In what way will sempahores ensure that we will only read after a
> >complete write?
> This comment needs fixing. What it is trying to say is that if we reached
> this point of the code then we're certainly allowed to modify the buffer
> queue and {rd, wr}_idx because the semaphore would have gone to sleep
> otherwise if the queue is full/empty.
> Should I just remove the reference to Semaphores from the comment or worth
> rephrasing it?
Any comments need to be comprehensible.
> Would it be better to rename {rd, wr}_{idx, sem} to {take, put}_{idx, sem}?
I'm not sure that helps to be honest, the main issue is that the scheme
is fairly complex and unexplained.
> >>+ buf = bufferq->queue[bufferq->rd_idx];
> >So buffers are always retired in the same order that they are acquired?
> I don't think I get you here. axd_bufferq_take() and axd_bufferq_put() could
> be called in any order.
Retiring buffers in the order they are acquired means that buffers are
always freed in the same order they are acquired, you can't free one
buffer before another that was acquired first.
> What this code is trying to do is make a contiguous memory area behave as a
> ring buffer. Then this ring buffer behave as a queue. We use semaphore
> counts to control how many are available to take/put. rd_idx and wr_idx
> should always point at the next location to take/put from/to.
> Does this help answering your question?
No. Why are we doing this? Essentially all ALSA buffers are ring
buffers handled in blocks, why does this one need this complex locking
scheme?
> >>+void axd_bufferq_abort_put(struct axd_bufferq *bufferq)
> >>+{
> >>+ if (axd_bufferq_is_full(bufferq)) {
> >>+ bufferq->abort_put = 1;
> >>+ up(&bufferq->wr_sem);
> >>+ }
> >>+}
> >These look *incredibly* racy. Why are they here and why are they safe?
> If we want to restart the firmware we will need to abort any blocking reads
> or writes for the user space to react. I also needed that to implement
I'm not questioning what the functionns are doing, I'm questioning their
implementation - it doesn't look like they are safe or reliable. They
just set a flag, relying on something else to notice that the flag has
been set and act appropriately before it goes on and corrupts data.
That just screams concurrency issues.
> nonblocking access in user space when this was a sysfs based driver. It was
> important then to implement omx IL component correctly.
Nobody cares about OMX ILs in mainline or sysfs based interfaces.
> Do I need to support nonblock reads and writes in ALSA? If I use SIGKILL as
> you suggested in the other email when restarting and nonblock is not
> important then I can remove this.
It would be better to support non blocking access.
signature.asc
Description: Digital signature
Re: [PATCH 05/10] ALSA: axd: add buffers manipulation files
On 08/26/2015 07:43 PM, Mark Brown wrote:
On Mon, Aug 24, 2015 at 01:39:14PM +0100, Qais Yousef wrote:
+ /*
+* must ensure we have one access at a time to the queue and rd_idx
+* to be preemption and SMP safe
+* Sempahores will ensure that we will only read after a complete write
+* has finished, so we will never read and write from the same location.
+*/
In what way will sempahores ensure that we will only read after a
complete write?
This comment needs fixing. What it is trying to say is that if we
reached this point of the code then we're certainly allowed to modify
the buffer queue and {rd, wr}_idx because the semaphore would have gone
to sleep otherwise if the queue is full/empty.
Should I just remove the reference to Semaphores from the comment or
worth rephrasing it?
Would it be better to rename {rd, wr}_{idx, sem} to {take, put}_{idx, sem}?
+ buf = bufferq->queue[bufferq->rd_idx];
So buffers are always retired in the same order that they are acquired?
I don't think I get you here. axd_bufferq_take() and axd_bufferq_put()
could be called in any order.
What this code is trying to do is make a contiguous memory area behave
as a ring buffer. Then this ring buffer behave as a queue. We use
semaphore counts to control how many are available to take/put. rd_idx
and wr_idx should always point at the next location to take/put from/to.
Does this help answering your question?
+int axd_bufferq_put(struct axd_bufferq *bufferq, char *buf, int buf_size)
+{
+ int ret;
+
+ if (!bufferq->queue)
+ return 0;
+
+ if (buf_size < 0)
+ buf_size = bufferq->stride;
We've got strides as well? What is that?
We break the contiguous buffer area allocated for us into smaller
buffers separated by (or of size) stride.
+void axd_bufferq_abort_take(struct axd_bufferq *bufferq)
+{
+ if (axd_bufferq_is_empty(bufferq)) {
+ bufferq->abort_take = 1;
+ up(&bufferq->rd_sem);
+ }
+}
+
+void axd_bufferq_abort_put(struct axd_bufferq *bufferq)
+{
+ if (axd_bufferq_is_full(bufferq)) {
+ bufferq->abort_put = 1;
+ up(&bufferq->wr_sem);
+ }
+}
These look *incredibly* racy. Why are they here and why are they safe?
If we want to restart the firmware we will need to abort any blocking
reads or writes for the user space to react. I also needed that to
implement nonblocking access in user space when this was a sysfs based
driver. It was important then to implement omx IL component correctly.
Do I need to support nonblock reads and writes in ALSA? If I use SIGKILL
as you suggested in the other email when restarting and nonblock is not
important then I can remove this.
I just looked at the code history and I was in the past sending SIGBUS
to the user if we needed to restart then I opted to the abort approach
as it will allow the application to terminate gracefully as it should
get EOF instead then and hide the need to restart the firmware in a
better way. What do you think?
Thanks,
Qais
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/10] ALSA: axd: add buffers manipulation files
On Mon, Aug 24, 2015 at 01:39:14PM +0100, Qais Yousef wrote:
> + /*
> + * must ensure we have one access at a time to the queue and rd_idx
> + * to be preemption and SMP safe
> + * Sempahores will ensure that we will only read after a complete write
> + * has finished, so we will never read and write from the same location.
> + */
In what way will sempahores ensure that we will only read after a
complete write?
> + buf = bufferq->queue[bufferq->rd_idx];
So buffers are always retired in the same order that they are acquired?
> +int axd_bufferq_put(struct axd_bufferq *bufferq, char *buf, int buf_size)
> +{
> + int ret;
> +
> + if (!bufferq->queue)
> + return 0;
> +
> + if (buf_size < 0)
> + buf_size = bufferq->stride;
We've got strides as well? What is that?
> +void axd_bufferq_abort_take(struct axd_bufferq *bufferq)
> +{
> + if (axd_bufferq_is_empty(bufferq)) {
> + bufferq->abort_take = 1;
> + up(&bufferq->rd_sem);
> + }
> +}
> +
> +void axd_bufferq_abort_put(struct axd_bufferq *bufferq)
> +{
> + if (axd_bufferq_is_full(bufferq)) {
> + bufferq->abort_put = 1;
> + up(&bufferq->wr_sem);
> + }
> +}
These look *incredibly* racy. Why are they here and why are they safe?
signature.asc
Description: Digital signature
