Hi Daniel,
Thank you for the patch.
On Fri, Oct 23, 2020 at 02:21:25PM +0200, Daniel Vetter wrote:
> Ends right after drm_atomic_helper_commit_hw_done(), absolutely
> nothing fancy going on here.
>
> Signed-off-by: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
&
Hi Thomas,
Thank you for the patch.
On Thu, Jun 24, 2021 at 09:29:05AM +0200, Thomas Zimmermann wrote:
> The field drm_device.irq_enabled is only used by legacy drivers
> with userspace modesetting. Don't set it in rcar-du.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by:
Hi Thomas,
Thank you for the patch.
On Thu, Jun 24, 2021 at 09:29:13AM +0200, Thomas Zimmermann wrote:
> The field drm_device.irq_enabled is only used by legacy drivers
> with userspace modesetting. Don't set it in vkms.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by:
his will also conflict with ongoing drmP.h cleanup by others I
> expect.
>
> v3: Rebase on top of atomic bochs.
>
> Cc: Sam Ravnborg
> Cc: Jani Nikula
> Cc: Laurent Pinchart
> Acked-by: Rodrigo Vivi (v2)
> Acked-by: Benjamin Gaignard (v2)
> Signed-off-by
sn't this slightly
more inefficient ?
> Changes in v3:
> - Added to the set
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Ben Skeggs
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Eric Anho
Hi Sean,
On Mon, May 13, 2019 at 10:38:58AM -0400, Sean Paul wrote:
> On Sat, May 11, 2019 at 3:12 PM Laurent Pinchart wrote:
> > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> >> From: Sean Paul
> >>
> >> Everyone who implements connecto
Hi Daniel,
On Mon, May 13, 2019 at 04:47:47PM +0200, Daniel Vetter wrote:
> On Sat, May 11, 2019 at 10:12:02PM +0300, Laurent Pinchart wrote:
> > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> >> From: Sean Paul
> >>
> >> Everyone w
value bits 7:0 of the G or Y component
> > + * DB[5]: CRC value bits 15:8 of the G or Y component
> > + * DB[6]: CRC value bits 7:0 of the B or Cb component
> > + * DB[7]: CRC value bits 15:8 of the B or Cb component
> > + * DB[8] - DB[31]: Reserved
> > + * VSC SDP Pay
changes
would be quite intrusive. Long term major changes will be needed there
anyway as it makes no sense to have to frameworks with similar purposes
in DRM/KMS and V4L2.
> + */
> +
> +/**
> * drm_dev_init - Initialise new DRM device
> * @dev: DRM device
> * @driver: DRM driver
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
state.
I don't think the second sentence applies to this patch.
> Signed-off-by: Maarten Lankhorst
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: linux-renesas-...@vger.kernel.org
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 11 +++
> 1 file changed, 3 inse
Hi Marteen,
On Fri, Mar 01, 2019 at 03:08:20PM +0100, Maarten Lankhorst wrote:
> Op 01-03-2019 om 14:13 schreef Laurent Pinchart:
> > On Fri, Mar 01, 2019 at 01:56:22PM +0100, Maarten Lankhorst wrote:
> >> Convert rcar-du to using __drm_atomic_helper_crtc_reset(), instead of
&g
Hi Marteen,
On Fri, Mar 01, 2019 at 03:47:02PM +0100, Maarten Lankhorst wrote:
> Op 01-03-2019 om 15:36 schreef Laurent Pinchart:
> > On Fri, Mar 01, 2019 at 03:08:20PM +0100, Maarten Lankhorst wrote:
> >> Op 01-03-2019 om 14:13 schreef Laurent Pinchart:
> >>> On F
Hi Ville,
On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote:
> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
> > On 03.12.2018 22:38, Ville Syrjälä wrote:
> >> On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote:
> >>> On 21.1
Hi Andrzej,
On Wednesday, 5 December 2018 10:46:40 EET Andrzej Hajda wrote:
> On 05.12.2018 07:32, Laurent Pinchart wrote:
> > On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote:
> >> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
> >>> On 0
avoid including drm_device.h by un-inlining (Daniel)
It would be nice to explain why you de-inline the function (I assume because
it's a bit too large).
Reviewed-by: Laurent Pinchart
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Signed-off-by: Jani Nikula
> ---
to make drm_file.h self-contained."
Reviewed-by: Laurent Pinchart
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Signed-off-by: Jani Nikula
> ---
> include/drm/drm_file.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/drm/drm
luding
linux/kernel.h. This prepares for dropping drmP.h from files including
drm_hdcp.h."
Reviewed-by: Laurent Pinchart
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Signed-off-by: Jani Nikula
> ---
> include/drm/drm_hdcp.h | 2 ++
> 1 file changed, 2
Hi Jani,
Thank you for the patch.
On Friday, 28 December 2018 10:28:15 EET Jani Nikula wrote:
> Make it easier to drop drmP.h includes. Switch from "" to <> includes
> while at it.
>
> v2: forward declare instead of including drm_file.h (Daniel)
Reviewed-by: Lau
It's also included in drm-tip now.
>
> So I did this *before* I got the review feedback from Laurent, based on
> Daniel's review only. Would you all like me to redo the branch with
> Laurent's comments addressed and r-b added?
If you think my comments are valuable, th
nector_get_single_encoder to drm_kms_helper module
>
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: dri-de...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: José Roberto
quot;
> #include "intel_frontbuffer.h"
>
> -#include "intel_drv.h"
> -#include "intel_dsi.h"
> -#include "intel_frontbuffer.h"
> -
> -#include "i915_drv.h"
> -#include "i915_gem_clflush.h"
&g
ch/msgid/20190508160920.144739-5-s...@poorly.run
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Ben Skeggs
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Eric Anholt
> Tested-by: Heiko Stueb
g this.
>
> Fixes: 6f3b62781bbd ("drm: Convert connector_helper_funcs->atomic_check to
> accept drm_atomic_state")
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Ben Skeggs
> Cc: Laurent Pin
Hi Daniel,
Thank you for the patch.
On Fri, Jun 14, 2019 at 10:35:42PM +0200, Daniel Vetter wrote:
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter
> Cc: Laurent Pinchart
Hi Daniel,
Thank you for the patch.
On Fri, Jun 14, 2019 at 10:35:44PM +0200, Daniel Vetter wrote:
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter
> Cc: Laurent Pinchart
>
> Link:
> https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
> Signed-off-by: Wolfram Sang
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/amd/amdgpu/atom.c | 2 +-
> drivers/gpu/drm/amd/pm/legacy-dpm/leg
rivers/gpu/drm/i915/i915_pci.c | 7 +-
> > drivers/gpu/drm/i915/i915_reg.h | 139 +++
> > 15 files changed, 1742 insertions(+), 3 deletions(-) create mode 100644
> > drivers/gpu/drm/i915/display/intel_wb_connector.c
> > create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
> > create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
> > create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h
--
Regards,
Laurent Pinchart
py(&mode, E, S)
> + drm_mode_copy(&mode, E)
> )
>
> @@
> struct drm_display_mode *mode;
> @@
> - &*mode
> + mode
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej
Hi Dmitry,
On Tue, Feb 22, 2022 at 06:32:50AM +0300, Dmitry Baryshkov wrote:
> On Thu, 10 Feb 2022 at 07:59, Laurent Pinchart wrote:
> > On Wed, Feb 09, 2022 at 05:40:29PM -0800, Abhinav Kumar wrote:
> > > Hi Laurent
> > >
> > > Gentle reminder on this.
> &
DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
capability to get the writeback connectors exposed by the kernel, but
more than that, a large refactoring is then often needed to chase all
code paths that assume a connector is a connector.
I'm afraid the same applies to the kernel. Drivers that don&#
Hi Rob,
On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
> > On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > > On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> > >> On Wed, 02 Fe
Hi Dmitry,
On Mon, Feb 28, 2022 at 11:07:41AM +0300, Dmitry Baryshkov wrote:
> On Mon, 28 Feb 2022 at 11:00, Laurent Pinchart wrote:
> > On Sat, Feb 26, 2022 at 05:10:06AM +, Kandpal, Suraj wrote:
> > > Hi Abhinav,
> > >
> > > > Based on the discus
Hi Jani,
On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> On Mon, 28 Feb 2022, Laurent Pinchart wrote:
> > On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> >> On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
> >> > On Wed, 02 Feb 2022, Laure
Hello,
On Mon, Feb 28, 2022 at 02:28:27PM +0200, Laurent Pinchart wrote:
> On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> > On Mon, 28 Feb 2022, Laurent Pinchart wrote:
> > > On Sat, Feb 26, 2022 at 10:27:59AM -0800, Rob Clark wrote:
> > >> On We
Hi Abhinav,
On Wed, Mar 02, 2022 at 10:28:03AM -0800, Abhinav Kumar wrote:
> On 2/28/2022 5:42 AM, Laurent Pinchart wrote:
> > On Mon, Feb 28, 2022 at 02:28:27PM +0200, Laurent Pinchart wrote:
> >> On Mon, Feb 28, 2022 at 02:09:15PM +0200, Jani Nikula wrote:
> >>>
gt;ddev, wb_conn,
> @@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
> struct drm_framebuffer *fb;
> unsigned int i;
>
> - state = rcrtc->writeback.base.state;
> + state = rcrtc->writeback.base->state;
> if (!state || !state->writeback_job)
> return;
>
--
Regards,
Laurent Pinchart
Hi Jani,
On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> >> Changing rcar_du driver to accomadate the change of
> >> drm_w
, Dmitry Baryshkov wrote:
> >> On Wed, 2 Feb 2022 at 16:26, Laurent Pinchart
> >> wrote:
> >>>
> >>> Hi Jani,
> >>>
> >>> On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> >>>> On Wed, 02 Feb 2022, Laurent P
gt; >> + return -EINVAL;
> >> +
> >> + if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
> >> + ptr[1] != 1 ||
> >> + ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
> >> + return -EINVAL;
> >> +
>
I can't rely
on drmm_* to release them in all cases, as the error path may be hit
before touching anything drm-related.
Until we figure out a good way forward and test it on a significant
number of drivers, let's not add WARN_ON() that will be hit with the
majority of drive
Hi Daniel,
On Thu, Apr 02, 2020 at 07:17:40AM +0200, Daniel Vetter wrote:
> On Thu, Apr 2, 2020 at 2:50 AM Laurent Pinchart wrote:
> > On Mon, Mar 23, 2020 at 03:49:18PM +0100, Daniel Vetter wrote:
> > > A few things:
> > > - Update the example driver in the documentati
_vrefresh(E) ? drm_mode_vrefresh(E) : drm_mode_vrefresh(E)
> + drm_mode_vrefresh(E)
>
> @find_substruct@
> identifier X;
> identifier S;
> @@
> struct X {
> ...
> struct drm_display_mode S;
> ...
> };
>
> @@
> identifier find_substruct.S;
> expression E;
> ident
her interface towards userspace ? If
the other related subsystem also required allocation of the driver
private structure through its corresponding API, we'd be stuck. As
stated before, I want this API to be optional.
> Cc: Paul Kocialkowski
> Cc: Laurent Pinchart
> Signed-off-by: Dani
nderstand from the information about that i915 does, but is that
usual ? Could there be drivers that really on this check to reject
modifier changes, and that aren't prepared to handle them if they are
not rejected by the core ? I'm not opposed to this change, but I'd like
to carefull
in the connector's sysfs directory to
expose the I2C adapter used by the connector."
Should we also mention that the field isn't meant to be set directly,
but shall be set with drm_connector_init_with_ddc() ?
"This field shall not be set directly by drivers, use
drm_connector_i
Hi Andrzej,
On Sun, Aug 04, 2019 at 03:04:37PM +0300, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch, and sorry for the late review (I've been
> travelling for the past few weeks).
>
> On Fri, Jul 26, 2019 at 07:22:55PM +0200, Andrzej Pietrasiewicz wrot
> drivers/gpu/drm/rockchip/rk3066_hdmi.c| 7 +-
> drivers/gpu/drm/sti/sti_hdmi.c| 6 +-
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 7 +-
> drivers/gpu/drm/tegra/hdmi.c | 7 +-
> drivers/gpu/drm/tegra/sor.c
-
> > drivers/gpu/drm/rockchip/rk3066_hdmi.c| 7 +-
> > drivers/gpu/drm/sti/sti_hdmi.c| 6 +-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 7 +-
> > drivers/gpu/drm/tegra/hdmi.c
river is enabled? I think that would take care of
> all this.
>
> Or too annoying for development?
>
> Also note that fbdev is in drm-misc now, so we should be able to fix
> this all without cross-tree conflicts.
Note that drivers/video/fbdev/omap2/omapfb/ will stay, it's
drivers/gpu/drm/omapdrm/displays/ that is being removed. FB_OMAP2
already depends on DRM_OMAP = n, I propose doing something similar at
the level of the individual display drivers.
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ues here? Any ideas/suggestions?
No, uvcvideo seems completely reunlated.
> >> @intel-gfx: any ideas about what is going on here with the i915 driver?
> >>
> >> Original message to lkml:
> >> https://lore.kernel.org/lkml/CAONH+Jm-O6=dq+k2n5pntnmg2sq1kcvnfluwevh6w82opef...@mail.gmail.com/T/#u
> >>
> >> Previous message for 5.1.21 kernel:
> >> https://lore.kernel.org/lkml/CAONH+JkTFujY9vEyNNuem+9rJ2qBKkf-PbKk9=DBSVEp6kW=y...@mail.gmail.com/
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, Aug 16, 2019 at 12:47:15PM +0300, Laurent Pinchart wrote:
> On Fri, Aug 16, 2019 at 08:23:54AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 16, 2019 at 6:48 AM Sam Ravnborg wrote:
> > > > Hi all,
> > > >
> > > > After merging the dr
working with - when the drm_bridge is attached.
> Likewise, we unregister the AUX adapter on bridge detachment by adding a
> ti_sn_bridge_detach() callback.
>
> Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 18 +
@name: user-visible name of this AUX channel and the I2C-over-AUX adapter
> * @ddc: I2C adapter that can be used for I2C-over-AUX communication
> * @dev: pointer to struct device that is the parent for this AUX channel
> + * @drm_dev: pointer to the &drm_device that owns thi
Hi Lyude,
Thank you for the patch.
On Fri, Feb 19, 2021 at 04:53:15PM -0500, Lyude Paul wrote:
> So that we can start using drm_dbg_*() in
> drm_dp_link_train_clock_recovery_delay().
>
> Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
> ---
> drivers/
Hi Lyude,
Thank you for the patch.
On Fri, Feb 19, 2021 at 04:53:16PM -0500, Lyude Paul wrote:
> So that we can start using drm_dbg_*() for
> drm_dp_link_train_channel_eq_delay() and
> drm_dp_lttpr_link_train_channel_eq_delay().
>
> Signed-off-by: Lyude Paul
Reviewed-by: L
time. Should
these (and likely other) drivers be updated ?
Other than that the patch looks good to me,
Reviewed-by: Laurent Pinchart
> Only call left is in i915, which doesn't use drm_mode_config_reset,
> but has its own fastboot infrastructure. So that's the only case where
&
fected
> by this change to atomic helpers.
>
> v2: Use the drm_dev_has_vblank() helper.
>
> v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
> instead of drm_crtc_vblank_reset. Adjust them too.
>
> Cc: Laurent Pinchart
&g
e the drm_dev_has_vblank() helper.
>
> v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
> instead of drm_crtc_vblank_reset. Adjust them too.
>
> v4: Laurent noticed that rcar-du and omap open-code their crtc reset
> and hence would actually be broken by this pa
would be nice to expand the commit message to
give some more context, and especially explain why ending signalling
right after drm_atomic_helper_commit_hw_done() is the right option.
I suppose I'll have to check the whole series in the meantime :-)
> Signed-off-by: Daniel Vetter
> Cc:
e commit message, with at
least a brief explanation of why this is correct, and what the
consequences here ?
>
> .fops = &zynqmp_dpsub_drm_fops,
>
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
e);
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.h
> b/drivers/gpu/drm/omapdrm/omap_gem.h
> index 729b7812a815..9e6b5c8195d9 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.h
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.h
> @@ -69,7 +69,6 @@ struct dma_buf *omap_gem_prime_export(
gt; Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 14 +-
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> in
letter was sent only to dri-devel and intel-gfx, many
> recipients of the patches won't have received it...
> https://lore.kernel.org/dri-devel/20200219102122.1607365-1-daniel.vet...@ffwll.ch/
I was also going to mention that it would be nice to send the cover
letter to all recip
+ __drmm_add_action(dev, action, data, #action)
> +
> +int __must_check __drmm_add_action(struct drm_device *dev,
> + drmres_release_t action,
> +void *data, const char *name);
> +
> +void drmm_add_final_kfree(struct drm_device *dev, void *parent);
> +
> +void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp) __malloc;
> +static inline void *drmm_kzalloc(struct drm_device *dev, size_t size, gfp_t
> gfp)
> +{
> + return drmm_kmalloc(dev, size, gfp | __GFP_ZERO);
> +}
> +
> +void drmm_kfree(struct drm_device *dev, void *data);
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index ca7cee8e728a..1c9417430d08 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -313,6 +313,10 @@ enum drm_debug_category {
>* @DRM_UT_DP: Used in the DP code.
>*/
> DRM_UT_DP = 0x100,
> + /**
> + * @DRM_UT_DRMRES: Used in the drm managed resources code.
> + */
> + DRM_UT_DRMRES = 0x200,
> };
>
> static inline bool drm_debug_enabled(enum drm_debug_category category)
> @@ -442,6 +446,8 @@ void drm_dev_dbg(const struct device *dev, enum
> drm_debug_category category,
> drm_dev_dbg((drm)->dev, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
> #define drm_dbg_dp(drm, fmt, ...)\
> drm_dev_dbg((drm)->dev, DRM_UT_DP, fmt, ##__VA_ARGS__)
> +#define drm_dbg_drmres(drm, fmt, ...)
> \
> + drm_dev_dbg((drm)->dev, DRM_UT_DRMRES, fmt, ##__VA_ARGS__)
>
>
> /*
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
v_init(struct xen_drm_front_info
> *front_info)
> fail_modeset:
> drm_kms_helper_poll_fini(drm_dev);
> drm_mode_config_cleanup(drm_dev);
> + drm_dev_put(drm_dev);
> fail:
> kfree(drm_info);
> return ret;
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
gt;drm);
> - kfree(udl);
> + drm_dev_put(&udl->drm);
> return ERR_PTR(r);
> }
>
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
mode_config_cleanup() be called here ?
> }
> EXPORT_SYMBOL(drm_mode_config_init);
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 3bcbe30339f0..160a3e4b51c3 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.
atically, removing the need to do so in drivers ? Otherwise when
someone will look at the commit later, without having the full context
in mind, the reason why the call is dropped won't be immediately clear.
With this fixed,
Reviewed-by: Laurent Pinchart
This also applies to similar patches for
one for the rcar-du patch taken into
account,
Reviewed-by: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: linux-renesas-...@vger.kernel.org
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 --
> drivers/gpu/drm/sh
+ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include "vbox_drv.h"
>
> @@ -54,6 +55,7 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
lease_event(struct drm_device *dev);
> /* drm_gem.c */
> struct drm_gem_object;
> int drm_gem_init(struct drm_device *dev);
> -void drm_gem_destroy(struct drm_device *dev);
> int drm_gem_handle_create_tail(struct drm_file *file_priv,
> struct drm_gem_object *obj,
> u32 *handlep);
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--- a/include/drm/drm_managed.h
> +++ b/include/drm/drm_managed.h
> @@ -21,5 +21,6 @@ static inline void *drmm_kzalloc(struct drm_device *dev,
> size_t size, gfp_t gfp)
> {
> return drmm_kmalloc(dev, size, gfp | __GFP_ZERO);
> }
> +char *drmm_kstrdup(struct drm_device
drm_gem_destroy(dev);
>
> - drm_legacy_ctxbitmap_cleanup(dev);
> - drm_legacy_remove_map_hash(dev);
> - drm_fs_inode_free(dev->anon_inode);
> -
> drm_minor_free(dev, DRM_MINOR_PRIMARY);
> drm_minor_free(dev, DRM_MINOR_RENDER);
> -
> - pu
Hi Daniel,
On Wed, Feb 19, 2020 at 03:30:59PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 3:11 PM Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 11:20:49AM +0100, Daniel Vetter wrote:
> > > These are the leftover drivers that didn't have a ->release ho
ged.lock, flags);
> +
> + if (WARN_ON(!dr))
> + return;
> +
> + kfree(dr);
> +}
> +EXPORT_SYMBOL(drmm_remove_action);
> +
> void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp)
> {
> struct drmres *dr;
> diff --git a/include/drm/
Hi Daniel,
On Wed, Feb 19, 2020 at 03:37:46PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 3:22 PM Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 11:20:54AM +0100, Daniel Vetter wrote:
> > > We might want to look into pushing this down into drm_mm_init, but
>
+ * @dev: DRM device
> + * @size: 0 terminated string to be duplicated
s/0 terminated/0-terminated/
> + * @gfp: GFP allocation flags
> + *
> + * This is a &drm_device managed version of kmalloc_array(). The allocated
> + * memory is automatically freed on the final drm_dev_put() and works exactly
> + * like a memory allocation obtained by drmm_kmalloc().
> + */
> static inline void *drmm_kmalloc_array(struct drm_device *dev,
> size_t n, size_t size, gfp_t flags)
> +
> +/**
> + * drmm_kcalloc - &drm_device managed kcalloc()
> + * @dev: DRM device
> + * @size: 0 terminated string to be duplicated
Ditto.
> + * @gfp: GFP allocation flags
> + *
> + * This is a &drm_device managed version of kcalloc(). The allocated memory
> is
> + * automatically freed on the final drm_dev_put() and works exactly like a
> + * memory allocation obtained by drmm_kmalloc().
> + */
> {
> size_t bytes;
>
> @@ -41,6 +87,7 @@ static inline void *drmm_kcalloc(struct drm_device *dev,
> {
> return drmm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
> }
> +
> char *drmm_kstrdup(struct drm_device *dev, const char *s, gfp_t gfp);
>
> void drmm_kfree(struct drm_device *dev, void *data);
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Daniel,
On Wed, Feb 19, 2020 at 04:27:57PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 3:35 PM Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 11:20:52AM +0100, Daniel Vetter wrote:
> > > Well for the simple stuff at least, vblank, gem and minor cleanup I
>
Hi Daniel,
On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote:
> > > drm_mode_config_cleanup is idempotent, so no harm in calling this
> &
b 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote:
> >>>> On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote:
> >>>>> We have lots of these. And the cleanup code tends to be of dubious
> >>>>> quality. The biggest wrong pattern is t
Hi Daniel,
On Wed, Feb 19, 2020 at 05:53:59PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 5:46 PM Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote:
> >> On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote:
> >>>
Hi Greg,
On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote:
> > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote:
> > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote:
&
Hi Greg,
On Wed, Feb 19, 2020 at 07:19:32PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote:
> >> On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter w
e *bridge)
> {
> struct tc358764 *ctx = bridge_to_tc358764(bridge);
> - struct drm_device *drm = bridge->dev;
>
> drm_connector_unregister(&ctx->connector);
> drm_panel_detach(ctx->panel);
--
Regards,
Laurent Pinchart
_
nnectors anymore and are just dummy. Now we have no callers to these
> functions hence remove them.
>
> Signed-off-by: Pankaj Bharadiya
I like this :-)
Reviewed-by: Laurent Pinchart
> ---
> include/drm/drm_fb_helper.h | 21 -
> 1 file changed, 21
t@psr-suspend.
No need to reflow, you can keep the first list entry as-is and just
remove the next two. With this fixed,
Reviewed-by: Laurent Pinchart
> Level: Intermediate
>
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ector(struct
> drm_dp_mst_topology_mgr *mgr,
> static void
> nv50_mstm_register_connector(struct drm_connector *connector)
> {
> - struct nouveau_drm *drm = nouveau_drm(connector->dev);
> -
> drm_connector_register(connector);
> }
>
--
Regards,
Lau
hat great).
> >
> > Cc: Harry Wentland
> > Cc: Dhinakaran Pandiyan
> > Cc: Maarten Lankhorst
> > Cc: Ville Syrjälä
> > Cc: Laurent Pinchart
> > Cc: Rob Clark
> > Cc: Alex Deucher
> > Cc: Ben Skeggs
> > Signed-off-by: Daniel Vetter
> Cc: Dhinakaran Pandiyan
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
> Cc: Laurent Pinchart
> Cc: Rob Clark
> Cc: Alex Deucher
> Cc: Ben Skeggs
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst | 6 ++
> d
Hi Daniel,
On Tuesday, 19 December 2017 12:03:55 EET Daniel Vetter wrote:
> On Mon, Dec 18, 2017 at 06:13:46PM +0200, Laurent Pinchart wrote:
> > On Thursday, 14 December 2017 22:30:53 EET Daniel Vetter wrote:
> >> DK put some nice docs into the commit introducing driver priva
Hi Daniel,
On Tuesday, 19 December 2017 16:00:36 EET Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 03:33:57PM +0200, Laurent Pinchart wrote:
> > On Tuesday, 19 December 2017 12:03:55 EET Daniel Vetter wrote:
> > > On Mon, Dec 18, 2017 at 06:13:46PM +0200, Laurent Pinchart
#x27;s just replace
> all current use cases of drm_dev_unref() with drm_dev_put and remove
> the function itself.
>
> Coccinelle was used for mass-patching.
>
> Signed-off-by: Vaishali Thakkar
I love seeing deprecated functions go.
Reviewed-by: Laurent Pinchart
> ---
&g
| 6 +++---
> > drivers/gpu/drm/tve200/tve200_drv.c| 4 ++--
> > drivers/gpu/drm/udl/udl_drv.c | 2 +-
> > drivers/gpu/drm/vc4/vc4_drv.c | 4 ++--
> > drivers/gpu/drm/vgem/vgem_drv.c|
olerate absence of 8-bit format
>
> lib/igt_gt.c | 24 ++--
> lib/igt_pm.c | 2 +-
> tests/kms_addfb_basic.c | 33 ++---
> tests/kms_panel_fitting.c | 1 +
> tests/kms_plane_lowres.c | 1 +
rm-misc-next but not merged in
the drm tree yet.
Dave, how would you like to handle this ? I can rebase my drm/du/next branch
on top of your tree once you merge drm-misc-next and send a new pull request,
but I'd like to avoid missing the v4.18 merge window. Another option would be
to handle th
: "David (ChunMing) Zhou"
> Cc: Archit Taneja
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Russell King
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Rob Clark
> Cc: Ben Ske
Chris pointed out on irc that the grammar went a bit wrong here. I'll fix
> this to
>
> "As a freedesktop.org project, dri-devel, and the DRM community, follows
> the Contributor Covenant, ..."
s/follows/follow/ ?
Apart from that and the other small style and typo changes
mmon error code for failed to
> look up an object throughout drm, so let's use it in the cma helpers,
> too.
Regardless of which is best, it's true that ENOENT is used through the DRM
code, so
Reviewed-by: Laurent Pinchart
Someone should however mention that this changes the
on
> the default) let's unexport it.
>
> Signed-off-by: Daniel Vetter
> Cc: Gustavo Padovan
> Cc: Maarten Lankhorst
> Cc: Sean Paul
> Cc: David Airlie
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Archit Taneja
> Cc: Neil A
Hi Daniel,
On Wednesday, 3 October 2018 12:08:38 EEST Daniel Vetter wrote:
> On Tue, Oct 02, 2018 at 04:53:12PM +0300, Laurent Pinchart wrote:
> > On Tuesday, 2 October 2018 16:35:10 EEST Daniel Vetter wrote:
> > > It's the default. The exported version was kinda a transit
1 - 100 of 294 matches
Mail list logo
