On Friday 31 August 2012 07:50 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
All functions of an interface driver used by a panel driver should have an
omap_dss_device pointer as an argument. This may not be needed by some of the
interfaces now as driver data is globally visible in them. The correct way
to retrieve driver data is to extract the platform device from the output,
and then extract the driver data from the platform device.

Add dssdev arguments from functions used by panel drivers which currently miss
it. This will come to use when the RFBI functions retrieve the driver data
in the correct manner.

This and the similar patch for HDMI could probably also be left out for
now. Again I agree that this is correct direction, but this is not
really needed (right?) for output work or writeback. And we'll
eventually just change these parameters again.

The motivation for this patch was probably to have common format for the
output driver's functions, so that you can use func pointers in an ops
struct?

Yes, or the fact that we need the function to pass something related to the output to configure it. Things work now since we just have one instance of hdmi/rfbi, and that we have a global struct from which we can get the required info. We definitely need to pass something to these functions, whether we should pass the panel, or the output itself isn't clear yet.


Let's delay that work until the common panel framework gets a bit more
solid.

I get your point. We might need to replace the dssdevs with outputs (or something similar) in the future. Hence it would lead to churn.


Sorry if I'm saying "leave this patch out" for most of the patches =). I
just want to avoid extra churn, going back and forth with the code. The
most important things now are to get the output work in a state that WB
can be used, and on the other hand to remove the dssdev dependencies so
that at some point we can remove dssdev totally.

That's okay. If we keep this stuff, it'll be us who have to change it later :)

Archit
--
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

Reply via email to