Re: [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers

[Ricardo Neri <ricardo.neri@ti.com>]

On 11/22/2012 06:52 AM, Tomi Valkeinen wrote:
> On 2012-11-22 02:20, Ricardo Neri wrote:
>> Hi Tomi, Mark,
>>
>> On 11/19/2012 07:15 PM, Mark Brown wrote:
>>> On Mon, Nov 19, 2012 at 02:58:41PM +0200, Tomi Valkeinen wrote:
>>>
>>>> I still don't understand why the codec and machine drivers need to be
>>>> created in the board file. That just forces us to replicate the same
>>>> code for all OMAP boards that have OMAP HDMI output. Why not create the
>>>> devices in some common code, for example arch/arm/mach-omap2/display.c?
>>>
>>> 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
>
> I don't =).
>
>> 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.
>
> The HDMI devices are still there in the HW even if we don't have a HDMI
> connector. I don't see any problem with probing the HDMI audio driver
> even in that case.
>
> But of course the user space shouldn't see a usable HDMI display/audio
> if there's no connector. For display side this is managed so that the
> HDMI IP driver is always loaded, but a HDMI panel driver is only there
> if the board file tells that we have a connector.
>
> I guess this could be optimized by having a "disabled" flag for HDMI IP
> driver, so that it wouldn't even need to allocate any private data
> structures of such. But the savings would be quite minimal.

Maybe, just create the devices for ASoC only if it sees a HDMI dss 
device in the omapdss_board_info?
>
>>>> With DT this should be similar: OMAP's hdmi devices should be presented
>>>> in the omap4.dtsi file, not in each individual board dts. Although the
>>>> DT data should represent the hardware, and if the code and machine
>>>> devices are not really there in the HW, then... I don't know =).
>>>
>>> Well, in a case like this where the sound card is essentially autoprobed
>>> based on the detection of the hardware at runtime the sound card
>>> probably shouldn't appear in the device tree at all - you'll probably
>>> want something to say there's a physical HDMI port it's worth looking at
>>> there but everything else should be figured out at runtime.
>>
>> Yes, I was planning to rely on the DSS DT entries in the omap4.dtsi
>> file. However, no HDMI audio support should be probed if the board does
>> not have an HDMI connector. Also, the TPD chip should appear on the
>> Pandaboard/SDP4430 dts files. Only if both conditions are met, probe the
>> HDMI audio drivers, this conditions will be checked at run time by the
>> ASoC HDMI machine driver.
>>
>> 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.
>
> The TPD chip really shouldn't be here in. It's an external component,
> not related to audio in any way. I think the HDMI audio driver should be
> only concerned about the HDMI IP.

OK. So display code will handle all the DT details for the audio drivers 
to use.

> The HDMI IP video driver shouldn't
> care about TPD chip either, but for now we need to manage it somewhere,
> and that's the easiest place for it.
BTW, I have a draft for this, but more urgent things have been consuming 
my bandwidth. :/

BR,

Ricardo
>
> So... I'm not sure how this should be managed, but I am 99% sure that
> there's nothing board specific with HDMI audio, and thus it should be
> managed in common .c files in arch code or dss code, or .dts files. If
> we add the hdmi display in the .dts files, I think the audio should just
> work.
>
> Or is there something in ASoC that forces us to represent it in the
> .dts? I don't think there's really anything related to HW to describe
> there related to HDMI audio. If we have HDMI video output, we also have
> the audio, as simple as that.
>
>   Tomi
>
>