The modesetting code is already present, this adds the rest of the API.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c | 573 +
drivers/gpu/drm/drm_debugfs.c | 7 +
drivers/gpu/drm/drm_drv.c | 11 +
drivers/gpu/drm/drm_fi
The stage is now set for a clean removal of drm_fb_helper_crtc.
struct drm_client_display is doing its job now.
Also remove the drm_fb_helper_funcs->initial_config which has been
superseded by drm_driver->initial_client_display.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c
No need to maintain a list of registered connectors. Just use the
connector iterator.
TODO: Remove:
- drm_fb_helper_add_one_connector()
- drm_fb_helper_single_add_all_connectors()
- drm_fb_helper_remove_one_connector()
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 359
Add a notifier that fires when a new DRM device is registered.
This can be used by the bootsplash client to connect to all devices.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_drv.c | 32
include/drm/drm_drv.h | 4
2 files changed, 36 insertio
This adds generic fbdev emulation for drivers that supports
dumb buffers which they can export.
All the driver has to do is call drm_fbdev_generic_setup().
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 255
include/drm/drm_fb_helper
A hack to test the client API.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/client/Kconfig | 9 ++
drivers/gpu/drm/client/drm_bootsplash.c | 248
dri
== Series Details ==
Series: drm/i915/cnl: Use mmio access to context status buffer
URL : https://patchwork.freedesktop.org/series/41630/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4049_full -> Patchwork_8679_full =
== Summary - WARNING ==
Minor unknown changes coming
I hit a 'Sending rate exceeded' error with this patchset, so it didn't
go out as it should.
I will resend the patchset when I find out how to avoid this problem.
Noralf.
Den 12.04.2018 15.17, skrev Noralf Trønnes:
This patchset explores the possibility of having generic fbdev emulation
in DRM
== Series Details ==
Series: GMBUS changes (rev2)
URL : https://patchwork.freedesktop.org/series/41632/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f6b744bf9f24 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
47340a0ebaad drm/i915/gmbus: Enable burst read
-:25: CHECK:SPACING:
== Series Details ==
Series: GMBUS changes (rev2)
URL : https://patchwork.freedesktop.org/series/41632/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4049 -> Patchwork_8682 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.or
== Series Details ==
Series: drm/i915: Block enabling FBC until flips have been completed
URL : https://patchwork.freedesktop.org/series/41634/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
aa6ceaa62430 drm/i915: Block enabling FBC until flips have been completed
-:92: CHECK:BR
On KBL platforms, with HW overlay and/or PSR2, a hard hang with corrupted
display is observed while running tests that frequently disable/re-enable
primary/overlay planes. Details recorded in this FDO bug:
https://bugs.freedesktop.org/show_bug.cgi?id=104975.
The issue has been root caused as a
== Series Details ==
Series: drm/i915: Check whitelist registers across resets (rev2)
URL : https://patchwork.freedesktop.org/series/41631/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4049_full -> Patchwork_8680_full =
== Summary - WARNING ==
Minor unknown changes comi
== Series Details ==
Series: drm/i915: Block enabling FBC until flips have been completed
URL : https://patchwork.freedesktop.org/series/41634/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4049 -> Patchwork_8683 =
== Summary - SUCCESS ==
No regressions found.
Externa
On 2018-03-30 20:23, Daniele Ceraolo Spurio wrote:
On 27/03/18 16:27, Chris Wilson wrote:
Quoting Tomasz Lis (2018-03-27 16:17:59)
The patch adds support of preempt-to-idle requesting by setting a
proper
bit within Execlist Control Register, and receiving preemption
result from
Context St
Before we start trying to use userptr to test interoperability with
PRIME, we first need to check that the device in question has userptr
support.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106013
Signed-off-by: Chris Wilson
---
tests/prime_mmap.c | 15 +++
1 file changed
== Series Details ==
Series: GMBUS changes (rev2)
URL : https://patchwork.freedesktop.org/series/41632/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4049_full -> Patchwork_8682_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_8682_full need to
== Series Details ==
Series: igt/prime_mmap: Test for userptr support first
URL : https://patchwork.freedesktop.org/series/41638/
State : success
== Summary ==
= CI Bug Log - changes from IGT_4426 -> IGTPW_1251 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patch
Peter Zijlstra writes:
> On Wed, Apr 11, 2018 at 09:26:11AM -0700, Francisco Jerez wrote:
>> "just like" here is possibly somewhat unfair to the schedutil governor,
>> admittedly its progressive IOWAIT boosting behavior seems somewhat less
>> wasteful than the intel_pstate non-HWP governor's IOWA
== Series Details ==
Series: drm/i915: Block enabling FBC until flips have been completed
URL : https://patchwork.freedesktop.org/series/41634/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4049_full -> Patchwork_8683_full =
== Summary - WARNING ==
Minor unknown changes
This seems like a typical atomic modeset requirement.
IPC should not impact register programming.
Vblank evasion only works if you have a guarantee on worst case
interrupts/delays. I think locks is part of the guarantee.
Double buffer control should guarantee safe alignment of programming across
On Thu, Apr 12, 2018 at 11:34:54AM -0700, Francisco Jerez wrote:
> The reason for the energy efficiency problem of iowait boosting is
> precisely the greater oscillation between turbo and idle. Say that
> iowait boost increases the frequency by a factor alpha relative to the
> optimal frequency f0
On Thu, 2018-04-12 at 18:07 +0200, Maarten Lankhorst wrote:
> There is a small race window in which FBC can be enabled after
> pre_plane_update is called, but before the page flip has been
> queued or completed.
I don't think there is such window, intel_fbc_deactivate() that is
called from intel_f
Peter Zijlstra writes:
> On Thu, Apr 12, 2018 at 11:34:54AM -0700, Francisco Jerez wrote:
>> The reason for the energy efficiency problem of iowait boosting is
>> precisely the greater oscillation between turbo and idle. Say that
>> iowait boost increases the frequency by a factor alpha relative
On 04/11/2018 04:11 PM, Chris Wilson wrote:
Quoting clinton.a.tay...@intel.com (2018-04-12 00:13:26)
From: Clint Taylor
In commit dc911f5bd8aa ("drm/i915/edp: Allow alternate fixed mode for eDP
if available."), the patch was always selecting the alternate refresh rate
even though user space
Juri Lelli writes:
> Hi,
>
> On 11/04/18 09:26, Francisco Jerez wrote:
>> Francisco Jerez writes:
>>
>> > Hi Srinivas,
>> >
>> > Srinivas Pandruvada writes:
>> >
>> >> On Tue, 2018-04-10 at 15:28 -0700, Francisco Jerez wrote:
>> >>> Francisco Jerez writes:
>> >>>
>> >> [...]
>> >>
>> >>
>> >
On Fri, Apr 06, 2018 at 06:56:22PM +0300, Ville Syrjälä wrote:
> On Thu, Mar 29, 2018 at 06:19:40AM +, Sripada, Radhakrishna wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > > Sent: Wednesday, March 28, 2018 3:36 AM
> > > To:
On 03/13/2018 06:11 AM, Ville Syrjälä wrote:
On Tue, Mar 13, 2018 at 10:28:55AM +0100, Maarten Lankhorst wrote:
On fi-cnl-y3 we have 2 modes that differ only by crtc_clock. This means
that if we request the normal mode, we automatically get the downclocked
mode.
This can be seen during boot:
On Thu, 2018-04-12 at 14:52 +0200, Katarzyna Dec wrote:
> On Tue, Apr 10, 2018 at 07:37:30PM -0700, Dhinakaran Pandiyan wrote:
> > BDW+ have PSR interrupts from which the kernel can update exit and
> > pre-entry time stamps. Tests should prefer this over sink crc to
> > validate PSR.
> >
> > Sign
From: Yang Shi
Refine the has_audio assignment for dp and hdmi.
Signed-off-by: Yang Shi
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_hdmi.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915
== Series Details ==
Series: drm/i915: Refine the has_audio assignment
URL : https://patchwork.freedesktop.org/series/41650/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4050 -> Patchwork_8684 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://pat
== Series Details ==
Series: drm/i915: Refine the has_audio assignment
URL : https://patchwork.freedesktop.org/series/41650/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4050_full -> Patchwork_8684_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwo
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Thursday, April 12, 2018 4:41 PM
> To: Srinivas, Vidya ; Intel Graphics Development
> ; Ville Syrjälä
>
> Cc: Kamath, Sunil ; Saarinen, Jani
>
> Subject: Re: [PATCH v1 5/6] drm/i915: Do not
On Thu, 12 Apr 2018, "Shi, Yang A" wrote:
> Dmesg is as following:
Full dmesg from boot please.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/ma
On 30.01.2018 09:38, Jani Nikula wrote:
> On Tue, 23 Jan 2018, Imre Deak wrote:
>> On Tue, Jan 23, 2018 at 11:48:22AM +0200, Jani Nikula wrote:
>>> On Mon, 22 Jan 2018, Imre Deak wrote:
On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
> On Thu, Oct 12, 2017 at 12:13:38PM -0700,
>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Thursday, April 12, 2018 4:06 PM
>To: Shi, Yang A ; De Marchi, Lucas
>
>Cc: Chris Wilson ; intel-gfx@lists.freedesktop.org;
>He, Bo
>; Deak, Imre
>Subject: RE: [Intel-gfx] [PATCH 1/1] drm/i915: move audio c
Modesetting requires DRM_MASTER privileges, so use
drm_open_driver_master() to assert that we do acquire them.
References: https://bugs.freedesktop.org/show_bug.cgi?id=105997
Signed-off-by: Chris Wilson
---
tests/kms_plane_scaling.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
On Wed, Apr 11, 2018 at 09:26:11AM -0700, Francisco Jerez wrote:
> "just like" here is possibly somewhat unfair to the schedutil governor,
> admittedly its progressive IOWAIT boosting behavior seems somewhat less
> wasteful than the intel_pstate non-HWP governor's IOWAIT boosting
> behavior, but it
On Thu, 12 Apr 2018, Timo Aaltonen wrote:
> On 30.01.2018 09:38, Jani Nikula wrote:
>> On Tue, 23 Jan 2018, Imre Deak wrote:
>>> On Tue, Jan 23, 2018 at 11:48:22AM +0200, Jani Nikula wrote:
On Mon, 22 Jan 2018, Imre Deak wrote:
> On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote
On Wed, 11 Apr 2018, vathsala nagaraju wrote:
> From: Vathsala Nagaraju
>
> For psr block #9, the vbt description has moved to options [0-3] for
> TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt
> structure. Since spec does not mention from which VBT version this
> change wa
On Wed, 11 Apr 2018, Chris Wilson wrote:
> Quoting Jani Nikula (2018-04-11 14:15:19)
>> No functional changes.
>>
>> Cc: Chris Wilson
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_bios.c | 10 --
>> 1 file changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git
Quoting Tvrtko Ursulin (2018-04-11 13:03:00)
>
> On 11/04/2018 12:34, Chris Wilson wrote:
> > Quoting Chris Wilson (2018-04-11 11:39:29)
> >> We can refine our current execlists->queue_priority if we inspect
> >> ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
> >> the uns
Op 12-04-18 om 12:07 schreef Srinivas, Vidya:
>
>> -Original Message-
>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>> Sent: Wednesday, April 11, 2018 4:08 PM
>> To: Srinivas, Vidya ; intel-gfx-
>> try...@lists.freedesktop.org
>> Cc: Kamath, Sunil ; Saarinen, Jani
>>
This patchset explores the possibility of having generic fbdev emulation
in DRM for drivers that supports dumb buffers which they can export. An
API is added to support in-kernel clients in general.
In this version I was able to reuse the modesetting code from
drm_fb_helper in the client API. This
It only makes sense for userspace clients.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_file.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index d4588d33f91c..5
From: David Herrmann
Rather than doing drm_file allocation/destruction right in the fops, lets
provide separate helpers. This decouples drm_file management from the
still-mandatory drm-fops. It prepares for use of drm_file without the
fops, both by possible separate fops implementations and APIs
Prepare for moving drm_fb_helper modesetting code to drm_client.
drm_client will be linked to drm.ko, so move
__drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
out of drm_kms_helper.ko.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_atomic.c| 168 +++
This the beginning of an API for in-kernel clients.
First out is a display representation that will be used by drm_fb_helper
in order to move out its mode setting code.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_client.c | 119 +++
This moves the committing part of the modesetting code to drm_client.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c| 242
drivers/gpu/drm/drm_fb_helper.c | 216 +--
include/drm/drm_client.h| 8
Prepare to move the modeset committing code to drm_client.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 161
include/drm/drm_fb_helper.h | 8 ++
2 files changed, 89 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/
Getting rotation info is cheap so we can do it on demand.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Cc: Hans de Goede
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 131
include/drm/drm_fb_helper.h
Atomic drivers can't use them so finish what was started in
commit 9c79e0b1d096 ("drm/fb-helper: Give up on kgdb for atomic drivers").
This prepares the ground for creating modesets on demand.
TODO:
- Actually remove the functions, not just the contents.
- Nuke drm_crtc_helper_funcs->mode_set_bas
For each enabled crtc the functions sets dpms on all registered connectors.
Limit this to only doing it once and on the connectors actually in use.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/dr
Move them over from drm_fb_helper since they are connector functions.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_connector.c| 94 ++
drivers/gpu/drm/drm_fb_helper.c| 75 ++
drivers/gpu/drm/i915/intel_fbdev.c | 7
Add functions to deal with the registred connectors as an array:
- drm_connector_get_all()
- drm_connector_put_all()
And to get the enabled status of those connectors:
drm_connector_get_enabled_status()
This is prep work to remove struct drm_fb_helper_connector.
Signed-off-by: Noralf Trønnes
--
Read ordering on cpu can be out of order and speculative.
In addition, the access to the hardware status page is snooped.
This raises a concern that we might use the HWSP in an unexpected
way as we may load the head of a cbs entry before we access the tail.
Concerns like that the coherency protocol
Quoting Mika Kuoppala (2018-04-12 14:52:37)
> Read ordering on cpu can be out of order and speculative.
If it didn't include a barrier to prevent compiler mispeculation. rmb()
only applies to other CPU cores and not the GPU so this is entirely
hocus.
-Chris
Quoting Chris Wilson (2018-04-12 14:57:42)
> Quoting Mika Kuoppala (2018-04-12 14:52:37)
> > Read ordering on cpu can be out of order and speculative.
>
> If it didn't include a barrier to prevent compiler mispeculation. rmb()
> only applies to other CPU cores and not the GPU so this is entirely
>
Quoting Chris Wilson (2018-04-12 14:57:42)
> Quoting Mika Kuoppala (2018-04-12 14:52:37)
> > Read ordering on cpu can be out of order and speculative.
>
> If it didn't include a barrier to prevent compiler mispeculation. rmb()
> only applies to other CPU cores and not the GPU so this is entirely
>
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-04-12 14:52:37)
>> Read ordering on cpu can be out of order and speculative.
>
> If it didn't include a barrier to prevent compiler mispeculation. rmb()
> only applies to other CPU cores and not the GPU so this is entirely
> hocus.
How I underst
== Series Details ==
Series: drm/i915: Enforce read order into the hardware status page csb
URL : https://patchwork.freedesktop.org/series/41622/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4049 -> Patchwork_8678 =
== Summary - SUCCESS ==
No regressions found.
Exter
On 12/04/18 01:43, Chris Wilson wrote:
Modesetting requires DRM_MASTER privileges, so use
drm_open_driver_master() to assert that we do acquire them.
References: https://bugs.freedesktop.org/show_bug.cgi?id=105997
Signed-off-by: Chris Wilson
Acked-by: Antonio Argenziano
__
Evidence indicates that Cannonlake HWSP is not coherent
as it should. Revert to using mmio access for now.
Testcase: igt/gem_ctx_switch
References: https://bugs.freedesktop.org/show_bug.cgi?id=105888
Cc: Chris Wilson
Cc: Rafael Antognolli
Cc: Rodrigo Vivi
Signed-off-by: Mika Kuoppala
---
driv
Quoting Mika Kuoppala (2018-04-12 15:58:02)
> Evidence indicates that Cannonlake HWSP is not coherent
> as it should. Revert to using mmio access for now.
>
> Testcase: igt/gem_ctx_switch
> References: https://bugs.freedesktop.org/show_bug.cgi?id=105888
> Cc: Chris Wilson
> Cc: Rafael Antognolli
== Series Details ==
Series: drm/i915: Enforce read order into the hardware status page csb
URL : https://patchwork.freedesktop.org/series/41622/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4049_full -> Patchwork_8678_full =
== Summary - WARNING ==
Minor unknown change
Add a selftest to ensure that we restore the whitelisted registers after
rewrite the registers everytime they might be scrubbed, e.g. module
load, reset and resume. For the other volatile workaround registers, we
export their presence via debugfs and check in igt/gem_workarounds.
However, we don't
Add a selftest to ensure that we restore the whitelisted registers after
rewrite the registers everytime they might be scrubbed, e.g. module
load, reset and resume. For the other volatile workaround registers, we
export their presence via debugfs and check in igt/gem_workarounds.
However, we don't
== Series Details ==
Series: drm/i915/cnl: Use mmio access to context status buffer
URL : https://patchwork.freedesktop.org/series/41630/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4049 -> Patchwork_8679 =
== Summary - SUCCESS ==
No regressions found.
External URL:
From BXT onwards Bspec says HW supports Max Bytes per single RD/WR op is
511Bytes instead of previous 256Bytes used in SW.
This change allows the max bytes per op upto 511Bytes from BXT onwards.
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_reg.h
== Series Details ==
Series: drm/i915: Check whitelist registers across resets (rev2)
URL : https://patchwork.freedesktop.org/series/41631/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
541de8069eef drm/i915: Check whitelist registers across resets
-:417: WARNING:FILE_PATH_CHAN
Support for Burst read in HW is added for HDCP2.2 compliance
requirement.
This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_i2c.c | 39
I am not aware if there is a reason for restricting the Bytes per GMBUS
WR/RD to 256 at present. But HW has 9Bits for Total Byte count for a
single read or Write cycle. Means we can extend a cycle of RD/WR to
511Bytes.
At present nothing much as ROI, as most of the usecases are for less
than 256By
== Series Details ==
Series: drm/i915: Check whitelist registers across resets (rev2)
URL : https://patchwork.freedesktop.org/series/41631/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4049 -> Patchwork_8680 =
== Summary - SUCCESS ==
No regressions found.
External UR
== Series Details ==
Series: GMBUS changes
URL : https://patchwork.freedesktop.org/series/41632/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bb2f104e57f8 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
b214f1744d40 drm/i915/gmbus: Enable burst read
-:22: CHECK:SPACING: spaces
Support for Burst read in HW is added for HDCP2.2 compliance
requirement.
This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.
v2:
Extra line is removed.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/
There is a small race window in which FBC can be enabled after
pre_plane_update is called, but before the page flip has been
queued or completed.
Signed-off-by: Maarten Lankhorst
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103167
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gp
== Series Details ==
Series: GMBUS changes
URL : https://patchwork.freedesktop.org/series/41632/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4049 -> Patchwork_8681 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1
Call the function drm_client_find_display().
No functional change apart from making width/height arguments optional.
Some function name/signature changes and whitespace adjustments.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c| 399
Make ioctl wrappers for functions that will be used by the in-kernel API.
The following functions are touched:
- drm_mode_create_dumb_ioctl()
- drm_mode_destroy_dumb_ioctl()
- drm_mode_addfb2()
- drm_mode_rmfb()
- drm_prime_handle_to_fd_ioctl()
drm_mode_addfb2() also gets the ability to override t
As part of moving the modesetting code out of drm_fb_helper and into
drm_client, the drm_fb_helper_funcs->initial_config callback needs to go.
Replace it with a drm_driver->initial_client_display callback that can
work for all in-kernel clients.
TODO:
- Add a patch that moves the function out of i
Give clients easy access to the display modes.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c | 159 +--
include/drm/drm_client.h | 25 +++
2 files changed, 148 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/drm_clien
Avoid pinning the module when exporting a GEM object as a dmabuf. This
makes it possible to unload drivers that has in-kernel clients using it.
The client is removed on drm_dev_unregister() so no need to pin the driver.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_prime.c | 24 +
These helpers keep track of fbdev users and drm_driver.last_close will
only restore fbdev when actually in use. Additionally the display is
turned off when the last user is closing. fbcon is a user in this context.
If struct fb_ops is defined in a library, fb_open() takes a ref on the
library (fb_
If there's a DRM master, return -EBUSY.
Block userspace from becoming master by taking the master lock while
the client is setting the mode.
Suggested-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_auth.c | 33 +
drivers/gpu/drm/drm_
84 matches
Mail list logo
