Messages in this thread | | | Date | Thu, 6 Jul 2023 09:33:15 +0200 | From | Neil Armstrong <> | Subject | Re: RFC: DSI host capabilities (was: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3) |
| |
On 06/07/2023 09:24, Maxime Ripard wrote: > On Wed, Jul 05, 2023 at 11:09:40PM +0300, Dmitry Baryshkov wrote: >> On 05/07/2023 19:53, Maxime Ripard wrote: >>> On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote: >>>> On Wed, 5 Jul 2023 at 17:24, Maxime Ripard <mripard@kernel.org> wrote: >>>>> >>>>> On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote: >>>>>>>>> >>>>>>>>> Either way, I'm not really sure it's a good idea to multiply the >>>>>>>>> capabilities flags of the DSI host, and we should just stick to the >>>>>>>>> spec. If the spec says that we have to support DSC while video is >>>>>>>>> output, then that's what the panels should expect. >>>>>>>> >>>>>>>> Except some panels supports DSC & non-DSC, Video and Command mode, and >>>>>>>> all that is runtime configurable. How do you handle that ? >>>>>>> >>>>>>> In this case, most of the constraints are going to be on the encoder >>>>>>> still so it should be the one driving it. The panel will only care about >>>>>>> which mode has been selected, but it shouldn't be the one driving it, >>>>>>> and thus we still don't really need to expose the host capabilities. >>>>>> >>>>>> This is an interesting perspective. This means that we can and actually have >>>>>> to extend the drm_display_mode with the DSI data and compression >>>>>> information. >>>>> >>>>> I wouldn't extend drm_display_mode, but extending one of the state >>>>> structures definitely. >>>>> >>>>> We already have some extra variables in drm_connector_state for HDMI, >>>>> I don't think it would be a big deal to add a few for MIPI-DSI. >>>>> >>>>> We also floated the idea for a while to create bus-specific states, with >>>>> helpers to match. Maybe it would be a good occasion to start doing it? >>>>> >>>>>> For example, the panel that supports all four types for the 1080p should >>>>>> export several modes: >>>>>> >>>>>> 1920x1080-command >>>>>> 1920x1080-command-DSC >>>>>> 1920x1080-video >>>>>> 1920x1080-video-DSC >>>>>> >>>>>> where video/command and DSC are some kinds of flags and/or information in >>>>>> the drm_display_mode? Ideally DSC also has several sub-flags, which denote >>>>>> what kind of configuration is supported by the DSC sink (e.g. bpp, yuv, >>>>>> etc). >>>>> >>>>> So we have two things to do, right? We need to expose what the panel can >>>>> take (ie, EDID for HDMI), and then we need to tell it what we picked >>>>> (infoframes). >>>>> >>>>> We already express the former in mipi_dsi_device, so we could extend the >>>>> flags stored there. >>>>> >>>>> And then, we need to tie what the DSI host chose to a given atomic state >>>>> so the panel knows what was picked and how it should set everything up. >>>> >>>> This is definitely something we need. Marijn has been stuck with the >>>> panels that support different models ([1]). >>>> >>>> Would you prefer a separate API for this kind of information or >>>> abusing atomic_enable() is fine from your point of view? >>>> >>>> My vote would be for going with existing operations, with the slight >>>> fear of ending up with another DSI-specific hack (like >>>> pre_enable_prev_first). >>> >>> I don't think we can get away without getting access to the atomic_state >>> from the panel at least. >>> >>> Choosing one setup over another is likely going to depend on the mode, >>> and that's only available in the state. >>> >>> We don't have to go the whole way though and create the sub-classes of >>> drm_connector_state, but I think we should at least provide it to the >>> panel. >>> >>> What do you think of creating a new set of atomic_* callbacks for >>> panels, call that new set of functions from msm and start from there? >> >> We are (somewhat) bound by the panel_bridge, but yeah, it seems possible. > > Bridges have access to the atomic state already, so it's another place > to plumb this through but I guess it would still be doable?
It's definitely doable, but I fear we won't be able to test most of the panel drivers, should we introduce a new atomic set of panel callbacks ?
Or shall be simply move the "new" panel driver supporting atomic to bridge and only use panel_bridge for basic panels ?
Neil
> > Maxime
| |