From: Keyon Jie <yang.jie@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: Why open-coding in sof_hda_bus_init()?
Date: Mon, 3 Jun 2019 13:58:03 +0800 [thread overview]
Message-ID: <f82b90df-77d5-911f-c448-e53957d6ce35@linux.intel.com> (raw)
In-Reply-To: <s5hftoujp7k.wl-tiwai@suse.de>
On 2019/6/1 上午5:20, Takashi Iwai wrote:
> On Fri, 31 May 2019 22:59:17 +0200,
> Pierre-Louis Bossart wrote:
>>
>>
>>>> we need everything that was removed in your proposal :-)
>>>>
>>>> - memset(bus, 0, sizeof(*bus));
>>>> - bus->dev = dev;
>>>> -
>>>> - bus->io_ops = &io_ops;
>>>> - INIT_LIST_HEAD(&bus->stream_list);
>>>> -
>>>> - bus->irq = -1;
>>>> - bus->ext_ops = ext_ops;
>>>> -
>>>> - /*
>>>> - * There is only one HDA bus atm. keep the index as 0.
>>>> - * Need to fix when there are more than one HDA bus.
>>>> - */
>>>> - bus->idx = 0;
>>>> -
>>>> - spin_lock_init(&bus->reg_lock);
>>>>
>>>> This is the smallest set of initialization needed when you don't need
>>>> hdmi/hdaudio codec support.
>>>
>>> I don't understand it... Why SOF core needs to initialize the content
>>> of HD-audio bus object even if you won't use it?
>>
>> we do use it left and right, but we only use the 'controller/DMA'
>> parts of that structure. we have zero use for CORB/RIRB and
>> codec-specific stuff when I2S and DMIC are the only connections to 3rd
>> party chips
>
> So you want to avoid the dependency on snd-hda-core if the system is
> with only I2S/DMIC?
Hi Takashi, yes, that's true. We want to reuse the hdac registers access
part(bus->io_ops, bus->stream_list), for host DMA stream management(e.g.
in sof/intel/hda-stream.c), without the dependency on snd-hda-core.
>
> But, snd-sof-intel-hda-common already has the hard dependency on
> snd-hda-core if CONFIG_SND_SOC_SOF_HDA is enabled. So the attempt
> makes little sense as long as CONFIG_SND_SOC_SOF_HDA is set.
>
> And, if CONFIG_SND_SOC_SOF_HDA isn't set -- i.e.
> CONFIG_SND_SOC_HF_HDA_LINK isn't set either; it implies that there can
> be no user of HD-audio bus. So, I see no big reason we need to care
> about the stuff...
>
>
>>> IOW, what's the merit of having hda-bus.c with the copy of
>>> snd-hda-core code? As far as I see, both hda.c and hda-bus.c are
>>> linked into the same snd-sof-intel-hda-common module. And, the former
>>> has the direct calls of HD-audio core API (with
>>> CONFIG_SND_SOC_SOF_HDA); i.e. snd-sof-intel-hda-common already depends
>>> on snd-hda-core if CONFIG_SND_SOC_SOF_HDA is on, no matter how you
>>> code hda-bus.c.
>>
>> I agree we could implement hda-bus in a cleaner way - but it's a very
>> small file.
>
> Yes, but this is a kind of layer violation. Imagine you do initialize
> the struct pci_dev or whatever else device object because you want to
> reduce the dependency on other core helpers; it would be nightmare
> from the maintenance POV.
>
> I've had already hard time to figure out why SOF HDA initializes the
> HD-audio bus, because it misses the explicit snd_hdac_*_bus_init()
> call. That's the starting point of this thread.
>
> So, let's avoid ugly hacks. Make it more straightforward. Again, if
> the module size matters, we can split and reduce the part of HD-audio
> core stuff that is directly linked to SOF core.
If we can split HD-audio core stuff to provide a host DMA/stream only
module for I2S/DMIC, that would be great.
Thanks,
~Keyon
>
>> A larger core repartitioning would take quite a bit of
>> time, and in the mean time we already have to sort out all the deltas
>> between legacy driver and hdac library.
>>
>> Anyways, that's it for me this week, enjoy your vacation!
>
> Thanks!
>
>
> Takashi
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
prev parent reply other threads:[~2019-06-03 5:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-31 17:11 Why open-coding in sof_hda_bus_init()? Takashi Iwai
2019-05-31 17:43 ` Pierre-Louis Bossart
2019-05-31 18:22 ` Takashi Iwai
2019-05-31 18:31 ` Pierre-Louis Bossart
2019-05-31 19:06 ` Takashi Iwai
2019-05-31 19:44 ` Takashi Iwai
2019-05-31 20:23 ` Pierre-Louis Bossart
2019-05-31 20:36 ` Takashi Iwai
2019-05-31 20:59 ` Pierre-Louis Bossart
2019-05-31 21:20 ` Takashi Iwai
2019-06-03 5:58 ` Keyon Jie [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=f82b90df-77d5-911f-c448-e53957d6ce35@linux.intel.com \
--to=yang.jie@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=pierre-louis.bossart@linux.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;
as well as URLs for NNTP newsgroup(s).