oss the series.
Jiapeng Chong has sent a patch to drop the function, and I've reviewed
it. See
https://lore.kernel.org/r/20240619075436.86407-1-jiapeng.ch...@linux.alibaba.com
I've sent a pull request for v6.12 but it hasn't been processed in time
:-( See
https://lore.kernel.org/r/20240822234445.ga23...@pendragon.ideasonboard.com
--
Regards,
Laurent Pinchart
Hi Thomas,
On Tue, Aug 20, 2024 at 09:22:36AM +0200, Thomas Zimmermann wrote:
> Am 18.08.24 um 22:07 schrieb Laurent Pinchart:
> > On Fri, Aug 16, 2024 at 02:22:30PM +0200, Thomas Zimmermann wrote:
> >> DRM may support multiple in-kernel clients that run as soon as a DRM
&g
gt;
> Signed-off-by: Thomas Zimmermann
> Cc: Laurent Pinchart
> Cc: Tomi Valkeinen
> Cc: Michal Simek
> ---
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
&
gt;
> Signed-off-by: Thomas Zimmermann
> Cc: Laurent Pinchart
> Cc: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/
>
> The rcar-du driver specifies a preferred color mode of 32. As this
> is the default if no format has been given, leave it out entirely.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> driv
*format);
void drm_client_setup_with_color_mode(struct drm_device *dev, unsigned int
color_mode);
#define drm_client_setup_(dev, format_or_color_mode)
\
_Generic(format_or_color_mode,
\
const struct drm_format_info *:
drm_client_setup_with_format(dev, format_or_color_mode), \
unsigned int: drm_client_setup_with_color_mode(dev,
format_or_color_mode)\
)
Up to you.
Reviewed-by: Laurent Pinchart
> +
> +#endif
--
Regards,
Laurent Pinchart
helpers into a 4CC helper,
s/form/from/
> so that is can be shared among DRM clients.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_fb_helper.c | 70 +++--
> drivers/gpu/drm/drm_fourcc.c|
I know for sure of one other person falling
> for the same.
Make that two. Thanks for the notice.
> Now, the members page for this year says "Application for the period:
> 02/2024-02/2025". Thanks to the people adding the month to reduce
> confusion.
--
Regards,
Laurent Pinchart
gure
> this out isn't super optimal perhaps.
>
> [1]:
> https://lore.kernel.org/dri-devel/20221108185004.2263578-1-wonch...@google.com/
--
Regards,
Laurent Pinchart
On Wed, Aug 02, 2023 at 10:01:19PM +0300, Dmitry Baryshkov wrote:
> On 02/08/2023 21:55, Laurent Pinchart wrote:
> > Hi Dmitry,
> >
> > Thank you for the patch.
> >
> > On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote:
> >> To properly d
{
> DRM_MODE_SUBCONNECTOR_HDMIA = 11, /*DP */
> DRM_MODE_SUBCONNECTOR_Native = 15, /*DP */
> DRM_MODE_SUBCONNECTOR_Wireless= 18, /* DP */
> + DRM_MODE_SUBCONNECTOR_USB = 20, /*DP */
> };
>
> #define DRM_MODE_CONNECTOR_Unknown 0
--
Regards,
Laurent Pinchart
ent_type_name(int val);
> int drm_get_tv_mode_from_name(const char *name, size_t len);
>
> int drm_mode_create_dvi_i_properties(struct drm_device *dev);
> -void drm_connector_attach_dp_subconnector_property(struct drm_connector
> *connector);
> +void drm_connector_attach_dp_subconnector_property(struct drm_connector
> *connector,
> +enum drm_mode_subconnector
> subtype);
>
> int drm_mode_create_tv_margin_properties(struct drm_device *dev);
> int drm_mode_create_tv_properties_legacy(struct drm_device *dev,
--
Regards,
Laurent Pinchart
roperty
> > exists,
> > and perhaps add a warning if not.
>
> This property is created in the previous call,
> drm_mode_create_tv_properties() ->
> drm_mode_create_tv_properties_legacy().
>
> > AFAIK same for DRM_MODE_CONNECTOR_DVII.
> >
> > > + }
> > > +
> > > return connector;
> > > }
> > > EXPORT_SYMBOL_GPL(drm_bridge_connector_init);
> > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > > index bf964cdfb330..68b14ac5ac0d 100644
> > > --- a/include/drm/drm_bridge.h
> > > +++ b/include/drm/drm_bridge.h
> > > @@ -739,6 +739,10 @@ struct drm_bridge {
> > >* identifies the type of connected display.
> > >*/
> > > int type;
> > > + /**
> > > + * @subtype: the subtype of the connector for the DP/TV/DVI-I cases.
> > > + */
> > > + enum drm_mode_subconnector subtype;
> > > /**
> > >* @interlace_allowed: Indicate that the bridge can handle
> > > interlaced
> > >* modes.
--
Regards,
Laurent Pinchart
the
> > upcoming election is 26 March 2023 at 23:59 UTC.
> >
> > If you are interested in joining the X.Org Foundation or in renewing
> > your membership, please visit the membership system site at:
> > https://members.x.org/
> >
> > Ricardo Garcia, on behalf of the X.Org elections committee
--
Regards,
Laurent Pinchart
ime)
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: Thierry Reding
> Cc: Emma Anholt
> Cc: Maxime Ripard
> Cc: intel-gfx@lists.freedesktop.org
> Cc: linux-te...@vge
00/0x474
> worker_thread+0x74/0x43c
> kthread+0xfc/0x110
> ret_from_fork+0x10/0x20
> ---[ end trace ]---
>
> Reported-by: Laurentiu Palcu
> Fixes: c8268795c9a9 ("drm/probe-helper: enable and disable HPD on connectors")
> Tested-by: Marek Szyp
he call. If
there's a general consensus it's better to require all drivers to handle
writeback connectors explicitly everywhere (Daniel and Dave may want to
chime in here), I can be overruled, like anybody else.
> > This series is
> > Acked-by: Harry Wentland
> >
struct drm_connector_list_iter *iter)
> {
> - iter->dev = dev;
> - iter->conn = NULL;
> - lock_acquire_shared_recursive(&connector_list_iter_dep_map, 0, 1, NULL,
> _RET_IP_);
> + drm_connector_list_iter_filter_begin(dev, iter, NULL, NULL);
&g
>
> 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
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:
> >>>
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 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
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 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
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 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.
> &
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
, 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
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
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 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:
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 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
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/
@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
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 +
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
&
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
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(
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
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 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
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
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
&
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
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
_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
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
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
gt; >> + return -EINVAL;
> >> +
> >> + if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
> >> + ptr[1] != 1 ||
> >> + ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
> >> + return -EINVAL;
> >> +
>
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
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
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
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
_
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
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 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:
> >>>
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 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
> &
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
>
+ * @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 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
>
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: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
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
--- 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
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
+ 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)
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
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
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.
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
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
+ __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
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
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
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
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
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
-
> > 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
> 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
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
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 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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
1 - 100 of 285 matches
Mail list logo
