On Wed, 16 Sep 2020 at 14:19, Dave Airlie wrote:
>
> On Wed, 16 Sep 2020 at 00:12, Christian König
> wrote:
> >
> > Hi Dave,
> >
> > I think we should just completely nuke ttm_tt_bind() and ttm_tt_unbind()
> > and all of that.
> >
> > Drivers can to this from their move_notify() callback now
On Wed, 16 Sep 2020 at 00:12, Christian König
wrote:
>
> Hi Dave,
>
> I think we should just completely nuke ttm_tt_bind() and ttm_tt_unbind()
> and all of that.
>
> Drivers can to this from their move_notify() callback now instead.
Good plan, I've put a bunch of rework into the same branch,
On Tue, 2020-09-15 at 15:38 -0700, Navare, Manasi wrote:
> On Tue, Sep 15, 2020 at 03:47:01PM -0400, Lyude Paul wrote:
> > On Tue, 2020-09-15 at 15:06 -0400, Rodrigo Vivi wrote:
> > > On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > > > Since we're about to start adding support for
When the GPU's ACE-Lite interface is fully wired up and capable of
snooping CPU caches, it may be described as "dma-coherent" in
devicetree, which will already inform the DMA layer not to perform
unnecessary cache maintenance. However, we still need to ensure that
the GPU uses the appropriate
Midgard GPUs have ACE-Lite master interfaces which allows systems to
integrate them in an I/O-coherent manner. It seems that from the GPU's
viewpoint, the rest of the system is its outer shareable domain, and so
even when snoop signals are wired up, they are only emitted for outer
shareable
According to a downstream commit I found in the Khadas vendor kernel,
the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
how to handle this properly) we should describe it as such. Otherwise
the mismatch leads to all manner of fun with mismatched attributes and
inadvertently
Hi all,
I polished up my original proof-of-concept a little while back, but now
that I've got my hands on my Juno again I've been able to actually test
it to my satisfaction, so here are proper patches!
It probably makes sense for patches #1 and #2 to stay together and both
go via drm-misc,
On Tue, Sep 15, 2020 at 8:27 AM Maxime Ripard wrote:
> Hi,
>
> On Mon, Sep 14, 2020 at 04:39:41PM -0700, Gurchetan Singh wrote:
> > Hi,
> >
> > This set of changes are required for zero-copy virtio-gpu.
> >
> > The following changes since commit
> 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
> >
>
The reference to the VSP device acquired with of_find_device_by_node()
in rcar_du_vsp_init() is never released. Fix it with a drmm action,
which gets run both in the probe error path and in the remove path.
Fixes: 6d62ef3ac30b ("drm: rcar-du: Expose the VSP1 compositor through KMS
planes")
Hi Yu,
Thank you for the patch.
On Thu, Sep 10, 2020 at 09:23:54PM +0800, Yu Kuai wrote:
> if of_find_device_by_node() succeed, rcar_du_vsp_init() doesn't have
> a corresponding put_device(). Thus add a jump target to fix the exception
> handling for this function implementation.
>
> Fixes:
Hi Stefan,
Thank you for the patch.
On Thu, Sep 10, 2020 at 11:24:23AM +0200, Stefan Agner wrote:
> To improve readability and make it easier to add further optional checks
> replace the boolean parameters with a single flag bitfield as parameter
> of drm_atomic_helper_check_plane_state.
>
>
On Tue, Sep 15, 2020 at 03:47:01PM -0400, Lyude Paul wrote:
> On Tue, 2020-09-15 at 15:06 -0400, Rodrigo Vivi wrote:
> > On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > > Since we're about to start adding support for Intel's magic HDR
> > > backlight interface over DPCD, we need to
cc'ing some more people.
On Tue, 15 Sep 2020 at 23:07, Paul Menzel wrote:
>
> Dear Andrew folks, dear Linux folks,
>
>
> With Linux 5.9-rc4 on a Dell OptiPlex 5080 with Intel Core i7-10700 CPU
> @ 2.90GHz, and external
>
> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
>
Hi Prabhakar,
Thank you for the patch.
On Fri, Sep 11, 2020 at 11:07:41AM +0100, Lad Prabhakar wrote:
> rcar_dw_hdmi driver is also used on Renesas RZ/G2 SoC's, update the
> same to reflect the description for DRM_RCAR_DW_HDMI config.
I'm not sure what you mean by "the same" here. I'd propose
Applied. Thanks!
Alex
On Mon, Sep 14, 2020 at 10:37 AM Kazlauskas, Nicholas
wrote:
>
> On 2020-09-14 3:52 a.m., Michel Dänzer wrote:
> > On 2020-09-07 9:57 a.m., Daniel Vetter wrote:
> >> On Fri, Sep 04, 2020 at 12:43:04PM +0200, Michel Dänzer wrote:
> >>> From: Michel Dänzer
> >>>
> >>>
On Tue, 2020-09-15 at 15:06 -0400, Rodrigo Vivi wrote:
> On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > Since we're about to start adding support for Intel's magic HDR
> > backlight interface over DPCD, we need to ensure we're properly
> > programming this field so that Intel
Applied. Thanks!
Alex
On Thu, Sep 10, 2020 at 11:35 AM Harry Wentland wrote:
>
> On 2020-09-09 11:13 p.m., YueHaibing wrote:
> > Add trigger_hotplug debugfs entry.
> >
> > Fixes: 6f77b2ac6280 ("drm/amd/display: Add connector HPD trigger debugfs
> > entry")
> > Signed-off-by: YueHaibing
>
>
Applied. Thanks,
Alex
On Thu, Sep 10, 2020 at 11:34 AM Harry Wentland wrote:
>
> On 2020-09-09 11:26 p.m., YueHaibing wrote:
> > If parse_write_buffer_into_params() fails, we should free
> > wr_buf before return.
> >
> > Fixes: 6f77b2ac6280 ("drm/amd/display: Add connector HPD trigger debugfs
Hi again,
W dniu 14.09.2020 o 23:19, Andrzej Hajda pisze:
> Hi Marek, Michael,
>
> On 14.09.2020 22:01, Michael Tretter wrote:
>> Hi,
>>
>> On Mon, 14 Sep 2020 14:31:19 +0200, Marek Szyprowski wrote:
>>> On 14.09.2020 10:29, Marek Szyprowski wrote:
On 11.09.2020 15:54, Michael Tretter wrote:
On Tue, Sep 15, 2020 at 03:16:32PM -0400, Alex Deucher wrote:
> I question the value of these warnings. Why even have a boolean type
> if you are going to get warnings when you use them...
> That said, applied to avoid getting these patches again and again
> every time someone sees this.
if
This function no longer exists.
Alex
On Thu, Sep 10, 2020 at 4:56 AM Christian König
wrote:
>
> Am 10.09.20 um 04:33 schrieb YueHaibing:
> > If CONFIG_AGP is not set, gcc warns:
> >
> > drivers/gpu/drm/radeon/radeon_ttm.c: In function ‘radeon_ttm_tt_bind’:
> >
On Tue, Sep 15, 2020 at 01:29:38PM -0400, Lyude Paul wrote:
> So-recently a bunch of laptops on the market have started using DPCD
> backlight controls instead of the traditional DDI backlight controls.
> Originally we thought we had this handled by adding VESA backlight
> control support to i915,
Applied. Thanks!
Alex
On Thu, Sep 10, 2020 at 3:23 AM Bernard Zhao wrote:
>
> In fnction is_cr_done & is_ch_eq_done, when done = false
> happened once, no need to circle left ln_count.
> This change is to make the code run a bit fast.
>
> Signed-off-by: Bernard Zhao
> ---
>
I question the value of these warnings. Why even have a boolean type
if you are going to get warnings when you use them...
That said, applied to avoid getting these patches again and again
every time someone sees this.
Alex
On Wed, Sep 9, 2020 at 9:21 AM Christian König wrote:
>
> Acked-by:
On Tue, Sep 15, 2020 at 01:29:36PM -0400, Lyude Paul wrote:
> Since we're going to need to add a set of lower-level PWM backlight
> control hooks to be shared by normal backlight controls and HDR
> backlight controls in SDR mode, let's add a prefix to the external PWM
> backlight functions so that
Applied. Thanks!
Alex
On Wed, Sep 9, 2020 at 7:04 AM Sandeep Raghuraman wrote:
>
> This patch adds support for reporting sclk values for Radeon GPUs, where
> supported.
>
> Signed-off-by: Sandeep Raghuraman
> ---
> drivers/gpu/drm/radeon/radeon_pm.c | 29 -
> 1
On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will
Applied. Thanks!
Alex
On Wed, Sep 9, 2020 at 5:11 AM Christian König wrote:
>
> Am 09.09.20 um 09:57 schrieb Tian Tao:
> > Fix kernel-doc warnings.
> > drivers/gpu/drm/scheduler/sched_fence.c:110: warning: Function parameter or
> > member 'f' not described in
Applied. Thanks!
Alex
On Wed, Sep 9, 2020 at 3:05 AM Randy Dunlap wrote:
>
> From: Randy Dunlap
>
> Fix spellos of "function" in drivers/gpu/drm/amd/display/.
>
> Signed-off-by: Randy Dunlap
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: amd-...@lists.freedesktop.org
> Cc:
Applied. Thanks!
Alex
On Wed, Sep 9, 2020 at 3:05 AM Chen Zhou wrote:
>
> Remove duplicate header which is included twice.
>
> Signed-off-by: Chen Zhou
> ---
> drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
This change breaks tons of systems.
This reverts commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206973
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206697
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=207763
Bug:
On Tue, Sep 8, 2020 at 1:27 AM Sandeep Raghuraman wrote:
>
>
>
> On 9/1/20 2:03 AM, Alex Deucher wrote:
> > On Sun, Aug 30, 2020 at 3:25 AM Sandeep Raghuraman
> > wrote:
> >>
> >> This patch series adds support for reporting sclk and vddc values for
> >> Radeon GPUs, where supported.
> >
> >
Hi Tomas,
Thanks for the patch.
On Tue, Sep 15, 2020 at 08:53:46AM -0700, Laurent Pinchart wrote:
> Hi Thomas,
>
> Thank you for the patch.
>
> On Tue, Sep 15, 2020 at 04:59:57PM +0200, Thomas Zimmermann wrote:
> > The xlnx driver uses CMA helpers with default callback functions.
> >
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #18 from Marco (rodomar...@protonmail.com) ---
As of 5.8.7 I've tried to revert to stock clocks, and I had no black screen
issue under load even after long game sessions.
It does *seems* to be fixed, at least for me.
I don't know
Am 15.09.20 um 17:44 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Christian König
Sent: Tuesday, September 15, 2020 10:31 AM
To: dri-devel@lists.freedesktop.org
Subject: [PATCH] drm/ttm: some cleanups
Unexport ttm_check_under_lowerlimit.
Make ttm_bo_acc_size
On Tue, 15 Sep 2020 19:07:59 +0200, Andrzej Hajda wrote:
>
> W dniu 11.09.2020 o 15:54, Michael Tretter pisze:
> > Platform drivers need to be aware if a mipi dsi device attaches or
> > detaches. Add host_ops to the driver_data for attach and detach
> > callbacks and move the i80 mode selection
Hello,
Is there anything blocking this ?
On Tue, Sep 08, 2020 at 07:03:36PM +0300, Laurent Pinchart wrote:
> Hi Dave and Daniel,
>
> The following changes since commit ce5c207c6b8dd9cdeaeeb2345b8a69335c0d98bf:
>
> Merge tag 'v5.9-rc4' into drm-next (2020-09-08 14:41:40 +1000)
>
> are
On 9/15/20 11:56 AM, Jordan Crouse wrote:
Commit 604234f33658 ("drm/msm: Enable expanded apriv support for a650")
was checking the result of adreno_is_a650() before the gpu revision
got probed in adreno_gpu_init() so it was always coming across as
false. Snoop into the revision ID ahead of time
Hi,
On Mon, Sep 14, 2020 at 04:39:41PM -0700, Gurchetan Singh wrote:
> Hi,
>
> This set of changes are required for zero-copy virtio-gpu.
>
> The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
>
> Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
>
> are available in the
On Wed 09 Sep 09:28 UTC 2020, Dmitry Baryshkov wrote:
> Lontium LT9611UXC is a DSI to HDMI bridge which supports 2 DSI ports
> and I2S port as input and one HDMI port as output. The LT9611UXC chip is
> handled by a separate driver, but the bindings used are fully compatible
> with the LT9611
On Tue, 15 Sep 2020 at 19:50, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.4.66 release.
> There are 132 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On Tue, Sep 15, 2020 at 12:24 AM Thomas Gleixner wrote:
>
> Alternatively we just make highmem a bit more expensive by making these
> maps preemptible. RT is doing this for a long time and it's not that
> horrible.
Ack.
In fact, I've wanted to start just removing kmap support entirely. At
some
On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner wrote:
>
> OTOH, having a working 'preemptible()' or maybe better named
> 'can_schedule()' check makes tons of sense to make decisions about
> allocation modes or other things.
No. I think that those kinds of decisions about actual behavior are
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.
HDR backlights, in particular VESA and Intel's HDR
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.
A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an
Since we're going to need to add a set of lower-level PWM backlight
control hooks to be shared by normal backlight controls and HDR
backlight controls in SDR mode, let's add a prefix to the external PWM
backlight functions so that the difference between them and the high
level PWM-only backlight
Since we're about to start adding support for Intel's magic HDR
backlight interface over DPCD, we need to ensure we're properly
programming this field so that Intel specific sink services are exposed.
Otherwise, 0x300-0x3ff will just read zeroes.
We also take care not to reprogram the source OUI
On Mon, Sep 14, 2020 at 01:59:15PM -0700, Linus Torvalds wrote:
> On Mon, Sep 14, 2020 at 1:45 PM Thomas Gleixner wrote:
> >
> > Recently merged code does:
> >
> > gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC;
> >
> > Looks obviously correct, except for the fact that preemptible() is
>
On Wed, 09 Sep 2020 12:28:22 +0300, Dmitry Baryshkov wrote:
> Lontium LT9611UXC is a DSI to HDMI bridge which supports 2 DSI ports
> and I2S port as input and one HDMI port as output. The LT9611UXC chip is
> handled by a separate driver, but the bindings used are fully compatible
> with the LT9611
W dniu 11.09.2020 o 15:54, Michael Tretter pisze:
> Platform drivers need to be aware if a mipi dsi device attaches or
> detaches. Add host_ops to the driver_data for attach and detach
> callbacks and move the i80 mode selection and the hotplug handling into
> the callback, because these depend
On Tue, Sep 15, 2020 at 08:14:34PM +0530, Naresh Kamboju wrote:
> On Tue, 15 Sep 2020 at 19:50, Greg Kroah-Hartman
> wrote:
> >
> > This is the start of the stable review cycle for the 5.4.66 release.
> > There are 132 patches in this series, all will be posted as a response
> > to this one. If
Commit 604234f33658 ("drm/msm: Enable expanded apriv support for a650")
was checking the result of adreno_is_a650() before the gpu revision
got probed in adreno_gpu_init() so it was always coming across as
false. Snoop into the revision ID ahead of time to correctly set the
hw_apriv flag so that
On Tue, 08 Sep 2020 09:34:17 +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> This patch adds R-Car M3-W+ (R8A77961) SoC bindings.
>
> Signed-off-by: Kuninori Morimoto
> Reviewed-by: Geert Uytterhoeven
> ---
> .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 1
On Tue, 08 Sep 2020 09:34:04 +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> Document the R-Car M3-W+ (R8A77961) SoC in the R-Car DU bindings.
>
> Signed-off-by: Kuninori Morimoto
> ---
> Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
> 1 file changed, 2
On 15/09/2020 17:41, Rob Herring wrote:
> On Mon, Sep 07, 2020 at 10:18:21AM +0200, Neil Armstrong wrote:
>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a),
>> with a custom
>> glue managing the IP resets, clock and data input similar to the DW-HDMI
>> Glue on other
From: Colin Ian King
The variable bit_per_pix is a u8 and is promoted in the multiplication
to an int type and then sign extended to a u64. If the result of the
int multiplication is greater than 0x7fff then the upper 32 bits will
be set to 1 as a result of the sign extension. Avoid this by
On 15/09/2020 15:59, Thomas Zimmermann wrote:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in i915.
v2:
* move object-function instance to i915_gem_object.c (Jani)
On Mon, Sep 14, 2020 at 10:42:13PM +0200, Thomas Gleixner wrote:
> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
> removed. Cleanup the leftovers before doing so.
>
> Signed-off-by: Thomas Gleixner
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Will Deacon
> ---
>
On Mon, Sep 14, 2020 at 10:42:15PM +0200, Thomas Gleixner wrote:
> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
> removed. Cleanup the leftovers before doing so.
>
> Signed-off-by: Thomas Gleixner
> ---
> include/linux/bit_spinlock.h |4 +---
> 1 file changed, 1
Commit 604234f33658 ("drm/msm: Enable expanded apriv support for a650")
was checking the result of adreno_is_a650() before the gpu revision
got probed in adreno_gpu_init() so it was always coming across as
false. Snoop into the revision ID ahead of time to correctly set the
hw_apriv flag so that
Hi Thomas,
Thank you for the patch.
On Tue, Sep 15, 2020 at 04:59:57PM +0200, Thomas Zimmermann wrote:
> The xlnx driver uses CMA helpers with default callback functions.
> Initialize the driver structure with the rsp CMA helper macro. The
> driver is being converted to use GEM object functions
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Tuesday, September 15, 2020 10:31 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH] drm/ttm: some cleanups
>
>Unexport ttm_check_under_lowerlimit.
>Make ttm_bo_acc_size static and unexport it.
>Remove
On Mon, Sep 07, 2020 at 10:18:21AM +0200, Neil Armstrong wrote:
> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a),
> with a custom
> glue managing the IP resets, clock and data input similar to the DW-HDMI Glue
> on other
> Amlogic SoCs.
>
> Signed-off-by: Neil
On Mon, Sep 07, 2020 at 10:18:20AM +0200, Neil Armstrong wrote:
> The Amlogic AXG SoC family has a downgraded VPU supporting only MIPI-DSI
> output
> after it's ENCL DPI encoder output.
>
> Signed-off-by: Neil Armstrong
> ---
> .../bindings/display/amlogic,meson-vpu.yaml | 36
Added my rb to the amdgpu and radeon patches.
Should we pick those up through the amd branches or do you want to push
everything to drm-misc-next?
I think the later since this should result in much merge clash.
Christian.
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
The GEM and PRIME
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in radeon.
v2:
* move object-function instance to radeon_gem.c (Christian)
On Tue, Sep 15, 2020 at 04:59:39PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in armada.
>
> Signed-off-by: Thomas Zimmermann
Acked-by:
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v2:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vc4. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Eric
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in pl111. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v2:
* use
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in rockchip. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
---
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vkms.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vkms/vkms_drv.c | 8
drivers/gpu/drm/vkms/vkms_gem.c | 13
The xlnx driver uses CMA helpers with default callback functions.
Initialize the driver structure with the rsp CMA helper macro. The
driver is being converted to use GEM object functions as part of
this change.
Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
to their default
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in mediatek. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
---
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in xen. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v2:
* convert xen_drm_drv_free_object_unlocked()
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vgem. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
---
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in tegra.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tegra/drm.c | 4
drivers/gpu/drm/tegra/gem.c | 8
2
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in etnaviv. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
---
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in msm. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
---
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in gma500.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/framebuffer.c | 2 ++
drivers/gpu/drm/gma500/gem.c |
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces virtgpu's per-driver PRIME export
function with a per-object function.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/virtio/virtgpu_drv.c| 1 -
Several GEM and PRIME callbacks have been deprecated in favor of
per-instance GEM object functions. Remove the callbacks as they are
now unused. The only exception is .gem_prime_mmap, which is still
in use by several drivers.
What is also gone is gem_vm_ops in struct drm_driver. All drivers now
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in nouveau.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 -
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in omapdrm.
v2:
* make omap_gem_free_object() static (Tomi)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in radeon.
v2:
* move object-function instance to radeon_gem.c (Christian)
* set callbacks in
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in i915.
v2:
* move object-function instance to i915_gem_object.c (Jani)
Signed-off-by: Thomas Zimmermann
---
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in exynos. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
---
The GEM and PRIME related callbacks in struct drm_driver are deprecated in
favor of GEM object functions in struct drm_gem_object_funcs. This patchset
converts the remaining drivers to object functions and removes most of the
obsolete interfaces.
Patches #1 to #16 and #18 to #19 convert DRM
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v2:
* move object-function instance to
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in armada.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/armada/armada_drv.c | 3 ---
drivers/gpu/drm/armada/armada_gem.c |
On Mon, Sep 14, 2020 at 11:26:30AM +0530, Karthik B S wrote:
> This hook is added to avoid writing other plane registers in case of
> async flips, so that we do not write the double buffered registers
> during async surface address update.
>
> v7: -Plane ctl needs bits from skl_plane_ctl_crtc as
Hi,
Here are three improvements to the ingenic-drm driver.
Patch 1 adds 30-bit RGB support for the SoCs that support it. Not much
to see here.
Patch 2 is here to allow the pixel clock to be re-set when the SoC's
main PLL changes, which can happen at any time. We get a callback before
and after
Hi Sam,
On 27/8/20 10:59, Enric Balletbo i Serra wrote:
> The first 4 patches of the series version 2:
> - drm/bridge_connector: Set default status connected for eDP connectors
> - drm/bridge: ps8640: Get the EDID from eDP control
> - drm/bridge: ps8640: Return an error for incorrect attach
Hi David, Chris and lists
I am inquiring about the current status of #2024 [1]
Problem: Kernels 5.7.x , 5.8.x, current 5.9-rcs and drm-tip have a large
regression on (some?) Haswell (HSW)
This is verified by _multiple people_ using different methods.
All his is documented in [1] , Kernel
Add support for static memory reserved from Device Tree. Since we're
using GEM buffers backed by CMA, it is interesting to have an option to
specify the CMA area where the GEM buffers will be allocated.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 19
Starting from the JZ4760 SoC, the primary and overlay planes support
30-bit pixel modes (10 bits per color component). Add support for these
in the ingenic-drm driver.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 41 +--
On Tue, Sep 15, 2020 at 12:34 AM Vaittinen, Matti
wrote:
>
>
> Hello All,
>
> On Mon, 2020-09-14 at 16:44 -0600, Rob Herring wrote:
> > On Fri, Sep 04, 2020 at 04:53:05PM +0200, Krzysztof Kozlowski wrote:
> > > Add common properties appearing in DTSes (clock-names,
> > > clock-output-names) to
Old Ingenic SoCs can overclock very well, up to +50% of their nominal
clock rate, whithout requiring overvolting or anything like that, just
by changing the rate of the main PLL. Unfortunately, all clocks on the
system are derived from that PLL, and when the PLL rate is updated, so
is our pixel
1 - 100 of 170 matches
Mail list logo
