linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: robert.jarzmik@free.fr (Robert Jarzmik)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/7] ALSA: ac97: add an ac97 bus
Date: Mon, 16 May 2016 10:53:56 +0200	[thread overview]
Message-ID: <87inyeidsr.fsf@belgarion.home> (raw)
In-Reply-To: <s5hoa867e6v.wl-tiwai@suse.de> (Takashi Iwai's message of "Mon, 16 May 2016 07:40:56 +0200")

Takashi Iwai <tiwai@suse.de> writes:

> On Sun, 15 May 2016 23:29:27 +0200,
> Robert Jarzmik wrote:
>> 
>> Takashi Iwai <tiwai@suse.de> writes:
>> 
>> > On Sat, 14 May 2016 11:50:50 +0200,
>> >
>> > No, my concern is that it's creating a dummy codec object temporarily
>> > on the stack just by copying some fields and calling the ops with it.
>> > (And actually the current code may work wrongly because lack of
>> >  zero-clear of the object.)
>> Ah yes, I remember now, the on-stack generated device, indeed ugly.
>> 
>> > IMO, a cleaner way would be to define the ops passed with both
>> > controller and codec objects as arguments, and pass NULL codec here.
>> It's rather unusual to need both the device and its controller in bus
>> operations. I must admit I have no better idea so far, so I'll try that just to
>> see how it looks like, and let's see next ...
>
> Thinking of this again, I wonder now why we need to pass the codec
> object at all.  It's the read/write ops via ac97, so we just need the
> ac97_controller object and the address slot of the accessed codec?
So far it would work. The only objection I would see is if in the future the bus
operation needs a specialization which is ac97 codec dependent, such as a flag
or a mask in ac97_codec_device structure.

Even if I'd like to not have these in bus operations, the struct snd_ac97 had a
need for a 'caps', 'ext_id', ... fields for example. Yet these could be
contained in the ac97_codec_device structure and not exposed to bus operations.

Another worry is the pattern (as an example) in atmel_ac97c_write() in
sound/atmel/ac97.c, where the codec structure is used to get the controller
through a container_of() type call. Yet passing the controller to bus operations
takes care of this one.

>From a "purely API" point of view the couple (ac97_controller, ac97_slot_id) is
what will route an ac97 bus operation, be that a read/write/reset/..., the
remaining question is will it cover the cases we've not thought of ?

Cheers.

-- 
Robert

  reply	other threads:[~2016-05-16  8:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-30 21:15 [RFC PATCH 0/7] AC97 device/driver model revamp Robert Jarzmik
2016-04-30 21:15 ` [RFC PATCH 1/7] ALSA: ac97: split out the generic ac97 registers Robert Jarzmik
2016-05-03 11:51   ` Mark Brown
2016-05-03 19:22     ` Robert Jarzmik
2016-05-04  9:07       ` Mark Brown
2016-05-05 19:06         ` Robert Jarzmik
2016-05-05 19:17           ` Mark Brown
2016-05-05 19:46             ` Robert Jarzmik
2016-05-06 17:17               ` Mark Brown
2017-09-04 17:25   ` Applied "ALSA: ac97: split out the generic ac97 registers" to the asoc tree Mark Brown
2016-04-30 21:15 ` [RFC PATCH 2/7] ALSA: ac97: add an ac97 bus Robert Jarzmik
2016-05-03 16:29   ` Mark Brown
2016-05-03 19:43     ` Robert Jarzmik
2016-05-04 16:22       ` Mark Brown
2016-05-05 19:14         ` Robert Jarzmik
2016-05-09  9:31   ` Takashi Iwai
2016-05-14  9:50     ` Robert Jarzmik
2016-05-14 15:13       ` Takashi Iwai
2016-05-15 21:29         ` Robert Jarzmik
2016-05-16  5:40           ` Takashi Iwai
2016-05-16  8:53             ` Robert Jarzmik [this message]
2016-05-16 12:58               ` Takashi Iwai
2016-05-16 13:12                 ` Mark Brown
2016-04-30 21:15 ` [RFC PATCH 3/7] ASoC: wm9713: add ac97 new bus support Robert Jarzmik
2016-04-30 21:15 ` [RFC PATCH 4/7] ASoC: pxa: switch to new ac97 " Robert Jarzmik
2016-04-30 21:15 ` [RFC PATCH 5/7] ARM: pxa: mioa701 remove wm9713 from platform devices Robert Jarzmik
2016-04-30 21:15 ` [RFC PATCH 6/7] ASoC: mioa701_wm9713: convert to new ac97 bus Robert Jarzmik
2016-04-30 21:15 ` [RFC PATCH 7/7] ASoC: add new ac97 bus support Robert Jarzmik
2016-05-09  9:04 ` [RFC PATCH 0/7] AC97 device/driver model revamp Takashi Iwai
2016-05-14  8:13   ` Robert Jarzmik

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=87inyeidsr.fsf@belgarion.home \
    --to=robert.jarzmik@free.fr \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).