On 10/23/2012 11:29 PM, Tomi Valkeinen wrote:
On 2012-10-23 20:21, Ricardo Neri wrote:
If so, you could pass only that one address, instead of the whole HDMI
register space?
Yes, that could work. I thought about that but the common HDMI driver
would have to know the the IP-specific register, which it should not.
Argh, of course...
Perhaps the IP-specific register address can be passed by a IP-specific
function such as hdmi_get_audio_dma_port for the common HDMI driver to
populate the resource.
Btw, could this be another reason to convert the IP-specific libraries
to drivers?
Yes, I think it makes more and more sense to do that.
Even though this would allow our HDMI drivers to be more inline with
what other HDMI drivers do, things like power management and interrupts
are still handled by DSS, unlike x86, for instance [1][2]. So the audio
drivers will still depend on DSS. Also, the register layout is different
for OMAP5 and audio registers are even more scattered. Furthermore, the
common HDMI driver would have to know the IP-specific layout to know
what register spaces expose to the audio driver (another reason to have
IP-specific drivers?). So I would vote for continuing using the omapdss
audio interface.
Okay.
I think your approach is ok for the time being. I don't like passing the
whole register space to the audio driver, but that's the best we can do
with the current driver.
What about for now having a function in the IP library to be called from
the common driver to determine the address of the port? Something like[1]:
res = platform_get_resource_byname(hdmi.pdev,
IORESOURCE_MEM, "hdmi_wp");
aud_offset = hdmi.ip_data.ops->audio_get_dma_port_off();
aud_res[0].start = res->start + aud_offset;
aud_res[0].end = res->start + aud_offset + 3;
Have you looked at converting to IP specific drivers? Any idea of the
effort? I'd like it to be done with the omap4 hdmi driver first, before
merging omap5 hdmi into the mainline, if at all possible.
As a first step, I have started implementing a separate driver for the
TPD12S015 as you suggested in the past. For converting the IP libraries
into drivers, I still don't see how to keep them independent of omapdss
to be reusable by DaVinci platforms (but afaik they are not using our
libraries anyways). Maybe, a thin compatibility layer for omapdss (the
hdmi_panel)? I still don't have a clear idea. :/
BR,
Ricardo
[1].
http://gitorious.org/omap-audio/linux-audio/blobs/ricardon/topic/3.7-hdmi-clean/drivers/video/omap2/dss/hdmi.c#line1098
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
