All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul@intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: liam.r.girdwood@linux.intel.com, patches.audio@intel.com,
	alsa-devel@alsa-project.org, broonie@kernel.org,
	Jeeja KP <jeeja.kp@intel.com>
Subject: Re: [PATCH v6 2/3] ALSA: hdac_ext: add hdac extended controller
Date: Mon, 8 Jun 2015 21:30:00 +0530	[thread overview]
Message-ID: <20150608160000.GS28601@localhost> (raw)
In-Reply-To: <s5hlhfuqk9q.wl-tiwai@suse.de>

On Mon, Jun 08, 2015 at 05:42:25PM +0200, Takashi Iwai wrote:
> At Mon, 8 Jun 2015 21:02:59 +0530,
> Vinod Koul wrote:
> > 
> > On Mon, Jun 08, 2015 at 11:12:48AM +0200, Takashi Iwai wrote:
> > > > +struct hdac_ext_link {
> > > > +	struct hdac_bus *bus;
> > > > +	int index;
> > > > +	void __iomem *ml_addr; /* link output stream reg pointer */
> > > > +	u32 lcaps;   /* link capablities */
> > > > +	u16 lsdiid;  /* link sdi identifier */
> > > > +	char codec[HDA_MAX_CODECS][32]; /* codecs connectes to the link */
> > > 
> > > Do we need to keep the codec name string?  Isn't it just codec address
> > > we'd like to check the match...?  If so, we may use bitmasks instead,
> > > too.
> > This is not for matching stuff (this is link structure and not codec)
> > So we keep name of codec found on this link. When ASoC BE triggers we use
> > codec name to find the link and use
> 
> But each codec name consists of just a few bits.  Why do you need to
> keep each codec name string?
Yes got your point now, we can indeed generate the codec name and avoid
char array

-- 
~Vinod

  reply	other threads:[~2015-06-08 16:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-04  9:53 [PATCH v6 0/3] ALSA: HDA: add extended HDA Vinod Koul
2015-06-04  9:53 ` [PATCH v6 1/3] ALSA: hdac_ext: add extended HDA bus Vinod Koul
2015-06-08  9:00   ` Takashi Iwai
2015-06-08 10:08     ` Vinod Koul
2015-06-08 15:30       ` Vinod Koul
2015-06-08 15:40         ` Takashi Iwai
2015-06-09 10:06           ` Vinod Koul
2015-06-09 10:37             ` Takashi Iwai
2015-06-08  9:03   ` Takashi Iwai
2015-06-08 10:10     ` Vinod Koul
2015-06-08 15:24       ` Vinod Koul
2015-06-08 15:37         ` Takashi Iwai
2015-06-08 15:55           ` Vinod Koul
2015-06-04  9:53 ` [PATCH v6 2/3] ALSA: hdac_ext: add hdac extended controller Vinod Koul
2015-06-08  9:12   ` Takashi Iwai
2015-06-08 15:32     ` Vinod Koul
2015-06-08 15:42       ` Takashi Iwai
2015-06-08 16:00         ` Vinod Koul [this message]
2015-06-04  9:53 ` [PATCH v6 3/3] ALSA: hdac_ext: add extended stream capabilities Vinod Koul

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=20150608160000.GS28601@localhost \
    --to=vinod.koul@intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=jeeja.kp@intel.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=patches.audio@intel.com \
    --cc=tiwai@suse.de \
    /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.