On 28/02/18 16:24, Laurent Pinchart wrote: > 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. Ok, yes, I see your point, and agree. Here, I think what's done (after the IRQ change patch) is that we get a an abstracted bit for the underflow. Omapdrm can map that bit to an omap_plane, and should get the name from omap_plane, instead of asking it directly from dispc. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
