Hi Mark,
On 11/21/2012 07:03 PM, Mark Brown wrote:
On Wed, Nov 21, 2012 at 06:20:00PM -0600, Ricardo Neri wrote:
On 11/19/2012 07:15 PM, Mark Brown wrote:
Yes, this would be more sensible if there's no board specifics involved.
I think they are truly board-specific. For instance, there could be some board that does not have the OMAP HDMI IP wired to an external connector. We don't want the drivers to be probed in that case. If they are in common code, the devices will be created even if a board does not have HDMI output.
That's just a case of having a flag in the platform data for the device saying "don't use this port"
Ok. I guess I can put code so that the devices for ASoC are created only if there are HDMI displays in the omapdss_board_info.devices array.
as opposed to having the entire ASoC device
instantiation infrastructure in there which is rather Linux specific.
But the board files are only for Linux, right? The ASoC drivers will always be initialized anyways. They will reach probe only if the devices are present.
Something like this:
sound_hdmi { compatible = "ti,omap-hdmi-card-audio"; ti,model = "OMAP4HDMI";
ti,hdmi_audio = <&hdmi>; ti,level_shifter = <&tpd12s015>;};
The ASoC machine driver would create the platform device for the HDMI codec if the DT has the required nodes.
Why not just make this a property of the main HDMI controller - the compatible property here looks like it's describing the Linux specifics not the hardware?
I see. So it seems that there will be nothing to add for DT support for HDMI from ASoC. Display code is able to take care of it. BTW, thanks for pointing out the issue with the compatible property, I have not noticed it.
BR,
Ricardo