Hi Tomi,
On Mon, Mar 7, 2011 at 3:16 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
> On Fri, 2011-03-04 at 01:48 -0600, K, Mythri P wrote:
>> Adding the hdmi interface driver header file (hdmi.h) to the dss driver.
>> Register and timing declaration to be used by the corresponding c file
>> is added in this file.
>
> The subject and description are wrong. Always before sending patches do
> a quick sanity check, by check the subjects, looking at the stats in the
> intro letter, etc.
My bad ,will reread.
>
>> Signed-off-by: Mythri P K <mythripk@xxxxxx>
<snip>
>> +const u8 header[8] = {0x0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0};
>
> Bad variable name, use something more descriptive.
>
will rename to edid_header.
>> +
<snip>
>> +static int hdmi_wait_phy_pwr(int val)
>
> These comments apply also to the function below.
>
> The parameter should be an enum.
>
> The function is misnamed. This doesn't wait for the power mode to
> change, as the name implies. This sets the power mode.
>
will make refsel an enum and add other option , also make all these
functions to take enum as a parameter.
<snip>
>> + * SW HACK : DDC needs time to stablize else it sometimes reads 0 values
>> + * or right shifted values.
>> + */
>> + usleep_range(800, 1000);
>
> This is still unclear. Is it an OMAP HW problem? OMAP HW feature? A
> feature in HDMI TVs? A HDMI spec delay? Or unknown reason?
>
there is an internal DDC (i2c bus) , without this delay I have
sometimes seen that while reading EDID
we sometimes (Not always and only with some TV's , even with a
particular TV it is not consistent)
read a shifted value or EDID value is 0. I can clarify with the h/w
team , but can we add this as a s/w hack for time being?
<snip>
Thanks and regards,
Mythri.
--
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
