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:02:59 +0530 [thread overview]
Message-ID: <20150608153259.GO28601@localhost> (raw)
In-Reply-To: <s5heglmk1gv.wl-tiwai@suse.de>
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
> > +/**
> > + * snd_hdac_ext_bus_parse_capabilities - parse capablity structure
> > + * @sbus: the pointer to extended bus object
> > + *
> > + * Returns 0 if successful, or a negative error code.
> > + */
> > +int snd_hdac_ext_bus_parse_capabilities(struct hdac_ext_bus *sbus)
> > +{
> > + unsigned int cur_cap;
> > + unsigned int offset;
> > + struct hdac_bus *bus = &sbus->bus;
> > +
> > + offset = snd_hdac_chip_readl(bus, LLCH);
> > +
> > + if (offset < 0)
> > + return -EIO;
> > +
> > + sbus->ppcap = false;
> > + sbus->mlcap = false;
> > + sbus->spbcap = false;
> > + sbus->gtscap = false;
> > +
> > + /* Lets walk the linked capabilities list */
> > + do {
> > + cur_cap = _snd_hdac_chip_read(l, bus, offset);
> > +
> > + if (cur_cap < 0)
> > + return -EIO;
> > +
> > + dev_dbg(bus->dev, "Capability version: 0x%x\n",
> > + ((cur_cap & AZX_CAP_HDR_VER_MASK) >> AZX_CAP_HDR_VER_OFF));
> > +
> > + dev_dbg(bus->dev, "HDA capability ID: 0x%x\n",
> > + (cur_cap & AZX_CAP_HDR_ID_MASK) >> AZX_CAP_HDR_ID_OFF);
> > +
> > + switch ((cur_cap & AZX_CAP_HDR_ID_MASK) >> AZX_CAP_HDR_ID_OFF) {
> > + case AZX_ML_CAP_ID:
> > + dev_dbg(bus->dev, "Found ML capability\n");
> > + sbus->mlcap = true;
> > + sbus->mlcap_addr = bus->remap_addr + offset;
>
> Can be flags (mlcap, gtscap, etc) removed by just NULL-checking the
> corresponding address?
Yes, removed these
> > + break;
> > +
> > + case AZX_GTS_CAP_ID:
> > + dev_dbg(bus->dev, "Found GTS capability offset=%x\n", offset);
> > + sbus->gtscap = true;
> > + sbus->gtscap_addr = bus->remap_addr + offset;
> > + break;
> > +
> > + case AZX_PP_CAP_ID:
> > + /* PP capability found, the Audio DSP is present */
> > + dev_dbg(bus->dev, "Found PP capability offset=%x\n", offset);
> > + sbus->ppcap = true;
> > + sbus->ppcap_addr = bus->remap_addr + offset;
> > + break;
> > +
> > + case AZX_SPB_CAP_ID:
> > + /* SPIB capability found, handler function */
> > + dev_dbg(bus->dev, "Found SPB capability\n");
> > + sbus->spbcap = true;
> > + sbus->spbcap_addr = bus->remap_addr + offset;
> > + break;
> > +
> > + default:
> > + dev_dbg(bus->dev, "Unknown capability %d\n", cur_cap);
> > + break;
> > + }
> > +
> > + /* read the offset of next capabiity */
> > + offset = cur_cap & AZX_CAP_HDR_NXT_PTR_MASK;
> > + } while (offset);
>
> Better to have a loop counter for avoiding the endless loop.
> You should never trust the hardware.
So we have 4 caps, so am going to put 10 as count for now and bail out on
10th one...
>
> > +MODULE_DESCRIPTION("HDA extended core");
> > +MODULE_LICENSE("GPL v2");
>
> These should have been added in the first patch.
Yes will move
--
~Vinod
next prev parent reply other threads:[~2015-06-08 15:31 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 [this message]
2015-06-08 15:42 ` Takashi Iwai
2015-06-08 16:00 ` Vinod Koul
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=20150608153259.GO28601@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox