Hi Jani,
Thanks for the feedback, sorry the late reply.
On Fri, Aug 01, 2025 at 03:19:08PM +0300, Jani Nikula wrote:
> On Fri, 01 Aug 2025, Marius Vlad wrote:
> > From: Derek Foreman
> >
> > Add a way to know the actual bpc of a running link.
> >
> > Drivers
On Tue, Sep 23, 2025 at 11:42:42AM +0300, Marius Vlad wrote:
> Hi Dmitry,
>
> On Sat, Aug 23, 2025 at 12:30:27AM +0300, Dmitry Baryshkov wrote:
> > On Tue, Jul 29, 2025 at 07:57:07PM +0300, Marius Vlad wrote:
> > > This patch introduces a new boolean variable u
Hi Dmitry,
On Sat, Aug 23, 2025 at 12:30:27AM +0300, Dmitry Baryshkov wrote:
> On Tue, Jul 29, 2025 at 07:57:07PM +0300, Marius Vlad wrote:
> > This patch introduces a new boolean variable used to track connector's
> > connect/disconnect status and it is being used on both pol
: Marius Vlad
---
drivers/gpu/drm/drm_probe_helper.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index a865d5aa6f73..98afab9f15e9 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
user-space to receive
the connector's ID, rather than having a generic hot-plug event for all
connectors, or in the HPD path, just the first one found with a
connection status change.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/drm_connector.c| 1 +
drivers/gpu/drm/drm_probe_hel
From: Andri Yngvason
This includes YUV420 as well YUV444 and Auto. Auto will fallback to RGB
to keep things sane and still working, similar to i915.
Signed-off-by: Werner Sembach
Signed-off-by: Andri Yngvason
Signed-off-by: Marius Vlad
Co-Developed-by: Andri Yngvason
Co-Developed-by: Marius
On Fri, Sep 12, 2025 at 05:33:42PM +0200, Maxime Ripard wrote:
> On Thu, Sep 11, 2025 at 04:07:36PM +0300, Marius Vlad wrote:
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index 61cab32e213a..15820e6ba057 100644
> > ---
From: Werner Sembach
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB whe
From: Andri Yngvason
This includes YUV420 as well YUV444 and Auto. Auto will fallback to RGB
to keep things sane and still working.
Signed-off-by: Werner Sembach
Signed-off-by: Andri Yngvason
Signed-off-by: Marius Vlad
Co-Developed-by: Andri Yngvason
Co-Developed-by: Marius Vlad
well as supported color format
for the DRM color format property.
This includes a fallback to RGB when Auto has been selected.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
drivers/gpu/drm/bridge/ite-it6263.c | 2 +-
drivers/gpu/drm/bridge
Patch does not introduce any functional change but would help out when
introducing DRM_COLOR_FORMAT enum in a sub-sequent patch.
Auto will implictly fallthrough to RGB as that should be further
driver-defined.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 3
On Fri, Sep 12, 2025 at 05:17:56PM +0200, Maxime Ripard wrote:
> Hi,
Hi Maxime,
>
> On Thu, Sep 11, 2025 at 04:07:33PM +0300, Marius Vlad wrote:
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > index 45b42f14a750..74fe925c69a2 100644
> > --- a/dri
On Fri, Sep 12, 2025 at 05:31:17PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Thu, Sep 11, 2025 at 08:34:48PM +0300, Marius Vlad wrote:
> > > > diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > > > b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> > >
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/drm_atomic_helper.c | 5 +
drivers/gpu/drm/drm_atomic_uapi.c | 4 +
drivers/gpu/drm/drm_connector.c | 177
include/drm/drm_connector.h | 54 -
4 files changed, 235 insertions(+), 5 deletions(-)
On Thu, Sep 11, 2025 at 04:55:29PM +0300, Dmitry Baryshkov wrote:
> On Thu, Sep 11, 2025 at 04:07:36PM +0300, Marius Vlad wrote:
> > Initialize drm_brige with advertised colors formats straight on.
> >
> > Drivers that make use of DRM helpers would check the
> > drm_b
This would please the compiler to have a enum transformation from one to
another even though the values are the same. It should also make things
obvious that we use different enums.
Signed-off-by: Marius Vlad
---
.../gpu/drm/display/drm_hdmi_state_helper.c| 4 +++-
drivers/gpu/drm
On Thu, Sep 11, 2025 at 04:50:59PM +0300, Dmitry Baryshkov wrote:
> On Thu, Sep 11, 2025 at 04:07:34PM +0300, Marius Vlad wrote:
> > From: Andri Yngvason
> >
> > Adds a new general DRM property named "color format" which can be used by
> > userspace
From: Derek Foreman
This adds YUV444 and Auto, which will fallback to RGB as per
commit "drm: Pass supported color formats straight onto drm_bridge".
Signed-off-by: Derek Foreman
Signed-off-by: Marius Vlad
---
.../gpu/drm/rockchip/dw_hdmi_qp-rockchip.c| 10 +++-
drivers/gpu/dr
at"
drm/i915: Implement the "color format" DRM property
drm/amdgpu: Implement "color format" DRM property
Derek Foreman (1):
drm/rockchip: Implement "color format" DRM property
Marius Vlad (3):
hdmi: Add HDMI_COLORSPACE_AUTO enum option
drm: Add enum conv
that.
If EDID is broken it depends on user-space if it presents all the
advertised color formats from the driver. There isn't a way to discern
between panels that do not support YUV formats and panels that do support
YUV formats but they don't expose that in the EDID.
>
> Best
Hi,
Prior work towards this is/was:
https://lore.kernel.org/dri-devel/20240115160554.720247-1-an...@yngvason.is/
I have slightly modified version of that, but still working on
getting another driver (besides amd/i915) working with it.
On Tue, Aug 26, 2025 at 02:39:59AM +0800, Shengyu Qu wrote:
introduces a new property 'link bpc' that user-space can
use to get the current bpc value of a running link. In the same
time this would allow user-space set up bpc using 'max_bpc' property.
Signed-off-by: Derek Foreman
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/dr
: Marius Vlad
---
drivers/gpu/drm/drm_probe_helper.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 761766181e99..52761ca34460 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
user-space to receive
the connector's ID, rather than having a generic hot-plug event for all
connectors, or in the HPD path, just the first one found with a
connection status change.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/drm_connector.c| 1 +
drivers/gpu/drm/drm_probe_hel
devel/20250627131751.2004-1-marius.v...@collabora.com/T/#m9e35be35b70dc0d799dd950ce3cb4ef9c910e9c5
Marius Vlad (2):
drm: Introduce a new connector status
drm: Propagate connector status change
drivers/gpu/drm/drm_connector.c| 1 +
drivers/gpu/drm/drm_probe_helper.c
Hi,
FWIW, we (Weston) also use vkms in CI and we have in plan to make use of
these changes to exercise some internal code paths and enhance our tests.
Look forward to getting these into the tree and have it a in release. We
tend to follow with a branch/stable release so I suppose that's going be
Manually setting/forcing the connector status in sysfs does not
propagate the CONNECTOR ID. For drivers that use polling, including
manually setting it up with sysfs this would similarly to the HDP IRQ
path which can pass it through drm_connector_helper_hpd_irq_event().
Signed-off-by: Marius Vlad
Hi all,
On Mon, May 13, 2024 at 10:08:38AM +0200, José Expósito wrote:
> On Fri, May 10, 2024 at 06:19:45PM +0200, Louis Chauvet wrote:
> > Le 09/05/24 - 18:18, Jim Shargo a écrit :
> > > Sima--thanks SO MUCH for going through with everything leaving a
> > > detailed review. I am excited to go thro
On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote:
>
Hi all,
>
> On 2024-04-04 06:24, Pekka Paalanen wrote:
> > On Wed, 3 Apr 2024 17:32:46 -0400
> > Leo Li wrote:
> >
> >> On 2024-03-28 10:33, Pekka Paalanen wrote:
> >>> On Fri, 15 Mar 2024 13:09:56 -0400
> >>> wrote:
> >>>
>
On Tue, Feb 13, 2024 at 11:57:59AM +0200, Tomi Valkeinen wrote:
> Hi,
Hi,
>
> On 13/02/2024 11:04, Pekka Paalanen wrote:
> > On Tue, 13 Feb 2024 10:16:36 +0200
> > Tomi Valkeinen wrote:
> >
> > > When the driver sets up the zpos property it sets the default zpos value
> > > to the HW id of the p
Hi Brandon,
Small nit-pick at the end.
On Tue, Aug 29, 2023 at 05:30:54AM +, Brandon Pollack wrote:
> From: Jim Shargo
>
> This change supports multiple CRTCs, encoders, connectors instead of one
> of each per device.
>
> Since ConfigFS-based devices will support multiple crtcs, it's usefu
Hi Brandon,
You can now add
https://lists.freedesktop.org/archives/igt-dev/2023-September/060717.html
as part of this series.
On Tue, Aug 29, 2023 at 05:30:52AM +, Brandon Pollack wrote:
> Since Jim is busy with other work and I'm working on some things that
> rely on this, I've taken up the
Hi Brandon,
See some minor missing rmdirs for connector_other and encoder_other.
On Mon, Aug 28, 2023 at 08:17:06AM +, Brandon Pollack wrote:
> From: Jim Shargo
>
> This change adds the basic scaffolding for ConfigFS, including setting
> up the default directories. It does not allow for the
Hi Brandon,
See a bottom comment about writeback connectors creation/initalization.
On Mon, Aug 28, 2023 at 08:17:04AM +, Brandon Pollack wrote:
> From: Jim Shargo
>
> This change supports multiple CRTCs, encoders, connectors instead of one
> of each per device.
>
> Since ConfigFS-based de
Hi Brandon,
On 8/18/23 10:43, Brandon Pollack wrote:
From: Jim Shargo
This change adds the basic scaffolding for ConfigFS, including setting
up the default directories. It does not allow for the registration of
configfs-backed devices, which is complex and provided in a follow-up
commit.
This
Hi Brandon,
A few nits I've found where I'm getting some kernel locking errors, when
running this new series.
On 8/18/23 10:43, Brandon Pollack wrote:
From: Jim Shargo
This change supports multiple CRTCs, encoders, connectors instead of one
of each per device.
Since ConfigFS-based devices
Hi,
Seem my comments below.
On 8/18/23 08:24, Brandon Ross Pollack wrote:
On 8/15/23 23:01, Marius Vlad wrote:
Hi,
See below some minor comments:
On Fri, Jun 23, 2023 at 06:23:47PM -0400, Jim Shargo wrote:
VKMS now supports creating and using virtual devices!
In addition to the enabling
Hi,
See below some minor comments:
On Fri, Jun 23, 2023 at 06:23:47PM -0400, Jim Shargo wrote:
> VKMS now supports creating and using virtual devices!
>
> In addition to the enabling logic, this commit also prevents users from
> adding new objects once a card is registered.
>
> Signed-off-by: J
Hi,
See below some comments about vkms_wb_atomic_commit().
On Fri, Jun 23, 2023 at 06:23:44PM -0400, Jim Shargo wrote:
> This change supports multiple CRTCs, encoders, connectors instead of one
> of each per device.
>
> Since ConfigFS-based devices will support multiple crtcs, it's useful to
> m
Hi Brandon,
Is Jim Shargo no longer able to follow-up with these anymore? Can you
reach out to him? Maybe he's on holiday/vacation at this point?
If you decide to follow-up we need a v3 -- and possibly a few more, but
I'd just focus on getting the ConfigFS infrastructure in, addressing
current co
ber of overalys, rather than the pipes. It will
probably take some time until that configFS series make it through though.
On 4/26/23 07:40, Marius Vlad wrote:
This adds support for creating multiple virtual pipes, in case one would
need to display multiple independent things on different out
And init it by default to NUM_OVERLAY_PLANES. This change would allow us
to configure the amount of overlay planes we can have in combination
with multiple pipes, in case we'll exceed the number of planes we can have.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_drv.c
And remove the run-time configuration comment regarding needing first
more than 1 pipe.
Signed-off-by: Marius Vlad
---
Documentation/gpu/vkms.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 0f599c897614
particular importance when testing out the DRM back-end in
compositors, but also to be able to independently set different DPMS states.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_crtc.c | 3 +--
drivers/gpu/drm/vkms/vkms_drv.c | 37 ++-
drivers
x27;pipes' as to use the proper terminology
(Thomas Zimmermann, Maíra Canal)
- Fixed passing wrong possible_crtc bitmask when initializing the
write back connector which address kms_writeback failure (Maíra Canal)
- Add a feat. note about moving overlay planes between CRTCs (Mel
In preparation of having multiple pipelines we need to able to choose the
correct encoder/connectors/crtc combination so pass also the index as a
bitmask as possible CRTCs for the encoder.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_output.c | 2 +-
1 file changed, 1 insertion
We can chat more and see where we overlap and can learn from each other :)
On Tue, Apr 25, 2023 at 4:30 PM Marius Vlad <mailto:marius.v...@collabora.com>> wrote:
With multiple pipe available we can perform management of outputs at
a more granular level, such that we're
Hi,
On 4/25/23 14:46, Maíra Canal wrote:
On 4/25/23 04:44, Marius Vlad wrote:
Hello,
On 4/21/23 15:53, Maíra Canal wrote:
On 4/21/23 04:05, Marius Vlad wrote:
Hi Maíra,
Thanks a lot for taking a look!
On Thu, Apr 20, 2023 at 01:47:59PM -0300, Maíra Canal wrote:
Hi Marius,
Thanks for the
particular importance when testing out the DRM back-end in
compositors, but also to be able to independently set different DPMS states.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_crtc.c | 3 +--
drivers/gpu/drm/vkms/vkms_drv.c | 38 ++-
drivers
And remove the run-time configuration comment regarding needing first
more than 1 pipe.
Signed-off-by: Marius Vlad
---
Documentation/gpu/vkms.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 49db221c0f52
In preparation of having multiple pipelines we need to able to choose the
correct encoder/connectors/crtc combination so pass also the index as a
bitmask as possible CRTCs for the encoder.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_output.c | 2 +-
1 file changed, 1 insertion
k connector which address kms_writeback failure (Maíra Canal)
- Add a feat. note about moving overlay planes between CRTCs (Melissa Wen)
Marius Vlad (3):
vkms: Pass the correct bitmask for possible crtcs
vkms: Add support for multiple pipes
Documentation/gpu/vkms.rst: Added a note about plane migr
Hello,
On 4/21/23 15:53, Maíra Canal wrote:
On 4/21/23 04:05, Marius Vlad wrote:
Hi Maíra,
Thanks a lot for taking a look!
On Thu, Apr 20, 2023 at 01:47:59PM -0300, Maíra Canal wrote:
Hi Marius,
Thanks for the changing the commit message! Just a few nits:
On 4/20/23 05:41, Marius Vlad
And remove the run-time configuration comment regarding needing first
more than 1 pipe.
Signed-off-by: Marius Vlad
---
Documentation/gpu/vkms.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 49db221c0f52
In preparation of having multiple pipelines we need to able to choose the
correct encoder/connectors/crtc combination so pass also the index as a
bitmask as possible CRTCs for the encoder.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_output.c | 2 +-
1 file changed, 1 insertion
particular importance when testing out the DRM back-end in
compositors, but also to be able to independently set different DPMS states.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_crtc.c | 3 +--
drivers/gpu/drm/vkms/vkms_drv.c | 31 +--
drivers
n, Maíra Canal)
- Fixed passing wrong possible_crtc bitmask when initializing the
write back connector which address kms_writeback failure (Maíra Canal)
- Add a feat. note about moving overlay planes between CRTCs (Melissa Wen)
Marius Vlad (3):
vkms: Pass the correct bitmask for possible
Hi Maíra,
Thanks a lot for taking a look!
On Thu, Apr 20, 2023 at 01:47:59PM -0300, Maíra Canal wrote:
> Hi Marius,
>
> Thanks for the changing the commit message! Just a few nits:
>
> On 4/20/23 05:41, Marius Vlad wrote:
> > This adds support for creating multiple virtu
Hi Melissa,
Added a note about that in the latest version.
Thanks!
On Mon, Apr 10, 2023 at 05:17:56PM -0100, Melissa Wen wrote:
> On 04/06, Marius Vlad wrote:
> > Hi Thomas,
> >
> > Thanks for the clarifications! Made a couple of remarks in-line.
> >
> > O
And remove the run-time configuration comment regarding needing first
more than 1 pipe.
Signed-off-by: Marius Vlad
---
Documentation/gpu/vkms.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 49db221c0f52
In preparation of having multiple pipelines we need to able to choose the
correct encoder/connectors/crtc combination so pass also the index as a
bitmask as possible CRTCs for the encoder.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_output.c | 2 +-
1 file changed, 1 insertion
particular importance when testing out the DRM back-end in
compositors, but also to be able to independently set different DPMS states.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_crtc.c | 3 +--
drivers/gpu/drm/vkms/vkms_drv.c | 27 ++-
drivers
íra Canal)
- Add a feat. note about moving overlay planes between CRTCs (Melissa Wen)
Marius Vlad (3):
vkms: Pass the correct bitmask for possible crtcs
vkms: Add support for multiple pipes
Documentation/gpu/vkms.rst: Added a note about plane migration
Documentation/gpu/vkms.rst
Hi Thomas,
Thanks for the clarifications! Made a couple of remarks in-line.
On 4/6/23 14:29, Thomas Zimmermann wrote:
Hi
Am 06.04.23 um 11:17 schrieb Marius Vlad:
Hi Maira,
Thanks a lot for taking a look. Yeah, indeed, this creates a new
connector, a CRTC and planes for it. Terminology
kms_ci
Best Regards,
- Maíra Canal
This is of particular importance when testing out the DRM backend in
compositors, but also to be able to independently handle multiple
outputs/connectors, like setting one to off/sleep on while the others
are on, and combinations that arise from that.
Signed-o
compositors, but also to be able to independently handle multiple
outputs/connectors, like setting one to off/sleep on while the others
are on, and combinations that arise from that.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_crtc.c | 3 +--
drivers/gpu/drm/vkms/vkms_drv.c | 26
In preparation of having multiple outputs/virtual connectors we need to
able to chose the correct encoder/connectors/crtc combination so pass also
the index as a bitmask as possible crtcs for the encoder.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/vkms/vkms_output.c | 2 +-
1 file changed
sitor related to management of outputs.
Marius Vlad (2):
vkms: Pass the correct bitmask for possible crtcs
vkms: Add support for multiple connectors
drivers/gpu/drm/vkms/vkms_crtc.c | 3 +--
drivers/gpu/drm/vkms/vkms_drv.c | 26 ++
drivers/gpu/drm/vkms/vkms_
On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this hap
On Wed, Sep 23, 2020 at 01:16:42PM +0200, Daniel Vetter wrote:
> On Wed, Sep 23, 2020 at 1:14 PM Marius Vlad wrote:
> >
> > On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad
> > > wrote:
> > &g
On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote:
> >
> > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote:
> > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote:
> > > &g
On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote:
> On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote:
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
> >
>
se the zpos property, choose the latter solution.
>
> Additionally, update the drm_plane_state.zpos docs to clarify that zpos
> disambiguation via plane object IDs is a recommendation for drivers, not
> something user-space can rely on.
>
> v2: clarify drm_plane_state.zpos docs
Hi Philipp,
Tested-By: Marius Vlad
Thanks!
On Fri, Feb 15, 2019 at 11:17:59AM +0100, Philipp Zabel wrote:
> Hi,
>
> I have added (most of) you to Cc: because I think you have either
> recently or significantly touched zpos property code. Could I ask
> for a review or ack of
t exit in case of fail, so that unlocking takes place
before dropping the reference.
- Include detail information about deadlock (Daniel Vetter)
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/drm_lease.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/
This case can been seen when creating the lease with same objects passed.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/drm_lease.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index d1eb56a..ae57f33 100644
--- a/drivers/gpu/drm
From: Marius Vlad
Signed-off-by: Marius Vlad
Signed-off-by: Marius-Adrian Negreanu
---
drivers/gpu/drm/i915/i915_drv.c | 3 ---
drivers/gpu/drm/i915/i915_perf.c | 21 +
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b
From: Marius Vlad
Signed-off-by: Marius Vlad
Signed-off-by: Marius-Adrian Negreanu
---
drivers/gpu/drm/i915/i915_drv.c | 145 +---
1 file changed, 78 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915
From: Marius Vlad
Signed-off-by: Marius Vlad
Signed-off-by: Marius-Adrian Negreanu
---
drivers/gpu/drm/drm_drv.c | 1 +
drivers/gpu/drm/drm_ioctl.c | 99 +++--
include/drm/drm_drv.h | 34
include/drm/drm_ioctl.h | 6
From: Marius Vlad
Signed-off-by: Marius Vlad
Signed-off-by: Marius-Adrian Negreanu
---
drivers/gpu/drm/i915/i915_drv.c | 35 ---
drivers/gpu/drm/i915/i915_gem.c | 52 +
2 files changed, 52 insertions(+), 35 deletions(-)
diff
From: Marius Vlad
Currently driver-specific ioctls have to be declared static and are confined to
DRM core driver. This patch series provides the means to remove those constrains
and allow to register driver-specific ioctls dynamically by keeping a list of
registered ioctls in struct drm_driver
Indeed, we argued at first to let the driver handle the ioctls directly,
but we would like to use the DRM interface if possible.
On Mon, Sep 4, 2017 at 6:26 PM, Chris Wilson
wrote:
> Quoting Marius Vlad (2017-09-04 16:16:41)
> > From: Marius Vlad
> >
> > Currently driver
Mon, Sep 4, 2017 at 6:25 PM, Daniel Vetter wrote:
> On Mon, Sep 04, 2017 at 06:16:41PM +0300, Marius Vlad wrote:
> > From: Marius Vlad
> >
> > Currently driver-specific ioctls have to be declared static and are
> confined to
> > DRM core driver. This patch s
Florian, if you're using drm-intel-nigthly submit a bug at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI, with DRM/intel
as component. This way we can track some kind of progress/regress. The FIFO
underruns should've have been fixed, but maybe there's something related
to your platform.
O
Allow the possibility to return an copy of the injected EDID when the connector
has been forced and an EDID has been specified over the debugfs interface.
Signed-off-by: Marius Vlad
---
drivers/gpu/drm/drm_edid.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions
85 matches
Mail list logo
