Hi Tomi,
On Thu, Mar 1, 2012 at 5:01 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
> Hi,
>
> On Thu, 2012-03-01 at 13:44 +0530, mythripk@xxxxxx wrote:
>> From: Mythri P K <mythripk@xxxxxx>
>>
>> Currently TX_PHY is put to TX_ON(transmission state) on receiving HPD.
>> It just ensures that the TV is connected but does not guarantee
>> that TMDS data lines and clock lines are up and ready for transmission.
>> Which although is very rare scenario has a potential to damage the HDMI
>> port.(A use case where TV is connected to board but it is in different
>> channel would still trigger a HPD but TMDS lines will be down).
>
> When/how does the damaging happen? When the HDMI cable is disconnected
> in the case above? Or does the damage just happen by having the cable
> connected, but the TV on different channel?
Damage never happens with the cable connected for a long time.. Damage
happens only
when the cable is connected when the PHY is in TX ON state. Which
requires the following sequence to be followed.
1. Wait for HPD connect
2. Wait for the PHY connect ( TMDS lines are up)
3. Enable PHY
We are currently missing step 2.
>> + tmds_clk = hdmi_read_reg(hdmi_wp_base(ip_data),
>> + HDMI_WP_WP_DEBUG_DATA);
>> + udelay(15);
>
> This code doesn't make any sense, or the HDMI TRM is wrong. You read the
> same register, HDMI_WP_WP_DEBUG_DATA, four times, assigning the value to
> data0-2/clk. The TRM I have doesn't talk about anything like that. What
> is the code supposed to do?
>
I am not very sure which TRM you have but the HDMI_WP_WP_DEBUG_DATA
can also be used to probe the TMDS lines as well, but i might as well
try pad config and let you know.
> The register HDMI_TXPHY_PAD_CONFIG_CONTROL also has bits for RXDET_LINE.
> Is that something different?
>
>> + } while ((tmds_data0 != tmds_data1 || tmds_data1 != tmds_data2
>> + || tmds_data1 != tmds_clk) && (loop < 500));
>
> This is a rather confusing way to do the loop. Why not just use for-loop
> with the timeout, and check the tmds variables inside the loop. Much
> easier to read.
>
> In the worst case the above causes a 7.5ms busy loop in an interrupt
> handler. That's not very good thing. Why is there a need for the loop?
I agree looping in interrupt context is bad.. That was the reason i
had a threaded irq handler and i case even here it is the threaded irq
handler i dont think it is happening in irq context.
>> + DSSERR("rxdet not set\n");
>> + return r;
>> + }
>
> Does this mean that if the user connects a TV which is in a different
> channel than HDMI, the only way for the user to get an image is to
> disconnect the cable and connect it again?
Well If the handling is based on HPD then yes.. Or one another thing
is i can add the core interrupt support and we can then wait on the
PHY_CONNECT instead of all the above scenario.
I shall put a wait_on_completion check in HPD and we can wait till we
get PHY connect.
Thanks and regards,
Mythri.
>
> 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
