[PATCH RFC 3/9] drm/omap: Add ovl_name() and mgr_name() to dispc_ops
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Wed Feb 28 14:24:35 UTC 2018
Hi Tomi,
On Wednesday, 28 February 2018 16:05:34 EET Tomi Valkeinen wrote:
> On 28/02/18 15:23, Laurent Pinchart wrote:
> > On Wednesday, 28 February 2018 13:37:48 EET Tomi Valkeinen wrote:
> >> On 27/02/18 16:35, Laurent Pinchart wrote:
> >>> the whole omap_irq_fifo_underflow() and omap_irq_ocp_error_handler() IRQ
> >>> handling to the DSS side, as they're not DRM/KMS-related ?
> >>
> >> I think we should react to both errors somehow (I'm not sure how,
> >> disable output probably), and that has to be done on the KMS level. We
> >> don't do that now, but moving this to DSS side would make error handling
> >> more difficult to do in the future.
> >
> > Ideally I'd demultiplex interrupts on the DSS side and report events to
> > the KMS side (page flip completion, underflows, ...).
>
> That's more or less what Jyri's "drm/omap: Make omapdss API more
> generic" does, isn't it? Or what is the difference with interrupt and
> event in your mind? Function calls vs status bits?
Yes, that's the difference in my mind. I'd keep the status bits on the DSS
side. We don't have to implement one callback function for each status bit, we
could translate them into abstract event bits that are not specific to a
particular DSS version. What I'd like to avoid is omapdrm calling into omapdss
to retrieve a name for a bit that is DSS-specific. If we want hardware names
in debug messages I think they should be printed on the omapdss side, and if
we want to handle status bits on the omapdrm side they shouldn't require
hardware names.
--
Regards,
Laurent Pinchart
More information about the dri-devel
mailing list