On Friday 02 September 2011 01:25 PM, Valkeinen, Tomi wrote:
On Fri, 2011-09-02 at 11:43 +0530, Archit Taneja wrote:
Sending a null packet to start the DDR clk is rather OMAP specific
internal thing, so I don't want to require the panel driver to need
to
know that it must send a null packet to start the clock. So if the
ddr
clk is not started automatically, I think we should have a function
to
do that (dsi_start_ddr_clk or whatever), which will then send the
null
packet (and perhaps return an error if DDR_CLK_ALWAYS_ON is not set,
dunno...).
Okay, If we can confirm that a panel asks for DDR_CLK_ALWAYS_ON
mainly
because it doesn't have its own fclk, then the dsi driver surely
needs
to start the DDR clock by sending a NULL packet.
If this is to be done, one thing that has to be thought of is:
- We need one of the requested VC's to be in HS mode for this. Do we
enable HS for a VC in the dsi driver itself? Currently, its the job
of
the panel driver to enable HSmode for a VC. Is this a clean approach?
I have to say I don't have any idea what would be the best approach...
What comes to my mind is that the DSI driver could automatically send
the null packet, when:
a) ddr_clk_always_on is set
b) a channel is changed to HS and enabled (I guess it needs to be
enabled also, does it?)
This approach sounds fine. The only drawback is that we send a NULL
packet each time we enable a high speed channel. So if a panel is using
2 VCs, and it wants high speed for both channels(for some reason), we
will be sending a NULL packet unnecessarily.
One observation was that the DDR clock has to be enabled only after the
bridge chip is reset. Enabling HS, and sending a NULL packet before
doing a hw reset of the bridge chip doesn't bring up the panel(that is a
bit peculiar). So we can't do this within omapdss_dsi_display_enable().
Archit
Well, we do seem to enable all VCs at init phase (which, thinking about
it, sounds a bit odd), so in practice we would just need to handle the
omapdss_dsi_vc_enable_hs() case.
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
