[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