From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>,
Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, kai.vehmanen@linux.intel.com,
lgirdwood@gmail.com, yung-chuan.liao@linux.intel.com,
tiwai@suse.com, hdegoede@redhat.com, broonie@kernel.org,
ranjani.sridharan@linux.intel.com,
amadeuszx.slawinski@linux.intel.com,
peter.ujfalusi@linux.intel.com
Subject: Re: [PATCH 2/4] ALSA: hda: Make snd_hda_codec_device_init() the only codec constructor
Date: Wed, 20 Jul 2022 11:00:21 -0500 [thread overview]
Message-ID: <3c3a453a-a9be-94f9-c7a0-4936fba5182d@linux.intel.com> (raw)
In-Reply-To: <8ff14178-7e81-68ff-71fa-7a31adef5cd5@intel.com>
On 7/20/22 10:39, Cezary Rojewski wrote:
> On 2022-07-20 3:13 PM, Takashi Iwai wrote:
>> On Wed, 20 Jul 2022 15:06:20 +0200,
>> Cezary Rojewski wrote:
>>>
>>> Refactor snd_hdac_ext_bus_device_init() so that it makes use of
>>> snd_hda_codec_device_init() to create and initialize new codec device.
>>> Causes the latter to become the sole codec device constructor.
>>>
>>> Users of the refactored function are updated accordingly and now also
>>> take responsibility for assigning driver's private data as that task is
>>> no longer performed by hdac_hda_dev_probe().
>>
>> Hrm, this doesn't look really right. It means you'll introduce a hard
>> dependency chain in a reverse order: snd-hda-ext-core ->
>> snd-hda-codec.
>>
>> Originally, the ext bus code was written completely independent from
>> the legacy HD-audio implementations, and hdac-hda driver was a kind of
>> wrapper / bridge for the legacy codec over the ext bus. If we want
>> change this rule and make the legacy HD-audio codec always tied with
>> the ext bus, a likely better way would be to call
>> snd_hda_codec_device_init() in the caller's side (e.g. skl or sof),
>> then pass the newly created codec object to
>> snd_hdac_ext_bus_device_init() for further initialization.
>
>
> Agree. That or drop the snd_hdac_ext_bus_device_init() entirely. Will
> send an update soon.
>
> In regard to the other subject, my plan:
> - separate code used by both ALSA/ASoC into sound/hda (this includes
> many hda_codec functions)
> - combine hda_bus and hdac_bus
> - combine hda_codec and hdac_device
> - drop HDA_DEV_ASOC
> - drop hdac_hda/hdac_hdmi (once skylake-driver is gone; sof will be
> updated accordingly)
the skylake driver cannot be removed until you have evidence that users
have switched, and SOF has other priorities that will likely conflict
with that goal. I don't even know what this 'drop hdac_hda' idea means
in detail, we need to keep an ASoC-based codec and the split between
platform/codec/machine. We are not going to move the HDaudio codec
management logic inside the SOF driver if that was the intent. The SOF
driver will focus on host/controller/DSP handling.
> <story does not end here>
I strongly recommend that we add no dependencies between hdac_ext and
hda_codec. To be clearer, we don't want to limit the hdac_ext bus and
stream management to platforms with HDaudio codecs.
next prev parent reply other threads:[~2022-07-20 16:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 13:06 [PATCH 0/4] ALSA: hda: Unify codec construction Cezary Rojewski
2022-07-20 13:06 ` [PATCH 1/4] ASoC: hdac_hda: Disconnect struct hdac_hda_priv and hda_codec Cezary Rojewski
2022-07-20 13:56 ` Mark Brown
2022-07-20 13:06 ` [PATCH 2/4] ALSA: hda: Make snd_hda_codec_device_init() the only codec constructor Cezary Rojewski
2022-07-20 13:13 ` Takashi Iwai
2022-07-20 15:39 ` Cezary Rojewski
2022-07-20 16:00 ` Pierre-Louis Bossart [this message]
2022-07-20 16:18 ` Cezary Rojewski
2022-07-20 13:06 ` [PATCH 3/4] ALSA: hda: Always free codec on the device release Cezary Rojewski
2022-07-20 13:06 ` [PATCH 4/4] ALSA: hda: Fix page fault in snd_hda_codec_shutdown() Cezary Rojewski
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=3c3a453a-a9be-94f9-c7a0-4936fba5182d@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=amadeuszx.slawinski@linux.intel.com \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=hdegoede@redhat.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=lgirdwood@gmail.com \
--cc=peter.ujfalusi@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=tiwai@suse.com \
--cc=tiwai@suse.de \
--cc=yung-chuan.liao@linux.intel.com \
/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