From: Takashi Iwai <tiwai@suse.de>
To: Jussi Laako <jussi@sonarnerd.net>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH v2 1/1] ALSA: usb-audio: Add custom mixer status quirks for RME CC devices
Date: Thu, 04 Oct 2018 23:19:08 +0200 [thread overview]
Message-ID: <s5h36tll8ab.wl-tiwai@suse.de> (raw)
In-Reply-To: <99b2ea2f-00e6-52d5-ee39-1125736b0d7e@sonarnerd.net>
On Thu, 04 Oct 2018 23:00:31 +0200,
Jussi Laako wrote:
>
> On 04.10.2018 23:34, Takashi Iwai wrote:
> > Rather include <linux/math64.h>, and put in the appropriate order.
>
> Sorry, I had a bit of hard time finding the function in first place,
> but what is the appropriate order?
No strict rule here. Often people put in the alphabetical order, or
some logic (e.g. header dependencies). In this case, just append to
linux/*.h files.
> > Since you're calling in the same pattern, it's better to consider to
> > provide a helper to call snd_usb_ctl_msg() with the given type (and
> > shows the error there). The helper can take snd_usb_lock_shutdown()
> > and unlock in it, so it'll simplify a lot.
>
> In first case I'm calling GET_STATUS1 and the lock surrounds that. In
> the second case I'm calling both GET_STATUS1 and GET_CURRENT_FREQ and
> the lock surrounds both calls togher. I didn't completely understand
> how to achieve this with the helper, unless you meant through some
> extra argument and control path inside?
This lock/unlock is not about spinlock or such race protection, but
just for a protection for the disconnection check. So it's fine to
take twice, once for each. As it's already with the USB ctl msg, it's
no real-time task, after all.
That is, a picture I had in my mind is something like:
static int rme_vendor_verb(struct snd_kcontrol *kcontrol, u32 cmd,
u32 *result)
{
struct usb_mixer_elem_list *list = snd_kcontrol_chip(kcontrol);
struct snd_usb_audio *chip = list->mixer->chip;
struct usb_device *dev = chip->dev;
int err;
err = snd_usb_lock_shutdown(chip);
if (err < 0)
return err;
err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), cmd,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
0, 0, result, sizeof(*result));
if (err < 0)
dev_err(&dev->dev,
"unable to issue vendor read request (ret = %d)", err);
snd_usb_unlock_shutdown(chip);
return err;
}
... and call it like
err = rme_vendor_verb(kcontrol, RME_GET_STATUS1, &status1);
Takashi
prev parent reply other threads:[~2018-10-04 21:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-04 19:17 [PATCH v2 0/1] ALSA: usb-audio: Add custom mixer status quirks for RME CC devices Jussi Laako
2018-10-04 19:17 ` [PATCH v2 1/1] " Jussi Laako
2018-10-04 20:34 ` Takashi Iwai
2018-10-04 21:00 ` Jussi Laako
2018-10-04 21:19 ` Takashi Iwai [this message]
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=s5h36tll8ab.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=jussi@sonarnerd.net \
/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.