[alsa-devel] [RFC 00/19] Enable platform HDA drivers
Dylan Reid
dgreid at chromium.org
Fri Feb 28 09:31:05 CET 2014
On Thu, Feb 27, 2014 at 11:57 PM, Takashi Iwai <tiwai at suse.de> wrote:
> At Thu, 27 Feb 2014 22:35:43 -0800,
> Dylan Reid wrote:
>>
>> This series rearranges some code in the HDA driver to break
>> dependencies on PCI and allow for most of the HDA code to be reused
>> for non-PCI based HDA controllers.
>>
>> I tried to break it up to make it less scary and to keep changes away
>> from copies of code. It is mostly copies with a few modifications to
>> make more of the code usable by both HDA drivers. The main changes
>> were to avoid using pci to get a device pointer, and to make the bus
>> reads/writes into callbacks so that the Tegra driver could ensure
>> 32-bit access to the HDA registers.
>>
>> The final patch is a work in progress included here to provide context
>> for the preceding patches. The Tegra HDA driver still needs some
>> cleaning up, but nothing that will affect the other changes. The last
>> infrastructure issue is that the Tegra driver uses DT, causing it to be
>> probed before the codec patches. I haven't determined how to fix that
>> yet.
>>
>> I didn't include the patch to move the hda directory from under pci
>> because of its size and how easy it will be to regenerate later.
>>
>> Thanks for looking. Let me know if you think any of these should be
>> squashed or re-ordered and if the changes and breakup of code makes
>> sense.
>
> The changes look almost good as I supposed.
> Through a quick glance, some random comments:
>
> - I prefer hda_controller.c (or something like that) to hda_shared.c.
> It's a helper module for the controller drivers, after all.
>
> - mark_pages_wc() and co can be moved back to hda_intel.c.
> Instead, provide the page allocator in ops, something like:
>
> int (*alloc_pages)(struct azx *chip, int size,
> struct snd_dma_buffer *buf);
> void (*free_pages)(struct azx *chip, struct snd_dma_buffer *buf);
>
> then X86-specific hacks can be done there.
>
> - The rest x86-specific hack is mmap. Maybe this can be also handled
> via an ops. For non-x86, just call snd_pcm_lib_default_mmap()
> (which is equivalent with pcm_ops.mmap = NULL).
>
> - There are lots of workarounds in the code, and which are really
> needed for Tegra? For example, bdl_pos_adj can be optional, and you
> can put a NULL check for chip->bdl_pos_adj and handle as 0 in
> azx_setup_periods().
>
> The buffer position check can be back to hda_intel.c, too. Instead,
> we may give another ops, e.g.
> bool (*position_check)(struct azx *, struct azx_dev *dev);
> and call it (optionally) in the irq handler. This checks the
> validity of the position, return true if it's OK, else queue the
> work, etc.
>
> irqreturn_t azx_interrupt(int irq, void *dev_id)
> {
> .....
> if (status & azx_dev->sd_int_sta_mask) {
> ....
> /* check whether this IRQ is really acceptable */
> if (!chip->ops->position_check)
> ok = true;
> else
> ok = chip->ops->position_check(chip, azx_dev);
> if (ok) {
> spin_unlock(&chip->reg_lock);
> snd_pcm_period_elapsed(azx_dev->substream);
> spin_lock(&chip->reg_lock);
> }
>
> Then we can move azx_irq_pending_work() to hda_intel.c, too.
That'll be nice. Thanks for the suggestions, I'll take a look at
re-spinning tomorrow morning.
>
> I'm not sure whether position_fix stuff is better in the shared code
> or not. Many hardware have problems regarding this, so it'd be
> still helpful to provide workarounds in the common code for future
> hardware, too.
Maybe put it in the intel code for now and if another platform needs
it, then it can be pulled into the common area at that point.
Thanks,
Dylan
>
>
> thanks,
>
> Takashi
More information about the Alsa-devel
mailing list