This commit implements the "active color format" drm property for the Intel GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 21 +++-
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c |
This commit implements the "active color range" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 36 insertions(+)
diff --git
This commit implements the "preferred color format" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
2 files changed, 22 insertions(+), 6
This commit implements the "active color range" drm property for the Intel GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 4
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
This commit implements the "preferred color format" drm property for the Intel
GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 +
3
This commit implements the "active color format" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 28 +--
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 30 insertions(+), 2
Add a new general drm property "preferred color format" which can be used by
userspace to tell the graphic drivers to which color format to use.
Possible options are:
- auto (default/current behaviour)
- rgb
- ycbcr444
- ycbcr422 (not supported by both amdgpu and i915)
-
Add a new general drm property "active bpc" which can be used by graphic drivers
to report the applied bit depth per pixel back to userspace.
While "max bpc" can be used to change the color depth, there was no way to check
which one actually got used. While in theory the driver chooses the
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.
There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of the
This commit implements the "active bpc" drm property for the AMD GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
2 files changed, 22 insertions(+), 1 deletion(-)
diff
Add a new general drm property "active color range" which can be used by graphic
drivers to report the used color range back to userspace.
There was no way to check which color range got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of the
monitor
This commit implements the "active bpc" drm property for the Intel GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 14 ++
drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an
integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git
I started work on my proposal for better color handling in Linux display
drivers: https://lkml.org/lkml/2021/5/12/764
In this 3rd revision everything except the generalised Broadcast RGB
implementation is included. I did however not yet include everything suggested
in the feedback for v1 and v2.
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 when the display reports
On Tue, Jun 15, 2021 at 03:35:19PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This is straightforward conversion, the mdev_state is actually serving as
> the vfio_device and we can replace all the mdev_get_drvdata()'s and the
> wonky dead code with a simple container_of().
>
>
On Tue, Jun 15, 2021 at 03:35:18PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This is straightforward conversion, the mdev_state is actually serving as
> the vfio_device and we can replace all the mdev_get_drvdata()'s and the
> wonky dead code with a simple container_of().
>
>
On Tue, Jun 15, 2021 at 03:35:17PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This is straightforward conversion, the mdev_state is actually serving as
> the vfio_device and we can replace all the mdev_get_drvdata()'s and the
> wonky dead code with a simple container_of()
>
>
On Tue, Jun 15, 2021 at 03:35:16PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This allows a mdev driver to opt out of using vfio_mdev.c, instead the
> driver will provide a 'struct mdev_driver' and register directly with the
> driver core.
>
> Much of mdev_parent_ops becomes
On Tue, Jun 15, 2021 at 03:35:15PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> For some reason the vfio_mdev shim mdev_driver has its own module and
> kconfig. As the next patch requires access to it from mdev.ko merge the
> two modules together and remove VFIO_MDEV_DEVICE.
>
>
On Tue, Jun 15, 2021 at 03:35:14PM +0200, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This is intended as a replacement API for device_bind_driver(). It has at
> least the following benefits:
>
> - Internal locking. Few of the users of device_bind_driver() follow the
> locking rules
On Tue, Jun 15, 2021 at 03:35:11PM +0200, Christoph Hellwig wrote:
> really_probe tries to special case errors from ->probe, but due to all
> other initialization added to the function over time now a lot of
> internal errors hit that code path as well. Untangle that by adding
> a new probe_err
On Tue, Jun 15, 2021 at 03:53:46PM +0200, Cornelia Huck wrote:
> On Tue, Jun 15 2021, Christoph Hellwig wrote:
>
> > really_probe tries to special case errors from ->probe, but due to all
> > other initialization added to the function over time now a lot of
> > internal errors hit that code path
On Tue, Jun 15 2021, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This allows a mdev driver to opt out of using vfio_mdev.c, instead the
> driver will provide a 'struct mdev_driver' and register directly with the
> driver core.
>
> Much of mdev_parent_ops becomes unused in this mode:
>
On Tue, Jun 15 2021, Christoph Hellwig wrote:
> EPROBE_DEFER is an internal kernel error code and it should not be leaked
> to userspace via the bind_store() sysfs. Userspace doesn't have this
> constant and cannot understand it.
>
> Further, it doesn't really make sense to have userspace
On Tue, Jun 15 2021, Christoph Hellwig wrote:
> really_probe tries to special case errors from ->probe, but due to all
> other initialization added to the function over time now a lot of
> internal errors hit that code path as well. Untangle that by adding
> a new probe_err local variable and
v10 here: https://lore.kernel.org/patchwork/cover/1446882/
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 33 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 6
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 36
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and use
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at
Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/kernel/dma/swiotlb.c
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel/dma/swiotlb.c
Propagate the swiotlb_force setting into io_tlb_default_mem->force and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 11 +++
kernel/dma/direct.c | 2 +-
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/pci/xen-pcifront.c
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 7 ---
kernel/dma/direct.c |
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
---
drivers/base/core.c| 4
include/linux/device.h | 4
kernel/dma/swiotlb.c | 8
3 files changed, 12 insertions(+), 4
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 49 ++--
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for
The ttm_bo_init_reserved() function calls ttm_bo_put(bo) which calls
nouveau_bo_del_ttm() which frees the "nvbo.bo" so the nouveau_bo_ref()
call leads to a double free.
Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object")
Signed-off-by: Dan Carpenter
---
This fix is
On 06/15, Wan Jiabing wrote:
> Fix the following coccicheck warning:
> drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c:917:56-57:
> pstate_enabled: first occurrence line 935, second occurrence line 937
>
> Signed-off-by: Wan Jiabing
> ---
>
Op 15-06-2021 om 14:24 schreef Thomas Hellström:
> Fix two memory leaks introduced with the ttm backend.
>
> Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 ++
> 1 file changed, 2
Fix two memory leaks introduced with the ttm backend.
Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Den 15.06.2021 11.17, skrev Peter Stuge:
> Hi Noralf,
>
> Noralf Trønnes wrote:
+static int gud_usb_bulk(struct gud_device *gdrm, size_t len)
> ..
+ timer_setup_on_stack(, gud_usb_bulk_timeout, 0);
+ mod_timer(, jiffies + msecs_to_jiffies(3000));
+
+
Am 15.06.21 um 14:11 schrieb Pan, Xinhui:
2021年6月15日 20:01，Christian König 写道：
Am 15.06.21 um 13:57 schrieb xinhui pan:
Amdgpu set SG flag in populate callback. So TTM still count pages in SG
BO.
It's probably better to fix this instead. E.g. why does amdgpu modify the SG
flag during
> 2021年6月15日 20:01，Christian König 写道：
>
> Am 15.06.21 um 13:57 schrieb xinhui pan:
>> Amdgpu set SG flag in populate callback. So TTM still count pages in SG
>> BO.
>
> It's probably better to fix this instead. E.g. why does amdgpu modify the SG
> flag during populate and not during initial
On Tuesday, June 15th, 2021 at 12:16, Pekka Paalanen
wrote:
> Good reminder about CRCs. CRCs have zero tolerance, so they are not
> useful for testing properties that have any leeway, are they?
IIRC, IGT's alpha blending test currently computes the CRC for all
possible roundings, then checks
Am 15.06.21 um 13:57 schrieb xinhui pan:
Amdgpu set SG flag in populate callback. So TTM still count pages in SG
BO.
It's probably better to fix this instead. E.g. why does amdgpu modify
the SG flag during populate and not during initial creation? That
doesn't seem to make sense.
Amdgpu set SG flag in populate callback. So TTM still count pages in SG
BO.
One easy way to fix this is lets count pages after populate callback.
We hit one issue that amdgpu alloc many SG BOs, but TTM try to do swap
again and again even if swapout does not swap SG BOs at all.
Signed-off-by:
On Tue, 15 Jun 2021 12:45:57 +0300
Laurent Pinchart wrote:
> On Tue, Jun 15, 2021 at 07:15:18AM +, Simon Ser wrote:
> > On Tuesday, June 15th, 2021 at 09:03, Pekka Paalanen
> > wrote:
> >
> > > indeed it will, but what else could one do to test userspace KMS
> > > clients in generic CI
Fix the following coccicheck warning:
drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c:917:56-57:
pstate_enabled: first occurrence line 935, second occurrence line 937
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 1 -
1 file changed, 1 deletion(-)
To help avoid evicting already resident buffers from the batch we're
processing, perform locking as a separate step.
Signed-off-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 25 ---
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git
Fix the following checkinclude.pl warning:
drivers/gpu/drm/i915/gt/intel_region_lmem.c
8 #include "intel_region_lmem.h"
12 #include "intel_region_lmem.h"
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git
Daniel pointed me towards this function and there are multiple obvious problems
in the implementation.
First of all the retry loop is not working as intended. In general the retry
makes only sense if you grab the reference first and then check the retry. Then
we skipped checking the exclusive
On Thu, May 27, 2021 at 3:42 PM Hsin-Yi Wang wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results
On Mon, Jun 14 2021, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This allows a mdev driver to opt out of using vfio_mdev.c, instead the
> driver will provide a 'struct mdev_driver' and register directly with the
> driver core.
>
> Much of mdev_parent_ops becomes unused in this mode:
>
On Mon, Jun 14 2021, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> For some reason the vfio_mdev shim mdev_driver has its own module and
> kconfig. As the next patch requires access to it from mdev.ko merge the
> two modules together and remove VFIO_MDEV_DEVICE.
>
> A later patch deletes
On Mon, Jun 14 2021, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> This is intended as a replacement API for device_bind_driver(). It has at
> least the following benefits:
>
> - Internal locking. Few of the users of device_bind_driver() follow the
> locking rules
>
> - Calls device
Add support for the 10.3" E Ink panel described at:
https://www.eink.com/product.html?type=productdetail=7
Signed-off-by: Alistair Francis
---
v2:
- Fix build warning
- Document new string
.../bindings/display/panel/panel-simple.yaml | 2 ++
drivers/gpu/drm/panel/panel-simple.c |
Add the E Ink Corporation to the vendor bindings.
Signed-off-by: Alistair Francis
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
On Mon, Jun 14 2021, Christoph Hellwig wrote:
> Currently really_probe() returns 1 on success and 0 if the probe() call
> fails. This return code arrangement is designed to be useful for
> __device_attach_driver() which is walking the device list and trying every
> driver. 0 means to keep
On Mon, Jun 14 2021, Christoph Hellwig wrote:
> From: Jason Gunthorpe
>
> Checking if the dev is dead or if the dev is already bound is a required
> precondition to invoking driver_probe_device(). All the call chains
> leading here duplicate these checks.
>
> Add it directly to
Invokes the pipelined page migration through blt, for
i915_ttm_move requests of eviction and also obj clear.
v2:
- subfunction for accel_move (Thomas)
- engine_pm_get/put around context_move/clear (Thomas)
- Invalidation at accel_clear (Thomas)
v3:
- Timeout is set for MAX_SCHEDULE_TIMEOUT
On Thu, Jun 03, 2021 at 02:47:51PM -0700, Hridya Valsaraju wrote:
> Overview
>
> The patch adds DMA-BUF statistics to /sys/kernel/dmabuf/buffers. It
> allows statistics to be enabled for each DMA-BUF in sysfs by enabling
> the config CONFIG_DMABUF_SYSFS_STATS.
>
> The following stats
From: Tvrtko Ursulin
When a non-persistent context exits we currently mark it as banned in
order to trigger fast termination of any outstanding GPU jobs it may have
left running.
In doing so we apply a very strict 1ms limit in which the left over job
has to preempt before we issues an engine
On Tue, Jun 15, 2021 at 07:15:18AM +, Simon Ser wrote:
> On Tuesday, June 15th, 2021 at 09:03, Pekka Paalanen
> wrote:
>
> > indeed it will, but what else could one do to test userspace KMS
> > clients in generic CI where all you can have is virtual hardware? Maybe
> > in the long run VKMS
Hi
Am 15.06.21 um 05:14 schrieb Pu Lehui:
There is a gcc '-Wunused-const-variable' warning:
drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:152:23: warning:
'hyperv_modifiers' defined but not used [-Wunused-const-variable=]
while the variable should be used in
Hi Noralf,
Noralf Trønnes wrote:
> >> +static int gud_usb_bulk(struct gud_device *gdrm, size_t len)
..
> >> + timer_setup_on_stack(, gud_usb_bulk_timeout, 0);
> >> + mod_timer(, jiffies + msecs_to_jiffies(3000));
> >> +
> >> + usb_sg_wait();
> >> +
> >> + if
On 14.06.2021 21:42, Matthew Brost wrote:
> From: Michal Wajdeczko
>
> Most of the changes to the 62.0.0 firmware revolved around CTB
> communication channel. Conform to the new (stable) CTB protocol.
>
> Signed-off-by: John Harrison
> Signed-off-by: Michal Wajdeczko
> Signed-off-by:
Den 14.06.2021 22.54, skrev Linus Walleij:
> Hi Noralf,
>
> On Mon, Mar 29, 2021 at 8:01 PM Noralf Trønnes wrote:
>
>> There'a limit to how big a kmalloc buffer can be, and as memory gets
>> fragmented it becomes more difficult to get big buffers. The downside of
>> smaller buffers is that
Hi Jason & Daniel,
maybe I should explain once more where the problem with this approach is
and why I think we need to get that fixed before we can do something
like this here.
To summarize what this patch here does is that it copies the exclusive
fence and/or the shared fences into a
Hi,
On 6/15/21 9:40 AM, Greg Kroah-Hartman wrote:
> On Fri, Jun 04, 2021 at 09:48:32PM +0200, Hans de Goede wrote:
>> Here is v3 of my patchset making DP over Type-C work on devices where the
>> Type-C controller does not drive the HPD pin on the GPU, but instead
>> we need to forward HPD events
Hi Michael,
Am Dienstag, dem 15.06.2021 um 00:17 +0200 schrieb Michael Walle:
> The LS1028A SoC errata sheet mentions A-050121 "GPU hangs if clock
> gating for Rasterizer, Setup Engine and Texture Engine are enabled".
> The workaround is to disable the corresponding clock gatings.
>
>
On Fri, Jun 04, 2021 at 09:48:32PM +0200, Hans de Goede wrote:
> Here is v3 of my patchset making DP over Type-C work on devices where the
> Type-C controller does not drive the HPD pin on the GPU, but instead
> we need to forward HPD events from the Type-C controller to the DRM driver.
>
>
On Fri, Jun 04, 2021 at 09:48:40PM +0200, Hans de Goede wrote:
> Use the new drm_connector_oob_hotplug_event() functions to let drm/kms
> drivers know about DisplayPort over Type-C hotplug events.
>
> Reviewed-by: Heikki Krogerus
> Tested-by: Heikki Krogerus
> Signed-off-by: Hans de Goede
On Fri, Jun 04, 2021 at 09:48:39PM +0200, Hans de Goede wrote:
> Make dp_altmode_notify() handle the dp->data.conf == 0 case too,
> rather then having separate code-paths for this in various places
> which call it.
>
> Reviewed-by: Heikki Krogerus
> Tested-by: Heikki Krogerus
> Signed-off-by:
On Tuesday, June 15th, 2021 at 09:03, Pekka Paalanen
wrote:
> indeed it will, but what else could one do to test userspace KMS
> clients in generic CI where all you can have is virtual hardware? Maybe
> in the long run VKMS needs to loop back to a userspace daemon that
> implements all the
On Thu, 10 Jun 2021 16:14:42 -0500
Jason Ekstrand wrote:
> This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds
> documentation for DMA_BUF_IOCTL_SYNC.
>
> v2 (Daniel Vetter):
> - Fix a couple typos
> - Add commentary about synchronization with other devices
> - Use item
Hi steve,
After I send the V2,I found I setting a wrong email
configuration,I hope it doesn't affect the patch submission :)
Did you received my another patch about panfrost_job.c?
Author: tangchunyou
Date: Wed Jun 9 14:44:52 2021 +0800
modified:
On Mon, 14 Jun 2021 19:33:47 +0300
Laurent Pinchart wrote:
> On Mon, Jun 14, 2021 at 04:24:13PM +0100, Liviu Dudau wrote:
> > On Mon, Jun 14, 2021 at 05:49:12PM +0300, Pekka Paalanen wrote:
> > > On Fri, 11 Jun 2021 13:03:09 +0100
> > > Liviu Dudau wrote:
> > >
> > > > On Fri, Jun 11, 2021
On Fri, Jun 4, 2021 at 11:57 PM Kai-Heng Feng
wrote:
>
> On Thu, May 20, 2021 at 2:58 PM Kai-Heng Feng
> wrote:
> >
> > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> > to discrete GFX after S3. This is not desirable, because userspace will
> > treat connected display
From: tangchunyou
of the low 8 bits.
Signed-off-by: tangchunyou
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 1fffb6a0b24f..d2d287bbf4e7
From: tangchunyou
of the low 8 bits.
Signed-off-by: tangchunyou
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 1fffb6a0b24f..d2d287bbf4e7
Am 25.05.21 um 10:25 schrieb Baokun Li:
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/nouveau/nouveau_bo.c: In function 'nouveau_ttm_tt_populate':
drivers/gpu/drm/nouveau/nouveau_bo.c:1258:17: warning:
variable ‘dev’ set but not used [-Wunused-but-set-variable]
101 - 185 of 185 matches
Mail list logo
