On Wed, 2012-06-27 at 17:48 +0530, Archit Taneja wrote:

On Wednesday 27 June 2012 05:35 PM, Tomi Valkeinen wrote:

quoted

The sync polarities between DISPC and DSI do not matter elsewhere, they
do not affect the DSI output, so why do we have them in the panel data?
Why doesn't dsi.c just use some hardcoded values for these.

Ok, are you saying that unlike DPI, where a panel may request for some 
different polarities. There is no such need for DSI panels, and we can 
set the polarities of DISPC and DSI always to active high(or any other 
combination)?

Yes. There are no sync polarities in DSI bus, there are only sync
packets. So afaik, the polarities used here matter only for DISPC and
DSI communication. And there the only thing that matters is that both
DISPC and DSI have the same configuration for the polarities, so that
the communication works.

Well, we are doing that indirectly in a way, a DSI panel driver would 
populate a omap_video_timings struct, and would leave hsync_level, 
vsync_level and de_level empty(i.e, the default values). This would be 
passed to the DSI driver, and the timings would be applied to DISPC. The 
function above would just pick up the same default values and program to 
the DSI registers.

What we could do is ignore these fields in the omap_video_timings when 
passed from the panel driver to DSI driver, and always use a fixed value 
for them, and this way we can use the same fixed values for DSI too. Do 
you think that is better?

I think that is clearer. Optimally we wouldn't even have a video timings
struct for DSI panels, the kind that contains sync polarities and such,
but a separate timings struct that contains stuff relevant for DSI. But
for now I think we should just ignore the "extra" values in video
timings.

 Tomi