Hi Tomi, On Mon, Mar 7, 2011 at 3:16 PM, Tomi Valkeinen <tomi.valkei...@ti.com> 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 <mythr...@ti.com>
<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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html