This converts the lms283gf05 backlight driver to use GPIO
descriptors and switches the single PXA Palm Z2 device
over to defining these.
Since the platform data was only used to convey GPIO
information we can delete the platform data header.
Notice that we define the proper active low semantics i
On Tue, 25 Aug 2020, Lyude Paul wrote:
> Just a tiny drive-by cleanup, we can consolidate i915's code for
> checking for MST support into a helper to be shared across drivers.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 18 ++-
From: Oleg Vasilev
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
v2: rebase
v3: renamed a function call
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Jeevan B
Signed-off-by: Oleg Vasilev
Rev
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
Use recently introduced common wrappers operating directly on the struct
sg_table objects and scatterlist page iterators to make the code a bit
more compact, robust, easier to follow and copy/paste safe.
No functional change, because the code already properly did all the
scaterlist related calls.
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Use common helper for converting a sg_table object into struct
page pointer array.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/omapdrm/omap_gem.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omap
Use common helper for converting a sg_table object into struct
page pointer array.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
b/drivers/gpu/drm/med
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
map_sg function. In this patchset I only fixed the
sg_table objects exported by dmabuf related functions. I hope that I
didn't break anything there.
Patches are based on top of Linux next-20200825. The required changes to
DMA-mapping framework has been already merged to v5.8-rc1.
I would l
Use common helper for checking the contiguity of the imported dma-buf.
Signed-off-by: Marek Szyprowski
Reviewed-by: Andrzej Hajda
Acked-by : Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/drivers
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Replace the current hand-crafted code for extracting pages and DMA
addresses from the given scatterlist by the much more robust
code based on the generic scatterlist iterators and recently
introduced sg_table-based wrappers. The resulting code is simple and
easy to understand, so the comment descri
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Use common helper for checking the contiguity of the imported dma-buf and
do this check before allocating resources, so the error path is simpler.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 28 ++
1 file changed, 6 insertions(+), 22 delet
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Use common helper for checking the contiguity of the imported dma-buf.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gp
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
It is a common operation done by DRM drivers to check the contiguity
of the DMA-mapped buffer described by a scatterlist in the
sg_table object. Let's add a common helper for this operation.
Signed-off-by: Marek Szyprowski
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/drm_gem_cma_helper.c | 23
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Hi
Am 26.08.20 um 03:44 schrieb Dave Airlie:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_
From: Dave Airlie
These tooks the same args in a different order to the dma
ones, just make things look nicer.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c| 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++--
dr
This is based on top of misc-next with Christians io rework for nouveau.
https://github.com/airlied/linux/tree/ttm-tt-cleanup (is a complete tree)
The idea is to move towards ttm_tt being just a backing store for system
allocated pages + dma info, and not be anything to do with a global TT.
Firs
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_ttm.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index c3530c6e46bd..4970c3450e88 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
From: Dave Airlie
Signed-off-by: Dave Airlie
---
include/drm/ttm/ttm_tt.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index 2aa4cd7d6451..3b87ce43864a 100644
--- a/include/drm/ttm/ttm_tt.h
+++ b/include/drm/t
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++--
drivers/gpu/drm/ttm/ttm_agp_backend.c | 17 -
include/drm/ttm/ttm_tt.h | 2 --
4 files changed, 4 insertions(+), 23 de
From: Dave Airlie
Get bound out is the next step.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/radeon/radeon_mn.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
From: Dave Airlie
next step move populated into upper page flag bits
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo_util.
From: Dave Airlie
These are now driver side.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_tt.c | 15 +++---
include/drm/ttm/ttm_tt.h | 39
2 files changed, 3 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/d
From: Dave Airlie
This can be gotten back from bdev.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_ttm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index f6311f404db8..092
From: Dave Airlie
If we move the bound flag out then the tt destroy is much
cleaner in a bo level wrapper, the code is in a few places,
leave the ttm_tt_destroy just about destroying the backing store.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 +
drivers/gpu/d
From: Dave Airlie
Make populating the backing store an explicit separate step
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ++-
drivers/gpu/drm/nouveau/nouveau_bo.c| 6 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 7 ++-
drivers/gpu/drm/ttm/ttm_
From: Dave Airlie
These are just minor changes that fill some obvious holes.
Signed-off-by: Dave Airlie
---
include/drm/ttm/ttm_placement.h | 2 +-
include/drm/ttm/ttm_tt.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/ttm/ttm_placement.h b/include/d
From: Dave Airlie
Since the agp bind/unbind/destroy are now getting called from drivers
rather than via the func table, drop the bdev parameter.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +++---
drivers/gpu/drm/radeon/radeon_ttm.c | 6 +++---
drivers/gpu/drm/
From: Dave Airlie
This is only used by drivers that have a dma tt backing store.
Signed-off-by: Dave Airlie
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 32 +--
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +--
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 9592505563bf..f07e7121bcc5 100644
---
From: Dave Airlie
These aren't used anymore.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_agp_backend.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index fbf98cd1a3e5..8072fb7c5bc8 100644
---
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index a76a7f542dd8..6757be98be14 10
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_gem_vram_helper.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 788557bc5c01..93586a310971 100644
--- a/drivers/g
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d7f668dbc9e0..00b2c0359735 100644
--- a/d
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 45 +
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 54 ++---
drivers/gpu/drm/nouveau/nouveau_ttm.h | 3 ++
3 files changed, 60 insertions(+), 42 deletions(-)
diff
From: Dave Airlie
Do agp decision in the driver, instead of special binding funcs
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon.h| 7 +-
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c| 6 +-
drivers/gpu/drm/radeon/radeon_object.
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_agp_backend.c | 15 +--
include/drm/ttm/ttm_tt.h | 6 ++
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_ba
From: Dave Airlie
I want to remove the backend funcs
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_tt.c| 15 +++---
include/drm/ttm/ttm_bo_driver.h | 36 +
2 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/t
From: Dave Airlie
I want to split this structure up and use it differently,
step one remove bdev pointer from it and pass it explicitly.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 40 +++
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
drive
On Sat, 22 Aug 2020 at 02:01, Christian König
wrote:
>
> While working on TTM cleanups I've found that the io_reserve_lru used by
> Nouveau is actually not working at all.
>
> In general we should remove driver specific handling from the memory
> management, so this patch moves the io_reserve_lru
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/qxl/qxl_display.c: In function
'qxl_display_read_client_monitors_config':
include/drm/drm_modeset_lock.h:167:7: error: implicit declaration of function
'drm_drv_uses_atomic_
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
between commits:
cacbbe7c0065 ("drm/amdgpu:
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/video/fbdev/arcfb.c
drivers/video/fbdev/atmel_lcdfb.c
drivers/video/fbdev/savage/savagefb_driver.c
between commit:
df561f6688fe ("treewide: Use fallthrough pseudo-keyword")
from Linus' tree and commit:
a
From: Tom Rix
clang static analysis flags this error
intel_combo_phy.c:268:7: warning: The left expression of the
compound assignment is an uninitialized value.
The computed value will also be garbage
ret &= check_phy_reg(...
~~~ ^
ret has no initial values,
On Wed, 19 Aug 2020 12:22:45 +0200, Lubomir Rintel wrote:
> Himax HX8837 is a secondary display controller used to drive the panel
> on OLPC platforms.
>
> Signed-off-by: Lubomir Rintel
>
> ---
> Changes since v3:
> - Moved to bindings/display/
> - Added the ports
> - Converted to YAML
> - Remov
On Wed, 19 Aug 2020 12:12:05 +0200, Lubomir Rintel wrote:
> Add the Innolux LS075AT011 7.5" (1200x900) color/reflective LCD panel to
> the panel-simple compatible list. This panel is used in the OLPC laptops.
>
> Signed-off-by: Lubomir Rintel
> ---
> .../devicetree/bindings/display/panel/panel-s
Hi Maxime,
Am 25.08.20 um 17:06 schrieb Maxime Ripard:
> Hi Stefan,
>
> On Wed, Jul 29, 2020 at 05:50:31PM +0200, Stefan Wahren wrote:
>> Am 29.07.20 um 16:42 schrieb Maxime Ripard:
>>> Hi,
>>>
>>> On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote:
On Wed, 8 Jul 2020 at 18:43, Ma
From: Sean Paul
This patch adds a new module parameter called drm.trace which accepts
the same mask as drm.debug. When a debug category is enabled, log
messages will be put in a new tracefs instance called drm for
consumption.
Using the new tracefs instance will allow distros to enable drm loggi
Hi Mauro.
Laurent and I discussed this driver a little on irc.
Some highlights:
This parts could use register names:
+ writel(0x2, noc_dss_base + 0xc);
+ writel(0x2, noc_dss_base + 0x8c);
+ writel(0x2, noc_dss_base + 0x10c);
+ writel(0x2, noc_dss_base + 0x18c);
The two no
Since DP 1.3, it's been possible for DP receivers to specify an
additional set of DPCD capabilities, which can take precedence over the
capabilities reported at DP_DPCD_REV.
Basically any device supporting DP is going to need to read these in an
identical manner, in particular nouveau, so let's go
We're going to be doing the same probing process in nouveau for
determining downstream DP port capabilities, so let's deduplicate the
work by moving i915's code for handling this into a shared helper:
drm_dp_downstream_read_info().
Note that when we do this, we also do make some functional changes
Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a conn
This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.
Note as well, we also start marking the connector as disconnected if we
can't read the DPCD, sinc
And of course, we'll also need to read the sink count from other drivers
as well if we're checking whether or not it's supported. So, let's
extract the code for this into another helper.
v2:
* Fix drm_dp_dpcd_readb() ret check
* Add back comment and move back sink_count assignment in intel_dp_get_
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.
Back when I originally wrote this, I d
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
include/drm/drm_dp_mst_helper.h | 22
Currently in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds(), we start the connector probing process
by releasing the previous EDID and informing DRM of the change. However,
since commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") drm_connector_update_edid_prop
Now that we've extracted i915's code for reading both the normal DPCD
caps and extended DPCD caps into a shared helper, let's start using this
in nouveau to enable us to start checking extended DPCD caps for free.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nou
For whatever reason we currently unset the EDID for DP CEC support when
responding to the connector being unplugged, instead of just doing it in
nouveau_connector_detect() where we set the CEC EDID. This isn't really
needed and could even potentially cause us to forget to unset the EDID
if the conn
No functional changes.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8db9216d52c69..4030806
Since other drivers are also going to need to be aware of the sink count
in order to do proper dongle detection, we might as well steal i915's
DP_SINK_COUNT helpers and move them into DRM helpers so that other
dirvers can use them as well.
Note that this also starts using intel_dp_has_sink_count()
This is another bit that we never implemented for nouveau: dongle
detection. When a "dongle", e.g. an active display adaptor, is hooked up
to the system and causes an HPD to be fired, we don't actually know
whether or not there's anything plugged into the dongle without checking
the sink count. As
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 032afc73e2a33..201c0b4335563 100644
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers
Since this actually logs accesses, we should probably always be using
this imho…
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/dr
Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nou
Most of the reason I'm asking for an RFC here is because this
code pulls a lot of code out of i915 and into shared DP helpers.
Anyway-nouveau's HPD related code has been collecting dust for a while.
Other then the occasional runtime PM related and MST related fixes,
we're missing a lot of nice thi
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
enabling") we've been clearing DP_MST_CTRL before we start enabling MST.
Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary
and redundant, so let's remove it.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with nv04_encoder_get_c
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8a0f7994e1aeb..ee778ddc95fae 100644
--- a/driv
Hi Mauro
> Before posting the big patch series again, let me send the new
> version folded into a single patch.
>
> If you'd like to see the entire thing, I'm placing it here:
>
>
> https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/hikey970_v2/
Review 3/3
For next submis
Hi Laurent,
On 23/08/2020 19:26, Aaro Koskinen wrote:
> Hi,
>
> On Tue, Aug 04, 2020 at 03:39:37PM +0300, Tomi Valkeinen wrote:
>> On 04/08/2020 15:13, Tomi Valkeinen wrote:
>
>>> Can you try to pinpoint a bit where the hang happens? Maybe add
>>> DRM/omapdrm debug prints, or perhaps sysrq works
On Sat, Jul 4, 2020 at 9:38 PM Maxime Ripard wrote:
>
> The LVDS controller can invert the polarity / lanes of the LVDS output.
> The default polarity causes some issues on some panels.
>
> However, U-Boot has always used the opposite polarity without any reported
> issue, and the only currently s
On 2020-08-22 5:59 a.m., Michel Dänzer wrote:
On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote:
On 2020-08-21 12:57 p.m., Michel Dänzer wrote:
From: Michel Dänzer
Don't check drm_crtc_state::active for this either, per its
documentation in include/drm/drm_crtc.h:
* Hence drivers must n
On Tue, 2020-08-25 at 08:28 +1000, Ben Skeggs wrote:
> On Tue, 25 Aug 2020 at 04:33, Lyude Paul wrote:
> > Not entirely sure why this never came up when I originally tested this
> > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
> > appears to cause the display engine to th
On Mon, Aug 24, 2020 at 11:31 PM Rodrigo Siqueira
wrote:
>
> In the vkms_composer.c, some of the functions related to CRC and compose
> have interdependence between each other. This patch reworks some
> functions inside vkms_composer to make crc and composer computation
> decoupled.
>
> This patch
On Tue, Aug 25, 2020 at 12:45 PM Melissa Wen wrote:
>
> On 08/24, Rodrigo Siqueira wrote:
> > This patch implements the necessary functions to add writeback support
> > for vkms. This feature is useful for testing compositors if you don't
> > have hardware with writeback support.
> >
> > Change in
Hi Rodrigo,
Nice work!
I tested this on the kms_writeback set of subtests and works fine.
I have also checked it on the other IGT tests that I usually uses:
- kms_cursor_crc/cursor-alpha-transparent was affected by a small
problem in the bitmap_clear of the get_pixel_from_buffer function,
th
1 - 100 of 154 matches
Mail list logo
