Hi Dave, Daniel,
Fixes for 5.9.
The following changes since commit 7f7a47952c0f981f9c9a6409c8cf8d025d55af64:
Merge tag 'drm-misc-fixes-2020-09-09' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2020-09-11 09:49:23
+1000)
are available in the Git repository at:
From: Dave Airlie
The pipeline and accel cleansups has similiar paths here.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 38 ---
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
From: Dave Airlie
This moves unbind into the driver side on destroy paths.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 +
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 +
drivers/gpu/drm/nouveau/nouveau_sgdma.c| 1 +
drivers/gpu/drm/radeon/radeon_ttm.c
From: Dave Airlie
Call the driver first and have it call the common code cleanup.
This is useful later to fix unbind.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 +
drivers/gpu/drm/drm_gem_vram_helper.c | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.c
From: Dave Airlie
Now the bind functions have all the protection explicitly the
drivers can just call them directly, and the api can be unexported
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 5 -
From: Dave Airlie
Both accel cleanup and pipeline move had the same code, make
a single function for it.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 105 --
1 file changed, 43 insertions(+), 62 deletions(-)
diff --git
From: Dave Airlie
This pattern is called in a few places, just clean it up.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 18 ++
include/drm/ttm/ttm_bo_driver.h | 10 --
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git
From: Dave Airlie
This moves the generic tracking into the drivers and protects
against reentrancy in the drivers. It fixes up radeon and agp
to be able to query the bound status as that is required.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 12 +
I've pulled a few of the cleaner bits of rework out for review.
The first thing is to move all the tt bind tracking into the driver
so the core doesn't do it all anymore. Once that is done it's possible
to flip over how destroy works so the drivers call some common code
instead of vice-versa.
[AMD Official Use Only - Internal Distribution Only]
Thanks. Reviewed-by: Evan Quan
-Original Message-
From: Xiaoliang Pang
Sent: Thursday, September 17, 2020 11:46 AM
To: Quan, Evan ; Deucher, Alexander
; Koenig, Christian ;
airl...@linux.ie; dan...@ffwll.ch; Feng, Kenneth ;
Replace horizontal_backporch_byte with vm->hback_porch * bpp to aovid
flowing judgement negative number.
if ((vm->hfront_porch * dsi_tmp_buf_bpp + horizontal_backporch_byte) >
data_phy_cycles * dsi->lanes + delta)
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 54
Hi Dave and Daniel,
As the original pull request hasn't been pulled yet, here's an updated
version that collects more acks and rb's, and includes an additional
patch.
The following changes since commit 818280d5adf1d80e78f95821815148abe9407e14:
Merge v5.9-rc5 into drm-next (2020-09-14 17:19:11
Hi Kieran,
On Wed, Sep 16, 2020 at 11:26:36AM +0100, Kieran Bingham wrote:
> On 16/09/2020 00:38, Laurent Pinchart wrote:
> > 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
Hi Tomi,
Thank you for the patch.
On Wed, Sep 16, 2020 at 05:44:40PM +0300, Tomi Valkeinen wrote:
> Add binding for DisplayPort connector. A few notes:
>
> * Similar to hdmi-connector, it has hpd-gpios as an optional property,
> as the HPD could also be handled by, e.g., the DP bridge.
>
> *
On Tue, Sep 8, 2020 at 11:55 PM Gerd Hoffmann wrote:
> Hi,
>
> > @@ -100,7 +102,7 @@ struct drm_virtgpu_resource_info {
> > __u32 bo_handle;
> > __u32 res_handle;
> > __u32 size;
> > - __u32 stride;
> > + __u32 blob_mem;
> > };
>
> Huh? This is not in the virtio
For upcoming blob resources, userspace can specify that the
resource will be used for cross-device sharing. This is mainly
for exportable blobs that will only shared with the virtgpu
display but not across devices.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
From: Gerd Hoffmann
A blob resource is a container for:
- VIRTIO_GPU_BLOB_MEM_GUEST: a guest memory allocation
(referred to as a "guest-only blob resource")
- VIRTIO_GPU_BLOB_MEM_HOST3D: a host3d memory allocation
(referred to as a "host-only blob resource")
-
The old transfer ioctls may work on blob resources, and there is no
TRANSFER_BLOB hypercall now for simplicity.
The guest may have a image view on the blob resources such that the
stride is not equal to width * bytes_per_pixel.
For host-only blobs, we can repurpose the transfer ioctls to
VRAM object will need it.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 2 ++
drivers/gpu/drm/virtio/virtgpu_object.c | 3 +--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
New api changes are now available to userspace. Also, the
comparison to true is redundant, so remove it.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git
This exposes the host visible feature to userspace. Without it,
it is an error to specify BLOB_MEM_HOST3D with
BLOG_FLAG_USE_MAPPABLE.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
Acked-by: Lingfeng Yang
---
include/uapi/drm/virtgpu_drm.h | 1 +
1 file changed, 1 insertion(+)
diff
From: Gerd Hoffmann
Implement resource create blob as specified.
Signed-off-by: Gerd Hoffmann
Co-developed-by: Gurchetan Singh
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 4 +-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 136
SCANOUT_BLOB forwards the DRM framebuffer metadata to the host. The
modifier is intentionally left out -- it may be possible to query
the host for that.
We also assume one blob resource per DRM framebuffer. That too is
an intentional simplification.
Signed-off-by: Gurchetan Singh
Acked-by:
From: Gerd Hoffmann
The availability of the host visible region means host 3D
allocations can be directly mapped in the guest.
Signed-off-by: Gerd Hoffmann
Co-developed-by: Gurchetan Singh
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c |
Useful for upcoming blob resources.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
This feature was recently added to virtio-gpu, lets make
it userspace queryable. It's an error to use
BLOB_FLAG_USE_CROSS_DEVICE when this feature is not present.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
include/uapi/drm/virtgpu_drm.h | 1 +
1 file changed, 1 insertion(+)
Useful for upcoming blob resources.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_object.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
From: Gerd Hoffmann
A virtio-gpu vram object is based on range-based allocation.
No guest shmemfs backing, so we call drm_gem_private_object_init.
This is for host memory without any guest backing (atleast initially).
Signed-off-by: Gerd Hoffmann
Co-developed-by: Gurchetan Singh
RESOURCE_MAP_BLOB / RESOURCE_UNMAP_BLOB can use this.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 6 +++---
drivers/gpu/drm/virtio/virtgpu_prime.c | 6 +++---
drivers/gpu/drm/virtio/virtgpu_vq.c| 10 +-
3 files changed, 11
From: Gerd Hoffmann
Let's proble for VIRTIO_GPU_F_RESOURCE_BLOB.
Signed-off-by: Gerd Hoffmann
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.h
This makes blob resources available to guest userspace. They are needed
for GL4.5, Vulkan and zero-copy virtio-gpu.
For Mesa, blob resources have been tested with Piglit's ARB_buffer_storage
tests and apitraces. Apitraces of GL4.5 games show we're between 70%
to 80% of host performance on Iris,
From: Gerd Hoffmann
This patch adds a new virtgpu feature that allows directly
mapping host allocated resources.
This is based on virtio shared memory regions, which allows
querying for memory regions using PCI transport. Each shared
memory region has an associated "shmid", the meaning of which
The stride field has never been used, so repurpose it to be
"blob_mem". This way, userspace can know the memory properties
of the blob if it's passed between userspace processes and
no suitable userspace API exists to transmit that knowledge.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
This implements the blob hypercall interface.
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 15 +++
drivers/gpu/drm/virtio/virtgpu_vq.c | 65
2 files changed, 80 insertions(+)
diff --git
Hi, Dave & Daniel:
This includes:
1. Fix scrolling of panel
2. Remove duplicated include
3. Use CPU when fail to get cmdq event
4. Add missing put_device() call
Regards,
Chun-Kuang.
The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
Linux 5.9-rc1 (2020-08-16
On Wed, Sep 16, 2020 at 11:43:02PM +0200, Daniel Vetter wrote:
> On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney wrote:
> >
> > On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote:
> > > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney
> > > wrote:
> > > >
> > > > On Wed, Sep 16,
On Wed, Sep 16, 2020 at 3:04 AM Christoph Hellwig wrote:
>
> On Tue, Sep 15, 2020 at 02:46:07PM -0400, Alex Deucher wrote:
> > This change breaks tons of systems.
>
> Did you do at least some basic root causing on why? Do GPUs get
> fed address they can't deal with? Any examples?
>
> Bug 1
On Mon, Feb 24, 2020 at 4:20 AM Thomas Backlund wrote:
>
> Den 09-01-2020 kl. 17:12, skrev Christian König:
> > Hi Christoph,
> >
> > Am 09.01.20 um 15:14 schrieb Christoph Hellwig:
> >> Hi Woody,
> >>
> >> sorry for the late reply, I've been off to a vacation over the holidays.
> >>
> >> On Sat,
https://bugzilla.kernel.org/show_bug.cgi?id=207763
--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
Another thing to try, does setting radeon.agpmode=-1 fix the issue?
--
You are receiving this mail because:
You are watching the assignee of the bug.
W dniu 15.09.2020 o 20:02, Michael Tretter pisze:
> 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
On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney wrote:
>
> On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote:
> > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote:
> > >
> > > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote:
> > > > On Tue, Sep 15, 2020 at 7:35
On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote:
> On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote:
> >
> > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds
> > > wrote:
> > > >
> > > > On Tue, Sep 15, 2020
https://bugzilla.kernel.org/show_bug.cgi?id=207763
--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
Does it work correctly with 5.9-rc1 or newer?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
On Wed, Sep 16, 2020 at 08:23:52PM +0100, Matthew Wilcox wrote:
> On Mon, Sep 14, 2020 at 11:55:24PM +0200, Thomas Gleixner wrote:
> > But just look at any check which uses preemptible(), especially those
> > which check !preemptible():
>
> hmm.
>
> +++ b/include/linux/preempt.h
> @@ -180,7
On Wed, Sep 16, 2020 at 11:32:00AM -0700, Linus Torvalds wrote:
> On Wed, Sep 16, 2020 at 8:29 AM Paul E. McKenney wrote:
> >
> > All fair, but some of us need to write code that must handle being
> > invoked from a wide variety of contexts.
>
> Note that I think that core functionality is
On 9/16/20 10:44 PM, Dmitry Osipenko wrote:
05.09.2020 13:34, Mikko Perttunen пишет:
With job recovery becoming optional, syncpoints may have a mismatch
between their value and max value when freed. As such, when freeing,
set the max value to the current value of the syncpoint so that it
is in
On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote:
>
> On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote:
> > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds
> > wrote:
> > >
> > > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner
> > > wrote:
> > > >
> > > > OTOH, having a
On Wed, Sep 16, 2020 at 10:01 PM Karol Herbst wrote:
>
> On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline wrote:
> >
> > The temp_get() function currently returns negative error numbers or a
> > temperature. However, the thermal sensors can (in theory) measure
> > negative temperatures. Some
On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline wrote:
>
> The temp_get() function currently returns negative error numbers or a
> temperature. However, the thermal sensors can (in theory) measure
> negative temperatures. Some implementations of temp_get() correctly
> clamp negative temperature
Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of
new gp1xx temperature sensor") added support for reading finer-grain
temperatures, but continued to report temperatures in 1 degree Celsius
increments via nvkm_therm_temp_get().
This alters the temp_get() API to return
The temp_get() function currently returns negative error numbers or a
temperature. However, the thermal sensors can (in theory) measure
negative temperatures. Some implementations of temp_get() correctly
clamp negative temperature readings to 0 so that users do not mistake
them for errors, but
Hi folks,
This series adjusts the temp_get() interface in the thermal functions to
report milli-degrees, and additionally alters the way errors are
reported. As I went through all the users and implementations I realized
that Pascal's temp_get() implementation didn't include turning negative
On Thu, 17 Sep 2020 at 00:24, Christian König
wrote:
>
> When we move from the SYSTEM domain to the TT domain
> we still need to potentially change the caching state.
>
> This is most likely the source of a bunch of problems with
> AGP and USWC together with hibernation and swap.
I'm going to
Add binding for DisplayPort connector. A few notes:
* Similar to hdmi-connector, it has hpd-gpios as an optional property,
as the HPD could also be handled by, e.g., the DP bridge.
* dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it
is not strictly required: standard DP
On Tue, Sep 15, 2020 at 12:57 PM Thomas Gleixner wrote:
>
> You wish. I just found a 7 year old bug in a 10G network driver which
> surely would have been found if people would enable debug configs and
> not just run the crap on their PREEMPT_NONE, all debug off kernel. And
> that driver is not
On Wed, Sep 16, 2020 at 8:29 AM Paul E. McKenney wrote:
>
> All fair, but some of us need to write code that must handle being
> invoked from a wide variety of contexts.
Note that I think that core functionality is different from random drivers.
Of course core code can (and will) look at things
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
> 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
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
>
> > So I get a performance regression with the dma-coherent approach, even if
> > it's
> > clearly the cleaner.
>
> That's bizarre -- this should really be the faster of the two.
Coherency may not be free. CortexA9 had something like
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
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
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 about to add support for a second type of backlight control
interface over DP AUX (specifically, Intel's proprietary HDR backlight
controls) let's rename all of the current backlight hooks we have for
vesa to make it clear that they're specific to the VESA interface and
not Intel's.
Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting
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
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.
No functional changes yet, this just adds definitions for all of the
known DPCD registers used by Intel's HDR backlight interface. Since
we'll only ever use this in i915, we just define them in
intel_dp_aux_backlight.c
Reviewed-by: Rodrigo Vivi
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
On Thu, Sep 03, 2020 at 09:14:38PM +0200, Krzysztof Kozlowski wrote:
> Device tree nodes should have hyphens instead of underscores. This is
> also expected by the bindings.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1. New patch
> ---
>
On Thu, Sep 03, 2020 at 09:14:37PM +0200, Krzysztof Kozlowski wrote:
> Device tree nodes should have hyphens instead of underscores. This is
> also expected by the bindings.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1. New patch
> ---
>
Hi,
This is version three of the series:
https://www.spinics.net/lists/arm-kernel/msg836244.html
There are no changes to the yaml in this version, but I am resending as
I missed cc'ing dri-devel previously.
I have also added Rob's reviewed-bys, and sending only the dt-schema
changes.
Tomi
Add assigned-clocks, assigned-clock-parents and dma-coherent optional
properties.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Rob Herring
---
.../devicetree/bindings/display/ti/ti,j721e-dss.yaml | 11 +++
1 file changed, 11 insertions(+)
diff --git
Add assigned-clocks, assigned-clock-parents and dma-coherent optional
properties.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Rob Herring
---
.../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 11 +++
1 file changed, 11 insertions(+)
diff --git
On Mon, Aug 17, 2020 at 9:09 AM Ezequiel Garcia wrote:
>
> This heap is basically a wrapper around DMA-API dma_alloc_attrs,
> which will allocate memory suitable for the given device.
>
> The implementation is mostly a port of the Contiguous Videobuf2
> memory allocator (see
Hi Swapnil, Yuti,
On 14/09/2020 15:48, Swapnil Jakhade wrote:
> From: Yuti Amonkar
>
> Document the bindings used for the Cadence MHDP8546 DPI/DP bridge in
> yaml format.
>
> Signed-off-by: Yuti Amonkar
> Signed-off-by: Swapnil Jakhade
> Reviewed-by: Rob Herring
> Reviewed-by: Laurent
On 9/16/2020 6:30 PM, Karthik B S wrote:
On 9/15/2020 8:11 PM, Ville Syrjälä wrote:
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
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/Kconfig |9 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
This eliminates the following sparse warning:
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c:217:15: warning: symbol
'vint_table' was not declared. Should it be static?
While at it, make the table const as it is never modified.
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
Reviewed-by:
anx7625: MIPI to DP transmitter DT schema
Signed-off-by: Xin Ji
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/analogix,anx7625.yaml | 95 ++
1 file changed, 95 insertions(+)
create mode 100644
On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote:
> But within the driver, we generally need thousands of these, and that
> tends to bring fd exhaustion problems with it. That's why all the private
> buffer objects which aren't shared with other process or other drivers are
> handles
Hi all,
The following series add support for the Slimport ANX7625 transmitter, a
ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device.
This is the v15 version, any mistakes, please let me know, I will fix it in
the next series.
Change history:
v15: Fix comments from
The dependency on interconnect in the Kconfig was introduced to avoid
the case of interconnect=m and driver=y, but the interconnect framework
has been converted from tristate to bool now. Remove the dependency as
the framework can't be a module anymore.
Signed-off-by: Georgi Djakov
---
Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately.
Signed-off-by: Zhang Qilong
---
.../video/fbdev/omap2/omapfb/dss/hdmi4_core.c | 10 +
.../video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 10
On Tue, Sep 15, 2020 at 04:38:04PM -0700, Gurchetan Singh wrote:
> 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.
> > >
> > >
We found two unused variables new_cnt and old_cnt when build kernel with
W=1.
So delete it.
Signed-off-by: Luo Jiaxing
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
On 2020/09/16 17:26, Greg KH wrote:
> On Wed, Sep 16, 2020 at 09:01:06AM +0900, Tetsuo Handa wrote:
>> Greg, will you pick up this patch?
>>
>> It seems that finding the real cause of [3] and actually fixing [3] will be
>> difficult.
>> Since I can't reproduce [3] locally, I will have to try
Enable asynchronous flips in i915 for gen9+ platforms.
v2: -Async flip enablement should be a stand alone patch (Paulo)
v3: -Move the patch to the end of the series (Paulo)
v4: -Rebased.
v5: -Rebased.
v6: -Rebased.
v7: -Rebased.
v8: -Rebased.
v9: -Rebased.
Signed-off-by: Karthik B S
In Gen 9 and Gen 10 platforms, async address update enable bit is
double buffered. Due to this, during the transition from async flip
to sync flip we have to wait until this bit is updated before continuing
with the normal commit for sync flip.
v9: -Rename skl_toggle_async_sync() to
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt
Add the details of the implementation of asynchronous flips for i915.
v7: -Rebased.
v8: -Rebased.
v9: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
Documentation/gpu/i915.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/gpu/i915.rst
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.
Asynchronous page flips will also boost the FPS of Mesa benchmarks.
v2: -Few patches have been squashed and patches have been
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 well. (Ville)
-Add a vfunc for skl_program_async_surface_address
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject async flip.
v2: -Replace DRM_ERROR (Paulo)
-Add check for changes in OFFSET, FBC, RC(Paulo)
v3:
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.
v2: -Moved the async check above vblank_get as it
was causing issues for PSR.
v3: -No need to wait for vblank to pass, as this wait was causing a
16ms delay
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
v2: -Move the Async flip enablement to individual patch (Paulo)
v3: -Rebased.
v4: -Add separate plane hook for async flip case (Ville)
v5: -Rebased.
v6: -Move the plane hook to separate patch. (Paulo)
On Wed, 2020-09-16 at 10:43 +0300, Jani Nikula wrote:
> On Tue, 15 Sep 2020, 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
On Wed, Sep 16, 2020 at 04:02:18PM +0200, Christian König wrote:
> Am 16.09.20 um 15:36 schrieb Alex Deucher:
> > On Wed, Sep 16, 2020 at 3:51 AM Daniel Vetter wrote:
> > > On Wed, Sep 16, 2020 at 09:38:34AM +0200, Christian König wrote:
> > > > Am 15.09.20 um 21:35 schrieb Ville Syrjälä:
> > > >
Am 16.09.20 um 17:24 schrieb Daniel Vetter:
On Wed, Sep 16, 2020 at 4:14 PM Christian König
wrote:
Am 16.09.20 um 16:07 schrieb Jason Gunthorpe:
On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote:
But within the driver, we generally need thousands of these, and that
tends to
On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote:
> On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds
> wrote:
> >
> > 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
On 2020-09-16 5:12 a.m., Daniel Vetter wrote:
On Fri, Sep 11, 2020 at 10:59:23AM -0400, Rodrigo Siqueira wrote:
Debug issues related to display can be a challenge due to the complexity
around this topic and different source of information might help in this
process. We already have support for
On Wed, Sep 16, 2020 at 4:14 PM Christian König
wrote:
>
> Am 16.09.20 um 16:07 schrieb Jason Gunthorpe:
> > On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote:
> >
> >> But within the driver, we generally need thousands of these, and that
> >> tends to bring fd exhaustion problems
1 - 100 of 188 matches
Mail list logo
