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
--
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
