r 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
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
_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
y 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
g 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...@
gt; 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 Szyprowski
&g
r 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
> >
> >> Cc: Arun R Murthy
> >> Cc: Dave Air
ruct drm_connector_list_iter *iter)
> {
> - iter->dev = dev;
> - iter->conn = NULL;
> - lock_acquire_shared_recursive(_list_iter_dep_map, 0, 1, NULL,
> _RET_IP_);
> + drm_connector_list_iter_filter_begin(dev, iter, NULL, NULL);
> }
> EXPORT_SYMBOL(drm_connector_lis
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/legacy_dpm.c
s/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 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 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
_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't use
writeback are largely una
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.
> &
_copy(, 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 Skrabec
> Signed-off-by: Ville Syrjälä
Revie
aryshkov 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 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
> >> d
> 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: Laur
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: Laur
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/
: pointer to the _device that owns this AUX channel. Beware,
> this may be %NULL
> + * before drm_dp_aux_register() has been called.
> * @crtc: backpointer to the crtc that is currently using this AUX channel
> * @hw_mutex: internal mutex used for locking transfers
> * @crc_work: worker that captures CRCs for each frame
> * @crc_count: counter of captured frame CRCs
> * @transfer: transfers a message representing a single AUX transaction
> *
> - * The @dev field should be set to a pointer to the device that implements
> the AUX channel.
> + * The @dev field should be set to a pointer to the device that implements
> the AUX channel. As well,
> + * the @drm_dev field should be set to the _device that will be using
> this AUX channel as early
> + * as possible. For many graphics drivers this should happen before
> drm_dp_aux_init(), however it's
> + * perfectly fine to set this field later so long as it's assigned before
> calling
> + * drm_dp_aux_register().
> *
> * The @name field may be used to specify the name of the I2C adapter. If
> set to %NULL, dev_name()
> * of @dev will be used.
> @@ -1866,6 +1872,7 @@ struct drm_dp_aux {
> const char *name;
> struct i2c_adapter ddc;
> struct device *dev;
> + struct drm_device *drm_dev;
> struct drm_crtc *crtc;
> struct mutex hw_mutex;
> struct work_struct crc_work;
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
th - 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
rs/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(struct drm_gem_object
is correct, and what the
consequences here ?
>
> .fops = _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: Laur
> 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 patch now. So fix them up
> by reusing
pers.
>
> 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
> Reviewed-by: Laurent Pinchart
> R
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
> we actually want this in the dr
nformation 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 carefully consider the fallout.
> Cc: s
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: Daniel Ve
efresh(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;
> identifie
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 documen
l 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 drivers, forcing them to be converted to something that is
clearly half-baked
return -EINVAL;
> >> +
> >> + if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
> >> + ptr[1] != 1 ||
> >> + ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
> >> + return -EINVAL;
> >> +
> >> + if (hdm
r(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,
Laurent Pinchart
end.
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
s 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 deletions(-)
&g
e *bridge)
> {
> struct tc358764 *ctx = bridge_to_tc358764(bridge);
> - struct drm_device *drm = bridge->dev;
>
> drm_connector_unregister(>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
>
ed 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 - _device managed kcalloc()
> + * @dev: DRM device
> + * @size: 0 terminated string to be duplicated
Ditto.
> + * @gfp: GFP allocation flags
> + *
> + * This is a _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
>
t; void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp)
> {
> struct drmres *dr;
> diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
> index 240edd395e88..df30f9355902 100644
> --- a/include/drm/drm_managed.h
> +++ b/include/drm/drm_managed.h
> @@ -14,6 +14,10 @@ int __must_check __drmm_add_action(struct drm_device *dev,
> drmres_release_t action,
> void *data, const char *name);
>
> +void drmm_remove_action(struct drm_device *dev,
> + drmres_release_t action,
> + void *data);
> +
> 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;
--
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: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 h
gacy_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);
> -
> - put_device(dev->dev);
> -
> - mutex_destroy(>master_mutex);
> - mutex_destroy(
+++ 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 *dev, const char *s, gfp_t gfp);
>
v);
> /* 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
ox_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)
>
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/shmobil
lly, 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 other driv
MBOL(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.h
> @@ -929,7 +929,7 @@ struct drm_mode_config {
> cons
(udl);
> + drm_dev_put(>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
uct 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
_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
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 recipients from the series, ot
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
ere? 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
nabled? 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
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 +-
> > dri
dmi.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 | 7 +-
> drivers/gpu/drm/tilcdc/t
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 wrote:
&g
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_init_with_ddc() instead."
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
gid/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 Stuebner
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 Payload for Pixe
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
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 Anholt
> S
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 insertion
ajor 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
ill 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: Dan
t. 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, that may be a goo
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)
R
g
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 inser
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
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
> ---
>
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
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
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 Skeggs
> Cc: T
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 transition s
1 - 100 of 272 matches
Mail list logo
