very sure and might be wrong. So other peoples
> can override me words.
>
> > Everyone agrees that CREATE_DUMB is not the best ioctl to allocate
> > buffers, and one can't consider it to work identically across the
> > platforms. But it's what we have and what has been used for ages.
>
> Yeah, your request are not unreasonable. It can be seen as a kind of rigid
> demand.
> Since GEM DMA helpers doesn't export an more advanced interface to userspace
> so far.
> As a result, drivers that employing GEM DMA has no other choice, but to abuse
> the
> dumb buffer API to do allocation for the more complex format buffers.
>
> The dumb buffer API doesn't support to specify buffer format, tile status and
> placement etc. The more advance drivers has been exposed the xxx_create_gem()
> to user-space. It seems that a few more experienced programmers hint us to
> create an new ioctl at above thread, so that we can keep employing simple API
> to do simple things and to suit complex needs with the more advanced APIs.
I'd really like to explore adding new ioctls to exposure memory
allocation constraints, and allocating the memory itself from DMA heaps.
--
Regards,
Laurent Pinchart
On Thu, Jan 16, 2025 at 12:07:49PM +0200, Tomi Valkeinen wrote:
> On 16/01/2025 11:38, Laurent Pinchart wrote:
> > On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
> >> On Wed, Jan 15, 2025 at 02:34:26PM +, Daniel Stone wrote:
> >>> On Wed, 15 Jan
need a standard ioctl that can create
linear YUV buffers. I've been told many times that DRM doesn't want to
standardize buffer allocation further than what CREATE_DUMB is made for.
Can we reconsider this rule then ?
--
Regards,
Laurent Pinchart
On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
> On Wed, Jan 15, 2025 at 02:34:26PM +, Daniel Stone wrote:
> > On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
> > > No disagreement there, we need CREATE_DUMB2.
> > >
> > > My point is t
; > 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
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
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
> - 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
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 +-
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
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
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
allow to reuse the tooling and also is going to
> make the virtio-video spec even bigger.
>
> [1]
> https://lore.kernel.org/virtio-comment/20230629144915.597188-1-alexander.gord...@opensynergy.com/
> [2]
> https://lore.kernel.org/linux-media/20200218202753.652093-1-dmitry.s...@opensynergy.com/
> [3]
> https://docs.kernel.org/userspace-api/media/v4l/dev-decoder.html#querying-capabilities
> [4]
> https://docs.kernel.org/userspace-api/media/v4l/dev-encoder.html#querying-capabilities
> [5] https://drive.google.com/file/d/1uPg4kxThlNPBSiC4b5veyFz4OFGytU7v/view
> [6] https://elinux.org/Device_Tree_Usage#Device_Specific_Data
> [7] https://www.devicetree.org/specifications/
> [8] https://github.com/rust-vmm/vm-fdt
> [9] https://github.com/devicetree-org/dt-schema
--
Regards,
Laurent Pinchart
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
+ * 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,
> + *
-
>
> Changes from v1:
> - Reintroduce the old_plane_state check in zynqmp_disp_crtc_atomic_disable
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 8
> drivers/gpu/drm/drm_simple_kms_helper.c | 4 +++-
> drivers/gpu/drm/mxsfb/mxsfb_k
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
17 matches
Mail list logo
