On Thu, 2012-08-16 at 17:41 +0530, Archit Taneja wrote: > On Thursday 16 August 2012 04:49 PM, Tomi Valkeinen wrote: > > On Thu, 2012-08-16 at 13:06 +0530, Archit Taneja wrote: > >> The DSI driver currently relies on the omap_dss_device struct to know the mode > >> of operation of the DSI protocol(command or video mode). This makes the DSI > >> interface driver dependent on the omap_dss_device struct. > >> > >> Make the DSI driver data maintain it's own operation mode field. The panel > >> driver is expected to call omapdss_dsi_set_operation_mode() before the interface > >> is enabled. > >> > >> Signed-off-by: Archit Taneja <archit@xxxxxx> > >> --- > >> drivers/video/omap2/displays/panel-taal.c | 1 + > >> drivers/video/omap2/dss/dsi.c | 42 +++++++++++++++++++++-------- > >> include/video/omapdss.h | 2 ++ > >> 3 files changed, 34 insertions(+), 11 deletions(-) > >> > >> diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c > >> index d220f19..649247f 100644 > >> --- a/drivers/video/omap2/displays/panel-taal.c > >> +++ b/drivers/video/omap2/displays/panel-taal.c > >> @@ -1063,6 +1063,7 @@ static int taal_power_on(struct omap_dss_device *dssdev) > >> omapdss_dsi_set_size(dssdev, dssdev->panel.timings.x_res, > >> dssdev->panel.timings.y_res); > >> omapdss_dsi_set_pixel_format(dssdev, dssdev->panel.dsi_pix_fmt); > >> + omapdss_dsi_set_operation_mode(dssdev, dssdev->panel.dsi_mode); > > > > Taal is always in cmd mode. Shouldn't we just use a hardcoded value > > here? > > > > Actually I think the same goes for the pix_fmt above. It's always the > > same for Taal. > > Yes, I'll do this. I guess we could gradually remove some of these > fields from omap_dss_device? Can't we? I mean, if there are no panels > which can ever support command and video mode together, then we can just > leave it to the driver to hold this information. Yes, we can remove them. Even if there was a panel taht supports both cmd and video mode, it would be the panel driver's job to handle it, and any parameters passed to the driver would happen via the panel's own platform data, not via dssdev. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
