All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Bahling <sbahling@suse.com>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	ffado-devel@lists.sf.net
Subject: Re: Controlling the Tascam FW-1884
Date: Fri, 02 Nov 2018 10:26:06 +0100	[thread overview]
Message-ID: <bd6c69dbb0cb7347f9023728a598e65f0b297323.camel@suse.com> (raw)
In-Reply-To: <daf2b08b-dfdf-b4a3-8820-0a5f3ab78fc4@sakamocchi.jp>


[-- Attachment #1.1: Type: text/plain, Size: 3153 bytes --]

On Tue, 2018-10-30 at 18:34 +0900, Takashi Sakamoto wrote:
> Hi Scott,
> 
> Sorry to be late for reply, but I was a bit busy with travel for
> Audio
> miniconference 2018 and tests for v4.20 merge window.
> 
> On 2018/10/22 20:47, Scott Bahling wrote:
> > I have tried this, but the endianness of the status bits passed via
> > this
> > method seems to be wrong.
> > 
> > I noticed in your latest kernel code[1], that you don't convert the
> > firewire
> > data to local CPU endian when storing in the "after" variable which
> > ends up
> > getting pushed into the status structure as big endian:
> > 
> > 
> >      after = buffer[s->data_block_quadlets - 1];
> > ...
> > ...
> > ...
> >      tscm->status[index] = after;
> > 
> > 
> > Shouldn't that be:
> > 
> >      after = be32_to_cpu(buffer[s->data_block_quadlets - 1]);
> > 
> > which also would remove the need for later conversions in that
> > block of
> > code?
> > 
> > I have a tested patch which I will send as a pull request once
> > github is
> > functioning again.
> 
> Ah, indeed. I completely overlooked it, sorry...
> 
> At first place, I just focused on reduction of CPU usage in
> packet processing, then cache big-endianness values from packets.
> Queued events have converted host-endiannness value from the cache.
> On the other hand, data returned by
> SNDRV_FIREWIRE_IOCTL_TASCAM_STATUS
> ioctl is just copied from the cache, then it's still big-endiannness,
> as you found.
> 
> Thanks for your PR[1] and it works well. But here I suggest that
> we can judge the frequency to call SNDRV_FIREWIRE_IOCTL_TASCAM_STATUS
> ioctl is surely less than the frequency on packet processing. If we
> attempt to keep low CPU usage in the packet processing, current
> implementation can be kept as is. Instead, a patch for handler of the
> ioctl is worth for commit.

Makes perfect sense.

> For example, This patch will fix the issue.
> 
> ```
> $ git diff
> diff --git a/sound/firewire/tascam/tascam-hwdep.c 
> b/sound/firewire/tascam/tascam-hwdep.c
> index ad164ad..dff7dc4 100644
> --- a/sound/firewire/tascam/tascam-hwdep.c
> +++ b/sound/firewire/tascam/tascam-hwdep.c
> @@ -189,10 +189,23 @@ static int hwdep_unlock(struct snd_tscm *tscm)
> 
>   static int tscm_hwdep_status(struct snd_tscm *tscm, void __user
> *arg)
>   {
> -       if (copy_to_user(arg, tscm->status, sizeof(tscm->status)))
> -               return -EFAULT;
> +       struct snd_firewire_tascam_status *status;
> +       int i;
> +       int err = 0;
> 
> -       return 0;
> +       status = kmalloc(sizeof(*status), GFP_KERNEL);
> +       if (!status)
> +               return -ENOMEM;
> +
> +       for (i = 0; i < SNDRV_FIREWIRE_TASCAM_STATUS_COUNT; ++i)
> +               status->data[i] = be32_to_cpu(tscm->status[i]);
> +
> +       if (copy_to_user(arg, status, sizeof(*status)))
> +               err = -EFAULT;
> +
> +       kfree(status);
> +
> +       return err;
>   }
> ```
> 
> I'd like you to test with this patch, before granting your PR.

I have tested and the patch above works as expected.

-Scott

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2018-11-02  9:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9cec059e1ff1a558f21a3f0729c5a69a3d506573.camel@suse.com>
2018-09-08  2:53 ` Controlling the Tascam FW-1884 Takashi Sakamoto
2018-09-08 11:21   ` Scott Bahling
2018-09-10  7:59     ` Takashi Sakamoto
2018-09-12  7:18       ` Scott Bahling
2018-09-17 14:36         ` Takashi Sakamoto
2018-09-24  9:32           ` Scott Bahling
2018-09-28  3:44             ` Takashi Sakamoto
2018-09-28 15:28               ` Scott Bahling
2018-10-02  3:16                 ` Takashi Sakamoto
2018-10-03 20:37                   ` Scott Bahling
2018-10-06  9:07                     ` Takashi Sakamoto
2018-10-07 11:32                       ` Scott Bahling
2018-10-07 14:11                   ` Takashi Sakamoto
2018-10-12  8:12                     ` Scott Bahling
2018-10-13 10:40                       ` Takashi Sakamoto
2018-10-14 19:09                         ` Scott Bahling
2018-10-22 11:47                           ` Scott Bahling
2018-10-30  9:34                             ` Takashi Sakamoto
2018-11-02  9:26                               ` Scott Bahling [this message]
2018-11-02 12:05                                 ` Takashi Sakamoto
2018-11-16 17:37                                   ` Scott Bahling
2018-10-03 19:31               ` Scott Bahling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bd6c69dbb0cb7347f9023728a598e65f0b297323.camel@suse.com \
    --to=sbahling@suse.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=ffado-devel@lists.sf.net \
    --cc=o-takashi@sakamocchi.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.