* Using HDA on an SoC without PCI
@ 2014-02-14 17:47 Dylan Reid
2014-02-14 18:01 ` Stephen Warren
0 siblings, 1 reply; 4+ messages in thread
From: Dylan Reid @ 2014-02-14 17:47 UTC (permalink / raw
To: alsa-devel; +Cc: Takashi Iwai, Stephen Warren
Hi,
I'm working on an system with an HDMI codec on an HDA interface, but
that interface doesn't use PCI. I want to re-use as much of the code
as possible, but I want to avoid scattering ifdefs all over
hda_intel.c.
Would gathering the pci specific functions from hda_intel.c into an
interface struct of some kind make sense? If azx was probed from pci,
then a pci interface would be used, if it was a platform driver, then
the correct interface for the platform would be used. It would add
some overhead to operations such as azx_writel, but that would be
measured to make sure it isn't detrimental to performance.
Any other ideas on how to approach this?
Thanks,
Dylan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Using HDA on an SoC without PCI
2014-02-14 17:47 Using HDA on an SoC without PCI Dylan Reid
@ 2014-02-14 18:01 ` Stephen Warren
2014-02-14 18:50 ` Dylan Reid
2014-02-14 20:13 ` Takashi Iwai
0 siblings, 2 replies; 4+ messages in thread
From: Stephen Warren @ 2014-02-14 18:01 UTC (permalink / raw
To: Dylan Reid, alsa-devel; +Cc: Takashi Iwai, Stephen Warren
On 02/14/2014 10:47 AM, Dylan Reid wrote:
> Hi,
>
> I'm working on an system with an HDMI codec on an HDA interface, but
> that interface doesn't use PCI. I want to re-use as much of the code
> as possible, but I want to avoid scattering ifdefs all over
> hda_intel.c.
I think the relevant APIs stub themselves out when appropriate, so you
can do this all without compile-time ifdefs.
> Would gathering the pci specific functions from hda_intel.c into an
> interface struct of some kind make sense? If azx was probed from pci,
> then a pci interface would be used, if it was a platform driver, then
> the correct interface for the platform would be used. It would add
> some overhead to operations such as azx_writel, but that would be
> measured to make sure it isn't detrimental to performance.
Our downstream trees do have patches to allow the HDA driver to be
instantiated from either PCI or from platform devices. You can find the
code in branch:
git://nv-tegra.nvidia.com/linux-2.6.git rel-roth-r3
e.g. ef8491346266 "ALSA: hda: Add hda platform driver support"
There are many other patches to sound/pci/hda after that. I don't recall
exactly how clean taht first patch was, and probably never saw anything
after it, but it might be a good start...
We've only recently had HDMI support upstream on Tegra, otherwise it's
possible I may have found time to try to upstream those patches before.
Not that I have spare time:-)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Using HDA on an SoC without PCI
2014-02-14 18:01 ` Stephen Warren
@ 2014-02-14 18:50 ` Dylan Reid
2014-02-14 20:13 ` Takashi Iwai
1 sibling, 0 replies; 4+ messages in thread
From: Dylan Reid @ 2014-02-14 18:50 UTC (permalink / raw
To: Stephen Warren; +Cc: Takashi Iwai, alsa-devel, Stephen Warren
On Fri, Feb 14, 2014 at 10:01 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 02/14/2014 10:47 AM, Dylan Reid wrote:
>> Hi,
>>
>> I'm working on an system with an HDMI codec on an HDA interface, but
>> that interface doesn't use PCI. I want to re-use as much of the code
>> as possible, but I want to avoid scattering ifdefs all over
>> hda_intel.c.
>
> I think the relevant APIs stub themselves out when appropriate, so you
> can do this all without compile-time ifdefs.
>
>> Would gathering the pci specific functions from hda_intel.c into an
>> interface struct of some kind make sense? If azx was probed from pci,
>> then a pci interface would be used, if it was a platform driver, then
>> the correct interface for the platform would be used. It would add
>> some overhead to operations such as azx_writel, but that would be
>> measured to make sure it isn't detrimental to performance.
>
> Our downstream trees do have patches to allow the HDA driver to be
> instantiated from either PCI or from platform devices. You can find the
> code in branch:
>
> git://nv-tegra.nvidia.com/linux-2.6.git rel-roth-r3
> e.g. ef8491346266 "ALSA: hda: Add hda platform driver support"
>
> There are many other patches to sound/pci/hda after that. I don't recall
> exactly how clean taht first patch was, and probably never saw anything
> after it, but it might be a good start...
>
> We've only recently had HDMI support upstream on Tegra, otherwise it's
> possible I may have found time to try to upstream those patches before.
> Not that I have spare time:-)
That is a good start, even better that it's also in 3.10 Tegra kernel.
That first patch looks pretty good. The following changes to enable
tegra hdmi are a little more interesting, but don't look impossible to
clean up. The register access is tricky, since the azx_write* defines
need to be different. I'll play with it for a while and see how it
goes.
Thanks Stephen,
Dylan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Using HDA on an SoC without PCI
2014-02-14 18:01 ` Stephen Warren
2014-02-14 18:50 ` Dylan Reid
@ 2014-02-14 20:13 ` Takashi Iwai
1 sibling, 0 replies; 4+ messages in thread
From: Takashi Iwai @ 2014-02-14 20:13 UTC (permalink / raw
To: Stephen Warren; +Cc: Dylan Reid, Stephen Warren, alsa-devel
At Fri, 14 Feb 2014 11:01:14 -0700,
Stephen Warren wrote:
>
> On 02/14/2014 10:47 AM, Dylan Reid wrote:
> > Hi,
> >
> > I'm working on an system with an HDMI codec on an HDA interface, but
> > that interface doesn't use PCI. I want to re-use as much of the code
> > as possible, but I want to avoid scattering ifdefs all over
> > hda_intel.c.
>
> I think the relevant APIs stub themselves out when appropriate, so you
> can do this all without compile-time ifdefs.
>
> > Would gathering the pci specific functions from hda_intel.c into an
> > interface struct of some kind make sense? If azx was probed from pci,
> > then a pci interface would be used, if it was a platform driver, then
> > the correct interface for the platform would be used. It would add
> > some overhead to operations such as azx_writel, but that would be
> > measured to make sure it isn't detrimental to performance.
>
> Our downstream trees do have patches to allow the HDA driver to be
> instantiated from either PCI or from platform devices. You can find the
> code in branch:
>
> git://nv-tegra.nvidia.com/linux-2.6.git rel-roth-r3
> e.g. ef8491346266 "ALSA: hda: Add hda platform driver support"
Interesting, I'll take a look later.
> There are many other patches to sound/pci/hda after that. I don't recall
> exactly how clean taht first patch was, and probably never saw anything
> after it, but it might be a good start...
I haven't looked at your patches yet, but the HD-audio codec drivers
(hda_codec.c, patch_*.c, etc) are basically independent from the h/w
access details, and the whole PCI and DMA implementations are isolated
in hda_intel.c. So, it shouldn't be too hard to implement on other
buses, I suppose.
If I were to implement, I'd rather write a new controller driver from
the scratch instead of hacking hda_intel.c. The controller driver
needs to create hda_bus and hda_codecs with proper ops. Some code
must be duplicated, but this might become cleaner in the end.
Let's see...
> We've only recently had HDMI support upstream on Tegra, otherwise it's
> possible I may have found time to try to upstream those patches before.
> Not that I have spare time:-)
Heh, famous last words ;)
thanks,
Takashi
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-02-14 20:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-14 17:47 Using HDA on an SoC without PCI Dylan Reid
2014-02-14 18:01 ` Stephen Warren
2014-02-14 18:50 ` Dylan Reid
2014-02-14 20:13 ` Takashi Iwai
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.