On Tuesday 12 March 2013 07:59 PM, Tomi Valkeinen wrote:
On 2013-03-12 16:01, Archit Taneja wrote:
On Tuesday 12 March 2013 07:07 PM, Tomi Valkeinen wrote:
So, I don't disagree with you. But I don't quite understand why we could
not use the fixed channels for now? They should work in all the boards
we have, right? Or is there something with DRM that forces the driver to
select the channel dynamically?
I think we can use fixed channels, but if the number of different fixed
channels crosses the number of crtcs the kernel wants, then we would
need to atleast change the channels of some of the outputs.
For example, suppose omapdrm is asked to use only 2 crtcs, and it picks
up LCD2 and TV managers. Now if there is some panel which says it's
recommended channel is LCD, then things won't work.
Are you saying omapdrm picks the managers for the crtcs before knowing
what panels there are? That can't work right... We need to know what
outputs are to be used before we can select the managers. Or, we always
need crtcs for all the managers.
That's how it is right now.
If we do know the panels, and thus outputs, then the managers to be used
are found easily from output->dispc_channel.
Yes, my patch tries to do the same, but it could assign a manger which
isn't the recommended channel. It can pick one from the list of
supported channels. I've explained it a bit more below.
But, of course, the crtc to manager mapping could be changed (if omapdrm
supports this). If omapdrm is asked to use only 1 crtc, but there are
two panels, then only one panel can be used at a time, and the manager
for the crtc needs to be changed when the panel to be used is changed.
But even in this case used manager is clear, it comes from
output->dispc_channel.
This is something I don't know that can be done or not, or if it can be
done easily. A crtc isn't purely an overlay manager. It also needs to
have one plane associated to it. So, if we want to change the overlay
manager tied to a crtc on the fly, we should make sure that it's still
connected to a plane pointing to the same buffer. This needs a better
understanding of drm internals. I guess Rob could answer this better.
At the moment, omapdrm maps a crtc with a manger using a function called
pipe2chan() which just selects a manager with the biggest channel no. So
if the kernel is configured to have num_crtcs as 1. The single crtc will
be mapped to LCD2. This method is wrong, as it doesn't even look at the
type of panels at all. For an omap5 panda, the most suitable manager to
map to the crtc would be TV(for hdmi).
I think what we probably need to do is to combine both the methods. I.e,
make each output connectible to only one channel, and also iterate
through the panels in omapdrm to find the most suitable channels. So in
my patch, instead of looking at all the supported managers for an
output(checking with dss_feat_get_supported_outputs() on each manager),
I just look at the recommended channel, and try to map that manager.
I don't know, I feel like I'm not understanding something here =).
:)
I think what I said above is equivalent to what you said here:
"If we do know the panels, and thus outputs, then the managers to be
used are found easily from output->dispc_channel."
Instead of using output->dispc_channel, the patch I made tried to get
the first supported channel(in increasing order of channel index) for an
output. If that channel was already taken/reserved by a previous output,
it tries to take the next supported channel if there are enough crtcs left.
My patch would break things if it chooses a manager for an output for
which we haven't written the necessary code yet(switching clock sources
etc).
So, what I'm saying is that we should stick to output->dispc_channel. We
iterate through all the panels, and by using output->dispc_channel, we
get the manager for an output, and map that manager to a crtc, and make
sure the number of unique managers we finally use is equal to NUM_CRTC.
Does that sound good?
Archit
--
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
