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|
*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
>
> 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
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/
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
&
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
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
-off-by: Thomas Zimmermann
Assuming you've compile-tested the driver,
Reviewed-by: Laurent Pinchart
Please get this merged through drm-misc as part of the series if
possible.
> ---
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/dri
e/drm/drm_plane.h b/include/drm/drm_plane.h
> index 0c1102dc4d88..cad641b1f797 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -803,6 +803,9 @@ void *__drmm_universal_plane_alloc(struct drm_device *dev,
> *
> * The @drm_plane_funcs.destr
rm_WARN_ON(dev, config->fb_modifiers_not_supported &&
format_modifier_count);
Reviewed-by: Laurent Pinchart
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
>
>ddev->mode_config.fb_modifiers_not_supported = true;
> +
> rdev->ddev->mode_config.fb_base = rdev->mc.aper_base;
>
> ret = radeon_modeset_create_props(rdev);
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 91ca575a78de
On Tue, Jun 22, 2021 at 07:11:33PM +0300, Laurent Pinchart wrote:
> Hi Thomas,
>
> Thank you for the patches.
>
> On Tue, Jun 22, 2021 at 04:09:40PM +0200, Thomas Zimmermann wrote:
> > Remove references to struct drm_device.irq_enabled from modern
> > DRM drivers and
gra/drm.c | 7 ---
> drivers/gpu/drm/tidss/tidss_irq.c | 3 ---
> drivers/gpu/drm/vc4/vc4_kms.c | 1 -
> drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 8
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c
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:
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
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-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
struct drm_plane_state *new_plane_state
> )
> {
> <+...
> - state
> + new_plane_state
> ...+>
> }
>
> Signed-off-by: Maxime Ripard
> ---
[...]
> drivers/gpu/drm/omapdrm/omap_plane.c | 19 +++++
> drivers/gpu/drm/rcar-
state @
> @@
>
> #include
>
> @ no_include depends on !include && adds_new_state @
> @@
>
> + #include
> #include
>
> Signed-off-by: Maxime Ripard
> ---
[snip]
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> drivers
rm_atomic_get_new_plane_state(state,
> plane);
> <...
> - plane_state->state
> + state
> ...>
> }
>
> Signed-off-by: Maxime Ripard
> ---
[snip]
> drivers/gpu/drm/omapdrm/omap_plane.c | 2 +-
> drivers/gpu/drm/xlnx/zynqmp_disp.c
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
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
>
> 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
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
+ * different options for the emulated framebuffer device registered.
> + *
> + * The options must be set using DRM_FB_SET_OPTION() and obtained using
> + * DRM_FB_GET_OPTION(). The options field are the following:
> + *
> + * * DRM_FB_BPP: bits per pixel for the device. If the field is not set,
> + *
ers
> for computing options bitfield values and getting the values respectively
>
> For now, only the DRM_FB_BPP option exists but other options can be added.
>
> Suggested-by: Thomas Zimmermann
> Signed-off-by: Javier Martinez Canillas
> Reviewed-by: Thomas Zimmermann
> Revi
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
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
{
> 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
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
gure
> this out isn't super optimal perhaps.
>
> [1]:
> https://lore.kernel.org/dri-devel/20221108185004.2263578-1-wonch...@google.com/
--
Regards,
Laurent Pinchart
union {
> + __u8 bPreferredVersion;
> + __u8 bPreferedVersion __attribute__((deprecated)); /* NOTYPO */
> + } __attribute__((__packed__));
Quite interestingly this typo is part of the USB device class definition
for video devices (UVC) specification. I thus think we should keep using
the field name bPreferedVersion through the code, otherwise it wouldn't
match the spec.
> __u8 bMinVersion;
> __u8 bMaxVersion;
> } __attribute__((__packed__));
[snip]
--
Regards,
Laurent Pinchart
: "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
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
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
drm.h | 1 -
> drivers/gpu/drm/tegra/output.c| 12 +--
> drivers/gpu/drm/tegra/sor.c | 6 +-
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c| 1 +
> drivers/gpu/drm/vc4/vc4_hdmi.c | 16
Hi Andrzej,
On Fri, Jul 05, 2019 at 10:38:27AM +0200, Andrzej Pietrasiewicz wrote:
> W dniu 28.06.2019 o 18:11, Laurent Pinchart pisze:
> > Hi Andrzej,
> >
> > Just FYI, I have a patch series that reworks how bridges and connectors
> > are handled, and it will heav
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
---
> include/drm/drm_plane.h| 8 ++
> 5 files changed, 22 insertions(+), 166 deletions(-)
--
Regards,
Laurent Pinchart
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Hi Harry,
On Monday 16 Jan 2017 16:13:39 Harry Wentland wrote:
> On 2017-01-16 03:39 PM, Laurent Pinchart wrote:
> > On Monday 16 Jan 2017 10:44:54 Andrey Grodzovsky wrote:
> >> This series is a folow-up on
> >> https://patchwork.kernel.org/patch/9501787/
> >>
/
> struct dc_target *target;
> };
--
Regards,
Laurent Pinchart
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
ck(struct drm_device *dev,
>* 1. This commit is not a page flip.
>* 2. This commit is a page flip, and targets are
created.
>*/
> - if (!page_flip_needed(plane_state, old_plane_state,
> - true) ||
> + if (!page_flip_needed(plane_state, old_plane_state,
true) ||
This seems to be an unrelated change.
> action == DM_COMMIT_ACTION_DPMS_ON ||
> action == DM_COMMIT_ACTION_SET) {
> struct dc_surface *surface;
--
Regards,
Laurent Pinchart
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> @@ -122,6 +122,14 @@ struct drm_plane_state {
>*/
> bool visible;
>
> +
> + /**
> + * @pflip_flags:
> + *
> + * Flip related config options
> + */
> + u32 pflip_flags;
> +
> struct drm_atomic_state *state;
> };
--
Regards,
Laurent Pinchart
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Hi Andrey,
On Tuesday 17 Jan 2017 04:03:11 Grodzovsky, Andrey wrote:
> On Monday, January 16, 2017 5:18 PM Laurent Pinchart wrote:
> > On Monday 16 Jan 2017 10:44:55 Andrey Grodzovsky wrote:
> > > Allows using atomic flip helpers for drivers using ASYNC flip.
> > > Re
Hi Michel,
On Wednesday 18 Jan 2017 10:50:01 Michel Dänzer wrote:
> On 17/01/17 07:16 AM, Laurent Pinchart wrote:
> > On Monday 16 Jan 2017 10:44:57 Andrey Grodzovsky wrote:
> >> Change-Id: Iad3e0b9b3546e4e4dc79be9233daf4fe4dba83e0
> >> Signe
s patch looks good to me.
> + */
> + u32 pflip_flags;
> +
> + /**
> * @event:
>*
>* Optional pointer to a DRM event to signal upon completion of the
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index db3bbde..57414ae 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -122,6 +122,7 @@ struct drm_plane_state {
>*/
> bool visible;
>
> struct drm_atomic_state *state;
> };
--
Regards,
Laurent Pinchart
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Hi Andrey,
(by the way there's a typo in the subject)
On Monday 30 Jan 2017 19:42:23 Grodzovsky, Andrey wrote:
> On Monday, January 30, 2017 6:05 AM Laurent Pinchart wrote:
> > On Saturday 28 Jan 2017 21:26:49 Andrey Grodzovsky wrote:
> >> Allows using atomic flip helpers
if (!page_flip_needed(plane_state, old_plane_state, true,
crtc->state->pflip_flags) ||
action == DM_COMMIT_ACTION_DPMS_ON ||
action == DM_COMMIT_ACTION_SET) {
[snip]
--
Regards,
Laurent Pinchart
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
t; I don't see much what could go wrong when merging them.
For what it's worth, I've once applied a patch from Markus for the uvcvideo
driver that seemed trivial but ended up introducing a breakage that I hadn't
caught during review. I r
> index b2c52843bc70..c81c75335cca 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -814,6 +814,8 @@ extern "C" {
> #define DRM_IOCTL_MODE_CREATEPROPBLOBDRM_IOWR(0xBD, struct
> drm_mode_create_blob)
> #define DRM_IOCTL_MODE_DESTROYPROPBLOBDRM_IOWR(0xBE, struct
> drm_mode_destroy_blob)
>
> +#define DRM_IOCTL_MODE_GETFB2 DRM_IOWR(0xC4, struct drm_mode_fb_cmd2)
> +
Which tree is this based on ? The last defined ioctl
(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE) is 0xC2 in drm-next and drm-misc-next.
> /**
> * Device specific ioctls should only be in their respective headers
> * The device specific ioctl range is from 0x40 to 0x9f.
--
Regards,
Laurent Pinchart
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Hi Joe,
On Tuesday 01 Aug 2017 10:24:25 Joe Kniss wrote:
> On Tue, Aug 1, 2017 at 5:09 AM, Laurent Pinchart wrote:
> > On Monday 31 Jul 2017 11:29:13 Joe Kniss wrote:
> >> New getfb2 functionality uses drm_mode_fb_cmd2 struct to be symmetric
> >> with addfb2.
> >
#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| 2 +-
&
6-shared.c | 2 +-
> > sound/soc/codecs/cs35l56.c| 2 +-
> > sound/soc/codecs/cs42l42-sdw.c| 2 +-
> > sound/soc/codecs/cs42l42.c| 4 +-
> > sound/soc/codecs/cs42l43-jack.c | 10 +-
> > sound/soc/codecs/cs42l43.c| 4 +-
> > sound/soc/codecs/hda.c| 6 +-
> > sound/soc/codecs/madera.c | 6 +-
> > sound/soc/codecs/max98363.c | 2 +-
> > sound/soc/codecs/max98373-sdw.c | 2 +-
> > sound/soc/codecs/rt1017-sdca-sdw.c| 2 +-
> > sound/soc/codecs/rt1308-sdw.c | 2 +-
> > sound/soc/codecs/rt1316-sdw.c | 2 +-
> > sound/soc/codecs/rt1318-sdw.c | 2 +-
> > sound/soc/codecs/rt1320-sdw.c | 2 +-
> > sound/soc/codecs/rt5682-sdw.c | 2 +-
> > sound/soc/codecs/rt700.c | 4 +-
> > sound/soc/codecs/rt711-sdca.c | 4 +-
> > sound/soc/codecs/rt711.c | 4 +-
> > sound/soc/codecs/rt712-sdca-dmic.c| 2 +-
> > sound/soc/codecs/rt712-sdca.c | 4 +-
> > sound/soc/codecs/rt715-sdca.c | 2 +-
> > sound/soc/codecs/rt715.c | 2 +-
> > sound/soc/codecs/rt722-sdca.c | 4 +-
> > sound/soc/codecs/wcd-mbhc-v2.c| 4 +-
> > sound/soc/codecs/wsa881x.c| 2 +-
> > sound/soc/codecs/wsa884x.c| 2 +-
> > sound/soc/intel/atom/sst/sst_pvt.c| 2 +-
> > sound/soc/intel/avs/core.c| 2 +-
> > sound/soc/intel/avs/debugfs.c | 4 +-
> > sound/soc/intel/avs/pcm.c | 2 +-
> > sound/soc/intel/catpt/pcm.c | 12 +-
> > sound/soc/intel/catpt/sysfs.c | 2 +-
> > sound/soc/soc-component.c | 2 +-
> > sound/soc/sof/control.c | 2 +-
> > sound/soc/sof/debug.c | 2 +-
> > sound/soc/sof/ipc3-dtrace.c | 2 +-
> > sound/soc/sof/ipc4-loader.c | 2 +-
> > sound/soc/sof/pcm.c | 2 +-
> > sound/soc/sof/sof-client-ipc-flood-test.c | 2 +-
> > .../soc/sof/sof-client-ipc-kernel-injector.c | 2 +-
> > sound/soc/sof/sof-client-ipc-msg-injector.c | 2 +-
> > sound/soc/sof/sof-client-probes.c | 6 +-
> > sound/x86/intel_hdmi_audio.c | 6 +-
> > 373 files changed, 1076 insertions(+), 1076 deletions(-)
--
Regards,
Laurent Pinchart
Hi Ulf,
On Tue, Oct 08, 2024 at 12:08:24AM +0200, Ulf Hansson wrote:
> On Mon, 7 Oct 2024 at 20:49, Laurent Pinchart wrote:
> > On Fri, Oct 04, 2024 at 04:38:36PM +0200, Ulf Hansson wrote:
> > > On Fri, 4 Oct 2024 at 11:41, Sakari Ailus wrote:
> > > >
> > >
ept const argument.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Laurent Pinchart
On a side note, there's only two I2C slave encoder drivers left... I
wonder if we could so something about them. The ch7006 and sil164
drivers seem to be used by nouveau only, could they be move
On Mon, Nov 18, 2024 at 01:22:12AM +0200, Dmitry Baryshkov wrote:
> On Sun, 17 Nov 2024 at 22:54, Laurent Pinchart wrote:
> > On Fri, Nov 15, 2024 at 11:09:26PM +0200, Dmitry Baryshkov wrote:
> > > The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge
> &g
On Mon, Nov 18, 2024 at 11:26:03AM +0200, Jani Nikula wrote:
> On Mon, 18 Nov 2024, Dmitry Baryshkov wrote:
> > On Mon, 18 Nov 2024 at 01:33, Laurent Pinchart wrote:
> >> On Mon, Nov 18, 2024 at 01:22:12AM +0200, Dmitry Baryshkov wrote:
> >> > On Sun, 17 Nov 2024 at
ept const argument.
I would write "take a const argument" instead of "accept". Same in the
other patches.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> include/drm/drm_modeset_h
> - drm_mode_set_crtcinfo(mode, 0);
> + test_mode = drm_mode_duplicate(connector->dev, mode);
> + if (!test_mode)
> + goto fail;
> +
> + drm_mode_set_crtcinfo(test_mode, 0);
I wonder if things could be refactored further to avoid t
llback of drm_connector to accept const
> struct drm_display_mode argument.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/sti/sti_hda.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/dr
ept const argument.
>
> Signed-off-by: Dmitry Baryshkov
Assuming you've compile-tested all this,
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 8
> drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
; > drivers/gpu/drm/tegra/hdmi.c | 2 +-
> > drivers/gpu/drm/tegra/sor.c | 2 +-
> > drivers/gpu/drm/vc4/vc4_txp.c| 2 +-
> > drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +-
> > include/drm/display/drm_hdmi_state_helper.h | 2 +-
> > include/drm/drm_encoder_slave.h | 2 +-
> > include/drm/drm_modeset_helper_vtables.h | 4 ++--
> > 71 files changed, 92 insertions(+), 93 deletions(-)
> > ---
> > base-commit: 4176cf5c5651c33769de83bb61b0287f4ec7719f
> > change-id: 20241115-drm-connector-mode-valid-const-ae3db0ef6cb7
--
Regards,
Laurent Pinchart
t
that to be the majority case, but I can't rule it out either. There's
also the issue that, even if the devices support configurable pitches,
the drivers may not implement it. That's fixable, but hardcoding the
pitch to 256 bytes without fixing that would be a regression.
--
Regards,
Laurent Pinchart
agree with your concern in general, AFAIK there's no other
> solution for this even on the horizon, after years of talking about
> it. The solution proposed here seems like an acceptable stop gap,
> assuming it won't result in a gazillion linear modifiers.
Flipping that argument, the reason why we still have no solution is
because we've constantly accepted stop-gap measures. Maybe it's time to
stop. It may feel a bit unfair to Marek that everybody until know got
away with hacks, but I don't think he would be left alone designing a
proper solution.
--
Regards,
Laurent Pinchart
oes this seem like something worth pursuing to others? I've been trying
> to decide how to best move the allocation constraints efforts forward,
> so it's potentially something I could put some time into this year.
It's a fairly interesting idea I hadn't thought of.
My limited experience with all the graphics protocols and their history
means I have had limited exposure to the pain that communicating
modifiers everywhere has generated. As a result, I would have (perhaps
naively) tried to design a new mechanism. Using modifiers as a transport
mechanism is clearly a hack, but it may be a clever one. It seems worth
experimenting with it at least.
After reading the whole thread, I however wonder if this will be
backward compatible. If two devices expose a constraint that ends up
being encoded in the same binary form in a modifier (let's say for
instance the same pitch alignment), isn't there a risk that an
application not aware of this new scheme will pick that common modifier
when intersecting the modifiers list as done today, without realizing
it's not a real modifier ?
--
Regards,
Laurent Pinchart
73 matches
Mail list logo
