plit the DSC code to be guarded by the separate
> DRM_DISPLAY_DSC_HELPER Kconfig symbol.
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
R
> config DRM_BRIDGE_CONNECTOR
> bool
> depends on DRM && DRM_BRIDGE && DRM_DISPLAY_HELPER
> + select DRM_DISPLAY_HDMI_STATE_HELPER
Sorry, I notice it on that patch, but it's really on the previous one:
both DRM_BRIDGE and DRM_DISPLAY_HELPER are meant to be selected, not
depended on.
Otherwise,
Reviewed-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Tue, Jul 02, 2024 at 12:48:54PM GMT, Dmitry Baryshkov wrote:
> drm_bridge_connector is a "leaf" driver, belonging to the display
> helper, rather than the "CRTC" drm_kms_helper module. Move the driver
> to the drm/display and add necessary Kconfig selection claus
On Tue, Jul 02, 2024 at 12:48:52PM GMT, Dmitry Baryshkov wrote:
> Document that DRM_MODE_PROP_IMMUTABLE must be set for the properties
> that are immutable by definition - e.g. ranges with min == max or enums
> with a single value. This matches the behaviour of the IGT tests, see
>
On Tue, Jun 25, 2024 at 07:38:22PM GMT, Dmitry Baryshkov wrote:
> On Tue, Jun 25, 2024 at 05:49:54PM GMT, Maxime Ripard wrote:
> > On Tue, Jun 25, 2024 at 06:05:33PM GMT, Dmitry Baryshkov wrote:
> > > On Tue, 25 Jun 2024 at 18:02, Maxime Ripard wrote:
> > > >
>
On Tue, Jun 25, 2024 at 06:05:33PM GMT, Dmitry Baryshkov wrote:
> On Tue, 25 Jun 2024 at 18:02, Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Sun, Jun 23, 2024 at 08:40:12AM GMT, Dmitry Baryshkov wrote:
> > > On HDMI connectors which use drm_bridge_connector and
Hi,
On Sun, Jun 23, 2024 at 08:40:12AM GMT, Dmitry Baryshkov wrote:
> On HDMI connectors which use drm_bridge_connector and DRM_BRIDGE_OP_HDMI
> IGT chokes on the max_bpc property in several kms_properties tests due
> to the the drm_bridge_connector failing to reset HDMI-related
> properties.
>
On Tue, Jun 25, 2024 at 10:23:14AM GMT, Dmitry Baryshkov wrote:
> On Tue, 25 Jun 2024 at 10:19, Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Tue, Jun 25, 2024 at 09:21:27AM GMT, Dmitry Baryshkov wrote:
> > > On Tue, 25 Jun 2024 a
Hi,
On Tue, Jun 25, 2024 at 09:21:27AM GMT, Dmitry Baryshkov wrote:
> On Tue, 25 Jun 2024 at 01:56, Abhinav Kumar wrote:
> >
> >
> >
> > On 6/24/2024 3:46 PM, Dmitry Baryshkov wrote:
> > > On Tue, 25 Jun 2024 at 01:39, Abhinav Kumar
> > > wrote:
> > >>
> > >> + IGT dev
> > >>
> > >> On
On Tue, Jun 11, 2024 at 02:26:12PM GMT, Dmitry Baryshkov wrote:
> On Tue, 11 Jun 2024 at 11:54, Maxime Ripard wrote:
> >
> > On Mon, Jun 10, 2024 at 08:54:09PM GMT, Dmitry Baryshkov wrote:
> > > On Mon, Jun 10, 2024 at 02:07:06PM +0200, Maxime Ripard wrote:
> >
On Mon, Jun 10, 2024 at 08:54:09PM GMT, Dmitry Baryshkov wrote:
> On Mon, Jun 10, 2024 at 02:07:06PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > +Hans
> >
> > On Mon, Jun 10, 2024 at 02:46:03PM GMT, Dmitry Baryshkov wrote:
> > > On Mon,
Hi,
+Hans
On Mon, Jun 10, 2024 at 02:46:03PM GMT, Dmitry Baryshkov wrote:
> On Mon, 10 Jun 2024 at 11:04, Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Fri, Jun 07, 2024 at 04:22:59PM GMT, Dmitry Baryshkov wrote:
> > > Turn drm_br
requires manual repacking in the driver, while GENERIC0 doesn't
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
th the audio functionality and just disabling the audio playback
> doesn't stop the HDMI hardware from sending the Infoframe.
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
ctor_cleanup() and so are safe to be dropped.
>
> Acked-by: Maxime Ripard
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/drm_bridge_connector.c | 23 +--
> 1 file changed, 5 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm
On Fri, 31 May 2024 23:07:29 +0300, Dmitry Baryshkov wrote:
> Setup the HDMI connector on the MSM HDMI outputs. Make use of
> atomic_check hook and of the provided Infoframe infrastructure.
>
> Signed-off-by: Dmitry Baryshkov
Acked-by: Maxime Ripard
Thanks!
Maxime
foframe. It wasn't
possible for the main helpers because we didn't have enough info for
some drivers, but I think we should try to make it mandatory, and be
prepared to relax it if needs be.
With that fixed:
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
Hi,
Sorry for not answering your mail on the previous version sooner.
On Fri, May 31, 2024 at 11:07:24PM GMT, Dmitry Baryshkov wrote:
> Allow passing NULL as audio infoframe as a way to disable Audio
> Infoframe generation.
>
> Signed-off-by: Dmitry Baryshkov
> ---
>
On Fri, 31 May 2024 23:07:30 +0300, Dmitry Baryshkov wrote:
> Use connector->display_info.is_hdmi instead of manually using
> drm_detect_hdmi_monitor().
>
> Signed-off-by: Dmitry Baryshkov
Acked-by: Maxime Ripard
Thanks!
Maxime
mitry Baryshkov
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
Hi,
On Thu, May 30, 2024 at 02:12:28AM GMT, Dmitry Baryshkov wrote:
> Setup the HDMI connector on the MSM HDMI outputs. Make use of
> atomic_check hook and of the provided Infoframe infrastructure.
>
> Signed-off-by: Dmitry Baryshkov
As a general comment: I really like it, it looks super tidy.
On Thu, 30 May 2024 02:12:27 +0300, Dmitry Baryshkov wrote:
> Change MSM HDMI bridge to use atomic_* callbacks in preparation to
> enablign the HDMI connector support.
>
> Signed-off-by: Dmitry Baryshkov
Acked-by: Maxime Ripard
Thanks!
Maxime
Hi,
On Thu, May 30, 2024 at 02:12:26AM GMT, Dmitry Baryshkov wrote:
> In order to let bridge chains implement HDMI connector infrastructure,
> add necessary glue code to the drm_bridge_connector. In case there is a
> bridge that sets DRM_BRIDGE_OP_HDMI, drm_bridge_connector will register
> itself
nup() and so are safe to be dropped.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
Hi,
On Thu, May 30, 2024 at 02:12:24AM GMT, Dmitry Baryshkov wrote:
> Allow passing NULL as audio infoframe as a way to disable Audio
> Infoframe generation.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 14 ++
> 1 file changed, 10
On Mon, Mar 11, 2024 at 05:55:36PM +0200, Dmitry Baryshkov wrote:
> On Mon, 11 Mar 2024 at 17:46, Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Sat, Mar 09, 2024 at 12:31:32PM +0200, Dmitry Baryshkov wrote:
> > > Setup the HDMI connector on the MSM HDMI outputs.
Hi,
On Sat, Mar 09, 2024 at 12:31:32PM +0200, Dmitry Baryshkov wrote:
> Setup the HDMI connector on the MSM HDMI outputs. Make use of
> atomic_check hook and of the provided Infoframe infrastructure.
>
> Note: for now only AVI Infoframes are enabled. Audio Infoframes are
> currenly handled
Hi,
On Sat, Mar 09, 2024 at 12:31:27PM +0200, Dmitry Baryshkov wrote:
> This patchset sits on top Maxime's HDMI connector patchset ([1]).
>
> Currently this is an RFC exploring the interface between HDMI bridges
> and HDMI connector code. This has been lightly verified on the Qualcomm
> DB820c,
Hi,
On Sat, Mar 09, 2024 at 12:31:29PM +0200, Dmitry Baryshkov wrote:
> To support connectors which do all the management on their own (like
> drm_bridge_connector), add drm_connector_hdmi_init() in addition to
> drmm_connector_hdmi_init().
>
> Signed-off-by: Dmitry Baryshkov
That's only
On Fri, Mar 08, 2024 at 12:52:04PM +0200, Dmitry Baryshkov wrote:
> On Fri, 8 Mar 2024 at 11:44, Maxime Ripard wrote:
> >
> > Hi Dmitry,
> >
> > Thanks a lot for working on that, it's greatly appreciated :)
> >
> > On Fri, Mar 08, 2024 at 01:57:02AM +0200,
Hi Dmitry,
Thanks a lot for working on that, it's greatly appreciated :)
On Fri, Mar 08, 2024 at 01:57:02AM +0200, Dmitry Baryshkov wrote:
> In order to use HDMI connector extensions from the bridge drivers, carve
> out the drm_connector_hdmi_setup() from drmm_connector_hdmi_init(). This
> way
Hi Dmitry,
On Sun, Feb 25, 2024 at 04:50:00PM +0200, Dmitry Baryshkov wrote:
> On Thu, 22 Feb 2024 at 20:14, Maxime Ripard wrote:
> > Here's a series that creates some extra infrastructure specifically
> > targeted at HDMI controllers.
> >
> > The idea behind thi
On Thu, Jan 25, 2024 at 07:17:21PM +0100, Daniel Vetter wrote:
> On Tue, Jan 23, 2024 at 06:09:05AM +, Jason-JH Lin (林睿祥) wrote:
> > Hi Maxime, Daniel,
> >
> > We encountered similar issue with mediatek SoCs.
> >
> > We have found that in drm_atomic_helper_commit_rpm(), when disabling
> >
On Fri, 08 Dec 2023 04:03:14 +0300, Dmitry Baryshkov wrote:
> As the renamed drm_atomic_helper_check_wb_connector_state() now accepts
> drm_writeback_connector as the first argument (instead of drm_encoder),
> move the VKMS writeback atomic_check from drm_encoder_helper_funcs to
>
On Fri, 08 Dec 2023 04:03:13 +0300, Dmitry Baryshkov wrote:
> The drm_atomic_helper_check_wb_encoder_state() function doesn't use
> encoder for anything other than getting the drm_device instance. The
> function's description talks about checking the writeback connector
> state, not the encoder
Hi,
On Wed, Dec 06, 2023 at 01:14:54PM +0300, Dmitry Baryshkov wrote:
> The drm_atomic_helper_check_wb_encoder_state() function doesn't use
> encoder for anything other than getting the drm_device instance. The
> function's description talks about checking the writeback connector
> state, not the
Hi Mark,
On Tue, Dec 05, 2023 at 04:13:41PM +, Mark Brown wrote:
> On Sun, Dec 03, 2023 at 02:53:13PM +0300, Dmitry Baryshkov wrote:
>
> > Each of connectors and CRTCs used by the DRM device provides debugfs
> > directory, which is used by several standard debugfs files and can
> > further
On Tue, Dec 05, 2023 at 03:37:15AM +0200, Dmitry Baryshkov wrote:
> On 04/12/2023 10:38, Maxime Ripard wrote:
> > On Sat, Dec 02, 2023 at 12:07:49AM +0200, Dmitry Baryshkov wrote:
> > > The drm_atomic_helper_check_wb_encoder_state() function doesn't use
> > > enco
Hi,
On Fri, Oct 27, 2023 at 03:32:57PM -0700, Jessica Zhang wrote:
> Loosen the requirements for atomic and legacy commit so that, in cases
> where pixel_source != FB, the commit can still go through.
>
> This includes adding framebuffer NULL checks in other areas to account for
> FB being NULL
lementation nor
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Sun, Dec 03, 2023 at 08:10:31PM +0200, Dmitry Baryshkov wrote:
> On Sun, 3 Dec 2023 at 14:15, Simon Ser wrote:
> >
> > On Saturday, December 2nd, 2023 at 22:41, Dmitry Baryshkov
> > wrote:
> >
> > > On Fri, 27 Oct 2023 15:32:50 -0700, Jessica Zhang wrote:
> > >
> > > > Some drivers support
r *encoder);
> +void drm_debugfs_encoder_remove(struct drm_encoder *encoder);
> #else
> static inline void drm_debugfs_dev_fini(struct drm_device *dev)
> {
> @@ -231,6 +233,13 @@ static inline void drm_debugfs_crtc_crc_add(struct
> drm_crtc *crtc)
> {
> }
>
> +static inline void drm_debugfs_encoder_add(struct drm_encoder *encoder)
> +{
> +}
<- You need to insert a new line here.
Once fixed,
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
> output and into debugfs/dri/N/state file.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Sun, 03 Dec 2023 01:55:52 +0300, Dmitry Baryshkov wrote:
> In case the drm_modeset_register_all() function fails, its error code
> will be ignored. Instead make the drm_dev_register() bail out in case of
> such an error.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Sat, Dec 02, 2023 at 12:07:49AM +0200, Dmitry Baryshkov wrote:
> The drm_atomic_helper_check_wb_encoder_state() function doesn't use
> encoder for anything other than getting the drm_device instance. The
> function's description talks about checking the writeback connector
> state, not the
Hi,
Thanks for your answer
On Tue, Nov 07, 2023 at 04:26:34PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 07, 2023 at 01:18:14PM +0100, Maxime Ripard wrote:
> > On Tue, Nov 07, 2023 at 12:22:21PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Nov 07, 2023 at 11:57:49AM +0
On Tue, Nov 07, 2023 at 12:22:21PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 07, 2023 at 11:57:49AM +0100, Maxime Ripard wrote:
> > +GKH
>
> Why? I don't see a question for me here, sorry.
I guess the question is: we have a bus with various power states
(powered off, low po
+GKH
On Thu, Oct 26, 2023 at 11:41:34AM +0300, Dmitry Baryshkov wrote:
> > > > Also, we would still need to update every single panel driver, which is
> > > > going to create a lot of boilerplate that people might get wrong.
> > >
> > > Yes, quite unfortunately. Another approach that I have in
On Sun, 08 Oct 2023 16:23:19 +0300, Dmitry Baryshkov wrote:
> In case of the merge requests it might be useful to push repo-specific
> fixes which have not yet propagated to the -external-fixes branch in the
> main UPSTREAM_REPO. For example, in case of drm/msm development, we are
> staging fixes
On Wed, Oct 25, 2023 at 06:16:14PM +0300, Dmitry Baryshkov wrote:
> On 25/10/2023 15:44, Maxime Ripard wrote:
> > On Thu, Oct 19, 2023 at 02:19:51PM +0300, Dmitry Baryshkov wrote:
> > > On Thu, 19 Oct 2023 at 12:26, Maxime Ripard wrote:
> > > >
> > > >
On Thu, Oct 19, 2023 at 02:19:51PM +0300, Dmitry Baryshkov wrote:
> On Thu, 19 Oct 2023 at 12:26, Maxime Ripard wrote:
> >
> > On Mon, Oct 16, 2023 at 07:53:48PM +0300, Dmitry Baryshkov wrote:
> > > The MIPI DSI links do not fully fall into the DRM callbacks model.
>
On Mon, Oct 16, 2023 at 07:53:48PM +0300, Dmitry Baryshkov wrote:
> The MIPI DSI links do not fully fall into the DRM callbacks model.
Explaining why would help
> The drm_bridge_funcs abstraction.
Is there a typo or missing words?
> Instead of having just two states (off and on) the DSI hosts
; private objects") this is no longer required, as the DRM framework
> handles private objects internally. Drop these custom locks, while also
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
On Wed, Sep 06, 2023 at 03:53:14PM +0300, Laurent Pinchart wrote:
> On Wed, Sep 06, 2023 at 03:48:35PM +0300, Dmitry Baryshkov wrote:
> > On Wed, 6 Sept 2023 at 15:44, Heikki Krogerus wrote:
> > > On Tue, Sep 05, 2023 at 01:56:59PM +0300, Dmitry Baryshkov wrote:
> > > > On Tue, 5 Sept 2023 at
On Thu, Jul 13, 2023 at 04:14:55PM +0100, Tvrtko Ursulin wrote:
>
> On 13/07/2023 16:09, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 13.07.23 um 16:41 schrieb Sean Paul:
> > > On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
> > > wrote:
> > > >
> > > > hello Sean,
> > > >
> > > > On Wed, Jul
On Wed, Jul 12, 2023 at 03:38:03PM +0200, Uwe Kleine-König wrote:
> Hello Maxime,
>
> On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
> > On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > > > Background is that this makes merge
On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > Background is that this makes merge conflicts easier to handle and detect.
>
> Really?
FWIW, I agree with Christian here.
> Each file (apart from include/drm/drm_crtc.h) is only touched once. So
> unless I'm missing something
On Thu, Jul 06, 2023 at 09:33:15AM +0200, Neil Armstrong wrote:
> 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
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 wrote:
> > > >
> > > >
On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote:
> On Wed, 5 Jul 2023 at 17:24, Maxime Ripard wrote:
> >
> > On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote:
> > > > > >
> > > > > > Either wa
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
>
On Wed, Jul 05, 2023 at 03:05:33PM +0200, Neil Armstrong wrote:
> On 05/07/2023 14:04, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, May 30, 2023 at 03:36:04PM +0300, Dmitry Baryshkov wrote:
> > > On 30/05/2023 15:15, AngeloGioacchino Del Regno wrote:
> > > &
Hi,
On Tue, May 30, 2023 at 03:36:04PM +0300, Dmitry Baryshkov wrote:
> On 30/05/2023 15:15, AngeloGioacchino Del Regno wrote:
> > Il 30/05/23 13:44, Dmitry Baryshkov ha scritto:
> > > On Tue, 30 May 2023 at 10:24, Neil Armstrong
> > > wrote:
> > > >
> > > > Hi Marijn, Dmitry, Caleb, Jessica,
>
On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> CC sfr
>
> On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard wrote:
> > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > > On Mon, Jun 19, 2023 at 11:45:3
On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > Hello Maxime,
> > >
> > > On Sun, Jun 18, 2023 at 0
On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> Hello Maxime,
>
> On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > On Sat, Jun 17, 2023 at 10:57:23AM -0
On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> Hello Doug,
>
> On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > wrote:
> > >
> > > [expanding recipents by the other affected persons]
> > >
> > > On Thu,
g report.
Thanks for submitting that patch. It's been in the downstream RPi tree
for a while, so I'd really like it to be merged eventually :)
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Thu, 10 Nov 2022 17:44:45 +0800, Gaosheng Cui wrote:
> The drm_atomic_get_new_private_obj_state() function returns NULL
> on error path, drm_atomic_get_old_private_obj_state() function
> returns NULL on error path, too, they does not return error pointers.
>
> By the way,
On Fri, Jul 29, 2022 at 12:57:40PM -0700, Doug Anderson wrote:
> Hi,
>
> On Fri, Jul 29, 2022 at 9:41 AM Maxime Ripard wrote:
> >
> > On Fri, Jul 29, 2022 at 07:50:20AM -0700, Doug Anderson wrote:
> > > On Fri, Jul 29, 2022 at 12:51 AM Maxime Ripard wrote:
> &
On Fri, Jul 29, 2022 at 07:50:20AM -0700, Doug Anderson wrote:
> On Fri, Jul 29, 2022 at 12:51 AM Maxime Ripard wrote:
> >
> > On Thu, Jul 28, 2022 at 02:18:38PM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, Jul 28, 2022 at 10:34 AM Abhinav
On Thu, Jul 28, 2022 at 02:18:38PM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Jul 28, 2022 at 10:34 AM Abhinav Kumar
> wrote:
> >
> > Hi Rob and Doug
> >
> > On 7/22/2022 10:36 AM, Rob Clark wrote:
> > > On Fri, Jul 22, 2022 at 9:48 AM Doug Anderson
> > > wrote:
> > >>
> > >> Hi,
> > >>
> >
On Fri, Jun 03, 2022 at 07:56:16AM -0700, Doug Anderson wrote:
> Hi,
>
> On Fri, Jun 3, 2022 at 7:14 AM Maxime Ripard wrote:
> >
> > On Fri, Jun 03, 2022 at 01:19:16PM +0300, Dmitry Baryshkov wrote:
> > > On Fri, 3 Jun 2022 at 11:21, Maxime Ripard wrote:
> &
On Fri, Jun 03, 2022 at 06:52:05AM -0700, Doug Anderson wrote:
> On Fri, Jun 3, 2022 at 3:19 AM Dmitry Baryshkov
> wrote:
> > On Fri, 3 Jun 2022 at 11:21, Maxime Ripard wrote:
> > >
> > > On Tue, May 31, 2022 at 02:06:34PM -0700, Doug Anderson wrote:
> > >
On Fri, Jun 03, 2022 at 01:19:16PM +0300, Dmitry Baryshkov wrote:
> On Fri, 3 Jun 2022 at 11:21, Maxime Ripard wrote:
> >
> > On Tue, May 31, 2022 at 02:06:34PM -0700, Doug Anderson wrote:
> > > On Mon, May 23, 2022 at 10:00 AM Doug Anderson
> > > wrote:
> &
On Tue, May 31, 2022 at 02:06:34PM -0700, Doug Anderson wrote:
> On Mon, May 23, 2022 at 10:00 AM Doug Anderson wrote:
> > On Sat, May 21, 2022 at 2:17 AM Maxime Ripard wrote:
> > > On Tue, May 10, 2022 at 12:29:43PM -0700, Douglas Anderson wrote:
> > > > Th
Hi,
On Tue, May 10, 2022 at 12:29:43PM -0700, Douglas Anderson wrote:
> This adds a devm managed version of drm_bridge_add(). Like other
> "devm" function listed in drm_bridge.h, this function takes an
> explicit "dev" to use for the lifetime management. A few notes:
> * In general we have a
Hi,
On Thu, Apr 21, 2022 at 07:49:12PM -0700, Stephen Boyd wrote:
> +Maxime
>
> Quoting Dmitry Baryshkov (2022-04-19 16:54:47)
> > Since the commit 948fb0969eae ("clk: Always clamp the rounded rate"),
> > the clk_core_determine_round_nolock() would clamp the requested rate
> > between min and
On Mon, 21 Feb 2022 10:59:08 +0100, Maxime Ripard wrote:
> The mdp KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane purpose.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in m
this is not needed anymore.
Cc: freedreno@lists.freedesktop.org
Cc: linux-arm-...@vger.kernel.org
Cc: Abhinav Kumar
Cc: Rob Clark
Cc: Sean Paul
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 16
1 file changed, 8
On Mon, Feb 21, 2022 at 08:33:39AM +0100, José Expósito wrote:
> The function "drm_of_find_panel_or_bridge" has been deprecated in
> favor of "devm_drm_of_get_bridge".
>
> Switch to the new function and reduce boilerplate.
>
> Signed-off-by: José Expósito
Hi,
On Mon, Feb 07, 2022 at 10:27:24PM +0300, Dmitry Baryshkov wrote:
> On Mon, 7 Feb 2022 at 19:56, Maxime Ripard wrote:
> >
> > While the mdp5_plane_install_properties() function calls
> > drm_plane_create_zpos_property() with an initial value of 1,
> > md
in the drm_plane_create_zpos_property() call.
Cc: freedreno@lists.freedesktop.org
Cc: linux-arm-...@vger.kernel.org
Cc: Abhinav Kumar
Cc: Rob Clark
Cc: Sean Paul
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers
this is not needed anymore.
Cc: freedreno@lists.freedesktop.org
Cc: linux-arm-...@vger.kernel.org
Cc: Abhinav Kumar
Cc: Rob Clark
Cc: Sean Paul
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm
On Fri, Oct 29, 2021 at 10:36:00AM +0200, Marek Szyprowski wrote:
> Hi Mexime,
>
> On 29.10.2021 10:05, Maxime Ripard wrote:
> > On Fri, Oct 29, 2021 at 08:23:45AM +0200, Marek Szyprowski wrote:
> >> On 25.10.2021 17:15, Maxime Ripard wrote:
> >>> In ord
Hi Marek,
On Fri, Oct 29, 2021 at 08:23:45AM +0200, Marek Szyprowski wrote:
> Hi,
>
> On 25.10.2021 17:15, Maxime Ripard wrote:
> > In order to avoid any probe ordering issue, the best practice is to move
> > the secondary MIPI-DSI device registration and attachment to
On Mon, 25 Oct 2021 17:15:36 +0200, Maxime Ripard wrote:
> From: Rob Clark
>
> Switch to the documented order dsi-host vs bridge probe.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:35 +0200, Maxime Ripard wrote:
> Without proper care and an agreement between how DSI hosts and devices
> drivers register their MIPI-DSI entities and potential components, we can
> end up in a situation where the drivers can never probe.
>
> Most driv
On Mon, 25 Oct 2021 17:15:34 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc
On Mon, 25 Oct 2021 17:15:33 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device. This also avoids leaking the device when we detach
> the bridge.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:32 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc
On Mon, 25 Oct 2021 17:15:31 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device. This also avoids leaking the device when we detach
> the bridge.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:30 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc
On Mon, 25 Oct 2021 17:15:29 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device. This also avoids leaking the device when we detach
> the bridge but don't remove its driver.
>
>
Applied to drm/drm-misc
On Mon, 25 Oct 2021 17:15:28 +0200, Maxime Ripard wrote:
> Commit 24417d5b0c00 ("drm/bridge: ti-sn65dsi83: Implement .detach
> callback") moved the unregistration of the bridge DSI device and bridge
> itself to the detach callback.
>
> While this is correct
On Mon, 25 Oct 2021 17:15:27 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc
On Mon, 25 Oct 2021 17:15:26 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device. This also avoids leaking the device on removal.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:25 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc
On Mon, 25 Oct 2021 17:15:24 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:23 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc
1 - 100 of 221 matches
Mail list logo
