Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
	andriy.shevchenko@intel.com, Takashi Iwai <tiwai@suse.de>,
	Pan Xiuli <xiuli.pan@linux.intel.com>,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	vkoul@kernel.org, Mark Brown <broonie@kernel.org>,
	sound-open-firmware@alsa-project.org,
	Rander Wang <rander.wang@linux.intel.com>,
	Alan Cox <alan@linux.intel.com>
Subject: Re: [Sound-open-firmware] [PATCH 01/21] ASoC: SOF: Intel: Add BYT, CHT and BSW DSP HW support.
Date: Fri, 18 Jan 2019 09:02:58 -0600	[thread overview]
Message-ID: <9672de72-6fe4-5ac4-a8bf-bc0e31f6ec9d@linux.intel.com> (raw)
In-Reply-To: <CAEnQRZCgwXTMQPEE47DTY_wgvB5QiUu0sXFjfenhc_w3HnaRfA@mail.gmail.com>


>> +struct snd_sof_dsp_ops sof_cht_ops = {
>> +       /* device init */
>> +       .probe          = byt_probe,
>> +
>> +       /* DSP core boot / reset */
>> +       .run            = byt_run,
>> +       .reset          = byt_reset,
>> +
>> +       /* Register IO */
>> +       .write          = sof_io_write,
>> +       .read           = sof_io_read,
>> +       .write64        = sof_io_write64,
>> +       .read64         = sof_io_read64,
>> +
>> +       /* Block IO */
>> +       .block_read     = sof_block_read,
>> +       .block_write    = sof_block_write,
>> +
>> +       /* doorbell */
>> +       .irq_handler    = byt_irq_handler,
>> +       .irq_thread     = byt_irq_thread,
>> +
> What is the reason for having irq_handler/irq_thread functions inside the
> snd_sof_dsp_ops structure?
>
> These functions are never used outside via sdev->ops pointer.

Good point indeed, thanks for raising it. We were in the middle of 
tagging which ops are required/optional (feedback from Mark) but we 
started from the core and should have looked at the structure definition.

Most drivers are "self-contained" and can reference the irq_thread and 
irq_handler directly.

The exception where the abstraction is used is internal to the HDaudio 
stuff:

intel/hda.c:    ret = request_threaded_irq(sdev->ipc_irq, 
hda_dsp_ipc_irq_handler,
intel/hda.c: sof_ops(sdev)->irq_thread, IRQF_SHARED,

That's useful since there a minor variations between hardware 
generations and you want to hide the hardware-specific parts.

But as you point out, it's a "private" use of ops callbacks, the core 
doesn't touch this.

I have no explanation other than legacy/historical reasons or a shortcut 
to make one's life easier during development.  Liam and Keyon might know?

We could try and move this to a more "private" structure, the 
"chip_info" part might be more suitable for this?

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2019-01-18 15:02 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11 21:30 [PATCH 00/21] Sound Open Firmware (SOF) - Intel support Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 01/21] ASoC: SOF: Intel: Add BYT, CHT and BSW DSP HW support Pierre-Louis Bossart
2018-12-12  4:08   ` Takashi Sakamoto
2018-12-12 14:45     ` Pierre-Louis Bossart
2018-12-12 19:24       ` [Sound-open-firmware] " Pierre-Louis Bossart
     [not found]     ` <b8db627a-bd32-34d7-b45b-aeb2206b2b17@linux.intel.com>
2018-12-17 13:40       ` Yang, Libin
2019-01-18  8:14   ` Daniel Baluta
2019-01-18 15:02     ` Pierre-Louis Bossart [this message]
2019-01-18 15:29       ` [Sound-open-firmware] " Daniel Baluta
2019-01-18 16:14         ` Pierre-Louis Bossart
2019-01-22  7:35   ` Daniel Baluta
2019-01-22 16:22     ` Pierre-Louis Bossart
2019-01-22 16:49       ` Daniel Baluta
2018-12-11 21:30 ` [PATCH 02/21] ASoC: SOF: Intel: Add HSW HW DSP support Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 03/21] ASoC: SOF: Intel: Add support for BDW " Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 04/21] ASoC: SOF: Intel: Add APL/CNL " Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 05/21] ASoC: SOF: Intel: Add HDA controller for Intel DSP Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 06/21] ASoC: SOF: Intel: Add Intel specific HDA DSP HW operations Pierre-Louis Bossart
2018-12-12 12:04   ` Takashi Iwai
2018-12-12 14:48     ` Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 07/21] ASoC: SOF: Intel: Add Intel specific HDA IPC mechanisms Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 08/21] ASoC: SOF: Intel: Add Intel specific HDA firmware loader Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 09/21] ASoC: SOF: Intel: Add Intel specific HDA PCM operations Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 10/21] ASoC: SOF: Intel: Add hda-bus support and initialization Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 11/21] ASoC: SOF: Intel: Add Intel specific HDA stream operations Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 12/21] ASoC: SOF: Intel: Add Intel specific HDA trace operations Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 13/21] ASoC: SOF: Intel: Add support for HDAudio codecs Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 14/21] ASoC: SOF: Intel: SKL, CNL, APL platform DAIs Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 15/21] ASoC: SOF: Intel: Add platform differentiation for SKL, APL and CNL Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 16/21] ASoC: SOF: Intel: Add SKL-specific code loader Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 17/21] ASoC: SOF: Add ACPI device support Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 18/21] ASoC: SOF: Add PCI " Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 19/21] ALSA: HDA: export process_unsol_events() Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 20/21] ASoC: Intel: Kconfig: expose common option between SST and SOF drivers Pierre-Louis Bossart
2018-12-11 21:30 ` [PATCH 21/21] ASoC: SOF: Add Build support for SOF core and Intel drivers Pierre-Louis Bossart
2018-12-12 11:50   ` Takashi Iwai
2018-12-12 14:51     ` Pierre-Louis Bossart

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=9672de72-6fe4-5ac4-a8bf-bc0e31f6ec9d@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alan@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andriy.shevchenko@intel.com \
    --cc=broonie@kernel.org \
    --cc=daniel.baluta@gmail.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=rander.wang@linux.intel.com \
    --cc=sound-open-firmware@alsa-project.org \
    --cc=tiwai@suse.de \
    --cc=vkoul@kernel.org \
    --cc=xiuli.pan@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