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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
