* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [180423 09:52]:
> On 20/04/18 18:29, Tony Lindgren wrote:
>
> >> I'm very reluctant to merge the series (there are also some unsolved
> >> work with the series), as it's adding more omapdrm specific
> >> functionality to the driver.
> >>
> >> Getting omapdrm to be a proper DRM driver is the topmost priority at the
> >> moment, and Laurent has been doing a lot of work to accomplish that
> >> (something like 100+ patches, many still unmerged). Anything that makes
> >> that work more difficult goes to the bottom of my list.
> >
> > Sure, let's do it in a maintainable way. But please reorient your
> > "bottom of the list" attitude though. We do have a case of a bunch
>
> Well, this one is on the top of that bottom list =).
Getting better :)
> > of people and real distros trying to use this thing. With mainline
> > kernel. After all that's what makes Linux kernel community :)
>
> Sure, and I'd like to get it merged. But we have to try to manage the
> very limited resources the best way possible. I think the work Laurent
> is doing affects many more in the community than this manual update
> support, as it finally gives us support for the same panels and bridges
> as the rest of the DRM world, and also makes it possible to finally do
> proper state checks, instead of things failing mysteriously without the
> userspace knowing about it.
>
> As I see it, at the moment we essentially don't support manual update
> displays. Which makes rewriting the driver for those parts easier
> because we don't need to keep those parts working. If we merge this
> series, that freedom is removed and lots of care must be taken not to
> break manual updates.
>
> And while I don't want to push the responsibility about the decision to
> merge this or not to Laurent, I'm fine with merging if Laurent believes
> this will not make his work more difficult (because he knows better the
> changes needed than me).
>
> >> When that work has been done, and omapdrm is using common DRM panels and
> >> bridges, I'm happy to merge manual update support.
> >
> > Hmm it seems that with the "refresh on pageflip" suggestion
> > Sebastian's series would be not intrusive at all?
>
> I'm not sure what you mean with this. We need the dirtyfb support too.
> But there were some review comments, which when solved perhaps clean up
> the series (or do the opposite...).
I guess I'm not fully clued into what all is missing. I was just
thinking what I noticed we're missing weston a while back. See the
test hack hack below, only compile tested. I have not played with
weston at least for a year. But yeah I guess we still need dirtyfb
support too and can't make omap_crtc_dss_start_update() do all the
work for us?
> In any case my worry about the work Laurent is doing is not only about
> the parts touched in this series. The whole DSI driver needs to be
> changed which is not touched by this series at all. And the panel-dsi-cm
> needs to be rewritten or ported. And the way we can deal with those
> changes is very much affected by whether we have them "officially"
> supported or not.
Sure, Laurent got any comments here?
/me thinks we're best of having the command mode displays working
through all these changes though as then we can easily veirfy no
regressions happen. I believe Sebastian already agreed to help
with any changes needed few months ago.
Regards,
Tony
8< -----------
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -147,7 +147,11 @@ static void omap_crtc_dss_disconnect(struct omap_drm_private *priv,
static void omap_crtc_dss_start_update(struct omap_drm_private *priv,
enum omap_channel channel)
{
+ struct omap_crtc *omap_crtc = omap_crtcs[channel];
+ struct drm_crtc *crtc = &omap_crtc->base;
+
priv->dispc_ops->mgr_enable(priv->dispc, channel, true);
+ omap_crtc_flush(crtc);
}
static bool omap_crtc_is_manually_updated(struct drm_crtc *crtc)
--
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
