On Thu, 2012-07-19 at 16:04 -0400, Raphael Assenat wrote: > On our AM3505 based board, dpi.c complains that there is no VDSS_DSI regulator > and the framebuffer cannot be enabled. However, this check does not seem to > apply to AM3505/17 chips. > > I am not the first facing this issue, see this thread from Nov. 2011: > http://marc.info/?l=linux-omap&m=132147745930213&w=2 > > The string 'vdds_dsi' does appear once in the technical reference manual[1] > but there is no corresponding power pin on the package[2]. I failed to > locate any signal that could be an equivalent. I am trying to obtain some > clarifications on TI's forum[3]... > > In any case, I am currently running with the patch below. In order to keep > cpu_is_xx uses to a minimum, I check for am35xx once at init time and allow > dpi.vdds_dsi_reg to be NULL from then on, getting rid of all the other > cpu_is_omap34xx uses in the process. > > Your comments would be appreciated. Please also consider for merging. VDDS_DSI is used to power up some of the DSS pins on OMAP3. I don't know why the HW was designed like that... If you have a correct image without the power, then obviously it's not needed. We don't currently deal with AM3xxx SoCs in any way in the driver. It's difficult enough trying to handle just OMAP DSS versions, and now we need to add AM3xxx to the mix. Sigh =). However, I don't want to apply this patch, as we're trying to remove the cpu_is checks (soc_is goes in the same category). I guess we need to add entries for the AM3xxx SoCs in the dss_features.c. Any idea what other differences AM3xxx has compared to OMAP3? Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
