Re: [PATCH] drm/malidp: Use struct drm_gem_object_funcs.get_sg_table internally
Hi
Am 18.08.20 um 19:15 schrieb Liviu Dudau:
> On Thu, Aug 13, 2020 at 02:01:19PM +0200, Daniel Vetter wrote:
>> On Thu, Aug 13, 2020 at 12:39 PM Thomas Zimmermann
>> wrote:
>>>
>>> Hi
>>>
>>> Am 13.08.20 um 12:31 schrieb Daniel Vetter:
On Thu, Aug 13, 2020 at 12:28:55PM +0200, Thomas Zimmermann wrote:
>
>
> Am 13.08.20 um 11:48 schrieb Daniel Vetter:
>> On Thu, Aug 13, 2020 at 11:19:31AM +0200, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 07.08.20 um 18:10 schrieb Daniel Vetter:
On Fri, Aug 7, 2020 at 4:02 PM Thomas Zimmermann
wrote:
>
> Hi
>
> Am 07.08.20 um 15:12 schrieb Daniel Vetter:
>> On Fri, Aug 07, 2020 at 01:10:22PM +0200, Thomas Zimmermann wrote:
>>> The malidp driver uses GEM object functions for callbacks. Fix it to
>>> use them internally as well.
>>>
>>> Signed-off-by: Thomas Zimmermann
>>> Fixes: ecdd6474644f ("drm/malidp: Use GEM CMA object functions")
>>> Cc: Thomas Zimmermann
>>> Cc: Emil Velikov
>>> Cc: Liviu Dudau
>>> Cc: Brian Starkey
>>> ---
>>> drivers/gpu/drm/arm/malidp_planes.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
>>> b/drivers/gpu/drm/arm/malidp_planes.c
>>> index ab45ac445045..351a85088d0e 100644
>>> --- a/drivers/gpu/drm/arm/malidp_planes.c
>>> +++ b/drivers/gpu/drm/arm/malidp_planes.c
>>> @@ -346,7 +346,7 @@ static bool malidp_check_pages_threshold(struct
>>> malidp_plane_state *ms,
>>> if (cma_obj->sgt)
>>> sgt = cma_obj->sgt;
>>> else
>>> -sgt =
>>> obj->dev->driver->gem_prime_get_sg_table(obj);
>>> +sgt = obj->funcs->get_sg_table(obj);
>>
>> Uh if there's not a switch somewhere I'd just call the right function
>> directly. Or call the right wrapper for this, this feels a bit fishy
>> ...
>
> The driver initializes the pointer via CMA helper macro to an
> CMA-internal default. Calling the actual function here is fragile if
> the
> CMA-internal default ever changes.
>
> But I have no strong feelings. I'll go with whatever the driver's
> maintainer prefers.
>
> Hi,
>
> Sorry for the silence, I was on holiday.
>
What I meant is: There should be an exported helper to get at the sgt.
Drivers using helpers shouldn't need to do this kind of stuff here.
Also the entire code is fairly suspect, getting at the sgt from
plane_check is a bit iffy. But that's a different kind of problem.
>>>
>>> I tried to somehow move the code to CMA, but it's not easy. There's no
>>> good place to put the look-up code of sgt. And sgt is later being freed
>>> iff it came from the callback (and not freed if it was stored in the
>>> object). AFIACT the best options are to either keep the code here or
>>> move the entire function to CMA helpers.
>>
>> Ok I read some code ... I'm confused. From the control flow it looks like
>> malidp is using cma helpers. Otherwise why does the upcasting not blow up
>> sometimes.
>>
>> But cma helpers already check at import time that any imported dma-buf is
>> contiguous, and they guarantee to fill out the cma_obj->sgt.
>>
>> So really no idea what this code is doing here.
>>
>> It's also not correct, since it doesn't coalesce sgt entries, since a
>> range might be split up, but still mapped into a contiguous dma_addr_t
>> range when you take it all together. The code in
>> drm_gem_cma_prime_import_sg_table() gets this more right.
>>
>> So maybe right fix is to just ditch this all, and use cma helpers fully?
>
> The driver already does use CMA, including
> drm_gem_cma_prime_import_sg_table().
>
> The patched code is not about importing/exporting sg tables. It
> configures the MMU's prefetching pattern by looking at some of the page
> sizes. I don't feel confident enough with this code to alter it. I'd
> expect to break the heuristics.
>
> That's right, this piece of code has nothing to do with importing dma-buf or
> checking if things are contiguous. Mali DP hardware has a prefetcher block
> that
> can generate some fake requests during vblank to get the MMU pagetables cached
> so that reads from the buffers can be done without waiting for page walks. The
> block supports two modes, a full page or partial page request (to cater for
> the
> ends of the buffer that might not be a full page).
>
> The patch proposed looks good to me, so:
>
> Acked-by: Liviu Dudau
>
> I will push the patch into drm-misc-next if Daniel has no other com
Re: [PATCH] drm: assure aux_dev is nonzero before using it
On Wed, 12 Aug 2020, Lyude Paul wrote: > On Wed, 2020-08-12 at 16:10 +0200, Daniel Vetter wrote: > > On Wed, Aug 12, 2020 at 12:16 AM Zwane Mwaikambo wrote: > > > On Tue, 11 Aug 2020, Daniel Vetter wrote: > > > > > > > On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote: > > > > > Hi Folks, > > > > > I know this thread eventually dropped off due to not identifying > > > > > the underlying issue. It's still occuring on 5.8 and in my case it > > > > > happened because the udev device nodes for the DP aux devices were not > > > > > cleaned up whereas the kernel had no association with them. I can > > > > > reproduce the bug just by creating a device node for a non-existent > > > > > minor > > > > > device and calling open(). > > > > > > > > Hm I don't have that thread anymore, but generally these bugs are solved > > > > by not registering the device before it's ready for use. We do have > > > > drm_connector->late_register for that stuff. Just a guess since I'm not > > > > seeing full details here. > > > > > > In this particular case, the physical device disappeared before the nodes > > > were cleaned up. It involves putting a computer to sleep with a monitor > > > plugged in and then waking it up with the monitor unplugged. > > > > We also have early_unregister for the reverse, but yes this sounds > > more tricky ... Adding Lyude who's been working on way too much > > lifetime fun around dp recently. > > -Daniel > > > Hi-I think just checking whether the auxdev is NULL or not is a reasonable > fix, although I am curious as to how exactly the aux dev's parent is getting > destroyed before it's child, which I would have thought would be the only way > you could hit this? Hi, If this is acceptable, would you consider an updated patch against 5.8? Thanks, Zwane ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] dma-buf: heaps: add chunk heap to dmabuf heaps
This patch adds support for a chunk heap that allows for buffers
that are made up of a list of fixed size chunks taken from a CMA.
Chunk sizes are configuratd when the heaps are created.
Signed-off-by: Hyesoo Yu
---
drivers/dma-buf/heaps/Kconfig | 9 ++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/chunk_heap.c | 222 +
3 files changed, 232 insertions(+)
create mode 100644 drivers/dma-buf/heaps/chunk_heap.c
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06..98552fa 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -12,3 +12,12 @@ config DMABUF_HEAPS_CMA
Choose this option to enable dma-buf CMA heap. This heap is backed
by the Contiguous Memory Allocator (CMA). If your system has these
regions, you should say Y here.
+
+config DMABUF_HEAPS_CHUNK
+ tristate "DMA-BUF CHUNK Heap"
+ depends on DMABUF_HEAPS && DMA_CMA
+ help
+ Choose this option to enable dma-buf CHUNK heap. This heap is backed
+ by the Contiguous Memory Allocator (CMA) and allocate the buffers that
+ are made up to a list of fixed size chunks tasken from CMA. Chunk
sizes
+ are configurated when the heaps are created.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 6e54cde..3b2a0986 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -2,3 +2,4 @@
obj-y += heap-helpers.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_CHUNK) += chunk_heap.o
diff --git a/drivers/dma-buf/heaps/chunk_heap.c
b/drivers/dma-buf/heaps/chunk_heap.c
new file mode 100644
index 000..1eefaec
--- /dev/null
+++ b/drivers/dma-buf/heaps/chunk_heap.c
@@ -0,0 +1,222 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ION Memory Allocator chunk heap exporter
+ *
+ * Copyright (c) 2020 Samsung Electronics Co., Ltd.
+ * Author: for Samsung Electronics.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "heap-helpers.h"
+
+struct chunk_heap {
+ struct dma_heap *heap;
+ phys_addr_t base;
+ phys_addr_t size;
+ atomic_t cur_pageblock_idx;
+ unsigned int max_num_pageblocks;
+ unsigned int order;
+};
+
+static void chunk_heap_free(struct heap_helper_buffer *buffer)
+{
+ struct chunk_heap *chunk_heap = dma_heap_get_drvdata(buffer->heap);
+ pgoff_t pg;
+
+ for (pg = 0; pg < buffer->pagecount; pg++)
+ __free_pages(buffer->pages[pg], chunk_heap->order);
+ kvfree(buffer->pages);
+ kfree(buffer);
+}
+
+static inline unsigned long chunk_get_next_pfn(struct chunk_heap *chunk_heap)
+{
+ unsigned long i = atomic_inc_return(&chunk_heap->cur_pageblock_idx) %
+ chunk_heap->max_num_pageblocks;
+
+ return PHYS_PFN(chunk_heap->base) + i * pageblock_nr_pages;
+}
+
+static int chunk_alloc_pages(struct chunk_heap *chunk_heap, struct page
**pages,
+unsigned int order, unsigned int count)
+{
+ unsigned long base;
+ unsigned int i = 0, nr_block = 0, nr_elem, ret;
+
+ while (count) {
+ /*
+* If the number of scanned page block is the same as max block,
+* the tries of allocation fails.
+*/
+ if (nr_block++ == chunk_heap->max_num_pageblocks) {
+ ret = -ENOMEM;
+ goto err_bulk;
+ }
+ base = chunk_get_next_pfn(chunk_heap);
+ nr_elem = min_t(unsigned int, count, pageblock_nr_pages >>
order);
+ ret = alloc_pages_bulk(base, base + pageblock_nr_pages,
MIGRATE_CMA,
+ GFP_KERNEL, order, nr_elem, pages + i);
+ if (ret < 0)
+ goto err_bulk;
+
+ i += ret;
+ count -= ret;
+ }
+
+ return 0;
+
+err_bulk:
+ while (i-- > 0)
+ __free_pages(pages[i], order);
+
+ return ret;
+}
+
+static int chunk_heap_allocate(struct dma_heap *heap, unsigned long len,
+unsigned long fd_flags, unsigned long heap_flags)
+{
+
+ struct chunk_heap *chunk_heap = dma_heap_get_drvdata(heap);
+ struct heap_helper_buffer *helper_buffer;
+ struct dma_buf *dmabuf;
+ unsigned int count = DIV_ROUND_UP(len, PAGE_SIZE << chunk_heap->order);
+ int ret = -ENOMEM;
+
+ helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
+ if (!helper_buffer)
+ return ret;
+
+ init_heap_helper_buffer(helper_buffer, chunk_heap_free);
+
+ helper_buffer->heap = heap;
+ helper_
Re: [PATCH v3] arm64: dts: qcom: sc7180: Add DisplayPort HPD pin dt node
Quoting Tanmay Shah (2020-08-17 20:36:57) > This node defines alternate DP HPD functionality of GPIO. > > Signed-off-by: Tanmay Shah > --- Reviewed-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/nouveau/nvenc: remove duplicate include
Remove priv.h which is included more than once Reported-by: Hulk Robot Signed-off-by: Wang Hai --- drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c b/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c index 484100e15668..7deb826d1ccc 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c @@ -21,7 +21,6 @@ */ #include "priv.h" -#include "priv.h" #include static void * -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Chunk Heap Support on DMA-HEAP
On Tue, Aug 18, 2020 at 11:55:57AM +0100, Brian Starkey wrote: > Hi, > > On Tue, Aug 18, 2020 at 05:04:12PM +0900, Hyesoo Yu wrote: > > These patch series to introduce a new dma heap, chunk heap. > > That heap is needed for special HW that requires bulk allocation of > > fixed high order pages. For example, 64MB dma-buf pages are made up > > to fixed order-4 pages * 1024. > > > > The chunk heap uses alloc_pages_bulk to allocate high order page. > > https://lore.kernel.org/linux-mm/20200814173131.2803002-1-minc...@kernel.org > > > > The chunk heap is registered by device tree with alignment and memory node > > of contiguous memory allocator(CMA). Alignment defines chunk page size. > > For example, alignment 0x1_ means chunk page size is 64KB. > > The phandle to memory node indicates contiguous memory allocator(CMA). > > If device node doesn't have cma, the registration of chunk heap fails. > > This reminds me of an ion heap developed at Arm several years ago: > https://protect2.fireeye.com/v1/url?k=aceed8af-f122140a-acef53e0-0cc47a30d446-0980fa451deb2df6&q=1&e=a58a9bb0-a837-4fc5-970e-907089bfe25e&u=https%3A%2F%2Fgit.linaro.org%2Flanding-teams%2Fworking%2Farm%2Fkernel.git%2Ftree%2Fdrivers%2Fstaging%2Fandroid%2Fion%2Fion_compound_page.c > > Some more descriptive text here: > https://protect2.fireeye.com/v1/url?k=83dc3e8b-de10f22e-83ddb5c4-0cc47a30d446-a406aa201ca7dddc&q=1&e=a58a9bb0-a837-4fc5-970e-907089bfe25e&u=https%3A%2F%2Fgithub.com%2FARM-software%2FCPA > > It maintains a pool of high-order pages with a worker thread to > attempt compaction and allocation to keep the pool filled, with high > and low watermarks to trigger freeing/allocating of chunks. > It implements a shrinker to allow the system to reclaim the pool under > high memory pressure. > > Is maintaining a pool something you considered? From the > alloc_pages_bulk thread it sounds like you want to allocate 300M at a > time, so I expect if you tuned the pool size to match that it could > work quite well. > > That implementation isn't using a CMA region, but a similar approach > could definitely be applied. > I have seriously considered CPA in our product but we developed our own because of the pool in CPA. The high-order pages are required by some specific users like Netflix app. Moreover required number of bytes are dramatically increasing because of high resolution videos and displays in these days. Gathering lots of free high-order pages in the background during run-time means reserving that amount of pages from the entier available system memory. Moreover the gathered pages are soon reclaimed whenever the system is sufferring from memory pressure (i.e. camera recording, heavy games). So we had to consider allocating hundreds of megabytes at at time. Of course we don't allocate all buffers by a single call to alloc_pages_bulk(). But still a buffer is very large. A single frame of 8K HDR video needs 95MB (7680*4320*2*1.5). Even a single frame of HDR 4K video needs 24MB and 4K HDR is now popular in Netflix, YouTube and Google Play video. > Thanks, > -Brian Thank you! KyongHo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] i2c: i2c-qcom-geni: Add shutdown callback for i2c
Quoting Roja Rani Yarubandi (2020-08-14 02:55:40)
> If the hardware is still accessing memory after SMMU translation
> is disabled(as part of smmu shutdown callback), then the
Put a space before (
> IOVAs(I/O virtual address) which it was using will go on the bus
Put a space before (
> as the physical addresses which will result in unknown crashes
> like NoC/interconnect errors.
>
> So, adding shutdown callback to i2c driver to unmap DMA mappings
> during system "reboot" or "shutdown".
>
Deserves a Fixes: tag if it's fixing a problem, which it looks like it
is.
> Signed-off-by: Roja Rani Yarubandi
> ---
> drivers/i2c/busses/i2c-qcom-geni.c | 36 ++
> include/linux/qcom-geni-se.h | 5 +
I'd prefer this is squashed with the previous patch. The first patch
doesn't really stand on its own anyway.
> 2 files changed, 41 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
> b/drivers/i2c/busses/i2c-qcom-geni.c
> index 53ca41f76080..749c225f95c4 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -613,6 +613,41 @@ static int geni_i2c_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static void geni_i2c_shutdown(struct platform_device *pdev)
> +{
> + int ret;
> + struct geni_i2c_dev *gi2c = platform_get_drvdata(pdev);
> + struct geni_se *se = &gi2c->se;
> + u32 dma;
> + u32 dma_dbg_reg;
Typically this is just called 'val'.
> +
> + ret = pm_runtime_get_sync(gi2c->se.dev);
> + if (ret < 0) {
> + dev_err(gi2c->se.dev, "Failed to resume device:%d\n", ret);
Maybe just write: "Failed to resume device\n"? Not sure anyone cares
what the error code is. And if they did, it would be connected to the
colon so it will be hard to read. Add a space after colon if you want to
keep the return value please.
> + return;
> + }
> +
> + dma = readl_relaxed(se->base + SE_GENI_DMA_MODE_EN);
> + if (dma) {
> + dma_dbg_reg = readl_relaxed(gi2c->se.base +
> SE_DMA_DEBUG_REG0);
> + if (dma_dbg_reg & DMA_TX_ACTIVE) {
> + geni_i2c_abort_xfer(gi2c);
> + gi2c->cur_wr = 0;
> + if (gi2c->err)
> + geni_i2c_tx_fsm_rst(gi2c);
> + geni_se_tx_dma_unprep(se, gi2c->tx_dma,
> gi2c->xfer_len);
> + }
> + if (dma_dbg_reg & DMA_RX_ACTIVE) {
> + geni_i2c_abort_xfer(gi2c);
> + gi2c->cur_rd = 0;
> + if (gi2c->err)
> + geni_i2c_rx_fsm_rst(gi2c);
> + geni_se_rx_dma_unprep(se, gi2c->rx_dma,
> gi2c->xfer_len);
> + }
Can this be a function? It sort of seems like we should be doing the
same sort of stuff if we're canceling a DMA transaction in flight.
> + }
> + pm_runtime_put_sync_suspend(gi2c->se.dev);
> +}
> +
> static int __maybe_unused geni_i2c_runtime_suspend(struct device *dev)
> {
> int ret;
> diff --git a/include/linux/qcom-geni-se.h b/include/linux/qcom-geni-se.h
> index dd464943f717..acad69be747d 100644
> --- a/include/linux/qcom-geni-se.h
> +++ b/include/linux/qcom-geni-se.h
> @@ -77,6 +77,7 @@ struct geni_se {
> #define SE_DMA_RX_FSM_RST 0xd58
> #define SE_HW_PARAM_0 0xe24
> #define SE_HW_PARAM_1 0xe28
> +#define SE_DMA_DEBUG_REG0 0xe40
>
> /* GENI_FORCE_DEFAULT_REG fields */
> #define FORCE_DEFAULT BIT(0)
> @@ -207,6 +208,10 @@ struct geni_se {
> #define RX_GENI_CANCEL_IRQ BIT(11)
> #define RX_GENI_GP_IRQ_EXT GENMASK(13, 12)
>
> +/* DMA DEBUG Register fields */
Please follow other style, ie. SE_DMA_DEBUG_REG0 fields
> +#define DMA_TX_ACTIVE BIT(0)
> +#define DMA_RX_ACTIVE BIT(1)
> +
> /* SE_HW_PARAM_0 fields */
> #define TX_FIFO_WIDTH_MSK GENMASK(29, 24)
> #define TX_FIFO_WIDTH_SHFT 24
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] dma-buf: add missing EXPORT_SYMBOL_GPL() for dma heaps
The interface of dma heap is used from kernel module to
register dma heaps, otherwize we will get compile error.
Signed-off-by: Hyesoo Yu
---
drivers/dma-buf/dma-heap.c | 2 ++
drivers/dma-buf/heaps/heap-helpers.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9..cc6339c 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -189,6 +189,7 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
{
return heap->priv;
}
+EXPORT_SYMBOL_GPL(dma_heap_get_drvdata);
struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
{
@@ -272,6 +273,7 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
kfree(heap);
return err_ret;
}
+EXPORT_SYMBOL_GPL(dma_heap_add);
static char *dma_heap_devnode(struct device *dev, umode_t *mode)
{
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
index 9f964ca..741bae0 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -24,6 +24,7 @@ void init_heap_helper_buffer(struct heap_helper_buffer
*buffer,
INIT_LIST_HEAD(&buffer->attachments);
buffer->free = free;
}
+EXPORT_SYMBOL_GPL(init_heap_helper_buffer);
struct dma_buf *heap_helper_export_dmabuf(struct heap_helper_buffer *buffer,
int fd_flags)
@@ -37,6 +38,7 @@ struct dma_buf *heap_helper_export_dmabuf(struct
heap_helper_buffer *buffer,
return dma_buf_export(&exp_info);
}
+EXPORT_SYMBOL_GPL(heap_helper_export_dmabuf);
static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
{
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] *** SUBJECT HERE ***
On Tue, Aug 18, 2020 at 11:50:35AM +0200, Greg Kroah-Hartman wrote: > On Tue, Aug 18, 2020 at 12:17:08PM +0300, Tomer Samara wrote: > > *** BLURB HERE *** > > Really? > > And your subject line could use some work too :( > sorry for that, i've made a script for sending patchset and accidently it sents mails without contorl. Fixed that ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] staging: android: Replace BUG_ON with WARN_ON
On Tue, Aug 18, 2020 at 04:11:06PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Aug 16, 2020 at 10:23:25PM +0300, Tomer Samara wrote:
> > BUG_ON() is replaced with WARN_ON at ion_page_pool.c
>
> Why?
>
> > Fixes the following issue:
> > Avoid crashing the kernel - try using WARN_ON & recovery code ratherthan
> > BUG() or BUG_ON().
>
> Ideally you can get rid of WARN_ON() too, right?
>
> Many systems run in panic-on-warn mode, so this really does not change
> anything. Try fixing this up properly to not crash at all.
>
You mean by that to just remove the WARN_ON and leave the condition the
same?
> >
> > Signed-off-by: Tomer Samara
> > ---
> > drivers/staging/android/ion/ion_page_pool.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/staging/android/ion/ion_page_pool.c
> > b/drivers/staging/android/ion/ion_page_pool.c
> > index 0198b886d906..c1b9eda35c96 100644
> > --- a/drivers/staging/android/ion/ion_page_pool.c
> > +++ b/drivers/staging/android/ion/ion_page_pool.c
> > @@ -46,11 +46,13 @@ static struct page *ion_page_pool_remove(struct
> > ion_page_pool *pool, bool high)
> > struct page *page;
> >
> > if (high) {
> > - BUG_ON(!pool->high_count);
> > + if (WARN_ON(!pool->high_count))
> > + return NULL;
>
> And can you test this that it works properly?
>
> thanks,
>
> greg k-h
Will do :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Chunk Heap Support on DMA-HEAP
These patch series to introduce a new dma heap, chunk heap. That heap is needed for special HW that requires bulk allocation of fixed high order pages. For example, 64MB dma-buf pages are made up to fixed order-4 pages * 1024. The chunk heap uses alloc_pages_bulk to allocate high order page. https://lore.kernel.org/linux-mm/20200814173131.2803002-1-minc...@kernel.org The chunk heap is registered by device tree with alignment and memory node of contiguous memory allocator(CMA). Alignment defines chunk page size. For example, alignment 0x1_ means chunk page size is 64KB. The phandle to memory node indicates contiguous memory allocator(CMA). If device node doesn't have cma, the registration of chunk heap fails. The patchset includes the following: - export dma-heap API to register kernel module dma heap. - add chunk heap implementation. - document of device tree to register chunk heap Hyesoo Yu (3): dma-buf: add missing EXPORT_SYMBOL_GPL() for dma heaps dma-buf: heaps: add chunk heap to dmabuf heaps dma-heap: Devicetree binding for chunk heap .../devicetree/bindings/dma-buf/chunk_heap.yaml| 46 + drivers/dma-buf/dma-heap.c | 2 + drivers/dma-buf/heaps/Kconfig | 9 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/chunk_heap.c | 222 + drivers/dma-buf/heaps/heap-helpers.c | 2 + 6 files changed, 282 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml create mode 100644 drivers/dma-buf/heaps/chunk_heap.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v10 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset
On Mon, Aug 17, 2020 at 05:53:09PM -0400, Jim Quinlan wrote:
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> capable of holding a single uniform offset and had no region bounds
> checking.
>
> The function of_dma_get_range() has been modified so that it takes a single
> argument -- the device node -- and returns a map, NULL, or an error code.
> The map is an array that holds the information regarding the DMA regions.
> Each range entry contains the address offset, the cpu_start address, the
> dma_start address, and the size of the region.
>
> of_dma_configure() is the typical manner to set range offsets but there are
> a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> driver code. These cases now invoke the function
> dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
...
> + if (dev) {
> + phys_addr_t paddr = PFN_PHYS(pfn);
> +
> + pfn -= (dma_offset_from_phys_addr(dev, paddr) >> PAGE_SHIFT);
PFN_DOWN() ?
> + }
...
> + pfn += (dma_offset_from_dma_addr(dev, addr) >> PAGE_SHIFT);
Ditto.
...
> +static inline u64 dma_offset_from_dma_addr(struct device *dev, dma_addr_t
> dma_addr)
> +{
> + const struct bus_dma_region *m = dev->dma_range_map;
> +
> + if (!m)
> + return 0;
> + for (; m->size; m++)
> + if (dma_addr >= m->dma_start && dma_addr - m->dma_start <
> m->size)
> + return m->offset;
> + return 0;
> +}
> +
> +static inline u64 dma_offset_from_phys_addr(struct device *dev, phys_addr_t
> paddr)
> +{
> + const struct bus_dma_region *m = dev->dma_range_map;
> +
> + if (!m)
> + return 0;
> + for (; m->size; m++)
> + if (paddr >= m->cpu_start && paddr - m->cpu_start < m->size)
> + return m->offset;
> + return 0;
> +}
Perhaps for these the form with one return 0 is easier to read
if (m) {
for (; m->size; m++)
if (paddr >= m->cpu_start && paddr - m->cpu_start <
m->size)
return m->offset;
}
return 0;
?
...
> + if (mem->use_dev_dma_pfn_offset) {
> + u64 base_addr = (u64)mem->pfn_base << PAGE_SHIFT;
PFN_PHYS() ?
> +
> + return base_addr - dma_offset_from_phys_addr(dev, base_addr);
> + }
...
> + * It returns -ENOMEM if out of memory, 0 otherwise.
This doesn't describe cases dev->dma_range_map != NULL and offset == 0.
> +int dma_set_offset_range(struct device *dev, phys_addr_t cpu_start,
> + dma_addr_t dma_start, u64 size)
> +{
> + struct bus_dma_region *map;
> + u64 offset = (u64)cpu_start - (u64)dma_start;
> +
> + if (!offset)
> + return 0;
> +
> + if (dev->dma_range_map) {
> + dev_err(dev, "attempt to add DMA range to existing map\n");
> + return -EINVAL;
> + }
> +
> + map = kcalloc(2, sizeof(*map), GFP_KERNEL);
> + if (!map)
> + return -ENOMEM;
> + map[0].cpu_start = cpu_start;
> + map[0].dma_start = dma_start;
> + map[0].offset = offset;
> + map[0].size = size;
> + dev->dma_range_map = map;
> +
> + return 0;
> +}
...
> +void *dma_copy_dma_range_map(const struct bus_dma_region *map)
> +{
> + int num_ranges;
> + struct bus_dma_region *new_map;
> + const struct bus_dma_region *r = map;
> +
> + for (num_ranges = 0; r->size; num_ranges++)
> + r++;
> + new_map = kcalloc(num_ranges + 1, sizeof(*map), GFP_KERNEL);
> + if (new_map)
> + memcpy(new_map, map, sizeof(*map) * num_ranges);
Looks like krealloc() on the first glance...
> +
> + return new_map;
> +}
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
On 18 August 2020 at 10:18 am, Gerd Hoffmann wrote: On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote: Hello I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the VirtIO-GPU (see below) still exists. Therefore we still need the patch (see below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine. It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a). Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which in turn should bring it to 5.9-rc2 or -rc3. take care, Gerd Hello Gerd, I compiled a new kernel with the latest DRM misc updates today. The patch is included in these updates. This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV machine on my X5000. Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") with a resolution of 640x480. If I set a higher resolution then the guest disables the monitor. I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU. Please check the latest DRM updates. Thanks, Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets
On 2020-08-18 14:59, Stephen Boyd wrote: Quoting Kuogee Hsieh (2020-08-18 14:15:46) add event thread to execute events serially from event queue. Also timeout mode is supported which allow an event be deferred to be executed at later time. Both link and phy compliant tests had been done successfully. Changes in v2: - Fix potential deadlock by removing redundant connect_mutex - Check and enable link clock during modeset - Drop unused code and fix function prototypes. - set sink power to normal operation state (D0) before DPCD read Changes in v3: - push idle pattern at main link before timing generator off - add timeout handles for both connect and disconnect This patch depends-on following series: https://lkml.kernel.org/lkml/20200812044223.19279-1-tan...@codeaurora.org/t.atom There's a v11 of this series. Can you rebase again? Signed-off-by: Kuogee Hsieh Signed-off-by: Guenter Roeck Signed-off-by: Tanmay Shah And fix this SoB chain to be proper with Co-developed-by tags and your tag coming last as you're the sender of the patch. Tanmay and Guenter signed-off were added by mistake. I will remove them ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: ast: fix double __iomem sparse warning
From: Randy Dunlap
sparse complains about having 2 "__iomem" attributes on the same line
where only one is needed since the first one applies to everything
up to the ending ';'.
However, to make it clear(er) that both of these pointers are
"__iomem", use separate lines for them.
../drivers/gpu/drm/ast/ast_cursor.c:256:26: CK: warning: duplicate [noderef]
../drivers/gpu/drm/ast/ast_cursor.c:256:26: CK: error: multiple address space
given: __iomem & __iomem
Signed-off-by: Randy Dunlap
Cc: Dave Airlie
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/ast/ast_cursor.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- lnx-59-rc1.orig/drivers/gpu/drm/ast/ast_cursor.c
+++ lnx-59-rc1/drivers/gpu/drm/ast/ast_cursor.c
@@ -253,7 +253,8 @@ void ast_cursor_show(struct ast_private
unsigned int offset_x, unsigned int offset_y)
{
u8 x_offset, y_offset;
- u8 __iomem *dst, __iomem *sig;
+ u8 __iomem *dst;
+ u8 __iomem *sig;
u8 jreg;
dst = ast->cursor.vaddr[ast->cursor.next_index];
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2] drm/msm: add shutdown support for display platform_driver
Hi,
On 2020-06-01 16:33, Krishna Manikandan wrote:
Define shutdown callback for display drm driver,
so as to disable all the CRTCS when shutdown
notification is received by the driver.
This change will turn off the timing engine so
that no display transactions are requested
while mmu translations are getting disabled
during reboot sequence.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Remove NULL check from msm_pdev_shutdown (Stephen Boyd)
- Change commit text to reflect when this issue
was uncovered (Sai Prakash Ranjan)
---
drivers/gpu/drm/msm/msm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c
b/drivers/gpu/drm/msm/msm_drv.c
index e4b750b..94e3963 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1322,6 +1322,13 @@ static int msm_pdev_remove(struct
platform_device *pdev)
return 0;
}
+static void msm_pdev_shutdown(struct platform_device *pdev)
+{
+ struct drm_device *drm = platform_get_drvdata(pdev);
+
+ drm_atomic_helper_shutdown(drm);
+}
+
static const struct of_device_id dt_match[] = {
{ .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
{ .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
@@ -1334,6 +1341,7 @@ static int msm_pdev_remove(struct platform_device
*pdev)
static struct platform_driver msm_platform_driver = {
.probe = msm_pdev_probe,
.remove = msm_pdev_remove,
+ .shutdown = msm_pdev_shutdown,
.driver = {
.name = "msm",
.of_match_table = dt_match,
Any more comments on this patch?
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] i2c: i2c-qcom-geni: Add tx_dma, rx_dma and xfer_len to geni_i2c_dev struct
Quoting Roja Rani Yarubandi (2020-08-14 02:55:39)
> Adding tx_dma, rx_dma and xfer length in geni_i2c_dev struct to
> store DMA mapping data to enhance its scope. For example during
> shutdown callback to unmap DMA mapping, these new struct members
> can be used as part of geni_se_tx_dma_unprep and
> geni_se_rx_dma_unprep calls.
Please read about how to write commit text from kernel docs[1]. Hint,
use imperative mood.
>
> Signed-off-by: Roja Rani Yarubandi
> ---
> drivers/i2c/busses/i2c-qcom-geni.c | 23 +--
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
> b/drivers/i2c/busses/i2c-qcom-geni.c
> index 7f130829bf01..53ca41f76080 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -86,6 +86,9 @@ struct geni_i2c_dev {
> u32 clk_freq_out;
> const struct geni_i2c_clk_fld *clk_fld;
> int suspended;
> + dma_addr_t tx_dma;
> + dma_addr_t rx_dma;
> + u32 xfer_len;
Why not size_t?
> };
>
> struct geni_i2c_err_log {
> @@ -352,12 +355,11 @@ static void geni_i2c_tx_fsm_rst(struct geni_i2c_dev
> *gi2c)
> static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg
> *msg,
> u32 m_param)
> {
> - dma_addr_t rx_dma;
> unsigned long time_left;
> void *dma_buf = NULL;
> struct geni_se *se = &gi2c->se;
> - size_t len = msg->len;
>
> + gi2c->xfer_len = msg->len;
I'd prefer to keep the local variable and then have
len = gi2c->xfer_len = msg->len;
> if (!of_machine_is_compatible("lenovo,yoga-c630"))
> dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
>
> @@ -366,9 +368,10 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev
> *gi2c, struct i2c_msg *msg,
> else
> geni_se_select_mode(se, GENI_SE_FIFO);
>
> - writel_relaxed(len, se->base + SE_I2C_RX_TRANS_LEN);
> + writel_relaxed(gi2c->xfer_len, se->base + SE_I2C_RX_TRANS_LEN);
So that all this doesn't have to change.
>
> - if (dma_buf && geni_se_rx_dma_prep(se, dma_buf, len, &rx_dma)) {
> + if (dma_buf && geni_se_rx_dma_prep(se, dma_buf, gi2c->xfer_len,
> + &gi2c->rx_dma)) {
> geni_se_select_mode(se, GENI_SE_FIFO);
> i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
> dma_buf = NULL;
> @@ -384,7 +387,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c,
> struct i2c_msg *msg,
> if (dma_buf) {
> if (gi2c->err)
> geni_i2c_rx_fsm_rst(gi2c);
> - geni_se_rx_dma_unprep(se, rx_dma, len);
> + geni_se_rx_dma_unprep(se, gi2c->rx_dma, gi2c->xfer_len);
> i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err);
> }
>
> @@ -394,12 +397,11 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev
> *gi2c, struct i2c_msg *msg,
> static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg
> *msg,
> u32 m_param)
> {
> - dma_addr_t tx_dma;
> unsigned long time_left;
> void *dma_buf = NULL;
> struct geni_se *se = &gi2c->se;
> - size_t len = msg->len;
>
> + gi2c->xfer_len = msg->len;
Same comment.
> if (!of_machine_is_compatible("lenovo,yoga-c630"))
> dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
>
[1]
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets
add event thread to execute events serially from event queue. Also
timeout mode is supported which allow an event be deferred to be
executed at later time. Both link and phy compliant tests had been
done successfully.
Changes in v2:
- Fix potential deadlock by removing redundant connect_mutex
- Check and enable link clock during modeset
- Drop unused code and fix function prototypes.
- set sink power to normal operation state (D0) before DPCD read
Changes in v3:
- push idle pattern at main link before timing generator off
- add timeout handles for both connect and disconnect
This patch depends-on following series:
https://lkml.kernel.org/lkml/20200812044223.19279-1-tan...@codeaurora.org/t.atom
Signed-off-by: Kuogee Hsieh
Signed-off-by: Guenter Roeck
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +
drivers/gpu/drm/msm/dp/dp_aux.c | 3 +
drivers/gpu/drm/msm/dp/dp_aux.h | 1 +
drivers/gpu/drm/msm/dp/dp_catalog.c | 77 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 370 +++---
drivers/gpu/drm/msm/dp/dp_ctrl.h| 3 +-
drivers/gpu/drm/msm/dp/dp_display.c | 747 +---
drivers/gpu/drm/msm/dp/dp_display.h | 1 -
drivers/gpu/drm/msm/dp/dp_drm.c | 4 -
drivers/gpu/drm/msm/dp/dp_hpd.c | 2 +-
drivers/gpu/drm/msm/dp/dp_hpd.h | 1 +
drivers/gpu/drm/msm/dp/dp_link.c| 22 +-
drivers/gpu/drm/msm/dp/dp_panel.c | 78 +-
drivers/gpu/drm/msm/dp/dp_panel.h | 9 +-
drivers/gpu/drm/msm/dp/dp_parser.c | 45 +-
drivers/gpu/drm/msm/dp/dp_parser.h | 2 +
drivers/gpu/drm/msm/dp/dp_power.c | 46 +-
drivers/gpu/drm/msm/dp/dp_power.h | 13 +
drivers/gpu/drm/msm/dp/dp_reg.h | 1 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
20 files changed, 972 insertions(+), 460 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 6a9e257d2fe6..81373bd38f0b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1221,6 +1221,11 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
/* wait for idle */
dpu_encoder_wait_for_event(drm_enc, MSM_ENC_TX_COMPLETE);
+ if (drm_enc->encoder_type == DRM_MODE_ENCODER_TMDS && priv->dp) {
+ if (msm_dp_display_pre_disable(priv->dp, drm_enc))
+ DPU_ERROR_ENC(dpu_enc, "dp display push idle failed\n");
+ }
+
dpu_encoder_resource_control(drm_enc, DPU_ENC_RC_EVENT_PRE_STOP);
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
@@ -1230,6 +1235,7 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
phys->ops.disable(phys);
}
+
/* after phys waits for frame-done, should be no more frames pending */
if (atomic_xchg(&dpu_enc->frame_done_timeout_ms, 0)) {
DPU_ERROR("enc%d timeout pending\n", drm_enc->base.id);
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 582b551f8689..5aaa4b50c303 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -189,6 +189,8 @@ static void dp_aux_native_handler(struct dp_aux_private
*aux)
aux->aux_error_num = DP_AUX_ERR_TOUT;
if (isr & DP_INTR_NACK_DEFER)
aux->aux_error_num = DP_AUX_ERR_NACK;
+ if (isr & DP_INTR_AUX_ERROR)
+ aux->aux_error_num = DP_AUX_ERR_DPPHY_AUX;
complete(&aux->comp);
}
@@ -359,6 +361,7 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
PHY_AUX_CFG1);
dp_catalog_aux_reset(aux->catalog);
}
+ usleep_range(400, 500); /* at least 400us to next try */
goto unlock_exit;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.h b/drivers/gpu/drm/msm/dp/dp_aux.h
index 2de11021d84a..1fbdfc9aa62e 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.h
+++ b/drivers/gpu/drm/msm/dp/dp_aux.h
@@ -15,6 +15,7 @@
#define DP_AUX_ERR_NACK-3
#define DP_AUX_ERR_DEFER -4
#define DP_AUX_ERR_NACK_DEFER -5
+#define DP_AUX_ERR_DPPHY_AUX -6
int dp_aux_register(struct drm_dp_aux *dp_aux);
void dp_aux_unregister(struct drm_dp_aux *dp_aux);
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index d186424044b1..f92a8e37a312 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -524,16 +524,21 @@ void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog
*dp_catalog,
* To make sure link reg writes happens before other operation,
* dp_write_link() function uses writel()
*/
- dp_write_link(catalog, REG_DP_MAINLINK_CTRL,
-
[PATCH v3] drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets
add event thread to execute events serially from event queue. Also
timeout mode is supported which allow an event be deferred to be
executed at later time. Both link and phy compliant tests had been
done successfully.
Changes in v2:
- Fix potential deadlock by removing redundant connect_mutex
- Check and enable link clock during modeset
- Drop unused code and fix function prototypes.
- set sink power to normal operation state (D0) before DPCD read
Changes in v3:
- push idle pattern at main link before timing generator off
- add timeout handles for both connect and disconnect
Signed-off-by: Kuogee Hsieh
This patch depends-on following series:
https://patchwork.kernel.org/project/dri-devel/list/?series=334239
This patch depends-on following series:
https://patchwork.kernel.org/project/dri-devel/list/?series=334239
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +
drivers/gpu/drm/msm/dp/dp_aux.c | 3 +
drivers/gpu/drm/msm/dp/dp_aux.h | 1 +
drivers/gpu/drm/msm/dp/dp_catalog.c | 77 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 370 +++---
drivers/gpu/drm/msm/dp/dp_ctrl.h| 3 +-
drivers/gpu/drm/msm/dp/dp_display.c | 747 +---
drivers/gpu/drm/msm/dp/dp_display.h | 1 -
drivers/gpu/drm/msm/dp/dp_drm.c | 4 -
drivers/gpu/drm/msm/dp/dp_hpd.c | 2 +-
drivers/gpu/drm/msm/dp/dp_hpd.h | 1 +
drivers/gpu/drm/msm/dp/dp_link.c| 22 +-
drivers/gpu/drm/msm/dp/dp_panel.c | 78 +-
drivers/gpu/drm/msm/dp/dp_panel.h | 9 +-
drivers/gpu/drm/msm/dp/dp_parser.c | 42 +-
drivers/gpu/drm/msm/dp/dp_parser.h | 2 +
drivers/gpu/drm/msm/dp/dp_power.c | 46 +-
drivers/gpu/drm/msm/dp/dp_power.h | 13 +
drivers/gpu/drm/msm/dp/dp_reg.h | 1 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
20 files changed, 971 insertions(+), 458 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 6a9e257d2fe6..81373bd38f0b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1221,6 +1221,11 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
/* wait for idle */
dpu_encoder_wait_for_event(drm_enc, MSM_ENC_TX_COMPLETE);
+ if (drm_enc->encoder_type == DRM_MODE_ENCODER_TMDS && priv->dp) {
+ if (msm_dp_display_pre_disable(priv->dp, drm_enc))
+ DPU_ERROR_ENC(dpu_enc, "dp display push idle failed\n");
+ }
+
dpu_encoder_resource_control(drm_enc, DPU_ENC_RC_EVENT_PRE_STOP);
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
@@ -1230,6 +1235,7 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
phys->ops.disable(phys);
}
+
/* after phys waits for frame-done, should be no more frames pending */
if (atomic_xchg(&dpu_enc->frame_done_timeout_ms, 0)) {
DPU_ERROR("enc%d timeout pending\n", drm_enc->base.id);
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 582b551f8689..5aaa4b50c303 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -189,6 +189,8 @@ static void dp_aux_native_handler(struct dp_aux_private
*aux)
aux->aux_error_num = DP_AUX_ERR_TOUT;
if (isr & DP_INTR_NACK_DEFER)
aux->aux_error_num = DP_AUX_ERR_NACK;
+ if (isr & DP_INTR_AUX_ERROR)
+ aux->aux_error_num = DP_AUX_ERR_DPPHY_AUX;
complete(&aux->comp);
}
@@ -359,6 +361,7 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
PHY_AUX_CFG1);
dp_catalog_aux_reset(aux->catalog);
}
+ usleep_range(400, 500); /* at least 400us to next try */
goto unlock_exit;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.h b/drivers/gpu/drm/msm/dp/dp_aux.h
index 2de11021d84a..1fbdfc9aa62e 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.h
+++ b/drivers/gpu/drm/msm/dp/dp_aux.h
@@ -15,6 +15,7 @@
#define DP_AUX_ERR_NACK-3
#define DP_AUX_ERR_DEFER -4
#define DP_AUX_ERR_NACK_DEFER -5
+#define DP_AUX_ERR_DPPHY_AUX -6
int dp_aux_register(struct drm_dp_aux *dp_aux);
void dp_aux_unregister(struct drm_dp_aux *dp_aux);
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index d186424044b1..f92a8e37a312 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -524,16 +524,21 @@ void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog
*dp_catalog,
* To make sure link reg writes happens before other operation,
* dp_write_link() function uses writel()
*/
- dp_write_link(catalog, REG
[PATCH 3/3] dma-heap: Devicetree binding for chunk heap
Document devicetree binding for chunk heap on dma heap framework
Signed-off-by: Hyesoo Yu
---
.../devicetree/bindings/dma-buf/chunk_heap.yaml| 46 ++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml
diff --git a/Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml
b/Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml
new file mode 100644
index 000..1ee8fad
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma-buf/chunk_heap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Device tree binding for chunk heap on DMA HEAP FRAMEWORK
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The chunk heap is backed by the Contiguous Memory Allocator (CMA) and
+ allocates the buffers that are made up to a list of fixed size chunks
+ taken from CMA. Chunk sizes are configurated when the heaps are created.
+
+properties:
+ compatible:
+enum:
+ - dma_heap,chunk
+
+required:
+ - compatible
+ - memory-region
+ - alignment
+
+additionalProperties: false
+
+examples:
+ - |
+reserved-memory {
+#address-cells = <2>;
+#size-cells = <1>;
+
+chunk_memory: chunk_memory {
+compatible = "shared-dma-pool";
+reusable;
+size = <0x1000>;
+};
+};
+
+chunk_default_heap: chunk_default_heap {
+compatible = "dma_heap,chunk";
+memory-region = <&chunk_memory>;
+alignment = <0x1>;
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2] drm/msm: add shutdown support for display platform_driver
On 2020-08-18 20:42, Rob Clark wrote:
On Tue, Aug 18, 2020 at 3:03 AM Sai Prakash Ranjan
wrote:
Hi,
On 2020-06-01 16:33, Krishna Manikandan wrote:
> Define shutdown callback for display drm driver,
> so as to disable all the CRTCS when shutdown
> notification is received by the driver.
>
> This change will turn off the timing engine so
> that no display transactions are requested
> while mmu translations are getting disabled
> during reboot sequence.
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v2:
> - Remove NULL check from msm_pdev_shutdown (Stephen Boyd)
> - Change commit text to reflect when this issue
> was uncovered (Sai Prakash Ranjan)
> ---
> drivers/gpu/drm/msm/msm_drv.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c
> b/drivers/gpu/drm/msm/msm_drv.c
> index e4b750b..94e3963 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -1322,6 +1322,13 @@ static int msm_pdev_remove(struct
> platform_device *pdev)
> return 0;
> }
>
> +static void msm_pdev_shutdown(struct platform_device *pdev)
> +{
> + struct drm_device *drm = platform_get_drvdata(pdev);
> +
> + drm_atomic_helper_shutdown(drm);
> +}
> +
> static const struct of_device_id dt_match[] = {
> { .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
> { .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
> @@ -1334,6 +1341,7 @@ static int msm_pdev_remove(struct platform_device
> *pdev)
> static struct platform_driver msm_platform_driver = {
> .probe = msm_pdev_probe,
> .remove = msm_pdev_remove,
> + .shutdown = msm_pdev_shutdown,
> .driver = {
> .name = "msm",
> .of_match_table = dt_match,
Any more comments on this patch?
sorry, I managed to overlook this earlier.. I've pulled it in to
msm-next
No problem, thanks Rob.
-Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
On 18 August 2020 at 10:18 am, Gerd Hoffmann wrote: On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote: Hello I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the VirtIO-GPU (see below) still exists. Therefore we still need the patch (see below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine. It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a). Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which in turn should bring it to 5.9-rc2 or -rc3. take care, Gerd Thank you! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] virtio: fix build for configs without dma-bufs
Reported-by: kernel test robot
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/Kconfig | 1 +
drivers/virtio/Kconfig | 7 +++
drivers/virtio/Makefile | 3 ++-
drivers/virtio/virtio_dma_buf.c | 3 +++
4 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index eff3047052d4..67624423013a 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -4,6 +4,7 @@ config DRM_VIRTIO_GPU
depends on DRM && VIRTIO && MMU
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
+ select VIRTIO_DMA_SHARED_BUFFER
help
This is the virtual GPU driver for virtio. It can be used with
QEMU based VMMs (like KVM or Xen).
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 5c92e4a50882..e76e9b9ba93c 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -126,4 +126,11 @@ config VIRTIO_MMIO_CMDLINE_DEVICES
If unsure, say 'N'.
+config VIRTIO_DMA_SHARED_BUFFER
+ tristate
+ depends on DMA_SHARED_BUFFER
+ help
+This option adds a flavor of dma buffers that are backed by
+virtio resources.
+
endif # VIRTIO_MENU
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 49da768ee7fd..591e6f72aa54 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o virtio_dma_buf.o
+obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o
obj-$(CONFIG_VIRTIO_MMIO) += virtio_mmio.o
obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o
virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
@@ -8,3 +8,4 @@ obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
obj-$(CONFIG_VIRTIO_VDPA) += virtio_vdpa.o
obj-$(CONFIG_VIRTIO_MEM) += virtio_mem.o
+obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o
diff --git a/drivers/virtio/virtio_dma_buf.c b/drivers/virtio/virtio_dma_buf.c
index 45d6e8647dcf..5127a2f0c986 100644
--- a/drivers/virtio/virtio_dma_buf.c
+++ b/drivers/virtio/virtio_dma_buf.c
@@ -5,6 +5,7 @@
* Copyright (C) 2020 Google, Inc.
*/
+#include
#include
/**
@@ -83,3 +84,5 @@ int virtio_dma_buf_get_uuid(struct dma_buf *dma_buf,
return ops->get_uuid(dma_buf, uuid);
}
EXPORT_SYMBOL(virtio_dma_buf_get_uuid);
+
+MODULE_LICENSE("GPL");
--
2.28.0.220.ged08abb693-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] char: ipmi: convert tasklets to use new tasklet_setup() API
> >
> > Signed-off-by: Romain Perier
> > Signed-off-by: Allen Pais
>
> This looks good to me.
>
> Reviewed-by: Corey Minyard
>
> Are you planning to push this, or do you want me to take it? If you
> want me to take it, what is the urgency?
Thanks. Well, not hurry, as long as it goes into 5.9 with all other
changes.
>
> -corey
>
> > ---
> > drivers/char/ipmi/ipmi_msghandler.c | 13 ++---
> > 1 file changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/char/ipmi/ipmi_msghandler.c
> > b/drivers/char/ipmi/ipmi_msghandler.c
> > index 737c0b6b24ea..e1814b6a1225 100644
> > --- a/drivers/char/ipmi/ipmi_msghandler.c
> > +++ b/drivers/char/ipmi/ipmi_msghandler.c
> > @@ -39,7 +39,7 @@
> >
> > static struct ipmi_recv_msg *ipmi_alloc_recv_msg(void);
> > static int ipmi_init_msghandler(void);
> > -static void smi_recv_tasklet(unsigned long);
> > +static void smi_recv_tasklet(struct tasklet_struct *t);
> > static void handle_new_recv_msgs(struct ipmi_smi *intf);
> > static void need_waiter(struct ipmi_smi *intf);
> > static int handle_one_recv_msg(struct ipmi_smi *intf,
> > @@ -3430,9 +3430,8 @@ int ipmi_add_smi(struct module *owner,
> > intf->curr_seq = 0;
> > spin_lock_init(&intf->waiting_rcv_msgs_lock);
> > INIT_LIST_HEAD(&intf->waiting_rcv_msgs);
> > - tasklet_init(&intf->recv_tasklet,
> > - smi_recv_tasklet,
> > - (unsigned long) intf);
> > + tasklet_setup(&intf->recv_tasklet,
> > + smi_recv_tasklet);
> > atomic_set(&intf->watchdog_pretimeouts_to_deliver, 0);
> > spin_lock_init(&intf->xmit_msgs_lock);
> > INIT_LIST_HEAD(&intf->xmit_msgs);
> > @@ -4467,10 +4466,10 @@ static void handle_new_recv_msgs(struct ipmi_smi
> > *intf)
> > }
> > }
> >
> > -static void smi_recv_tasklet(unsigned long val)
> > +static void smi_recv_tasklet(struct tasklet_struct *t)
> > {
> > unsigned long flags = 0; /* keep us warning-free. */
> > - struct ipmi_smi *intf = (struct ipmi_smi *) val;
> > + struct ipmi_smi *intf = from_tasklet(intf, t, recv_tasklet);
> > int run_to_completion = intf->run_to_completion;
> > struct ipmi_smi_msg *newmsg = NULL;
> >
> > @@ -4542,7 +4541,7 @@ void ipmi_smi_msg_received(struct ipmi_smi *intf,
> > spin_unlock_irqrestore(&intf->xmit_msgs_lock, flags);
> >
> > if (run_to_completion)
> > - smi_recv_tasklet((unsigned long) intf);
> > + smi_recv_tasklet(&intf->recv_tasklet);
> > else
> > tasklet_schedule(&intf->recv_tasklet);
> > }
> > --
> > 2.17.1
> >
--
- Allen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets
Quoting Kuogee Hsieh (2020-08-18 14:15:46) > add event thread to execute events serially from event queue. Also > timeout mode is supported which allow an event be deferred to be > executed at later time. Both link and phy compliant tests had been > done successfully. > > Changes in v2: > - Fix potential deadlock by removing redundant connect_mutex > - Check and enable link clock during modeset > - Drop unused code and fix function prototypes. > - set sink power to normal operation state (D0) before DPCD read > > Changes in v3: > - push idle pattern at main link before timing generator off > - add timeout handles for both connect and disconnect > > This patch depends-on following series: > https://lkml.kernel.org/lkml/20200812044223.19279-1-tan...@codeaurora.org/t.atom There's a v11 of this series. Can you rebase again? > > Signed-off-by: Kuogee Hsieh > Signed-off-by: Guenter Roeck > Signed-off-by: Tanmay Shah And fix this SoB chain to be proper with Co-developed-by tags and your tag coming last as you're the sender of the patch. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: backlight: sky81452-backlight: Fix refcount imbalance on error
When of_property_read_u32_array() returns an error code, a
pairing refcount decrement is needed to keep np's refcount
balanced.
Fixes: f705806c9f355 ("backlight: Add support Skyworks SKY81452 backlight
driver")
Signed-off-by: Dinghao Liu
---
drivers/video/backlight/sky81452-backlight.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/backlight/sky81452-backlight.c
b/drivers/video/backlight/sky81452-backlight.c
index 0ce181585008..8268ac43d54f 100644
--- a/drivers/video/backlight/sky81452-backlight.c
+++ b/drivers/video/backlight/sky81452-backlight.c
@@ -217,6 +217,7 @@ static struct sky81452_bl_platform_data
*sky81452_bl_parse_dt(
num_entry);
if (ret < 0) {
dev_err(dev, "led-sources node is invalid.\n");
+ of_node_put(np);
return ERR_PTR(-EINVAL);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/nouveau/svm: remove duplicate include
Remove nvif/if000c.h which is included more than once Reported-by: Hulk Robot Signed-off-by: Wang Hai --- drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c index 4e8112fde3e6..897b2dbee84e 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c @@ -33,7 +33,6 @@ #include #include #include -#include #include -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/mediatek: remove duplicate include
Remove mtk_drm_ddp.h which is included more than once Reported-by: Hulk Robot Signed-off-by: Wang Hai --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index 040a8f393fe2..a34fd805ce6d 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -27,7 +27,6 @@ #include "mtk_drm_crtc.h" #include "mtk_drm_ddp.h" -#include "mtk_drm_ddp.h" #include "mtk_drm_ddp_comp.h" #include "mtk_drm_drv.h" #include "mtk_drm_gem.h" -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 1/4] dt-bindings: display: panel-dsi-cm: convert to YAML
* Sebastian Reichel [200716 18:07]: > On Thu, Jul 16, 2020 at 07:52:58PM +0200, Sam Ravnborg wrote: > > The DTS file changes needs to go in via another route. > > No worries. I guess Tony will queue them up when he finds some time. Thanks applying the dts changes into omap-for-v5.10/dt. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] char: ipmi: convert tasklets to use new tasklet_setup() API
On Tue, Aug 18, 2020 at 02:46:23PM +0530, Allen wrote:
> > >
> > > Signed-off-by: Romain Perier
> > > Signed-off-by: Allen Pais
> >
> > This looks good to me.
> >
> > Reviewed-by: Corey Minyard
> >
> > Are you planning to push this, or do you want me to take it? If you
> > want me to take it, what is the urgency?
>
> Thanks. Well, not hurry, as long as it goes into 5.9 with all other
> changes.
Ok, this is queued in my for-next branch.
-corey
>
>
> >
> > -corey
> >
> > > ---
> > > drivers/char/ipmi/ipmi_msghandler.c | 13 ++---
> > > 1 file changed, 6 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/char/ipmi/ipmi_msghandler.c
> > > b/drivers/char/ipmi/ipmi_msghandler.c
> > > index 737c0b6b24ea..e1814b6a1225 100644
> > > --- a/drivers/char/ipmi/ipmi_msghandler.c
> > > +++ b/drivers/char/ipmi/ipmi_msghandler.c
> > > @@ -39,7 +39,7 @@
> > >
> > > static struct ipmi_recv_msg *ipmi_alloc_recv_msg(void);
> > > static int ipmi_init_msghandler(void);
> > > -static void smi_recv_tasklet(unsigned long);
> > > +static void smi_recv_tasklet(struct tasklet_struct *t);
> > > static void handle_new_recv_msgs(struct ipmi_smi *intf);
> > > static void need_waiter(struct ipmi_smi *intf);
> > > static int handle_one_recv_msg(struct ipmi_smi *intf,
> > > @@ -3430,9 +3430,8 @@ int ipmi_add_smi(struct module *owner,
> > > intf->curr_seq = 0;
> > > spin_lock_init(&intf->waiting_rcv_msgs_lock);
> > > INIT_LIST_HEAD(&intf->waiting_rcv_msgs);
> > > - tasklet_init(&intf->recv_tasklet,
> > > - smi_recv_tasklet,
> > > - (unsigned long) intf);
> > > + tasklet_setup(&intf->recv_tasklet,
> > > + smi_recv_tasklet);
> > > atomic_set(&intf->watchdog_pretimeouts_to_deliver, 0);
> > > spin_lock_init(&intf->xmit_msgs_lock);
> > > INIT_LIST_HEAD(&intf->xmit_msgs);
> > > @@ -4467,10 +4466,10 @@ static void handle_new_recv_msgs(struct ipmi_smi
> > > *intf)
> > > }
> > > }
> > >
> > > -static void smi_recv_tasklet(unsigned long val)
> > > +static void smi_recv_tasklet(struct tasklet_struct *t)
> > > {
> > > unsigned long flags = 0; /* keep us warning-free. */
> > > - struct ipmi_smi *intf = (struct ipmi_smi *) val;
> > > + struct ipmi_smi *intf = from_tasklet(intf, t, recv_tasklet);
> > > int run_to_completion = intf->run_to_completion;
> > > struct ipmi_smi_msg *newmsg = NULL;
> > >
> > > @@ -4542,7 +4541,7 @@ void ipmi_smi_msg_received(struct ipmi_smi *intf,
> > > spin_unlock_irqrestore(&intf->xmit_msgs_lock, flags);
> > >
> > > if (run_to_completion)
> > > - smi_recv_tasklet((unsigned long) intf);
> > > + smi_recv_tasklet(&intf->recv_tasklet);
> > > else
> > > tasklet_schedule(&intf->recv_tasklet);
> > > }
> > > --
> > > 2.17.1
> > >
>
>
>
> --
>- Allen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 --- Comment #34 from Petteri Aimonen (j...@kernelbug.mail.kapsi.fi) --- @krakopo Can you apply the debug info patch from here? https://bugzilla.kernel.org/attachment.cgi?id=289421&action=diff What kernel are you running inside the KVM virtual machine? I wonder if the virtual machine has the MXCSR problem, perhaps it could be leaking to the host somehow. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] virtio: fix build for configs without dma-bufs
On Wed, Aug 19, 2020 at 12:10:11PM +0900, David Stevens wrote: > Reported-by: kernel test robot > Signed-off-by: David Stevens Pushed to drm-misc-next thanks for the qick fix, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987
krak...@protonmail.com changed:
What|Removed |Added
CC||krak...@protonmail.com
--- Comment #33 from krak...@protonmail.com ---
I'm seeing this on an AMD Ryzen 4500U laptop running 5.8.1 (Arch Linux
5.8.1-arch1-1). I can repro fairly consistently when running a 64-bit KVM
virtual machine.
The kernel I'm running has the commit which should resolve this:
7ad816762f9b ("x86/fpu: Reset MXCSR to default in kernel_fpu_begin()")
Confirmed patch is in my kernel:
https://git.archlinux.org/linux.git/tree/arch/x86/kernel/fpu/core.c?h=v5.8.1-arch1#n106
Here is what I see in dmesg:
Aug 18 20:25:49 archpad kernel: simd exception: [#1] PREEMPT SMP NOPTI
Aug 18 20:25:49 archpad kernel: CPU: 0 PID: 509 Comm: Xorg Not tainted
5.8.1-arch1-1 #1
Aug 18 20:25:49 archpad kernel: Hardware name: LENOVO 81W4/LNVNB161216, BIOS
DZCN19WW 04/13/2020
Aug 18 20:25:49 archpad kernel: RIP: 0010:dcn_bw_ceil2+0x35/0x60 [amdgpu]
Aug 18 20:25:49 archpad kernel: Code: cd 7b 3e 0f 28 d0 66 0f ef db 66 0f ef e4
f3 0f 5e d1 f3 0f 5a e0 f3 0f 2c c2 66 0f ef d2 f3 0f 2a d0 f3 0f 59 d1 f3 0f
5a da 0f 58 1d 5b 19 2e 00 66 0f 2f dc 72 01 c3 f3 0f 58 ca 0f 28 c1
Aug 18 20:25:49 archpad kernel: RSP: 0018:b8fac07035f8 EFLAGS: 00010202
Aug 18 20:25:49 archpad kernel: RAX: 0004 RBX:
RCX: 0780
Aug 18 20:25:49 archpad kernel: RDX: 97ebd0a63080 RSI: 97ebd0a69560
RDI: 4440
Aug 18 20:25:49 archpad kernel: RBP: 97ebd0a631c0 R08: 97ebd0a633b4
R09:
Aug 18 20:25:49 archpad kernel: R10: R11:
R12: 97ebd0a63360
Aug 18 20:25:49 archpad kernel: R13: 0001 R14: 97ebd0a62188
R15: 97ebd0a62028
Aug 18 20:25:49 archpad kernel: FS: 7f8787a65940()
GS:97ec4740() knlGS:
Aug 18 20:25:49 archpad kernel: CS: 0010 DS: ES: CR0:
80050033
Aug 18 20:25:49 archpad kernel: CR2: 00080088 CR3: 0001f904
CR4: 00340ef0
Aug 18 20:25:49 archpad kernel: Call Trace:
Aug 18 20:25:49 archpad kernel:
dml21_ModeSupportAndSystemConfigurationFull+0x437/0x5cf0 [amdgpu]
Aug 18 20:25:49 archpad kernel: ? sysvec_apic_timer_interrupt+0x46/0xe0
Aug 18 20:25:49 archpad kernel: ? asm_sysvec_apic_timer_interrupt+0x12/0x20
Aug 18 20:25:49 archpad kernel: ? sched_clock+0x5/0x10
Aug 18 20:25:49 archpad kernel: ? sched_clock_local+0x12/0x80
Aug 18 20:25:49 archpad kernel: ? amdgpu_sa_bo_new+0xbc/0x550 [amdgpu]
Aug 18 20:25:49 archpad kernel: ? sched_clock_cpu+0xae/0xd0
Aug 18 20:25:49 archpad kernel: ? kmem_cache_alloc_trace+0x17c/0x220
Aug 18 20:25:49 archpad kernel: ? amdgpu_sa_bo_new+0xbc/0x550 [amdgpu]
Aug 18 20:25:49 archpad kernel: ? _raw_spin_unlock+0x16/0x30
Aug 18 20:25:49 archpad kernel: ? preempt_count_add+0x49/0xa0
Aug 18 20:25:49 archpad kernel: ? kernel_init_free_pages+0x6d/0x90
Aug 18 20:25:49 archpad kernel: ? prep_new_page+0xa2/0xb0
Aug 18 20:25:49 archpad kernel: ? get_page_from_freelist+0xfa8/0x1220
Aug 18 20:25:49 archpad kernel: ? __mod_zone_page_state+0x66/0xa0
Aug 18 20:25:49 archpad kernel: ? hubbub2_get_dcc_compression_cap+0xa8/0x270
[amdgpu]
Aug 18 20:25:49 archpad kernel: ? fill_plane_buffer_attributes+0x26f/0x420
[amdgpu]
Aug 18 20:25:49 archpad kernel: dml_get_voltage_level+0x116/0x1e0 [amdgpu]
Aug 18 20:25:49 archpad kernel: dcn20_fast_validate_bw+0x359/0x680 [amdgpu]
Aug 18 20:25:49 archpad kernel: ? resource_build_scaling_params+0xc44/0x11a0
[amdgpu]
Aug 18 20:25:49 archpad kernel: dcn21_validate_bandwidth+0xcd/0x2a0 [amdgpu]
Aug 18 20:25:49 archpad kernel: dc_validate_global_state+0x2f2/0x390 [amdgpu]
Aug 18 20:25:49 archpad kernel: amdgpu_dm_atomic_check+0xefb/0x1010 [amdgpu]
Aug 18 20:25:49 archpad kernel: drm_atomic_check_only+0x57c/0x7f0 [drm]
Aug 18 20:25:49 archpad kernel: ?
__drm_atomic_helper_crtc_duplicate_state+0x85/0xd0 [drm_kms_helper]
Aug 18 20:25:49 archpad kernel: drm_atomic_commit+0x13/0x50 [drm]
Aug 18 20:25:49 archpad kernel: drm_atomic_helper_legacy_gamma_set+0x123/0x180
[drm_kms_helper]
Aug 18 20:25:49 archpad kernel: drm_mode_gamma_set_ioctl+0x19a/0x230 [drm]
Aug 18 20:25:49 archpad kernel: ? drm_color_lut_check+0xa0/0xa0 [drm]
Aug 18 20:25:49 archpad kernel: drm_ioctl_kernel+0xb2/0x100 [drm]
Aug 18 20:25:49 archpad kernel: drm_ioctl+0x208/0x360 [drm]
Aug 18 20:25:49 archpad kernel: ? drm_color_lut_check+0xa0/0xa0 [drm]
Aug 18 20:25:49 archpad kernel: amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
Aug 18 20:25:49 archpad kernel: ksys_ioctl+0x82/0xc0
Aug 18 20:25:49 archpad kernel: __x64_sys_ioctl+0x16/0x20
Aug 18 20:25:49 archpad kernel: do_syscall_64+0x44/0x70
Aug 18 20:25:49 archpad kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Aug 18 20:25:49 archpad kernel: RIP: 0033:0x7f87887888eb
Aug 18 20:2
[PATCH 2/3] drm/amdgpu: Get DRM dev from adev by inline-f
Add a static inline adev_to_drm() to obtain
the DRM device pointer from an amdgpu_device pointer.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 6 +-
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 178
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 26 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 34 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 20 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 18 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +-
.../gpu/drm/amd/amdgpu/atombios_encoders.c| 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 46 ++---
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 46 ++---
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 46 ++---
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 46 ++---
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 36 ++--
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 84
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 +-
.../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 4 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +-
drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 6 +-
drivers/gpu/drm/amd/pm/amdgpu_pm.c| 194 +-
33 files changed, 430 insertions(+), 425 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index d75f6a29a0d2..735480cc7dcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -993,6 +993,11 @@ static inline struct amdgpu_device *drm_to_adev(struct
drm_device *ddev)
return ddev->dev_private;
}
+static inline struct drm_device *adev_to_drm(struct amdgpu_device *adev)
+{
+ return adev->ddev;
+}
+
static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)
{
return container_of(bdev, struct amdgpu_device, mman.bdev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 913c8f0513bd..4a93b880c6bf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -463,11 +463,11 @@ static int amdgpu_atif_handler(struct amdgpu_device *adev,
if (req.pending & ATIF_DGPU_DISPLAY_EVENT) {
if (adev->flags & AMD_IS_PX) {
- pm_runtime_get_sync(adev->ddev->dev);
+ pm_runtime_get_sync(adev_to_drm(adev)->dev);
/* Just fire off a uevent and let userspace
tell us what to do */
- drm_helper_hpd_irq_event(adev->ddev);
- pm_runtime_mark_last_busy(adev->ddev->dev);
- pm_runtime_put_autosuspend(adev->ddev->dev);
+ drm_helper_hpd_irq_event(adev_to_drm(adev));
+
pm_runtime_mark_last_busy(adev_to_drm(adev)->dev);
+
pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
}
}
/* TODO: check other events */
@@ -817,7 +817,7 @@ int amdgpu_acpi_init(struct amdgpu_device *adev)
struct drm_encoder *tmp;
/* Find the encoder controlling the brightness */
- list_for_each_entry(tmp,
&adev->ddev->mode_config.encoder_list,
+ list_for_each_entry(tmp,
&adev_to_drm(adev)->mode_config.encoder_list,
head) {
struct amdgpu_encoder *enc =
to_amdgpu_encoder(tmp);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index b74846fc3933..d58148f455dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -119,7 +119,7 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
.gpuvm_size = min(adev->vm_manager.max_pfn
<< AMDGPU_GPU_PAGE_SHIFT,
AMDGPU_GMC_HOLE_START),
- .drm_
[PATCH 0/3] Embed drm_device and eliminate use of dev_private (v2)
As per the comments in include/drm/drm_device.h, struct drm_device::dev_private seems to be obsolete and it's recommended that drivers embed struct drm_device into their larger per-device structure. This patchset embeds struct drm_device into struct amdgpu_device, adds inline functions to access both structures from one another, adds a DRM driver release callback to free the container struct amdgpu_device, and eliminates using struct drm_device::dev_private. v2: Split out patch 2/2 into two patches. Luben Tuikov (3): drm/amdgpu: drm_device to amdgpu_device by inline-f (v2) drm/amdgpu: Get DRM dev from adev by inline-f drm/amdgpu: Embed drm_device into amdgpu_device (v2) drivers/gpu/drm/amd/amdgpu/amdgpu.h | 16 +- drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 8 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 16 +- drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +- .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 20 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 186 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 61 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 42 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 53 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 20 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 12 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 14 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 20 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 36 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 6 +- drivers/gpu/drm/amd/amdgpu/atombios_crtc.c| 22 +- drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 6 +- .../gpu/drm/amd/amdgpu/atombios_encoders.c| 36 +-- drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 94 +++--- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 96 +++--- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 104 +++ drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 94 +++--- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 40 +-- drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 2 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 145 + .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 3 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 8 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 4 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 8 +- drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 6 +- drivers/gpu/drm/amd/pm/amdgpu_pm.c| 274 +- 54 files changed, 774 insertions(+), 768 deletions(-) -- 2.28.0.215.g878e727637 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/amdgpu: drm_device to amdgpu_device by inline-f (v2)
Get the amdgpu_device from the DRM device by use
of an inline function, drm_to_adev(). The inline
function resolves a pointer to struct drm_device
to a pointer to struct amdgpu_device.
v2: Use a typed visible static inline function
instead of an invisible macro.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 2 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 10 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 18 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 20 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 12 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 10 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 4 +-
drivers/gpu/drm/amd/amdgpu/atombios_crtc.c| 22 ++---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 6 +-
.../gpu/drm/amd/amdgpu/atombios_encoders.c| 34
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 48 +--
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 50 ++--
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 58 +++---
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 48 +--
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 4 +-
drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 2 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 61 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 3 +-
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 2 +-
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +-
drivers/gpu/drm/amd/pm/amdgpu_pm.c| 80 +--
44 files changed, 304 insertions(+), 301 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 9c6fb38ce59d..d75f6a29a0d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -988,6 +988,11 @@ struct amdgpu_device {
struct ratelimit_state throttling_logging_rs;
};
+static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
+{
+ return ddev->dev_private;
+}
+
static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)
{
return container_of(bdev, struct amdgpu_device, mman.bdev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 0effc1d46824..b74846fc3933 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -483,7 +483,7 @@ int amdgpu_amdkfd_get_dmabuf_info(struct kgd_dev *kgd, int
dma_buf_fd,
/* Can't handle buffers from different drivers */
goto out_put;
- adev = obj->dev->dev_private;
+ adev = drm_to_adev(obj->dev);
bo = gem_to_amdgpu_bo(obj);
if (!(bo->preferred_domains & (AMDGPU_GEM_DOMAIN_VRAM |
AMDGPU_GEM_DOMAIN_GTT)))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 7e2394b50fbf..b1ce0d4e94c4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1674,7 +1674,7 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev *kgd,
return -EINVAL;
obj = dma_buf->priv;
- if (obj->dev->dev_private != adev)
+ if (drm_to_adev(obj->dev) != adev)
/* Can't handle buffers from other devices */
return -EINVAL;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
index e33f63712b46..662cc414ceec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -1882,7 +1882,7 @@ static voi
[PATCH 3/3] drm/amdgpu: Embed drm_device into amdgpu_device (v2)
a) Embed struct drm_device into struct amdgpu_device.
b) Modify the inline-f drm_to_adev() accordingly.
c) Modify the inline-f adev_to_drm() accordingly.
d) Eliminate the use of drm_device.dev_private,
in amdgpu.
e) Switch from using drm_dev_alloc() to
drm_dev_init().
f) Add a DRM driver release function, which frees
the container amdgpu_device after all krefs on
the contained drm_device have been released.
v2: Split out adding adev_to_drm() into its own
patch (previous commit), making this patch
more succinct and clear. More detailed commit
description.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 10 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 43 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 20 +++---
4 files changed, 43 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 735480cc7dcf..107a6ec920f7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -724,8 +724,8 @@ struct amd_powerplay {
#define AMDGPU_MAX_DF_PERFMONS 4
struct amdgpu_device {
struct device *dev;
- struct drm_device *ddev;
struct pci_dev *pdev;
+ struct drm_device ddev;
#ifdef CONFIG_DRM_AMD_ACP
struct amdgpu_acp acp;
@@ -990,12 +990,12 @@ struct amdgpu_device {
static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
{
- return ddev->dev_private;
+ return container_of(ddev, struct amdgpu_device, ddev);
}
static inline struct drm_device *adev_to_drm(struct amdgpu_device *adev)
{
- return adev->ddev;
+ return &adev->ddev;
}
static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)
@@ -1004,8 +1004,6 @@ static inline struct amdgpu_device
*amdgpu_ttm_adev(struct ttm_bo_device *bdev)
}
int amdgpu_device_init(struct amdgpu_device *adev,
- struct drm_device *ddev,
- struct pci_dev *pdev,
uint32_t flags);
void amdgpu_device_fini(struct amdgpu_device *adev);
int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
@@ -1195,7 +1193,7 @@ static inline void *amdgpu_atpx_get_dhandle(void) {
return NULL; }
extern const struct drm_ioctl_desc amdgpu_ioctls_kms[];
extern const int amdgpu_max_kms_ioctl;
-int amdgpu_driver_load_kms(struct drm_device *dev, unsigned long flags);
+int amdgpu_driver_load_kms(struct amdgpu_device *adev, unsigned long flags);
void amdgpu_driver_unload_kms(struct drm_device *dev);
void amdgpu_driver_lastclose_kms(struct drm_device *dev);
int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 07012d71eeea..6e529548e708 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1216,7 +1216,8 @@ static int amdgpu_device_check_arguments(struct
amdgpu_device *adev)
* Callback for the switcheroo driver. Suspends or resumes the
* the asics before or after it is powered up using ACPI methods.
*/
-static void amdgpu_switcheroo_set_state(struct pci_dev *pdev, enum
vga_switcheroo_state state)
+static void amdgpu_switcheroo_set_state(struct pci_dev *pdev,
+ enum vga_switcheroo_state state)
{
struct drm_device *dev = pci_get_drvdata(pdev);
int r;
@@ -2977,8 +2978,6 @@ static const struct attribute *amdgpu_dev_attributes[] = {
* amdgpu_device_init - initialize the driver
*
* @adev: amdgpu_device pointer
- * @ddev: drm dev pointer
- * @pdev: pci dev pointer
* @flags: driver flags
*
* Initializes the driver info and hw (all asics).
@@ -2986,18 +2985,15 @@ static const struct attribute *amdgpu_dev_attributes[]
= {
* Called at driver startup.
*/
int amdgpu_device_init(struct amdgpu_device *adev,
- struct drm_device *ddev,
- struct pci_dev *pdev,
uint32_t flags)
{
+ struct drm_device *ddev = adev_to_drm(adev);
+ struct pci_dev *pdev = adev->pdev;
int r, i;
bool boco = false;
u32 max_MBps;
adev->shutdown = false;
- adev->dev = &pdev->dev;
- adev->ddev = ddev;
- adev->pdev = pdev;
adev->flags = flags;
if (amdgpu_force_asic_type >= 0 && amdgpu_force_asic_type < CHIP_LAST)
@@ -3451,9 +3447,8 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
fbcon)
struct drm_connector_list_iter iter;
int r;
- if (dev == NULL || dev->dev_private == NULL) {
+ if (!dev)
return -ENODEV;
- }
adev = drm_to_adev(dev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_
Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
On Tue, Aug 18, 2020 at 04:41:38PM +0200, Christian Zigotzky wrote: > Hello Gerd, > > I compiled a new kernel with the latest DRM misc updates today. The patch is > included in these updates. > > This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV machine > on my X5000. > > Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") with > a resolution of 640x480. If I set a higher resolution then the guest > disables the monitor. > I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU. > > Please check the latest DRM updates. https://patchwork.freedesktop.org/patch/385980/ (tests & reviews & acks are welcome) HTH, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/qxl: Fix build errors
On Tue, 18 Aug 2020 at 15:32, Gerd Hoffmann wrote: > > Hi, > > > I guess things are never quite so easy :-). It looks like Daniel's > > patch is in drm-misc-fixes and Sidong's patch is in drm-misc-next. On > > their own they're fine, but once they are merged in drm-tip the build > > error shows up. > > Ah, ok. I've already wondered how that got past my build testing. > This explains it. > > thanks for looking into it, I've fixed this in drm-tip with a fixup. In future when we find these silent conflicts, can someone please https://drm.pages.freedesktop.org/maintainer-tools/drm-tip.html follow those instructions to fix it up. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/i915/dp: TPS4 PHY test pattern compliance support
On Tue, 2020-08-18 at 14:29 -0700, Navare, Manasi wrote:
> On Wed, Jul 22, 2020 at 05:36:27PM -0700, Khaled Almahallawy wrote:
> > Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source
> > tests.
> >
> > v2: uniform bit names TP4a/b/c (Manasi)
> >
> > Signed-off-by: Khaled Almahallawy
>
> Looks good to me,
>
> Reviewed-by: Manasi Navare
>
> Khaled, could you also give a tested by here?
>
> Manasi
Passed all TPS4 tests on DP Compliance scope with DPoC1.4a test
specification
Tested-by: Khaled Almahallawy
>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 14 --
> > drivers/gpu/drm/i915/i915_reg.h | 4
> > 2 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d6295eb20b63..4b74b2ec5665 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5371,7 +5371,7 @@ static void
> > intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> > &intel_dp->compliance.test_data.phytest;
> > struct intel_crtc *crtc = to_intel_crtc(dig_port-
> > >base.base.crtc);
> > enum pipe pipe = crtc->pipe;
> > - u32 pattern_val;
> > + u32 pattern_val, dp_tp_ctl;
> >
> > switch (data->phy_pattern) {
> > case DP_PHY_TEST_PATTERN_NONE:
> > @@ -5411,7 +5411,7 @@ static void
> > intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> >DDI_DP_COMP_CTL_ENABLE |
> >DDI_DP_COMP_CTL_CUSTOM80);
> > break;
> > - case DP_PHY_TEST_PATTERN_CP2520:
> > + case DP_PHY_TEST_PATTERN_CP2520_PAT1:
> > /*
> > * FIXME: Ideally pattern should come from DPCD 0x24A.
> > As
> > * current firmware of DPR-100 could not set it, so
> > hardcoding
> > @@ -5423,6 +5423,16 @@ static void
> > intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> >DDI_DP_COMP_CTL_ENABLE |
> > DDI_DP_COMP_CTL_HBR2 |
> >pattern_val);
> > break;
> > + case DP_PHY_TEST_PATTERN_CP2520_PAT3:
> > + DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
> > + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
> > 0x0);
> > + dp_tp_ctl = intel_de_read(dev_priv,
> > TGL_DP_TP_CTL(pipe));
> > + dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
> > + dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
> > + dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
> > + dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
> > + intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe),
> > dp_tp_ctl);
> > + break;
> > default:
> > WARN(1, "Invalid Phy Test Pattern\n");
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index a0d31f3bf634..c586595b9e76 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -9982,6 +9982,10 @@ enum skl_power_gate {
> > #define DP_TP_CTL_MODE_SST(0 << 27)
> > #define DP_TP_CTL_MODE_MST(1 << 27)
> > #define DP_TP_CTL_FORCE_ACT (1 << 25)
> > +#define DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
> > +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
> > +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
> > +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
> > #define DP_TP_CTL_ENHANCED_FRAME_ENABLE (1 << 18)
> > #define DP_TP_CTL_FDI_AUTOTRAIN (1 << 15)
> > #define DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
> > --
> > 2.17.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 14/14] drm/print: Add tracefs support to the drm logging helpers
Hi Sean,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on tegra-drm/drm/tegra/for-next drm-tip/drm-tip
linus/master drm-exynos/exynos-drm-next v5.9-rc1 next-20200818]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Sean-Paul/drm-trace-Mirror-DRM-debug-logs-to-tracefs/20200819-050745
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: openrisc-randconfig-s031-20200818 (attached as .config)
compiler: or1k-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-183-gaa6ede3b-dirty
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=openrisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/drm_print.c:459:21: sparse: sparse: non-ANSI function
>> declaration of function 'drm_trace_init'
>> drivers/gpu/drm/drm_print.c:498:24: sparse: sparse: non-ANSI function
>> declaration of function 'drm_trace_cleanup'
drivers/gpu/drm/drm_print.c:467:15: sparse: sparse: undefined identifier
'trace_array_init_printk'
drivers/gpu/drm/drm_print.c: note: in included file (through
arch/openrisc/include/asm/io.h, include/linux/io.h):
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
#
https://github.com/0day-ci/linux/commit/fe0a955028a2121ce9ab9acd1c2ab74d219cdc60
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Sean-Paul/drm-trace-Mirror-DRM-debug-logs-to-tracefs/20200819-050745
git checkout fe0a955028a2121ce9ab9acd1c2ab74d219cdc60
vim +/drm_trace_init +459 drivers/gpu/drm/drm_print.c
452
453 /**
454 * drm_trace_init - initializes the drm trace array
455 *
456 * This function fetches (or creates) the drm trace array. This should
be called
457 * once on drm subsystem creation and matched with drm_trace_cleanup().
458 */
> 459 void drm_trace_init()
460 {
461 int ret;
462
463 trace_arr = trace_array_get_by_name("drm");
464 if (!trace_arr)
465 return;
466
467 ret = trace_array_init_printk(trace_arr);
468 if (ret)
469 drm_trace_cleanup();
470 }
471 EXPORT_SYMBOL(drm_trace_init);
472
473 /**
474 * drm_trace_printf - adds an entry to the drm tracefs instance
475 * @format: printf format of the message to add to the trace
476 *
477 * This function adds a new entry in the drm tracefs instance
478 */
479 void drm_trace_printf(const char *format, ...)
480 {
481 struct va_format vaf;
482 va_list args;
483
484 va_start(args, format);
485 vaf.fmt = format;
486 vaf.va = &args;
487 trace_array_printk(trace_arr, _THIS_IP_, "%pV", &vaf);
488 va_end(args);
489 }
490
491 /**
492 * drm_trace_cleanup - destroys the drm trace array
493 *
494 * This function destroys the drm trace array created with
drm_trace_init. This
495 * should be called once on drm subsystem close and matched with
496 * drm_trace_init().
497 */
> 498 void drm_trace_cleanup()
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] Fix Kconfig dependency issue with DMAENGINES selection
Matt, Alexandre, Gentle ping. As this should be fixed in v5.9, a quick reply would be really appreciated. Otherwise I'll have to bundle the rapidio fix with the DPSUB fix, and get them both merged through the DRM/KMS tree without your ack. On Wed, Aug 12, 2020 at 01:52:04AM +0300, Laurent Pinchart wrote: > On Sun, Aug 02, 2020 at 12:14:09PM +0530, Vinod Koul wrote: > > On 31-07-20, 23:42, Laurent Pinchart wrote: > > > On Fri, Jul 31, 2020 at 10:17:44PM +0530, Vinod Koul wrote: > > > > On 31-07-20, 18:24, Laurent Pinchart wrote: > > > > > Hello, > > > > > > > > > > This small series fixes a Kconfig dependency issue with the recently > > > > > merged Xilixn DPSUB DRM/KMS driver. The fix is in patch 3/3, but > > > > > requires a separate fixes in patches 1/3 and 2/3 to avoid circular > > > > > dependencies: > > > > > > > > > > drivers/i2c/Kconfig:8:error: recursive dependency detected! > > > > > drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC > > > > > drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB > > > > > drivers/video/fbdev/Kconfig:12: symbol FB is selected by > > > > > DRM_KMS_FB_HELPER > > > > > drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER > > > > > depends on DRM_KMS_HELPER > > > > > drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is > > > > > selected by DRM_ZYNQMP_DPSUB > > > > > drivers/gpu/drm/xlnx/Kconfig:1: symbol DRM_ZYNQMP_DPSUB > > > > > depends on DMA_ENGINE > > > > > drivers/dma/Kconfig:44: symbol DMA_ENGINE depends on > > > > > DMADEVICES > > > > > drivers/dma/Kconfig:6: symbol DMADEVICES is selected by > > > > > SND_SOC_SH4_SIU > > > > > sound/soc/sh/Kconfig:30:symbol SND_SOC_SH4_SIU is > > > > > selected by SND_SIU_MIGOR > > > > > sound/soc/sh/Kconfig:60:symbol SND_SIU_MIGOR depends > > > > > on I2C > > > > > For a resolution refer to > > > > > Documentation/kbuild/kconfig-language.rst > > > > > subsection "Kconfig recursive dependency limitations" > > > > > > > > > > Due to the DPSUB driver being merged in v5.9, this is a candidate fix > > > > > for v5.9 as well. 1/3 and 2/3 can be merged independently, 3/3 depends > > > > > on the first two. What's the best course of action, can I merge this > > > > > all > > > > > in a single tree, or should the rapidio and ASoC patches be merged > > > > > independently early in the -rc cycle, and the DRM patch later on top > > > > > ? I > > > > > don't expect conflicts (especially in 2/3 and 3/3), so merging the > > > > > whole > > > > > series in one go would be simpler in my opinion. > > > > > > > > Acked-By: Vinod Koul > > > > > > Thank you. > > > > > > As Mark as queued the sound fix in his for-next branch for v5.9, could > > > you queue the dmaengine fix for v5.9 too ? > > > > Dmaengine? I see three patches none of which touch dmaengine.. > > Did I miss something? > > I'm not sure what I was thinking... It's the rapidio patch that needs to > be merged. > > Matt, Alexandre, can you either merge the patch as a v5.9 fix, or give > me an ack to get it merged through the DRM tree ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: ast: fix double __iomem sparse warning
Hi Randy,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on linus/master v5.9-rc1 next-20200818]
[cannot apply to linux/master drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Randy-Dunlap/drm-ast-fix-double-__iomem-sparse-warning/20200819-043022
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-s002-20200818 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-183-gaa6ede3b-dirty
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/ast/ast_cursor.c:42:59: sparse: sparse: incorrect type in
>> argument 2 (different address spaces) @@ expected void *vaddr @@ got
>> void [noderef] __iomem * @@
>> drivers/gpu/drm/ast/ast_cursor.c:42:59: sparse: expected void *vaddr
>> drivers/gpu/drm/ast/ast_cursor.c:42:59: sparse: got void [noderef]
>> __iomem *
>> drivers/gpu/drm/ast/ast_cursor.c:80:23: sparse: sparse: incorrect type in
>> assignment (different address spaces) @@ expected void [noderef] __iomem
>> *vaddr @@ got void * @@
>> drivers/gpu/drm/ast/ast_cursor.c:80:23: sparse: expected void [noderef]
>> __iomem *vaddr
>> drivers/gpu/drm/ast/ast_cursor.c:80:23: sparse: got void *
drivers/gpu/drm/ast/ast_cursor.c:98:59: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void *vaddr @@ got
void [noderef] __iomem * @@
drivers/gpu/drm/ast/ast_cursor.c:98:59: sparse: expected void *vaddr
drivers/gpu/drm/ast/ast_cursor.c:98:59: sparse: got void [noderef]
__iomem *
>> drivers/gpu/drm/ast/ast_cursor.c:126:19: sparse: sparse: cast removes
>> address space '__iomem' of expression
>> drivers/gpu/drm/ast/ast_cursor.c:126:16: sparse: sparse: incorrect type in
>> assignment (different address spaces) @@ expected unsigned char
>> [noderef] [usertype] __iomem *dstxor @@ got unsigned char [usertype] * @@
>> drivers/gpu/drm/ast/ast_cursor.c:126:16: sparse: expected unsigned char
>> [noderef] [usertype] __iomem *dstxor
>> drivers/gpu/drm/ast/ast_cursor.c:126:16: sparse: got unsigned char
>> [usertype] *
#
https://github.com/0day-ci/linux/commit/7e1ff39fdb33febec4c542a6be21c28b352eb588
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Randy-Dunlap/drm-ast-fix-double-__iomem-sparse-warning/20200819-043022
git checkout 7e1ff39fdb33febec4c542a6be21c28b352eb588
vim +42 drivers/gpu/drm/ast/ast_cursor.c
2ccebf561e4a902 Thomas Zimmermann 2020-07-02 34
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 35 static void
ast_cursor_fini(struct ast_private *ast)
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 36 {
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 37 size_t i;
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 38 struct
drm_gem_vram_object *gbo;
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 39
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 40 for (i = 0; i <
ARRAY_SIZE(ast->cursor.gbo); ++i) {
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 41 gbo =
ast->cursor.gbo[i];
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 @42
drm_gem_vram_vunmap(gbo, ast->cursor.vaddr[i]);
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 43
drm_gem_vram_unpin(gbo);
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 44
drm_gem_vram_put(gbo);
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 45 }
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 46 }
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 47
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 48 static void
ast_cursor_release(struct drm_device *dev, void *ptr)
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 49 {
365c0e70da83a52 Thomas Zimmermann 2020-07-30 50 struct ast_private *ast
= to_ast_private(dev);
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 51
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 52 ast_cursor_fini(ast);
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 53 }
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 54
2ccebf561e4a902 Thomas Zimmermann 2020-07-02 55 /*
2ccebf561e4a902 Thomas Zimmermann 2020-07-02 56 * Allocate cursor BOs and
pins them at the end of VRAM.
2ccebf561e4a902 Thomas Zimmermann 2020-07-02
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 --- Comment #7 from Coleman Kane (ck...@colemankane.org) --- Thanks for the tip - I think I understand how this works now, so I will go through the cycles of bisecting and follow up with what it finds, or a patch if I think I'm able to address it myself. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 11/14] drm/mst: Convert debug printers to debug category printers
Reviewed-by: Lyude Paul
On Tue, 2020-08-18 at 17:05 -0400, Sean Paul wrote:
> From: Sean Paul
>
> The printers in dp_mst are meant to be gated on DRM_UT_DP, so use the
> debug category printer to avoid dumping mst transactions to the wrong
> place.
>
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-12-s...@poorly.run
> #v5
>
> Changes in v5:
> -Added to the set
> Changes in v6:
> -None
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 67dd72ea200e..127120b60580 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1242,7 +1242,8 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
> }
> out:
> if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) {
> - struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> + struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
> + DBG_PREFIX);
>
> drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> }
> @@ -2781,7 +2782,8 @@ static int process_single_tx_qlock(struct
> drm_dp_mst_topology_mgr *mgr,
>
> ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
> if (unlikely(ret) && drm_debug_enabled(DRM_UT_DP)) {
> - struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> + struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
> + DBG_PREFIX);
>
> drm_printf(&p, "sideband msg failed to send\n");
> drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> @@ -2825,7 +2827,8 @@ static void drm_dp_queue_down_tx(struct
> drm_dp_mst_topology_mgr *mgr,
> list_add_tail(&txmsg->next, &mgr->tx_msg_downq);
>
> if (drm_debug_enabled(DRM_UT_DP)) {
> - struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> + struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
> + DBG_PREFIX);
>
> drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> }
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
Just one small comment
On Tue, 2020-08-18 at 11:39 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Used to query whether an MST stream is encrypted or not.
>
> Cc: Lyude Paul
> Reviewed-by: Anshuman Gupta
> Signed-off-by: Sean Paul
>
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
> #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-s...@poorly.run
> #v5
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-s...@poorly.run
> #v6
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-16-s...@poorly.run
> #v7
>
> Changes in v4:
> -Added to the set
> Changes in v5:
> -None
> Changes in v6:
> -Use FIELD_PREP to generate request buffer bitfields (Lyude)
> -Add mst selftest and dump/decode_sideband_req for QSES (Lyude)
> Changes in v7:
> -None
> Changes in v8:
> -Reverse the parsing on the hdcp_*x_device_present bits and leave
> breadcrumb in case this is incorrect (Anshuman)
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 150 ++
> .../drm/selftests/test-drm_dp_mst_helper.c| 17 ++
> include/drm/drm_dp_helper.h | 3 +
> include/drm/drm_dp_mst_helper.h | 44 +
> 4 files changed, 214 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 67dd72ea200e..f2b77ef40281 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -20,11 +20,13 @@
> * OF THIS SOFTWARE.
> */
>
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -423,6 +425,22 @@ drm_dp_encode_sideband_req(const struct
> drm_dp_sideband_msg_req_body *req,
> memcpy(&buf[idx], req->u.i2c_write.bytes, req-
> >u.i2c_write.num_bytes);
> idx += req->u.i2c_write.num_bytes;
> break;
> + case DP_QUERY_STREAM_ENC_STATUS: {
> + const struct drm_dp_query_stream_enc_status *msg;
> +
> + msg = &req->u.enc_status;
> + buf[idx] = msg->stream_id;
> + idx++;
> + memcpy(&buf[idx], msg->client_id, sizeof(msg->client_id));
> + idx += sizeof(msg->client_id);
> + buf[idx] = 0;
> + buf[idx] |= FIELD_PREP(GENMASK(1, 0), msg->stream_event);
> + buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
> + buf[idx] |= FIELD_PREP(GENMASK(4, 3), msg->stream_behavior);
> + buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
> + idx++;
> + }
> + break;
> }
> raw->cur_len = idx;
> }
> @@ -551,6 +569,20 @@ drm_dp_decode_sideband_req(const struct
> drm_dp_sideband_msg_tx *raw,
> return -ENOMEM;
> }
> break;
> + case DP_QUERY_STREAM_ENC_STATUS:
> + req->u.enc_status.stream_id = buf[idx++];
> + for (i = 0; i < sizeof(req->u.enc_status.client_id); i++)
> + req->u.enc_status.client_id[i] = buf[idx++];
> +
> + req->u.enc_status.stream_event = FIELD_GET(GENMASK(1, 0),
> +buf[idx]);
> + req->u.enc_status.valid_stream_event = FIELD_GET(BIT(2),
> + buf[idx]);
> + req->u.enc_status.stream_behavior = FIELD_GET(GENMASK(4, 3),
> + buf[idx]);
> + req->u.enc_status.valid_stream_behavior = FIELD_GET(BIT(5),
> + buf[idx]);
> + break;
> }
>
> return 0;
> @@ -629,6 +661,16 @@ drm_dp_dump_sideband_msg_req_body(const struct
> drm_dp_sideband_msg_req_body *req
> req->u.i2c_write.num_bytes, req->u.i2c_write.num_bytes,
> req->u.i2c_write.bytes);
> break;
> + case DP_QUERY_STREAM_ENC_STATUS:
> + P("stream_id=%u client_id=%*ph stream_event=%x "
> + "valid_event=%d stream_behavior=%x valid_behavior=%d",
> + req->u.enc_status.stream_id,
> + (int)ARRAY_SIZE(req->u.enc_status.client_id),
> + req->u.enc_status.client_id, req->u.enc_status.stream_event,
> + req->u.enc_status.valid_stream_event,
> + req->u.enc_status.stream_behavior,
> + req->u.enc_status.valid_stream_behavior);
> + break;
> default:
> P("???\n");
> break;
> @@ -936,6 +978,42 @@ static bool
> drm_dp_sideband_parse_power_updown_phy_ack(struct drm_dp_sideband_ms
> return true;
> }
>
> +static bool
> +drm_dp_sideband_parse_query_stream_enc_status(
> + struct drm_dp_sideband_msg_rx *raw,
> +
Re: [PATCH v2 2/2] drm/i915/dp: TPS4 PHY test pattern compliance support
On Wed, Jul 22, 2020 at 05:36:27PM -0700, Khaled Almahallawy wrote:
> Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.
>
> v2: uniform bit names TP4a/b/c (Manasi)
>
> Signed-off-by: Khaled Almahallawy
Looks good to me,
Reviewed-by: Manasi Navare
Khaled, could you also give a tested by here?
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 14 --
> drivers/gpu/drm/i915/i915_reg.h | 4
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d6295eb20b63..4b74b2ec5665 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5371,7 +5371,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp
> *intel_dp)
> &intel_dp->compliance.test_data.phytest;
> struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
> enum pipe pipe = crtc->pipe;
> - u32 pattern_val;
> + u32 pattern_val, dp_tp_ctl;
>
> switch (data->phy_pattern) {
> case DP_PHY_TEST_PATTERN_NONE:
> @@ -5411,7 +5411,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp
> *intel_dp)
> DDI_DP_COMP_CTL_ENABLE |
> DDI_DP_COMP_CTL_CUSTOM80);
> break;
> - case DP_PHY_TEST_PATTERN_CP2520:
> + case DP_PHY_TEST_PATTERN_CP2520_PAT1:
> /*
>* FIXME: Ideally pattern should come from DPCD 0x24A. As
>* current firmware of DPR-100 could not set it, so hardcoding
> @@ -5423,6 +5423,16 @@ static void intel_dp_phy_pattern_update(struct
> intel_dp *intel_dp)
> DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
> pattern_val);
> break;
> + case DP_PHY_TEST_PATTERN_CP2520_PAT3:
> + DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
> + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
> + dp_tp_ctl = intel_de_read(dev_priv,
> TGL_DP_TP_CTL(pipe));
> + dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
> + dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
> + dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
> + dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
> + intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe),
> dp_tp_ctl);
> + break;
> default:
> WARN(1, "Invalid Phy Test Pattern\n");
> }
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a0d31f3bf634..c586595b9e76 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9982,6 +9982,10 @@ enum skl_power_gate {
> #define DP_TP_CTL_MODE_SST (0 << 27)
> #define DP_TP_CTL_MODE_MST (1 << 27)
> #define DP_TP_CTL_FORCE_ACT (1 << 25)
> +#define DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
> +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
> +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
> +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
> #define DP_TP_CTL_ENHANCED_FRAME_ENABLE (1 << 18)
> #define DP_TP_CTL_FDI_AUTOTRAIN (1 << 15)
> #define DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 03/14] drm/i915/utils: Replace dev_printk with drm helpers
From: Sean Paul Use drm logging helpers to add support for the upcoming tracefs implementation. Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-4-s...@poorly.run #v5 Changes in v5: -Added to the set Changes in v6: -None --- drivers/gpu/drm/i915/i915_utils.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_utils.c b/drivers/gpu/drm/i915/i915_utils.c index 4c305d838016..f16a75b165a3 100644 --- a/drivers/gpu/drm/i915/i915_utils.c +++ b/drivers/gpu/drm/i915/i915_utils.c @@ -30,10 +30,9 @@ __i915_printk(struct drm_i915_private *dev_priv, const char *level, vaf.va = &args; if (is_error) - dev_printk(level, kdev, "%pV", &vaf); + drm_dev_printk(kdev, level, "%pV", &vaf); else - dev_printk(level, kdev, "[" DRM_NAME ":%ps] %pV", - __builtin_return_address(0), &vaf); + drm_err(&dev_priv->drm, "%pV", &vaf); va_end(args); -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 04/14] drm/msm/dpu: Replace definitions for dpu debug macros
From: Sean Paul
The debug messages shouldn't be logged as errors when debug categories
are enabled. Use the drm logging helpers to do the right thing
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-5-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index e140cd633071..b1e9c529d3b5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -29,27 +29,15 @@
* DPU_DEBUG - macro for kms/plane/crtc/encoder/connector logs
* @fmt: Pointer to format string
*/
-#define DPU_DEBUG(fmt, ...)\
- do { \
- if (drm_debug_enabled(DRM_UT_KMS)) \
- DRM_DEBUG(fmt, ##__VA_ARGS__); \
- else \
- pr_debug(fmt, ##__VA_ARGS__); \
- } while (0)
+#define DPU_DEBUG(fmt, ...) DRM_DEBUG_KMS(fmt, ##__VA_ARGS__)
/**
* DPU_DEBUG_DRIVER - macro for hardware driver logging
* @fmt: Pointer to format string
*/
-#define DPU_DEBUG_DRIVER(fmt, ...) \
- do { \
- if (drm_debug_enabled(DRM_UT_DRIVER)) \
- DRM_ERROR(fmt, ##__VA_ARGS__); \
- else \
- pr_debug(fmt, ##__VA_ARGS__); \
- } while (0)
-
-#define DPU_ERROR(fmt, ...) pr_err("[dpu error]" fmt, ##__VA_ARGS__)
+#define DPU_DEBUG_DRIVER(fmt, ...) DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__)
+
+#define DPU_ERROR(fmt, ...) DRM_ERROR(fmt, ##__VA_ARGS__)
/**
* ktime_compare_safe - compare two ktime structures
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 13/14] drm/atomic: Use debug category printer for atomic state printer
From: Sean Paul
The atomic state is printed if the DRM_UT_STATE is active, but it's
printed at INFO level. This patch converts it to use the debug
category printer so:
a- it's consistent with other DRM_UT_STATE logging
b- it's properly routed through drm_trace when introduced
Signed-off-by: Sean Paul
Changes in v6:
-Added to the set
---
drivers/gpu/drm/drm_atomic.c| 5 +++--
drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
drivers/gpu/drm/drm_crtc_internal.h | 3 ++-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 58527f151984..96b804e85903 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1543,9 +1543,10 @@ int __drm_atomic_helper_set_config(struct drm_mode_set
*set,
}
EXPORT_SYMBOL(__drm_atomic_helper_set_config);
-void drm_atomic_print_state(const struct drm_atomic_state *state)
+void drm_atomic_print_state(const struct drm_atomic_state *state,
+ const char *prefix)
{
- struct drm_printer p = drm_info_printer(state->dev->dev);
+ struct drm_printer p = drm_debug_category_printer(DRM_UT_STATE, prefix);
struct drm_plane *plane;
struct drm_plane_state *plane_state;
struct drm_crtc *crtc;
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 25c269bc4681..c6f3c652f47c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1413,7 +1413,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
ret = drm_atomic_nonblocking_commit(state);
} else {
if (drm_debug_enabled(DRM_UT_STATE))
- drm_atomic_print_state(state);
+ drm_atomic_print_state(state, "commit_state");
ret = drm_atomic_commit(state);
}
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index da96b2f64d7e..077ea92fb12a 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -233,7 +233,8 @@ int __drm_atomic_helper_disable_plane(struct drm_plane
*plane,
int __drm_atomic_helper_set_config(struct drm_mode_set *set,
struct drm_atomic_state *state);
-void drm_atomic_print_state(const struct drm_atomic_state *state);
+void drm_atomic_print_state(const struct drm_atomic_state *state,
+ const char *prefix);
/* drm_atomic_uapi.c */
int drm_atomic_connector_commit_dpms(struct drm_atomic_state *state,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 12/14] drm/i915: Use debug category printer for welcome message
From: Sean Paul
The welcome printer is meant to be gated on DRM_UT_DRIVER, so use the
debug category printer to avoid dumping the message in the wrong
place.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-13-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 00292a849c34..0206be123b28 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -872,7 +872,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
static void i915_welcome_messages(struct drm_i915_private *dev_priv)
{
if (drm_debug_enabled(DRM_UT_DRIVER)) {
- struct drm_printer p = drm_debug_printer("i915 device info:");
+ struct drm_printer p = drm_debug_category_printer(DRM_UT_DRIVER,
+ "i915 device info:");
drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s
(subplatform=0x%x) gen=%i\n",
INTEL_DEVID(dev_priv),
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 07/14] drm/etnaviv: Change buffer dump checks to target syslog
From: Sean Paul
Since the logs protected by these checks specifically target syslog,
use the new drm_debug_syslog_enabled() call to avoid triggering
these prints when only trace is enabled.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-8-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index 76d38561c910..7713474800e8 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -353,7 +353,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
lockdep_assert_held(&gpu->lock);
- if (drm_debug_enabled(DRM_UT_DRIVER))
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER))
etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
link_target = etnaviv_cmdbuf_get_va(cmdbuf,
@@ -509,13 +509,13 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
etnaviv_cmdbuf_get_va(buffer,
&gpu->mmu_context->cmdbuf_mapping)
+ buffer->user_size - 4);
- if (drm_debug_enabled(DRM_UT_DRIVER))
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER))
pr_info("stream link to 0x%08x @ 0x%08x %p\n",
return_target,
etnaviv_cmdbuf_get_va(cmdbuf,
&gpu->mmu_context->cmdbuf_mapping),
cmdbuf->vaddr);
- if (drm_debug_enabled(DRM_UT_DRIVER)) {
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER)) {
print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
cmdbuf->vaddr, cmdbuf->size, 0);
@@ -534,6 +534,6 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
VIV_FE_LINK_HEADER_PREFETCH(link_dwords),
link_target);
- if (drm_debug_enabled(DRM_UT_DRIVER))
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER))
etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 06/14] drm/amd: Gate i2c transaction logs on drm_debug_syslog
From: Sean Paul
Since the logs protected by these checks specifically target syslog,
use the new drm_debug_syslog_enabled() call to avoid triggering
these prints when only trace is enabled.
Acked-by: Christian König
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-7-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
b/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
index d55bf64770c4..1600a007344b 100644
--- a/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
+++ b/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
@@ -232,7 +232,7 @@ static uint32_t smu_v11_0_i2c_transmit(struct i2c_adapter
*control,
DRM_DEBUG_DRIVER("I2C_Transmit(), address = %x, bytes = %d , data: ",
(uint16_t)address, numbytes);
- if (drm_debug_enabled(DRM_UT_DRIVER)) {
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER)) {
print_hex_dump(KERN_INFO, "data: ", DUMP_PREFIX_NONE,
16, 1, data, numbytes, false);
}
@@ -386,7 +386,7 @@ static uint32_t smu_v11_0_i2c_receive(struct i2c_adapter
*control,
DRM_DEBUG_DRIVER("I2C_Receive(), address = %x, bytes = %d, data :",
(uint16_t)address, bytes_received);
- if (drm_debug_enabled(DRM_UT_DRIVER)) {
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER)) {
print_hex_dump(KERN_INFO, "data: ", DUMP_PREFIX_NONE,
16, 1, data, bytes_received, false);
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 00/14] drm/trace: Mirror DRM debug logs to tracefs
From: Sean Paul Mostly a rebase on drm-tip. New changes: - Use the new trace_array_init_printk() call init the global trace buffers. - Add patch 13 to the set to pipe atomic state logging through trace v5 is available here: https://patchwork.freedesktop.org/series/78133/ Sean Paul (14): drm/mipi_dbi: Convert pr_debug calls to DRM_DEBUG_DRIVER drm/sil164: Convert dev_printk to drm_dev_dbg drm/i915/utils: Replace dev_printk with drm helpers drm/msm/dpu: Replace definitions for dpu debug macros drm/print: rename drm_debug* to be more syslog-centric drm/amd: Gate i2c transaction logs on drm_debug_syslog drm/etnaviv: Change buffer dump checks to target syslog drm/nouveau: Change debug checks to specifically target syslog drm/i915: Change infoframe debug checks to specify syslog drm/print: Add drm_debug_category_printer drm/mst: Convert debug printers to debug category printers drm/i915: Use debug category printer for welcome message drm/atomic: Use debug category printer for atomic state printer drm/print: Add tracefs support to the drm logging helpers Documentation/gpu/drm-uapi.rst | 6 + drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 4 +- drivers/gpu/drm/drm_atomic.c | 5 +- drivers/gpu/drm/drm_atomic_uapi.c| 2 +- drivers/gpu/drm/drm_crtc_internal.h | 3 +- drivers/gpu/drm/drm_dp_mst_topology.c| 9 +- drivers/gpu/drm/drm_drv.c| 3 + drivers/gpu/drm/drm_mipi_dbi.c | 8 +- drivers/gpu/drm/drm_print.c | 235 --- drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 8 +- drivers/gpu/drm/i2c/sil164_drv.c | 12 +- drivers/gpu/drm/i915/display/intel_display.c | 4 +- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/i915_utils.c| 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 20 +- drivers/gpu/drm/nouveau/nouveau_drv.h| 4 +- include/drm/drm_print.h | 96 +++- 17 files changed, 329 insertions(+), 98 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 09/14] drm/i915: Change infoframe debug checks to specify syslog
From: Sean Paul
Since the logs protected by these checks specifically target syslog,
use the new drm_debug_syslog_enabled() call to avoid triggering
these prints when only trace is enabled.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-10-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 2ddabf92adde..30dcc8a2daa7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12908,7 +12908,7 @@ static void
intel_dump_infoframe(struct drm_i915_private *dev_priv,
const union hdmi_infoframe *frame)
{
- if (!drm_debug_enabled(DRM_UT_KMS))
+ if (!drm_debug_syslog_enabled(DRM_UT_KMS))
return;
hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, frame);
@@ -13551,7 +13551,7 @@ pipe_config_infoframe_mismatch(struct drm_i915_private
*dev_priv,
const union hdmi_infoframe *b)
{
if (fastset) {
- if (!drm_debug_enabled(DRM_UT_KMS))
+ if (!drm_debug_syslog_enabled(DRM_UT_KMS))
return;
drm_dbg_kms(&dev_priv->drm,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 01/14] drm/mipi_dbi: Convert pr_debug calls to DRM_DEBUG_DRIVER
From: Sean Paul
Use the drm logging helpers to output these messages to ensure they'll
be included by the drm tracefs instance.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-2-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/drm_mipi_dbi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 230c4fd7131c..e233b6da7cca 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -764,9 +764,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi *dbi,
int dc,
int i, ret;
u8 *dst;
- if (drm_debug_enabled(DRM_UT_DRIVER))
- pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
-__func__, dc, max_chunk);
+ DRM_DEBUG_DRIVER("dc=%d, max_chunk=%zu, transfers:\n", dc, max_chunk);
tr.speed_hz = mipi_dbi_spi_cmd_max_speed(spi, len);
spi_message_init_with_transfers(&m, &tr, 1);
@@ -888,9 +886,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi, int
dc,
max_chunk = dbi->tx_buf9_len;
dst16 = dbi->tx_buf9;
- if (drm_debug_enabled(DRM_UT_DRIVER))
- pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
-__func__, dc, max_chunk);
+ DRM_DEBUG_DRIVER("dc=%d, max_chunk=%zu, transfers:\n", dc, max_chunk);
max_chunk = min(max_chunk / 2, len);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 10/14] drm/print: Add drm_debug_category_printer
From: Sean Paul
This patch adds a new printer which will select the appropriate output
for a given debug category. Currently there is only one output target,
which is syslog. However in the future we'll have tracefs and it will be
useful to print to syslog, tracefs, or both. Drivers just need to create
the printer for the appropriate category and the printer will decide
where to send the output.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-11-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/drm_print.c | 5 +
include/drm/drm_print.h | 28
2 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 2ff7a6ecc632..4d984a01b3a3 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -172,6 +172,11 @@ void __drm_printfn_err(struct drm_printer *p, struct
va_format *vaf)
}
EXPORT_SYMBOL(__drm_printfn_err);
+void __drm_printfn_noop(struct drm_printer *p, struct va_format *vaf)
+{
+}
+EXPORT_SYMBOL(__drm_printfn_noop);
+
/**
* drm_puts - print a const string to a &drm_printer stream
* @p: the &drm printer
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index ce7675bf0d2b..8987b98bbfda 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -87,6 +87,7 @@ void __drm_puts_seq_file(struct drm_printer *p, const char
*str);
void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_debug_syslog(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_err(struct drm_printer *p, struct va_format *vaf);
+void __drm_printfn_noop(struct drm_printer *p, struct va_format *vaf);
__printf(2, 3)
void drm_printf(struct drm_printer *p, const char *f, ...);
@@ -329,6 +330,33 @@ static inline bool drm_debug_enabled(enum
drm_debug_category category)
return drm_debug_syslog_enabled(category);
}
+/**
+ * drm_debug_category_printer - construct a &drm_printer that outputs to
+ * pr_debug() if enabled for the given category.
+ * @category: the DRM_UT_* message category this message belongs to
+ * @prefix: trace output prefix
+ *
+ * RETURNS:
+ * The &drm_printer object
+ */
+static inline struct drm_printer
+drm_debug_category_printer(enum drm_debug_category category,
+ const char *prefix)
+{
+ struct drm_printer p = {
+ .prefix = prefix
+ };
+
+ if (drm_debug_syslog_enabled(category)) {
+ p.printfn = __drm_printfn_debug_syslog;
+ } else {
+ WARN(1, "Debug category %d is inactive.", category);
+ p.printfn = __drm_printfn_noop;
+ }
+
+ return p;
+}
+
/*
* struct device based logging
*
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 14/14] drm/print: Add tracefs support to the drm logging helpers
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 logging
in production without impacting performance or spamming the system
logs.
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Pekka Paalanen
Cc: Rob Clark
Cc: Steven Rostedt
Cc: Thomas Zimmermann
Cc: Ville Syrjälä
Cc: Chris Wilson
Cc: Steven Rostedt
Acked-by: Pekka Paalanen
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191010204823.195540-1-s...@poorly.run
#v1
Link:
https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html #v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212203301.142437-1-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200114172155.215463-1-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-14-s...@poorly.run
#v5
Changes in v5:
-Re-write to use trace_array and the tracefs instance support
Changes in v6:
-Use the new trace_array_init_printk() to initialize global trace
buffers
---
Documentation/gpu/drm-uapi.rst | 6 +
drivers/gpu/drm/drm_drv.c | 3 +
drivers/gpu/drm/drm_print.c| 216 -
include/drm/drm_print.h| 63 --
4 files changed, 248 insertions(+), 40 deletions(-)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 7dce175f6d75..0297ff71f8f8 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -424,6 +424,12 @@ Debugfs Support
.. kernel-doc:: drivers/gpu/drm/drm_debugfs.c
:export:
+DRM Tracing
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_print.c
+ :doc: DRM Tracing
+
Sysfs Support
=
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 13068fdf4331..555b40580497 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -1107,12 +1107,15 @@ static void drm_core_exit(void)
drm_sysfs_destroy();
idr_destroy(&drm_minors_idr);
drm_connector_ida_destroy();
+ drm_trace_cleanup();
}
static int __init drm_core_init(void)
{
int ret;
+ drm_trace_init();
+
drm_connector_ida_init();
idr_init(&drm_minors_idr);
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 4d984a01b3a3..6b11143d1ab2 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -43,17 +44,34 @@
unsigned int __drm_debug_syslog;
EXPORT_SYMBOL(__drm_debug_syslog);
-MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug
category.\n"
-"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
-"\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n"
-"\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
-"\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
-"\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
-"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
-"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)\n"
-"\t\tBit 8 (0x100) will enable DP messages (displayport code)");
+/*
+ * __drm_debug_trace: Enable debug output in drm tracing instance.
+ * Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
+ */
+unsigned int __drm_debug_trace;
+EXPORT_SYMBOL(__drm_debug_trace);
+
+#define DEBUG_PARM_DESC(dst) \
+"Enable debug output to " dst ", where each bit enables a debug category.\n" \
+"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n" \
+"\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n" \
+"\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n" \
+"\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n" \
+"\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n" \
+"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n" \
+"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)\n" \
+"\t\tBit 8 (0x100) will enable DP messages (displayport code)"
+
+MODULE_PARM_DESC(debug, DEBUG_PARM_DESC("syslog"));
module_param_named(debug, __drm_debug_syslog, int, 0600);
+MODULE_PARM_DESC(trace, DEBUG_PARM_DESC("tracefs"));
+module_param_named(trace, __drm_debug_trace, int, 0600);
+
+#ifdef CONFIG_TRACING
+struct trace_array *trace_arr;
+#endif
+
void __drm_puts_coredump(struct drm_printer *p, const char *str)
{
struct drm_print_iterator *iterator = p->arg;
@@ -166,6 +184,20 @@ void __drm_printfn_debug_syslog(struct drm_printer *p,
struct va_format *vaf)
}
EXPORT_SYMBOL(__drm_printfn_debug_syslog);
+void __drm_printfn_trace(struct drm_printer *p, struct va_format *vaf)
+{
+ drm_trace_printf("%s
[PATCH v6 02/14] drm/sil164: Convert dev_printk to drm_dev_dbg
From: Sean Paul
Use the drm debug helper instead of dev_printk in order to leverage the
upcoming tracefs support
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-3-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/i2c/sil164_drv.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i2c/sil164_drv.c b/drivers/gpu/drm/i2c/sil164_drv.c
index 741886b54419..b315a789fca2 100644
--- a/drivers/gpu/drm/i2c/sil164_drv.c
+++ b/drivers/gpu/drm/i2c/sil164_drv.c
@@ -43,11 +43,6 @@ struct sil164_priv {
#define to_sil164_priv(x) \
((struct sil164_priv *)to_encoder_slave(x)->slave_priv)
-#define sil164_dbg(client, format, ...) do { \
- if (drm_debug_enabled(DRM_UT_KMS)) \
- dev_printk(KERN_DEBUG, &client->dev,\
- "%s: " format, __func__, ## __VA_ARGS__); \
- } while (0)
#define sil164_info(client, format, ...) \
dev_info(&client->dev, format, __VA_ARGS__)
#define sil164_err(client, format, ...)\
@@ -359,8 +354,8 @@ sil164_probe(struct i2c_client *client, const struct
i2c_device_id *id)
int rev = sil164_read(client, SIL164_REVISION);
if (vendor != 0x1 || device != 0x6) {
- sil164_dbg(client, "Unknown device %x:%x.%x\n",
- vendor, device, rev);
+ drm_dev_dbg(&client->dev, DRM_UT_KMS,
+ "Unknown device %x:%x.%x\n", vendor, device, rev);
return -ENODEV;
}
@@ -389,7 +384,8 @@ sil164_detect_slave(struct i2c_client *client)
};
if (i2c_transfer(adap, &msg, 1) != 1) {
- sil164_dbg(adap, "No dual-link slave found.");
+ drm_dev_dbg(&adap->dev, DRM_UT_KMS,
+ "No dual-link slave found.");
return NULL;
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 05/14] drm/print: rename drm_debug* to be more syslog-centric
From: Sean Paul
In preparation for tracefs support, rename drm_debug related functions
to reflect that it targets the syslog. This will allow us to selectively
target syslog and/or tracefs.
No functional changes here.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-6-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/drm_print.c | 12 ++--
include/drm/drm_print.h | 13 +
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 111b932cf2a9..2ff7a6ecc632 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -37,11 +37,11 @@
#include
/*
- * __drm_debug: Enable debug output.
+ * __drm_debug_syslog: Enable debug output to system logs
* Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
*/
-unsigned int __drm_debug;
-EXPORT_SYMBOL(__drm_debug);
+unsigned int __drm_debug_syslog;
+EXPORT_SYMBOL(__drm_debug_syslog);
MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug
category.\n"
"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
@@ -52,7 +52,7 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit
enables a debug cat
"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)\n"
"\t\tBit 8 (0x100) will enable DP messages (displayport code)");
-module_param_named(debug, __drm_debug, int, 0600);
+module_param_named(debug, __drm_debug_syslog, int, 0600);
void __drm_puts_coredump(struct drm_printer *p, const char *str)
{
@@ -160,11 +160,11 @@ void __drm_printfn_info(struct drm_printer *p, struct
va_format *vaf)
}
EXPORT_SYMBOL(__drm_printfn_info);
-void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf)
+void __drm_printfn_debug_syslog(struct drm_printer *p, struct va_format *vaf)
{
pr_debug("%s %pV", p->prefix, vaf);
}
-EXPORT_SYMBOL(__drm_printfn_debug);
+EXPORT_SYMBOL(__drm_printfn_debug_syslog);
void __drm_printfn_err(struct drm_printer *p, struct va_format *vaf)
{
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 1c9417430d08..ce7675bf0d2b 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -35,7 +35,7 @@
#include
/* Do *not* use outside of drm_print.[ch]! */
-extern unsigned int __drm_debug;
+extern unsigned int __drm_debug_syslog;
/**
* DOC: print
@@ -85,7 +85,7 @@ void __drm_puts_coredump(struct drm_printer *p, const char
*str);
void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf);
void __drm_puts_seq_file(struct drm_printer *p, const char *str);
void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
-void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
+void __drm_printfn_debug_syslog(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_err(struct drm_printer *p, struct va_format *vaf);
__printf(2, 3)
@@ -227,7 +227,7 @@ static inline struct drm_printer drm_info_printer(struct
device *dev)
static inline struct drm_printer drm_debug_printer(const char *prefix)
{
struct drm_printer p = {
- .printfn = __drm_printfn_debug,
+ .printfn = __drm_printfn_debug_syslog,
.prefix = prefix
};
return p;
@@ -319,9 +319,14 @@ enum drm_debug_category {
DRM_UT_DRMRES = 0x200,
};
+static inline bool drm_debug_syslog_enabled(enum drm_debug_category category)
+{
+ return unlikely(__drm_debug_syslog & category);
+}
+
static inline bool drm_debug_enabled(enum drm_debug_category category)
{
- return unlikely(__drm_debug & category);
+ return drm_debug_syslog_enabled(category);
}
/*
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 08/14] drm/nouveau: Change debug checks to specifically target syslog
From: Sean Paul
Since the logs protected by these checks specifically target syslog,
use the new drm_debug_syslog_enabled() call to avoid triggering
these prints when only trace is enabled.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-9-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-Rebased on drm-tip, changes in dispnv50/disp.h were rebased out
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index f63ac72aa556..70be12038b0c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -258,11 +258,11 @@ void nouveau_drm_device_remove(struct drm_device *dev);
#define NV_INFO(drm,f,a...) NV_PRINTK(info, &(drm)->client, f, ##a)
#define NV_DEBUG(drm,f,a...) do {
\
- if (drm_debug_enabled(DRM_UT_DRIVER)) \
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER))
\
NV_PRINTK(info, &(drm)->client, f, ##a); \
} while(0)
#define NV_ATOMIC(drm,f,a...) do {
\
- if (drm_debug_enabled(DRM_UT_ATOMIC)) \
+ if (drm_debug_syslog_enabled(DRM_UT_ATOMIC))
\
NV_PRINTK(info, &(drm)->client, f, ##a); \
} while(0)
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 11/14] drm/mst: Convert debug printers to debug category printers
From: Sean Paul
The printers in dp_mst are meant to be gated on DRM_UT_DP, so use the
debug category printer to avoid dumping mst transactions to the wrong
place.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-12-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/drm_dp_mst_topology.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 67dd72ea200e..127120b60580 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1242,7 +1242,8 @@ static int drm_dp_mst_wait_tx_reply(struct
drm_dp_mst_branch *mstb,
}
out:
if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) {
- struct drm_printer p = drm_debug_printer(DBG_PREFIX);
+ struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
+ DBG_PREFIX);
drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
}
@@ -2781,7 +2782,8 @@ static int process_single_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr,
ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
if (unlikely(ret) && drm_debug_enabled(DRM_UT_DP)) {
- struct drm_printer p = drm_debug_printer(DBG_PREFIX);
+ struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
+ DBG_PREFIX);
drm_printf(&p, "sideband msg failed to send\n");
drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
@@ -2825,7 +2827,8 @@ static void drm_dp_queue_down_tx(struct
drm_dp_mst_topology_mgr *mgr,
list_add_tail(&txmsg->next, &mgr->tx_msg_downq);
if (drm_debug_enabled(DRM_UT_DP)) {
- struct drm_printer p = drm_debug_printer(DBG_PREFIX);
+ struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
+ DBG_PREFIX);
drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On Tue, 2020-08-18 at 13:10 -0700, Kees Cook wrote: > On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote: > > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > > > On 8/17/20 12:48 PM, Kees Cook wrote: > > > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: > > > > > On 8/17/20 12:29 PM, Kees Cook wrote: > > > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: > > > > > > > On 8/17/20 2:15 AM, Allen Pais wrote: > > > > > > > > From: Allen Pais > > > > > > > > > > > > > > > > In preparation for unconditionally passing the > > > > > > > > struct tasklet_struct pointer to all tasklet > > > > > > > > callbacks, switch to using the new tasklet_setup() > > > > > > > > and from_tasklet() to pass the tasklet pointer > > > > > > > > explicitly. > > > > > > > > > > > > > > Who came up with the idea to add a macro 'from_tasklet' > > > > > > > that > > > > > > > is just container_of? container_of in the code would be > > > > > > > _much_ more readable, and not leave anyone guessing wtf > > > > > > > from_tasklet is doing. > > > > > > > > > > > > > > I'd fix that up now before everything else goes in... > > > > > > > > > > > > As I mentioned in the other thread, I think this makes > > > > > > things > > > > > > much more readable. It's the same thing that the > > > > > > timer_struct > > > > > > conversion did (added a container_of wrapper) to avoid the > > > > > > ever-repeating use of typeof(), long lines, etc. > > > > > > > > > > But then it should use a generic name, instead of each sub- > > > > > system > > > > > using some random name that makes people look up exactly what > > > > > it > > > > > does. I'm not huge fan of the container_of() redundancy, but > > > > > adding private variants of this doesn't seem like the best > > > > > way > > > > > forward. Let's have a generic helper that does this, and use > > > > > it > > > > > everywhere. > > > > > > > > I'm open to suggestions, but as things stand, these kinds of > > > > treewide > > > > > > On naming? Implementation is just as it stands, from_tasklet() is > > > totally generic which is why I objected to it. from_member()? Not > > > great with naming... But I can see this going further and then > > > we'll > > > suddenly have tons of these. It's not good for readability. > > > > Since both threads seem to have petered out, let me suggest in > > kernel.h: > > > > #define cast_out(ptr, container, member) \ > > container_of(ptr, typeof(*container), member) > > > > It does what you want, the argument order is the same as > > container_of with the only difference being you name the containing > > structure instead of having to specify its type. > > I like this! Shall I send this to Linus to see if this can land in > -rc2 for use going forward? Sure ... he's probably been lurking on this thread anyway ... it's about time he got off his arse^Wthe fence and made an executive decision ... James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Chunk Heap Support on DMA-HEAP
On Tue, Aug 18, 2020 at 12:45 AM Hyesoo Yu wrote: > > These patch series to introduce a new dma heap, chunk heap. > That heap is needed for special HW that requires bulk allocation of > fixed high order pages. For example, 64MB dma-buf pages are made up > to fixed order-4 pages * 1024. > > The chunk heap uses alloc_pages_bulk to allocate high order page. > https://lore.kernel.org/linux-mm/20200814173131.2803002-1-minc...@kernel.org > > The chunk heap is registered by device tree with alignment and memory node > of contiguous memory allocator(CMA). Alignment defines chunk page size. > For example, alignment 0x1_ means chunk page size is 64KB. > The phandle to memory node indicates contiguous memory allocator(CMA). > If device node doesn't have cma, the registration of chunk heap fails. > > The patchset includes the following: > - export dma-heap API to register kernel module dma heap. > - add chunk heap implementation. > - document of device tree to register chunk heap > > Hyesoo Yu (3): > dma-buf: add missing EXPORT_SYMBOL_GPL() for dma heaps > dma-buf: heaps: add chunk heap to dmabuf heaps > dma-heap: Devicetree binding for chunk heap Hey! Thanks so much for sending this out! I'm really excited to see these heaps be submitted and reviewed on the list! The first general concern I have with your series is that it adds a dt binding for the chunk heap, which we've gotten a fair amount of pushback on. A possible alternative might be something like what Kunihiko Hayashi proposed for non-default CMA heaps: https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunih...@socionext.com/ This approach would insteal allow a driver to register a CMA area with the chunk heap implementation. However, (and this was the catch Kunihiko Hayashi's patch) this requires that the driver also be upstream, as we need an in-tree user of such code. Also, it might be good to provide some further rationale on why this heap is beneficial over the existing CMA heap? In general focusing the commit messages more on the why we might want the patch, rather than what the patch does, is helpful. "Special hardware" that doesn't have upstream drivers isn't very compelling for most maintainers. That said, I'm very excited to see these sorts of submissions, as I know lots of vendors have historically had very custom out of tree ION heaps, and I think it would be a great benefit to the community to better understand the experience vendors have in optimizing performance on their devices, so we can create good common solutions upstream. So I look forward to your insights on future revisions of this patch series! thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/5] drm/panel: Use dev_ based logging
On Sat, Aug 15, 2020 at 02:54:01PM +0200, Sam Ravnborg wrote: > The drm/panel drivers uses a mixture of DRM_ and dev_ based logging. > With this patchset all panel drivers are migrated to use dev_ based > logging as the DRM_ based logging did not add any extra info. > > Drop the now unused include of drm_print.h. > > With this change new panel drivers will be requires to change to dev_ > based logging - so some of the in-flight panel drivers will need trivial > updates before they are accepted. > > Patch divided in smaller bites to ease review. There is no dependencies > between the patches. > > Copied a few people that may have input to the move away from DRM_ based > logging (Daniel (presumeably on vacation), Jani). > > Sam > > Sam Ravnborg (5): > drm/panel: samsung: Use dev_ based logging > drm/panel: leadtek: Use dev_ based logging > drm/panel: raydium: Use dev_ based logging > drm/panel: sitronix: Use dev_ based logging > drm/panel: Use dev_ based logging Thanks for the reviews from Linus and Guido. Series is now applied to drm-misc-next. Sam > > drivers/gpu/drm/panel/panel-boe-himax8279d.c | 44 > drivers/gpu/drm/panel/panel-elida-kd35t133.c | 51 +- > drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 19 +++-- > .../gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 21 +++--- > drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 3 +- > drivers/gpu/drm/panel/panel-innolux-p079zca.c | 31 +++-- > drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c | 33 - > drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c | 58 ++-- > drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 49 + > drivers/gpu/drm/panel/panel-novatek-nt35510.c | 40 --- > drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 13 ++-- > drivers/gpu/drm/panel/panel-raydium-rm67191.c | 33 - > drivers/gpu/drm/panel/panel-raydium-rm68200.c | 18 +++-- > drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 16 ++--- > drivers/gpu/drm/panel/panel-samsung-ld9040.c | 3 +- > drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 23 +++--- > drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 3 +- > drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 3 +- > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 22 +++--- > drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 3 +- > drivers/gpu/drm/panel/panel-sitronix-st7701.c | 10 ++- > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 61 ++-- > drivers/gpu/drm/panel/panel-sony-acx424akp.c | 81 > -- > drivers/gpu/drm/panel/panel-tpo-tpg110.c | 38 +- > drivers/gpu/drm/panel/panel-truly-nt35597.c| 63 ++--- > drivers/gpu/drm/panel/panel-visionox-rm69299.c | 41 --- > drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c | 51 +- > 27 files changed, 308 insertions(+), 523 deletions(-) > > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > On 8/17/20 12:48 PM, Kees Cook wrote: > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: > > > On 8/17/20 12:29 PM, Kees Cook wrote: > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: > > > > > On 8/17/20 2:15 AM, Allen Pais wrote: > > > > > > From: Allen Pais > > > > > > > > > > > > In preparation for unconditionally passing the > > > > > > struct tasklet_struct pointer to all tasklet > > > > > > callbacks, switch to using the new tasklet_setup() > > > > > > and from_tasklet() to pass the tasklet pointer explicitly. > > > > > > > > > > Who came up with the idea to add a macro 'from_tasklet' that > > > > > is just container_of? container_of in the code would be > > > > > _much_ more readable, and not leave anyone guessing wtf > > > > > from_tasklet is doing. > > > > > > > > > > I'd fix that up now before everything else goes in... > > > > > > > > As I mentioned in the other thread, I think this makes things > > > > much more readable. It's the same thing that the timer_struct > > > > conversion did (added a container_of wrapper) to avoid the > > > > ever-repeating use of typeof(), long lines, etc. > > > > > > But then it should use a generic name, instead of each sub-system > > > using some random name that makes people look up exactly what it > > > does. I'm not huge fan of the container_of() redundancy, but > > > adding private variants of this doesn't seem like the best way > > > forward. Let's have a generic helper that does this, and use it > > > everywhere. > > > > I'm open to suggestions, but as things stand, these kinds of > > treewide > > On naming? Implementation is just as it stands, from_tasklet() is > totally generic which is why I objected to it. from_member()? Not > great with naming... But I can see this going further and then we'll > suddenly have tons of these. It's not good for readability. Since both threads seem to have petered out, let me suggest in kernel.h: #define cast_out(ptr, container, member) \ container_of(ptr, typeof(*container), member) It does what you want, the argument order is the same as container_of with the only difference being you name the containing structure instead of having to specify its type. James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote: > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > > On 8/17/20 12:48 PM, Kees Cook wrote: > > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: > > > > On 8/17/20 12:29 PM, Kees Cook wrote: > > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: > > > > > > On 8/17/20 2:15 AM, Allen Pais wrote: > > > > > > > From: Allen Pais > > > > > > > > > > > > > > In preparation for unconditionally passing the > > > > > > > struct tasklet_struct pointer to all tasklet > > > > > > > callbacks, switch to using the new tasklet_setup() > > > > > > > and from_tasklet() to pass the tasklet pointer explicitly. > > > > > > > > > > > > Who came up with the idea to add a macro 'from_tasklet' that > > > > > > is just container_of? container_of in the code would be > > > > > > _much_ more readable, and not leave anyone guessing wtf > > > > > > from_tasklet is doing. > > > > > > > > > > > > I'd fix that up now before everything else goes in... > > > > > > > > > > As I mentioned in the other thread, I think this makes things > > > > > much more readable. It's the same thing that the timer_struct > > > > > conversion did (added a container_of wrapper) to avoid the > > > > > ever-repeating use of typeof(), long lines, etc. > > > > > > > > But then it should use a generic name, instead of each sub-system > > > > using some random name that makes people look up exactly what it > > > > does. I'm not huge fan of the container_of() redundancy, but > > > > adding private variants of this doesn't seem like the best way > > > > forward. Let's have a generic helper that does this, and use it > > > > everywhere. > > > > > > I'm open to suggestions, but as things stand, these kinds of > > > treewide > > > > On naming? Implementation is just as it stands, from_tasklet() is > > totally generic which is why I objected to it. from_member()? Not > > great with naming... But I can see this going further and then we'll > > suddenly have tons of these. It's not good for readability. > > Since both threads seem to have petered out, let me suggest in > kernel.h: > > #define cast_out(ptr, container, member) \ > container_of(ptr, typeof(*container), member) > > It does what you want, the argument order is the same as container_of > with the only difference being you name the containing structure > instead of having to specify its type. I like this! Shall I send this to Linus to see if this can land in -rc2 for use going forward? -- Kees Cook ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208115] amdgpu (likely) - power management and display connection problems with an RX590 card
https://bugzilla.kernel.org/show_bug.cgi?id=208115 --- Comment #1 from Adarion from userland (h_mailingli...@posteo.de) --- Sadly I did not yet find the time for long time tests in my productive systems. a quick check: RX 590 in my FX-6300 based box (Asus M5A78L-M PLUS/USB3) I did one successful return from DPMS, but that was just one, and different (newly purchased) monitor (Asus PA24A) hooked up via HDMI. Kernel was 5.7.x. idle KDE session: ~69 W (wall, "empty system" just mainboard, CPU, fans, RAM and one SSD to boot from) early DPMS off: 66 W BACO(?): jumps between 62...77 W (there shouldn't have been much of a system activity, I wonder what's caused the alterations) "sensors" readings still high, show something around 30W idle. (The RX 560 however, is down to 56 W in idle KDE, but also shows some variance during DPMS off/BACO.) Expected: The RX 590 should be roughly 9-12 W idle, like it's smaller brethren. Currently running the Zen+ with some old HD 5450, the RX 590 is gathering dust. (Can't risk crashing my productive system every 10 minutes.) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 --- Comment #6 from Coleman Kane (ck...@colemankane.org) --- Thanks Alex - I have added the four attachments you requested. I haven't done a git bisect before, but I am very familiar with using git and understand the concept of a bisect, so I could probably figure it out using some documentation such as https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html. Now is as good a time as any to learn! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 --- Comment #5 from Coleman Kane (ck...@colemankane.org) --- Created attachment 292017 --> https://bugzilla.kernel.org/attachment.cgi?id=292017&action=edit Xorg log from failure case (same 5.9-next kernel) Xorg.log from trying to run Xorg under kernel that fails to set resolutions properly. The DisplayPort-0 displays at 1024x768, and I can not set the resolution any higher than that from within Xorg (using the enlightenment "screen" settings panel). You can see from the following line that it boots into 1024x768: [38.608] (II) AMDGPU(0): Output DisplayPort-0 using initial mode 1024x768 +0+0 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 --- Comment #4 from Coleman Kane (ck...@colemankane.org) --- Created attachment 292015 --> https://bugzilla.kernel.org/attachment.cgi?id=292015&action=edit Xorg.log from working case (Arch 5.8.1-1 kernel) Xorg from working case on Arch 5.8.1-1 kernel package. You can see from the following line that it is booting to 3840x2160 resolution: [25.694] (II) AMDGPU(0): Output DisplayPort-0 using initial mode 3840x2160 +1920+0 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 --- Comment #3 from Coleman Kane (ck...@colemankane.org) --- Created attachment 292013 --> https://bugzilla.kernel.org/attachment.cgi?id=292013&action=edit dmesg on faliure case from linux-next.git as of 2020-08-18 00:00:00 (pending-fixes branch) I built a bootable kernel from the linux-next "pending-fixes" based upon sources synchronized with upstream git repo as of 2020-08-18 morning. Did this to verify that there is no pending fix to this issue. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 --- Comment #2 from Coleman Kane (ck...@colemankane.org) --- Created attachment 292011 --> https://bugzilla.kernel.org/attachment.cgi?id=292011&action=edit Working dmesg from Arch "linux" kernel 5.8.1-1 Working dmesg from Arch "linux" kernel 5.8.1-1 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: s6e63m0: Order enable/disable sequence
Hi Linus. On Mon, Aug 17, 2020 at 11:39:06PM +0200, Linus Walleij wrote: > The upstream S6E63M0 driver has some pecularities around > the prepare/enable disable/unprepare sequence: the screen > is taken out of sleep in prepare() as part of > s6e63m0_init() the put to on with MIPI_DCS_SET_DISPLAY_ON > in enable(). > > However it is just put into sleep mode directly in > disable(). As disable()/enable() can be called without > unprepare()/prepare() being called, this is unbalanced, > we should take the display out of sleep in enable() > then turn it off(). > > Further MIPI_DCS_SET_DISPLAY_OFF is never called > balanced with MIPI_DCS_SET_DISPLAY_ON. > > The vendor driver for Samsung GT-I8190 (Golden) does all > of these things in strict order. > > Augment the driver to do exit sleep/set display on in > enable() and set display off/enter sleep in disable(). > > Further send an explict reset pulse in power_on() so we > come up in a known state, and issue the MCS_ERROR_CHECK > command after setting display on like the vendor driver > does. Also use the timings from the vendor driver in > the sequence. > > Doing all of these things makes the display much more > stable on the Samsung GT-I8190 when enabling/disabling > the display pipeline. > > Cc: Paweł Chmiel > Cc: Stephan Gerhold > Signed-off-by: Linus Walleij Browsed through this patch - looks fine. Acked-by: Sam Ravnborg Sam > --- > This is based on top of the earlier patches for s6e63m0. > --- > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 18 +++--- > 1 file changed, 15 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > index f1d96ec3b57f..49b0470bcccd 100644 > --- a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > @@ -26,6 +26,7 @@ > #define MCS_ELVSS_ON0xb1 > #define MCS_MIECTL10xc0 > #define MCS_BCMODE 0xc1 > +#define MCS_ERROR_CHECK 0xd5 > #define MCS_READ_ID1 0xda > #define MCS_READ_ID2 0xdb > #define MCS_READ_ID3 0xdc > @@ -281,8 +282,6 @@ static void s6e63m0_init(struct s6e63m0 *ctx) > > s6e63m0_dcs_write_seq_static(ctx, MCS_ELVSS_ON, >0x0b); > - > - s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_EXIT_SLEEP_MODE); > } > > static int s6e63m0_power_on(struct s6e63m0 *ctx) > @@ -295,6 +294,9 @@ static int s6e63m0_power_on(struct s6e63m0 *ctx) > > msleep(25); > > + /* Be sure to send a reset pulse */ > + gpiod_set_value(ctx->reset_gpio, 1); > + msleep(5); > gpiod_set_value(ctx->reset_gpio, 0); > msleep(120); > > @@ -324,8 +326,10 @@ static int s6e63m0_disable(struct drm_panel *panel) > > backlight_disable(ctx->bl_dev); > > + s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_OFF); > + msleep(10); > s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_ENTER_SLEEP_MODE); > - msleep(200); > + msleep(120); > > ctx->enabled = false; > > @@ -391,7 +395,15 @@ static int s6e63m0_enable(struct drm_panel *panel) > if (ctx->enabled) > return 0; > > + s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_EXIT_SLEEP_MODE); > + msleep(120); > s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_ON); > + msleep(10); > + > + s6e63m0_dcs_write_seq_static(ctx, MCS_ERROR_CHECK, > + 0xE7, 0x14, 0x60, 0x17, 0x0A, 0x49, 0xC3, > + 0x8F, 0x19, 0x64, 0x91, 0x84, 0x76, 0x20, > + 0x0F, 0x00); > > backlight_enable(ctx->bl_dev); > > -- > 2.26.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi Sam,
On Tue, Aug 18, 2020 at 07:05:56PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Mon, Aug 17, 2020 at 10:14:33AM +0200, Guido Günther wrote:
> >
> > The panel uses a Focaltech FT8006p, the touch part is handled by the already
> > existing edt-ft5x06. It can be found in e.g. the Librem 5.
> >
> > Changes from v2:
> > - Due to review comments by Sam Ravnborg, thanks!
> > https://lore.kernel.org/lkml/20200815212727.ga1244...@ravnborg.org/
> > - Drop unused header
> > - Use newline before comment
> > - Add Reviewed/Acked-by by Sam Ravnborg, thanks!
> > https://lore.kernel.org/lkml/20200815212727.ga1244...@ravnborg.org/
> > https://lore.kernel.org/lkml/20200815212750.gb1244...@ravnborg.org/
> > https://lore.kernel.org/lkml/20200815212840.gc1244...@ravnborg.org/
> >
> > Changes from v1:
> > - Due to review comments by Sam Ravnborg, thanks!
> > https://lore.kernel.org/dri-devel/20200815083917.ga993...@ravnborg.org/
> > - Don't preserve newlines with '|' in description
> > - Use reset-gpios and backlight from panel-common.yaml
> > - Reindent example
> > https://lore.kernel.org/dri-devel/20200815093226.gb993...@ravnborg.org/
> > - Drop unused includes
> > - Use dev_* instead of DRM_* for printing
> > - Turn off regulators in reverse order from enable
> > - Silence errors in mantix_{shutdown,remove}
> > - Drop duplicate mipi_dsi_dcs_enter_sleep_mode()
> > https://lore.kernel.org/dri-devel/20200815100230.ga1002...@ravnborg.org/
> > - Use dev_err_probe()
> > - Add delays when turning off panel as suggested by the data sheet
> >
> > This series is against next-20200814.
> >
> > Guido Günther (3):
> > dt-bindings: vendor-prefixes: Add mantix vendor prefix
> > dt-bindings: Add Mantix MLAF057WE51-X panel bindings
> > drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
>
> Maxime Ripard backmerged -rc1 to drm-misc-next so I went ahead and applied
> this series to drm-misc-next, forgetting you got commit rights. As they are
> already pushed out too late for you to do push them - sorry!
On the contrary: Thanks a lot for handling this so promptly!
-- Guido
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/panel: s6e63m0: Add DSI transport
Hi Linus. On Sun, Aug 09, 2020 at 11:51:00PM +0200, Linus Walleij wrote: > This begins to modify the Samsung S6E63M0 driver to provide > DSI support. > > After these initial changes the driver can already be used > with the Samsung GT-I8190 (Golden) phone. > > After this initial support we will make more changes to > support more gammas (more levels of backlight), special > biasing on different display types and handling of the > ESD IRQ. > > But let's begin with this. How does this patchset relate to the patchset posted by Paul? https://lore.kernel.org/dri-devel/20200727164613.19744-1-p...@crapouillou.net/ Seems that two different approcahes are used for the same type of problem. Is it possible to find a common solution? Sam > > Linus Walleij (4): > drm/panel: s6e63m0: Break out SPI transport > drm/panel: s6e63m0: Add DSI transport > drm/panel: s6e63m0: Add reading functionality > drm/panel: s6e63m0: Add code to identify panel > > drivers/gpu/drm/panel/Kconfig | 23 ++- > drivers/gpu/drm/panel/Makefile| 2 + > .../gpu/drm/panel/panel-samsung-s6e63m0-dsi.c | 145 + > .../gpu/drm/panel/panel-samsung-s6e63m0-spi.c | 101 > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 146 ++ > drivers/gpu/drm/panel/panel-samsung-s6e63m0.h | 13 ++ > 6 files changed, 363 insertions(+), 67 deletions(-) > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0-spi.c > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0.h > > -- > 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/malidp: Use struct drm_gem_object_funcs.get_sg_table internally
On Thu, Aug 13, 2020 at 02:01:19PM +0200, Daniel Vetter wrote:
> On Thu, Aug 13, 2020 at 12:39 PM Thomas Zimmermann
> wrote:
> >
> > Hi
> >
> > Am 13.08.20 um 12:31 schrieb Daniel Vetter:
> > > On Thu, Aug 13, 2020 at 12:28:55PM +0200, Thomas Zimmermann wrote:
> > >>
> > >>
> > >> Am 13.08.20 um 11:48 schrieb Daniel Vetter:
> > >>> On Thu, Aug 13, 2020 at 11:19:31AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 07.08.20 um 18:10 schrieb Daniel Vetter:
> > > On Fri, Aug 7, 2020 at 4:02 PM Thomas Zimmermann
> > > wrote:
> > >>
> > >> Hi
> > >>
> > >> Am 07.08.20 um 15:12 schrieb Daniel Vetter:
> > >>> On Fri, Aug 07, 2020 at 01:10:22PM +0200, Thomas Zimmermann wrote:
> > The malidp driver uses GEM object functions for callbacks. Fix it
> > to
> > use them internally as well.
> >
> > Signed-off-by: Thomas Zimmermann
> > Fixes: ecdd6474644f ("drm/malidp: Use GEM CMA object functions")
> > Cc: Thomas Zimmermann
> > Cc: Emil Velikov
> > Cc: Liviu Dudau
> > Cc: Brian Starkey
> > ---
> > drivers/gpu/drm/arm/malidp_planes.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> > b/drivers/gpu/drm/arm/malidp_planes.c
> > index ab45ac445045..351a85088d0e 100644
> > --- a/drivers/gpu/drm/arm/malidp_planes.c
> > +++ b/drivers/gpu/drm/arm/malidp_planes.c
> > @@ -346,7 +346,7 @@ static bool
> > malidp_check_pages_threshold(struct malidp_plane_state *ms,
> > if (cma_obj->sgt)
> > sgt = cma_obj->sgt;
> > else
> > -sgt =
> > obj->dev->driver->gem_prime_get_sg_table(obj);
> > +sgt = obj->funcs->get_sg_table(obj);
> > >>>
> > >>> Uh if there's not a switch somewhere I'd just call the right
> > >>> function
> > >>> directly. Or call the right wrapper for this, this feels a bit
> > >>> fishy ...
> > >>
> > >> The driver initializes the pointer via CMA helper macro to an
> > >> CMA-internal default. Calling the actual function here is fragile if
> > >> the
> > >> CMA-internal default ever changes.
> > >>
> > >> But I have no strong feelings. I'll go with whatever the driver's
> > >> maintainer prefers.
Hi,
Sorry for the silence, I was on holiday.
> > >
> > > What I meant is: There should be an exported helper to get at the sgt.
> > > Drivers using helpers shouldn't need to do this kind of stuff here.
> > >
> > > Also the entire code is fairly suspect, getting at the sgt from
> > > plane_check is a bit iffy. But that's a different kind of problem.
> >
> > I tried to somehow move the code to CMA, but it's not easy. There's no
> > good place to put the look-up code of sgt. And sgt is later being freed
> > iff it came from the callback (and not freed if it was stored in the
> > object). AFIACT the best options are to either keep the code here or
> > move the entire function to CMA helpers.
> > >>>
> > >>> Ok I read some code ... I'm confused. From the control flow it looks
> > >>> like
> > >>> malidp is using cma helpers. Otherwise why does the upcasting not blow
> > >>> up
> > >>> sometimes.
> > >>>
> > >>> But cma helpers already check at import time that any imported dma-buf
> > >>> is
> > >>> contiguous, and they guarantee to fill out the cma_obj->sgt.
> > >>>
> > >>> So really no idea what this code is doing here.
> > >>>
> > >>> It's also not correct, since it doesn't coalesce sgt entries, since a
> > >>> range might be split up, but still mapped into a contiguous dma_addr_t
> > >>> range when you take it all together. The code in
> > >>> drm_gem_cma_prime_import_sg_table() gets this more right.
> > >>>
> > >>> So maybe right fix is to just ditch this all, and use cma helpers fully?
> > >>
> > >> The driver already does use CMA, including
> > >> drm_gem_cma_prime_import_sg_table().
> > >>
> > >> The patched code is not about importing/exporting sg tables. It
> > >> configures the MMU's prefetching pattern by looking at some of the page
> > >> sizes. I don't feel confident enough with this code to alter it. I'd
> > >> expect to break the heuristics.
That's right, this piece of code has nothing to do with importing dma-buf or
checking if things are contiguous. Mali DP hardware has a prefetcher block that
can generate some fake requests during vblank to get the MMU pagetables cached
so that reads from the buffers can be done without waiting for page walks. The
block supports two modes, a full page or partial page request (to cater for the
ends of the buffer that might not be a full page).
The patch proposed looks good to me, so:
Acked-by: Liviu Dudau
I will push the
Re: [PATCH v3 0/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi Guido.
On Mon, Aug 17, 2020 at 10:14:33AM +0200, Guido Günther wrote:
>
> The panel uses a Focaltech FT8006p, the touch part is handled by the already
> existing edt-ft5x06. It can be found in e.g. the Librem 5.
>
> Changes from v2:
> - Due to review comments by Sam Ravnborg, thanks!
> https://lore.kernel.org/lkml/20200815212727.ga1244...@ravnborg.org/
> - Drop unused header
> - Use newline before comment
> - Add Reviewed/Acked-by by Sam Ravnborg, thanks!
> https://lore.kernel.org/lkml/20200815212727.ga1244...@ravnborg.org/
> https://lore.kernel.org/lkml/20200815212750.gb1244...@ravnborg.org/
> https://lore.kernel.org/lkml/20200815212840.gc1244...@ravnborg.org/
>
> Changes from v1:
> - Due to review comments by Sam Ravnborg, thanks!
> https://lore.kernel.org/dri-devel/20200815083917.ga993...@ravnborg.org/
> - Don't preserve newlines with '|' in description
> - Use reset-gpios and backlight from panel-common.yaml
> - Reindent example
> https://lore.kernel.org/dri-devel/20200815093226.gb993...@ravnborg.org/
> - Drop unused includes
> - Use dev_* instead of DRM_* for printing
> - Turn off regulators in reverse order from enable
> - Silence errors in mantix_{shutdown,remove}
> - Drop duplicate mipi_dsi_dcs_enter_sleep_mode()
> https://lore.kernel.org/dri-devel/20200815100230.ga1002...@ravnborg.org/
> - Use dev_err_probe()
> - Add delays when turning off panel as suggested by the data sheet
>
> This series is against next-20200814.
>
> Guido Günther (3):
> dt-bindings: vendor-prefixes: Add mantix vendor prefix
> dt-bindings: Add Mantix MLAF057WE51-X panel bindings
> drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Maxime Ripard backmerged -rc1 to drm-misc-next so I went ahead and applied
this series to drm-misc-next, forgetting you got commit rights. As they are
already pushed out too late for you to do push them - sorry!
Sam
>
> .../display/panel/mantix,mlaf057we51-x.yaml | 70
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 7 +
> drivers/gpu/drm/panel/Kconfig | 11 +
> drivers/gpu/drm/panel/Makefile| 1 +
> .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 328 ++
> 6 files changed, 419 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
>
> --
> 2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: Add DT bindings for RaspberryPi 7" display ATTINY88-based regulator/backlight controller
On Sun, 9 Aug 2020 12:59:37 +0200, Marek Vasut wrote: > Add DT bindings for RaspberryPi 7" display ATTINY88-based > regulator/backlight controller, this one is used in the > Raspberry Pi 7" touchscreen display unit. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/2] regulator: Add DT bindings for RaspberryPi 7" display ATTINY88-based regulator/backlight controller commit: 9c535960891470eaec5664eed2a56dbb2b6a205b [2/2] regulator: rpi-panel: Add regulator/backlight driver for RPi panel commit: 38573472278da49e2ab588062d88bc2f0c11a325 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] dma-heap: Devicetree binding for chunk heap
On Tue, 18 Aug 2020 17:04:15 +0900, Hyesoo Yu wrote: > Document devicetree binding for chunk heap on dma heap framework > > Signed-off-by: Hyesoo Yu > --- > .../devicetree/bindings/dma-buf/chunk_heap.yaml| 46 > ++ > 1 file changed, 46 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/dma-buf/chunk_heap.example.dt.yaml: chunk_default_heap: 'alignment', 'memory-region' do not match any of the regexes: 'pinctrl-[0-9]+' See https://patchwork.ozlabs.org/patch/1346687 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: enable vblank during atomic commits
From: Rob Clark
This has roughly the same effect as drm_atomic_helper_wait_for_vblanks(),
basically just ensuring that vblank accounting is enabled so that we get
valid timestamp/seqn on pageflip events.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_atomic.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 5ccfad794c6a..561bfa48841c 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -27,6 +27,34 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
return msm_framebuffer_prepare(new_state->fb, kms->aspace);
}
+/*
+ * Helpers to control vblanks while we flush.. basically just to ensure
+ * that vblank accounting is switched on, so we get valid seqn/timestamp
+ * on pageflip events (if requested)
+ */
+
+static void vblank_get(struct msm_kms *kms, unsigned crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask) {
+ if (!crtc->state->active)
+ continue;
+ drm_crtc_vblank_get(crtc);
+ }
+}
+
+static void vblank_put(struct msm_kms *kms, unsigned crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask) {
+ if (!crtc->state->active)
+ continue;
+ drm_crtc_vblank_put(crtc);
+ }
+}
+
static void msm_atomic_async_commit(struct msm_kms *kms, int crtc_idx)
{
unsigned crtc_mask = BIT(crtc_idx);
@@ -44,6 +72,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
kms->funcs->enable_commit(kms);
+ vblank_get(kms, crtc_mask);
+
/*
* Flush hardware updates:
*/
@@ -58,6 +88,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
+ vblank_put(kms, crtc_mask);
+
mutex_lock(&kms->commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
mutex_unlock(&kms->commit_lock);
@@ -221,6 +253,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
*/
kms->pending_crtc_mask &= ~crtc_mask;
+ vblank_get(kms, crtc_mask);
+
/*
* Flush hardware updates:
*/
@@ -235,6 +269,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
+ vblank_put(kms, crtc_mask);
+
mutex_lock(&kms->commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
mutex_unlock(&kms->commit_lock);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: Use alpha value to blend values.
I wrote this patch for TODO list in vkms documentation.
Use alpha value to blend source value and destination value Instead of
just overwrite with source value.
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Signed-off-by: Sidong Yang
---
drivers/gpu/drm/vkms/vkms_composer.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 4f3b07a32b60..e3230e2a99af 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -77,6 +77,9 @@ static void blend(void *vaddr_dst, void *vaddr_src,
for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
+ u8 *src, *dst;
+ u32 alpha, inv_alpha;
+
offset_dst = dest_composer->offset
+ (i_dst * dest_composer->pitch)
+ (j_dst++ * dest_composer->cpp);
@@ -84,8 +87,15 @@ static void blend(void *vaddr_dst, void *vaddr_src,
+ (i * src_composer->pitch)
+ (j * src_composer->cpp);
- memcpy(vaddr_dst + offset_dst,
- vaddr_src + offset_src, sizeof(u32));
+ src = vaddr_src + offset_src;
+ dst = vaddr_dst + offset_dst;
+ alpha = src[3] + 1;
+ inv_alpha = 256 - src[3];
+ dst[0] = (alpha * src[0] + inv_alpha * dst[0]) >> 8;
+ dst[1] = (alpha * src[1] + inv_alpha * dst[1]) >> 8;
+ dst[2] = (alpha * src[2] + inv_alpha * dst[2]) >> 8;
+ dst[3] = 0xff;
+
}
i_dst++;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Cc: Lyude Paul
Reviewed-by: Anshuman Gupta
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-16-s...@poorly.run
#v7
Changes in v4:
-Added to the set
Changes in v5:
-None
Changes in v6:
-Use FIELD_PREP to generate request buffer bitfields (Lyude)
-Add mst selftest and dump/decode_sideband_req for QSES (Lyude)
Changes in v7:
-None
Changes in v8:
-Reverse the parsing on the hdcp_*x_device_present bits and leave
breadcrumb in case this is incorrect (Anshuman)
---
drivers/gpu/drm/drm_dp_mst_topology.c | 150 ++
.../drm/selftests/test-drm_dp_mst_helper.c| 17 ++
include/drm/drm_dp_helper.h | 3 +
include/drm/drm_dp_mst_helper.h | 44 +
4 files changed, 214 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 67dd72ea200e..f2b77ef40281 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -20,11 +20,13 @@
* OF THIS SOFTWARE.
*/
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -423,6 +425,22 @@ drm_dp_encode_sideband_req(const struct
drm_dp_sideband_msg_req_body *req,
memcpy(&buf[idx], req->u.i2c_write.bytes,
req->u.i2c_write.num_bytes);
idx += req->u.i2c_write.num_bytes;
break;
+ case DP_QUERY_STREAM_ENC_STATUS: {
+ const struct drm_dp_query_stream_enc_status *msg;
+
+ msg = &req->u.enc_status;
+ buf[idx] = msg->stream_id;
+ idx++;
+ memcpy(&buf[idx], msg->client_id, sizeof(msg->client_id));
+ idx += sizeof(msg->client_id);
+ buf[idx] = 0;
+ buf[idx] |= FIELD_PREP(GENMASK(1, 0), msg->stream_event);
+ buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
+ buf[idx] |= FIELD_PREP(GENMASK(4, 3), msg->stream_behavior);
+ buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
+ idx++;
+ }
+ break;
}
raw->cur_len = idx;
}
@@ -551,6 +569,20 @@ drm_dp_decode_sideband_req(const struct
drm_dp_sideband_msg_tx *raw,
return -ENOMEM;
}
break;
+ case DP_QUERY_STREAM_ENC_STATUS:
+ req->u.enc_status.stream_id = buf[idx++];
+ for (i = 0; i < sizeof(req->u.enc_status.client_id); i++)
+ req->u.enc_status.client_id[i] = buf[idx++];
+
+ req->u.enc_status.stream_event = FIELD_GET(GENMASK(1, 0),
+ buf[idx]);
+ req->u.enc_status.valid_stream_event = FIELD_GET(BIT(2),
+buf[idx]);
+ req->u.enc_status.stream_behavior = FIELD_GET(GENMASK(4, 3),
+ buf[idx]);
+ req->u.enc_status.valid_stream_behavior = FIELD_GET(BIT(5),
+ buf[idx]);
+ break;
}
return 0;
@@ -629,6 +661,16 @@ drm_dp_dump_sideband_msg_req_body(const struct
drm_dp_sideband_msg_req_body *req
req->u.i2c_write.num_bytes, req->u.i2c_write.num_bytes,
req->u.i2c_write.bytes);
break;
+ case DP_QUERY_STREAM_ENC_STATUS:
+ P("stream_id=%u client_id=%*ph stream_event=%x "
+ "valid_event=%d stream_behavior=%x valid_behavior=%d",
+ req->u.enc_status.stream_id,
+ (int)ARRAY_SIZE(req->u.enc_status.client_id),
+ req->u.enc_status.client_id, req->u.enc_status.stream_event,
+ req->u.enc_status.valid_stream_event,
+ req->u.enc_status.stream_behavior,
+ req->u.enc_status.valid_stream_behavior);
+ break;
default:
P("???\n");
break;
@@ -936,6 +978,42 @@ static bool
drm_dp_sideband_parse_power_updown_phy_ack(struct drm_dp_sideband_ms
return true;
}
+static bool
+drm_dp_sideband_parse_query_stream_enc_status(
+ struct drm_dp_sideband_msg_rx *raw,
+ struct drm_dp_sideband_msg_reply_body *repmsg)
+{
+ struct drm_dp_query_stream_enc_status_ack_reply *reply;
+
+ reply = &repmsg->u.enc_status;
+
+ reply->stream_id = raw->ms
[PATCH v8 16/17] drm/i915: Print HDCP version info for all connectors
From: Sean Paul
De-duplicate the HDCP version code for each connector and print it for
all connectors.
Cc: Juston Li
Cc: Ramalingam C
Reviewed-by: Juston Li
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200227185714.171466-1-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-16-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-16-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-17-s...@poorly.run
#v7
Changes in v4:
- Added to the set
Changes in v5:
-Print "No connector support" for hdcp sink capability as well (Ram)
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
.../drm/i915/display/intel_display_debugfs.c | 21 ---
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index f549381048b3..58c26a5afc49 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -601,6 +601,11 @@ static void intel_hdcp_info(struct seq_file *m,
{
bool hdcp_cap, hdcp2_cap;
+ if (!intel_connector->hdcp.shim) {
+ seq_puts(m, "No Connector Support");
+ goto out;
+ }
+
hdcp_cap = intel_hdcp_capable(intel_connector);
hdcp2_cap = intel_hdcp2_capable(intel_connector);
@@ -612,6 +617,7 @@ static void intel_hdcp_info(struct seq_file *m,
if (!hdcp_cap && !hdcp2_cap)
seq_puts(m, "None");
+out:
seq_puts(m, "\n");
}
@@ -628,10 +634,6 @@ static void intel_dp_info(struct seq_file *m,
drm_dp_downstream_debug(m, intel_dp->dpcd, intel_dp->downstream_ports,
&intel_dp->aux);
- if (intel_connector->hdcp.shim) {
- seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
- }
}
static void intel_dp_mst_info(struct seq_file *m,
@@ -649,10 +651,6 @@ static void intel_hdmi_info(struct seq_file *m,
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(intel_encoder);
seq_printf(m, "\taudio support: %s\n", yesno(intel_hdmi->has_audio));
- if (intel_connector->hdcp.shim) {
- seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
- }
}
static void intel_lvds_info(struct seq_file *m,
@@ -708,6 +706,9 @@ static void intel_connector_info(struct seq_file *m,
break;
}
+ seq_puts(m, "\tHDCP version: ");
+ intel_hdcp_info(m, intel_connector);
+
seq_printf(m, "\tmodes:\n");
list_for_each_entry(mode, &connector->modes, head)
intel_seq_print_mode(m, 2, mode);
@@ -2029,10 +2030,6 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
if (connector->status != connector_status_connected)
return -ENODEV;
- /* HDCP is supported by connector */
- if (!intel_connector->hdcp.shim)
- return -EINVAL;
-
seq_printf(m, "%s:%d HDCP version: ", connector->name,
connector->base.id);
intel_hdcp_info(m, intel_connector);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 17/17] drm/i915: Add HDCP 1.4 support for MST connectors
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Cc: Juston Li
Reviewed-by: Anshuman Gupta
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-18-s...@poorly.run
#v7
Changes in v2:
-Toggle HDCP from encoder disable/enable
-Don't disable HDCP on MST connector destroy, leave that for encoder
disable, just ensure the check_work routine isn't running any longer
Changes in v3:
-Place the shim in the new intel_dp_hdcp.c file (Ville)
Changes in v4:
-Actually use the mst shim for mst connections (Juston)
-Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
Changes in v5:
-Add sleep on disable signalling to match hdmi delay
Changes in v6:
-Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I
don't have hardware to test it
Changes in v7:
-Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam)
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 66 +++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 ++
drivers/gpu/drm/i915/display/intel_hdcp.c| 2 +-
3 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index b744253a5924..03424d20e9f7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -7,10 +7,12 @@
*/
#include
+#include
#include
#include
#include "intel_display_types.h"
+#include "intel_ddi.h"
#include "intel_dp.h"
#include "intel_hdcp.h"
@@ -619,6 +621,65 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.protocol = HDCP_PROTOCOL_DP,
};
+static int
+intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port *dig_port,
+ enum transcoder cpu_transcoder,
+ bool enable)
+{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ int ret;
+
+ if (!enable)
+ usleep_range(6, 60); /* Bspec says >= 6us */
+
+ ret = intel_ddi_toggle_hdcp_signalling(&dig_port->base,
+ cpu_transcoder, enable);
+ if (ret)
+ drm_dbg_kms(&i915->drm, "%s HDCP signalling failed (%d)\n",
+ enable ? "Enable" : "Disable", ret);
+ return ret;
+}
+
+static
+bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
+ struct intel_connector *connector)
+{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ struct intel_dp *intel_dp = &dig_port->dp;
+ struct drm_dp_query_stream_enc_status_ack_reply reply;
+ int ret;
+
+ if (!intel_dp_hdcp_check_link(dig_port, connector))
+ return false;
+
+ ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
+ connector->port, &reply);
+ if (ret) {
+ drm_dbg_kms(&i915->drm,
+ "[CONNECTOR:%d:%s] failed QSES ret=%d\n",
+ connector->base.base.id, connector->base.name, ret);
+ return false;
+ }
+
+ return reply.auth_completed && reply.encryption_enabled;
+}
+
+static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
+ .write_an_aksv = intel_dp_hdcp_write_an_aksv,
+ .read_bksv = intel_dp_hdcp_read_bksv,
+ .read_bstatus = intel_dp_hdcp_read_bstatus,
+ .repeater_present = intel_dp_hdcp_repeater_present,
+ .read_ri_prime = intel_dp_hdcp_read_ri_prime,
+ .read_ksv_ready = intel_dp_hdcp_read_ksv_ready,
+ .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
+ .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
+ .toggle_signalling = intel_dp_mst_hdcp_toggle_signalling,
+ .check_link = intel_dp_mst_hdcp_check_link,
+ .hdcp_capable = intel_dp_hdcp_capable,
+
+ .protocol = HDCP_PROTOCOL_DP,
+};
+
int intel_dp_init_hdcp(struct intel_digital_port *dig_port,
struct intel_connector *intel_connector)
{
@@ -631,7 +692,10 @@ int intel_dp_init_hdcp(str
[PATCH v8 14/17] drm/i915: Add connector to hdcp_shim->check_link()
From: Sean Paul
Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.
Reviewed-by: Anshuman Gupta
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-14-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-14-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-15-s...@poorly.run
#v7
Changes in v4:
-Added to the set
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +-
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e01f2f840c9..413b60337a0b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -318,7 +318,8 @@ struct intel_hdcp_shim {
bool enable);
/* Ensures the link is still protected */
- bool (*check_link)(struct intel_digital_port *dig_port);
+ bool (*check_link)(struct intel_digital_port *dig_port,
+ struct intel_connector *connector);
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *dig_port,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index c164ad11e617..b744253a5924 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -224,7 +224,8 @@ int intel_dp_hdcp_toggle_signalling(struct
intel_digital_port *dig_port,
}
static
-bool intel_dp_hdcp_check_link(struct intel_digital_port *dig_port)
+bool intel_dp_hdcp_check_link(struct intel_digital_port *dig_port,
+ struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
ssize_t ret;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index f25cfb7a9565..028cf3ac548f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -952,7 +952,7 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
goto out;
}
- if (hdcp->shim->check_link(dig_port)) {
+ if (hdcp->shim->check_link(dig_port, connector)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
intel_hdcp_update_value(connector,
DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index c0ea16dae3b3..0978b0d8f4c6 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1546,11 +1546,10 @@ int intel_hdmi_hdcp_toggle_signalling(struct
intel_digital_port *dig_port,
}
static
-bool intel_hdmi_hdcp_check_link_once(struct intel_digital_port *dig_port)
+bool intel_hdmi_hdcp_check_link_once(struct intel_digital_port *dig_port,
+struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- struct intel_connector *connector =
- dig_port->hdmi.attached_connector;
enum port port = dig_port->base.port;
enum transcoder cpu_transcoder = connector->hdcp.cpu_transcoder;
int ret;
@@ -1578,13 +1577,14 @@ bool intel_hdmi_hdcp_check_link_once(struct
intel_digital_port *dig_port)
}
static
-bool intel_hdmi_hdcp_check_link(struct intel_digital_port *dig_port)
+bool intel_hdmi_hdcp_check_link(struct intel_digital_port *dig_port,
+ struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
int retry;
for (retry = 0; retry < 3; retry++)
- if (intel_hdmi_hdcp_check_link_once(dig_port))
+ if (intel_hdmi_hdcp_check_link_once(dig_port, connector))
return true;
drm_err(&i915->drm, "Link check failed\n");
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedeskt
[PATCH v8 08/17] drm/i915: Clean up intel_hdcp_disable
From: Sean Paul
Add an out label and un-indent hdcp disable in preparation for
hdcp_mutex. No functional changes
Reviewed-by: Anshuman Gupta
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-9-s...@poorly.run
#v7
Changes in v7:
-Split into separate patch (Ramalingam)
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index fe9377a6e4d5..4de87012659b 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2112,16 +2112,17 @@ int intel_hdcp_disable(struct intel_connector
*connector)
mutex_lock(&hdcp->mutex);
- if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- intel_hdcp_update_value(connector,
- DRM_MODE_CONTENT_PROTECTION_UNDESIRED,
- false);
- if (hdcp->hdcp2_encrypted)
- ret = _intel_hdcp2_disable(connector);
- else if (hdcp->hdcp_encrypted)
- ret = _intel_hdcp_disable(connector);
- }
+ if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ goto out;
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED, false);
+ if (hdcp->hdcp2_encrypted)
+ ret = _intel_hdcp2_disable(connector);
+ else if (hdcp->hdcp_encrypted)
+ ret = _intel_hdcp_disable(connector);
+
+out:
mutex_unlock(&hdcp->mutex);
cancel_delayed_work_sync(&hdcp->check_work);
return ret;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 12/17] drm/i915: Factor out HDCP shim functions from dp for use by dp_mst
From: Sean Paul
These functions are all the same for dp and dp_mst, so move them into a
dedicated file for both sst and mst to use.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-12-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-12-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-12-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-12-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-12-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-13-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-Created intel_dp_hdcp.c for the shared functions to live (Ville)
Changes in v4:
-Rebased on new drm logging change
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-Rebased patch
Changes in v8:
-None
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 607 +-
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 637 +++
4 files changed, 642 insertions(+), 606 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index bda4c0e408f8..e5574e506a5c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -234,6 +234,7 @@ i915-y += \
display/intel_ddi.o \
display/intel_dp.o \
display/intel_dp_aux_backlight.o \
+ display/intel_dp_hdcp.o \
display/intel_dp_link_training.o \
display/intel_dp_mst.o \
display/intel_dsi.o \
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b54577a04ccf..41d76df7423e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include "i915_debugfs.h"
@@ -6401,610 +6400,6 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
edp_panel_vdd_off_sync(intel_dp);
}
-static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp, int timeout)
-{
- long ret;
-
-#define C (hdcp->cp_irq_count_cached != atomic_read(&hdcp->cp_irq_count))
- ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
- msecs_to_jiffies(timeout));
-
- if (!ret)
- DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
-}
-
-static
-int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *dig_port,
- u8 *an)
-{
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- u8 aksv[DRM_HDCP_KSV_LEN] = {};
- ssize_t dpcd_ret;
-
- /* Output An first, that's easy */
- dpcd_ret = drm_dp_dpcd_write(&dig_port->dp.aux, DP_AUX_HDCP_AN,
-an, DRM_HDCP_AN_LEN);
- if (dpcd_ret != DRM_HDCP_AN_LEN) {
- drm_dbg_kms(&i915->drm,
- "Failed to write An over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
-
- /*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So we
-* send an empty buffer of the correct length through the DP helpers. On
-* the other side, in the transfer hook, we'll generate a flag based on
-* the destination address which will tickle the hardware to output the
-* Aksv on our behalf after the header is sent.
-*/
- dpcd_ret = drm_dp_dpcd_write(&dig_port->dp.aux, DP_AUX_HDCP_AKSV,
-aksv, DRM_HDCP_KSV_LEN);
- if (dpcd_ret != DRM_HDCP_KSV_LEN) {
- drm_dbg_kms(&i915->drm,
- "Failed to write Aksv over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bksv(struct intel_digital_port *dig_port,
- u8 *bksv)
-{
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- ssize_t ret;
-
- ret = drm_dp_dpcd_read(&dig_port->dp.aux, DP_AUX_HDCP_BKSV, bksv,
- DRM_HDCP_KSV_LEN);
- if (ret != DRM_HDCP_KSV_LEN) {
- drm_dbg_kms(&i915->drm,
- "Read Bksv from DP/AUX failed (%zd)\n", ret);
- return ret >= 0 ? -EIO : ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bstatus(struct intel_digita
[PATCH v8 05/17] drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-6-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-6-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-6-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-6-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-6-s...@poorly.run
#v7
Changes in v2:
-Added to the set
Changes in v3:
-s/hdcp/hdmi/ in commit msg (Ram)
Changes in v4:
-Rebased on intel_de_(read|write) change
Changes in v5:
-Update hdcp->cpu_transcoder in intel_hdcp_enable so it works with pipe != 0
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c | 13 +++--
drivers/gpu/drm/i915/display/intel_ddi.h | 2 ++
.../gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.c| 15 ---
drivers/gpu/drm/i915/display/intel_hdmi.c| 16 +++-
6 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index b02cd36647d6..2feec47a48e0 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1820,12 +1820,12 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
}
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable)
{
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
intel_wakeref_t wakeref;
- enum pipe pipe = 0;
int ret = 0;
u32 tmp;
@@ -1834,19 +1834,12 @@ int intel_ddi_toggle_hdcp_signalling(struct
intel_encoder *intel_encoder,
if (drm_WARN_ON(dev, !wakeref))
return -ENXIO;
- if (drm_WARN_ON(dev,
- !intel_encoder->get_hw_state(intel_encoder, &pipe))) {
- ret = -EIO;
- goto out;
- }
-
- tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(pipe));
+ tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
tmp |= TRANS_DDI_HDCP_SIGNALLING;
else
tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
- intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe), tmp);
-out:
+ intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
}
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index 077e9dbbe367..f5fb62fc9400 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -16,6 +16,7 @@ struct intel_crtc_state;
struct intel_dp;
struct intel_dpll_hw_state;
struct intel_encoder;
+enum transcoder;
void intel_ddi_fdi_post_disable(struct intel_atomic_state *state,
struct intel_encoder *intel_encoder,
@@ -43,6 +44,7 @@ void intel_ddi_compute_min_voltage_level(struct
drm_i915_private *dev_priv,
u32 bxt_signal_levels(struct intel_dp *intel_dp);
u32 ddi_signal_levels(struct intel_dp *intel_dp);
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable);
void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9349b15afff6..d30ec7728a99 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -314,6 +314,7 @@ struct intel_hdcp_shim {
/* Enables HDCP signalling on the port */
int (*toggle_signalling)(struct intel_digital_port *dig_port,
+enum transcoder cpu_transcoder,
bool enable);
/* Ensures the link is still protected */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7d1774bfbe41..adef7b508ff5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp
[PATCH v8 06/17] drm/i915: Factor out hdcp->value assignments
From: Sean Paul
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-7-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-7-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-7-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-7-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-7-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-7-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-7-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on top of drm_* logging changes
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 67 ---
1 file changed, 46 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index b28a351f3a98..ab2e2f9d0020 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -876,6 +876,21 @@ static struct intel_connector
*intel_hdcp_to_connector(struct intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
}
+static void intel_hdcp_update_value(struct intel_connector *connector,
+ u64 value, bool update_property)
+{
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ drm_WARN_ON(connector->base.dev, !mutex_is_locked(&hdcp->mutex));
+
+ if (hdcp->value == value)
+ return;
+
+ hdcp->value = value;
+ if (update_property)
+ schedule_work(&hdcp->prop_work);
+}
+
/* Implements Part 3 of the HDCP authorization procedure */
static int intel_hdcp_check_link(struct intel_connector *connector)
{
@@ -903,15 +918,16 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
connector->base.name, connector->base.base.id,
intel_de_read(dev_priv, HDCP_STATUS(dev_priv,
cpu_transcoder, port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
if (hdcp->shim->check_link(dig_port)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
}
goto out;
}
@@ -923,16 +939,18 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
ret = _intel_hdcp_disable(connector);
if (ret) {
drm_err(&dev_priv->drm, "Failed to disable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = _intel_hdcp_enable(connector);
if (ret) {
drm_err(&dev_priv->drm, "Failed to enable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
@@ -1768,16 +1786,18 @@ static int intel_hdcp2_check_link(struct
intel_connector *connector)
"HDCP2.2 link stopped the encryption, %x\n",
intel_de_read(dev_priv, HDCP2_STATUS(dev_priv,
cpu_transcoder, port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = hdcp->shim->check_2
[PATCH v8 09/17] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP will
also bring down HDCP on the port.
In order to achieve this, we need to keep a refcount in intel_digital_port
and protect it using a new hdcp_mutex.
Cc: Ramalingam C
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-9-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-9-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-9-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-10-s...@poorly.run
#v7
Changes in v2:
-Move the toggle_signalling call into _intel_hdcp_disable so it's called from
check_work
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-Split minor intel_hdcp_disable refactor into separate patch (Ramalingam)
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 ++
.../drm/i915/display/intel_display_types.h| 5 +++
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 33 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 ++
5 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 2feec47a48e0..a1643588b5f9 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4996,6 +4996,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
drm_encoder_init(&dev_priv->drm, &encoder->base, &intel_ddi_funcs,
DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
+ mutex_init(&dig_port->hdcp_mutex);
+ dig_port->num_hdcp_streams = 0;
+
encoder->hotplug = intel_ddi_hotplug;
encoder->compute_output_type = intel_ddi_compute_output_type;
encoder->compute_config = intel_ddi_compute_config;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d30ec7728a99..b6d0ad171432 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1416,6 +1416,11 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
+ /* protects num_hdcp_streams reference count */
+ struct mutex hdcp_mutex;
+ /* the number of pipes using HDCP signalling out of this port */
+ unsigned int num_hdcp_streams;
+
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index adef7b508ff5..b54577a04ccf 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -8285,6 +8285,8 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder = &dig_port->base;
encoder = &intel_encoder->base;
+ mutex_init(&dig_port->hdcp_mutex);
+
if (drm_encoder_init(&dev_priv->drm, &intel_encoder->base,
&intel_dp_enc_funcs, DRM_MODE_ENCODER_TMDS,
"DP %c", port_name(port)))
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 4de87012659b..dc77db0a8df3 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -801,6 +801,19 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
+ /*
+* If there are other connectors on this port using HDCP, don't disable
+* it. Instead, toggle the HDCP signalling off on that particular
+* connector/pipe and exit.
+*/
+ if (dig_port->num_hdcp_streams > 0) {
+ ret = hdcp->shim->toggle_signalling(dig_port,
+ cpu_transcoder, false);
+ if (ret)
+ DRM_ERROR("Failed to disable HDCP signalling\n");
+ retur
[PATCH v8 07/17] drm/i915: Protect workers against disappearing connectors
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't do a synchronous wait since it needs
to take connection_mutex which could cause deadlock. Instead, we'll take
a reference on the connector when scheduling prop_work and give it up
once we're done.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-8-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-8-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-8-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-8-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-8-s...@poorly.run
#v7
Changes in v2:
-Added to the set
Changes in v3:
-Change the WARN_ON condition in intel_hdcp_cleanup to allow for
initializing connectors as well
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 44 ---
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index ab2e2f9d0020..fe9377a6e4d5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -887,8 +887,10 @@ static void intel_hdcp_update_value(struct intel_connector
*connector,
return;
hdcp->value = value;
- if (update_property)
+ if (update_property) {
+ drm_connector_get(&connector->base);
schedule_work(&hdcp->prop_work);
+ }
}
/* Implements Part 3 of the HDCP authorization procedure */
@@ -980,6 +982,8 @@ static void intel_hdcp_prop_work(struct work_struct *work)
mutex_unlock(&hdcp->mutex);
drm_modeset_unlock(&dev_priv->drm.mode_config.connection_mutex);
+
+ drm_connector_put(&connector->base);
}
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
@@ -1859,6 +1863,9 @@ static void intel_hdcp_check_work(struct work_struct
*work)
check_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
+ if (drm_connector_is_unregistered(&connector->base))
+ return;
+
if (!intel_hdcp2_check_link(connector))
schedule_delayed_work(&hdcp->check_work,
DRM_HDCP2_CHECK_PERIOD_MS);
@@ -2185,12 +2192,39 @@ void intel_hdcp_component_fini(struct drm_i915_private
*dev_priv)
void intel_hdcp_cleanup(struct intel_connector *connector)
{
- if (!connector->hdcp.shim)
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ if (!hdcp->shim)
return;
- mutex_lock(&connector->hdcp.mutex);
- kfree(connector->hdcp.port_data.streams);
- mutex_unlock(&connector->hdcp.mutex);
+ /*
+* If the connector is registered, it's possible userspace could kick
+* off another HDCP enable, which would re-spawn the workers.
+*/
+ drm_WARN_ON(connector->base.dev,
+ connector->base.registration_state == DRM_CONNECTOR_REGISTERED);
+
+ /*
+* Now that the connector is not registered, check_work won't be run,
+* but cancel any outstanding instances of it
+*/
+ cancel_delayed_work_sync(&hdcp->check_work);
+
+ /*
+* We don't cancel prop_work in the same way as check_work since it
+* requires connection_mutex which could be held while calling this
+* function. Instead, we rely on the connector references grabbed before
+* scheduling prop_work to ensure the connector is alive when prop_work
+* is run. So if we're in the destroy path (which is where this
+* function should be called), we're "guaranteed" that prop_work is not
+* active (tl;dr This Should Never Happen).
+*/
+ drm_WARN_ON(connector->base.dev, work_pending(&hdcp->prop_work));
+
+ mutex_lock(&hdcp->mutex);
+ kfree(hdcp->port_data.streams);
+ hdcp->shim = NULL;
+ mutex_unlock(&hdcp->mutex);
}
void intel_hdcp_atomic_check(struct drm_connector *connector,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 13/17] drm/i915: Plumb port through hdcp init
From: Sean Paul
This patch plumbs port through hdcp init instead of relying on
intel_attached_encoder() to return a non-NULL encoder which won't work
for MST connectors.
Cc: Ville Syrjälä
Reviewed-by: Anshuman Gupta
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-13-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-13-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-14-s...@poorly.run
#v7
Changes in v5:
-Added to the set
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c| 11 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h| 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c| 2 +-
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 0b8200bed061..c164ad11e617 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -631,7 +631,8 @@ int intel_dp_init_hdcp(struct intel_digital_port *dig_port,
return 0;
if (!intel_dp_is_edp(intel_dp))
- return intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
+ return intel_hdcp_init(intel_connector, port,
+ &intel_dp_hdcp_shim);
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index dc77db0a8df3..f25cfb7a9565 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1954,6 +1954,7 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder
cpu_transcoder)
}
static int initialize_hdcp_port_data(struct intel_connector *connector,
+enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1961,8 +1962,7 @@ static int initialize_hdcp_port_data(struct
intel_connector *connector,
struct hdcp_port_data *data = &hdcp->port_data;
if (INTEL_GEN(dev_priv) < 12)
- data->fw_ddi =
-
intel_get_mei_fw_ddi_index(intel_attached_encoder(connector)->port);
+ data->fw_ddi = intel_get_mei_fw_ddi_index(port);
else
/*
* As per ME FW API expectation, for GEN 12+, fw_ddi is filled
@@ -2032,14 +2032,14 @@ void intel_hdcp_component_init(struct drm_i915_private
*dev_priv)
}
}
-static void intel_hdcp2_init(struct intel_connector *connector,
+static void intel_hdcp2_init(struct intel_connector *connector, enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
- ret = initialize_hdcp_port_data(connector, shim);
+ ret = initialize_hdcp_port_data(connector, port, shim);
if (ret) {
drm_dbg_kms(&i915->drm, "Mei hdcp data init failed\n");
return;
@@ -2049,6 +2049,7 @@ static void intel_hdcp2_init(struct intel_connector
*connector,
}
int intel_hdcp_init(struct intel_connector *connector,
+ enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -2059,7 +2060,7 @@ int intel_hdcp_init(struct intel_connector *connector,
return -EINVAL;
if (is_hdcp2_supported(dev_priv))
- intel_hdcp2_init(connector, shim);
+ intel_hdcp2_init(connector, port, shim);
ret =
drm_connector_attach_content_protection_property(&connector->base,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 86bbaec120cc..1bbf5b67ed0a 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -22,7 +22,7 @@ enum transcoder;
void intel_hdcp_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
-int intel_hdcp_init(struct intel_connector *connector,
+int intel_hdcp_init(struct intel_connector *connector, enum port port,
const struct intel_hdcp_shim *hdcp_shim);
int intel_hdcp_enable(struct intel_connector *connector,
enum transcoder cpu_transcoder, u8 content_type);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 9c3b1ae2cd2b..c0ea16dae3b3 100644
--- a/drivers/gpu/drm/i915/
[PATCH v8 11/17] drm/i915: Use ddi_update_pipe in intel_dp_mst
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-11-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-11-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-11-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-11-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-11-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-12-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c| 11 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 6 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a1643588b5f9..36022281d7e0 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4012,13 +4012,14 @@ static void intel_ddi_update_pipe_dp(struct
intel_atomic_state *state,
intel_panel_update_backlight(state, encoder, crtc_state, conn_state);
}
-static void intel_ddi_update_pipe(struct intel_atomic_state *state,
- struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
+void intel_ddi_update_pipe(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
- if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
+ !intel_encoder_is_mst(encoder))
intel_ddi_update_pipe_dp(state, encoder, crtc_state,
conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index b901ab850cbd..d13b45151a3f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -17,6 +17,7 @@ struct drm_encoder;
struct drm_i915_private;
struct drm_modeset_acquire_ctx;
struct drm_dp_vsc_sdp;
+struct intel_atomic_state;
struct intel_connector;
struct intel_crtc_state;
struct intel_digital_port;
@@ -128,4 +129,9 @@ static inline unsigned int intel_dp_unused_lane_mask(int
lane_count)
u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
+void intel_ddi_update_pipe(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state);
+
#endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index a2d91a499700..b97b2918d802 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -865,6 +865,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port
*dig_port, enum pipe
intel_encoder->compute_config_late = intel_dp_mst_compute_config_late;
intel_encoder->disable = intel_mst_disable_dp;
intel_encoder->post_disable = intel_mst_post_disable_dp;
+ intel_encoder->update_pipe = intel_ddi_update_pipe;
intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
intel_encoder->pre_enable = intel_mst_pre_enable_dp;
intel_encoder->enable = intel_mst_enable_dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 10/17] drm/i915: Support DP MST in enc_to_dig_port() function
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-10-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-10-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-10-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-10-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-10-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-11-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
.../drm/i915/display/intel_display_types.h| 21 ---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b6d0ad171432..5e01f2f840c9 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1531,6 +1531,18 @@ static inline bool intel_encoder_is_dig_port(struct
intel_encoder *encoder)
}
}
+static inline bool intel_encoder_is_mst(struct intel_encoder *encoder)
+{
+ return encoder->type == INTEL_OUTPUT_DP_MST;
+}
+
+static inline struct intel_dp_mst_encoder *
+enc_to_mst(struct intel_encoder *encoder)
+{
+ return container_of(&encoder->base, struct intel_dp_mst_encoder,
+ base.base);
+}
+
static inline struct intel_digital_port *
enc_to_dig_port(struct intel_encoder *encoder)
{
@@ -1539,6 +1551,8 @@ enc_to_dig_port(struct intel_encoder *encoder)
if (intel_encoder_is_dig_port(intel_encoder))
return container_of(&encoder->base, struct intel_digital_port,
base.base);
+ else if (intel_encoder_is_mst(intel_encoder))
+ return enc_to_mst(encoder)->primary;
else
return NULL;
}
@@ -1549,13 +1563,6 @@ intel_attached_dig_port(struct intel_connector
*connector)
return enc_to_dig_port(intel_attached_encoder(connector));
}
-static inline struct intel_dp_mst_encoder *
-enc_to_mst(struct intel_encoder *encoder)
-{
- return container_of(&encoder->base, struct intel_dp_mst_encoder,
- base.base);
-}
-
static inline struct intel_dp *enc_to_intel_dp(struct intel_encoder *encoder)
{
return &enc_to_dig_port(encoder)->dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 04/17] drm/i915: Intercept Aksv writes in the aux hooks
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an LG monitor on my desk, I noticed it was passing
back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP
auth was failing as a result. Instead of copy/pasting all of the retry
logic and delays from drm dp helpers, let's just use the helpers and hide
the aksv select as best as we can.
Reviewed-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-3-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-5-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-5-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-5-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-5-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-5-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-5-s...@poorly.run
#v7
Changes in v2:
-Remove 'generate' in intel_dp_aux_generate_xfer_flags, make arg const (Ville)
-Bundle Aksv if statement together (Ville)
-Rename 'txbuf' to 'aksv' (Ville)
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_dp.c | 62 -
1 file changed, 29 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 79c27f91f42c..7d1774bfbe41 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1563,6 +1563,20 @@ intel_dp_aux_header(u8 txbuf[HEADER_SIZE],
txbuf[3] = msg->size - 1;
}
+static u32 intel_dp_aux_xfer_flags(const struct drm_dp_aux_msg *msg)
+{
+ /*
+* If we're trying to send the HDCP Aksv, we need to set a the Aksv
+* select bit to inform the hardware to send the Aksv after our header
+* since we can't access that data from software.
+*/
+ if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_WRITE &&
+ msg->address == DP_AUX_HDCP_AKSV)
+ return DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+
+ return 0;
+}
+
static ssize_t
intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
{
@@ -1570,6 +1584,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 txbuf[20], rxbuf[20];
size_t txsize, rxsize;
+ u32 flags = intel_dp_aux_xfer_flags(msg);
int ret;
intel_dp_aux_header(txbuf, msg);
@@ -1590,7 +1605,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
@@ -1613,7 +1628,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
return -E2BIG;
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -6403,15 +6418,8 @@ int intel_dp_hdcp_write_an_aksv(struct
intel_digital_port *dig_port,
u8 *an)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- struct intel_dp *intel_dp =
enc_to_intel_dp(to_intel_encoder(&dig_port->base.base));
- static const struct drm_dp_aux_msg msg = {
- .request = DP_AUX_NATIVE_WRITE,
- .address = DP_AUX_HDCP_AKSV,
- .size = DRM_HDCP_KSV_LEN,
- };
- u8 txbuf[HEADER_SIZE + DRM_HDCP_KSV_LEN] = {}, rxbuf[2], reply = 0;
+ u8 aksv[DRM_HDCP_KSV_LEN] = {};
ssize_t dpcd_ret;
- int ret;
/* Output An first, that's easy */
dpcd_ret = drm_dp_dpcd_write(&dig_port->dp.aux, DP_AUX_HDCP_AN,
@@ -6424,31 +6432,19 @@ int intel_dp_hdcp_write_an_aksv(struct
intel_digital_port *dig_port,
}
/*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So in
-* order to get it on the wire, we need to create the AUX header as if
-*
[PATCH v8 02/17] drm/i915: Clear the repeater bit on HDCP disable
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-3-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-3-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-3-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-3-s...@poorly.run
#v7
Changes in v2:
-Added to the set
Changes in v3:
-None
I had previously agreed that clearing the rep_ctl bits on enable would
also be a good idea. However when I committed that idea to code, it
didn't look right. So let's rely on enables and disables being paired
and everything outside of that will be considered a bug
Changes in v4:
-s/I915_(READ|WRITE)/intel_de_(read|write)/
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6189b7583277..1a0d49af2a08 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -795,6 +795,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
struct intel_hdcp *hdcp = &connector->hdcp;
enum port port = dig_port->base.port;
enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
+ u32 repeater_ctl;
int ret;
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
@@ -810,6 +811,11 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
return -ETIMEDOUT;
}
+ repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
+ port);
+ intel_de_write(dev_priv, HDCP_REP_CTL,
+ intel_de_read(dev_priv, HDCP_REP_CTL) & ~repeater_ctl);
+
ret = hdcp->shim->toggle_signalling(dig_port, false);
if (ret) {
drm_err(&dev_priv->drm, "Failed to disable HDCP signalling\n");
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 01/17] drm/i915: Fix sha_text population code
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being placed on the wrong half of sha_text, overlapping the leftover
ksv value
3- In the sha_leftovers == 2 case, we need to manually terminate the
byte stream with 0x80 since the hardware doesn't have enough room to
add it after writing M0
The upside is that all of the HDCP supported HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-2-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-2-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-2-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-2-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-2-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on intel_de_write changes
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 26 +--
include/drm/drm_hdcp.h| 3 +++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 89a4d294822d..6189b7583277 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -336,8 +336,10 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Fill up the empty slots in sha_text and write it out */
sha_empty = sizeof(sha_text) - sha_leftovers;
- for (j = 0; j < sha_empty; j++)
- sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
+ for (j = 0; j < sha_empty; j++) {
+ u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) *
8);
+ sha_text |= ksv[j] << off;
+ }
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
@@ -435,7 +437,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Write 32 bits of text */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24 | bstatus[1] << 16;
+ sha_text |= bstatus[0] << 8 | bstatus[1];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
@@ -450,17 +452,29 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
return ret;
sha_idx += sizeof(sha_text);
}
+
+ /*
+* Terminate the SHA-1 stream by hand. For the other leftover
+* cases this is appended by the hardware.
+*/
+ intel_de_write(dev_priv, HDCP_REP_CTL,
+ rep_ctl | HDCP_SHA1_TEXT_32);
+ sha_text = DRM_HDCP_SHA1_TERMINATOR << 24;
+ ret = intel_write_sha_text(dev_priv, sha_text);
+ if (ret < 0)
+ return ret;
+ sha_idx += sizeof(sha_text);
} else if (sha_leftovers == 3) {
- /* Write 32 bits of text */
+ /* Write 32 bits of text (filled from LSB) */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24;
+ sha_text |= bstatus[0];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
sha_idx += sizeof(sha_text);
- /* Write 8 bits of text, 24 bits of M0 */
+ /* Write 8 bits of text (filled from LSB), 24 bits of M0 */
intel_de_write(dev_priv, HDCP_REP_CTL,
[PATCH v8 03/17] drm/i915: WARN if HDCP signalling is enabled upon disable
From: Sean Paul HDCP signalling should not be left on, WARN if it is Cc: Ville Syrjälä Cc: Daniel Vetter Reviewed-by: Ramalingam C Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-4-s...@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-4-s...@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-4-s...@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-4-s...@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-4-s...@poorly.run #v7 Changes in v2: -Added to the set in lieu of just clearing the bit Changes in v3: -None Changes in v4: -None Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None Changes in v7: -Rebased, variable name changed from 'ctl' to 'val' Changes in v8: -None --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index de5b216561d8..b02cd36647d6 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -1791,6 +1791,8 @@ void intel_ddi_disable_transcoder_func(const struct intel_crtc_state *crtc_state ctl = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder)); + drm_WARN_ON(crtc->base.dev, ctl & TRANS_DDI_HDCP_SIGNALLING); + ctl &= ~TRANS_DDI_FUNC_ENABLE; if (IS_GEN_RANGE(dev_priv, 8, 10)) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 00/17] drm/i915: Add support for HDCP 1.4 over MST
From: Sean Paul Only one functional change, reversed the hdcp_1x/2x_present bits in the QUERY_STREAM_ENCRYPTION_STATUS parsing with a comment explaining my confusion. Other than that, lots of rebasing, the most notable being the s/intel_dig_port/dig_port/ rename. Every patch now has a Reviewed-by tag now, I've done build tests on each patch and tested the set as a whole. Hopefully we can get this landed. Sean Sean Paul (17): drm/i915: Fix sha_text population code drm/i915: Clear the repeater bit on HDCP disable drm/i915: WARN if HDCP signalling is enabled upon disable drm/i915: Intercept Aksv writes in the aux hooks drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling drm/i915: Factor out hdcp->value assignments drm/i915: Protect workers against disappearing connectors drm/i915: Clean up intel_hdcp_disable drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it drm/i915: Support DP MST in enc_to_dig_port() function drm/i915: Use ddi_update_pipe in intel_dp_mst drm/i915: Factor out HDCP shim functions from dp for use by dp_mst drm/i915: Plumb port through hdcp init drm/i915: Add connector to hdcp_shim->check_link() drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message drm/i915: Print HDCP version info for all connectors drm/i915: Add HDCP 1.4 support for MST connectors drivers/gpu/drm/drm_dp_mst_topology.c | 150 drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- drivers/gpu/drm/i915/display/intel_ddi.h | 2 + .../drm/i915/display/intel_display_debugfs.c | 21 +- .../drm/i915/display/intel_display_types.h| 30 +- drivers/gpu/drm/i915/display/intel_dp.c | 646 +--- drivers/gpu/drm/i915/display/intel_dp.h | 9 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 703 ++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 + drivers/gpu/drm/i915/display/intel_hdcp.c | 217 -- drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 30 +- .../drm/selftests/test-drm_dp_mst_helper.c| 17 + include/drm/drm_dp_helper.h | 3 + include/drm/drm_dp_mst_helper.h | 44 ++ include/drm/drm_hdcp.h| 3 + 17 files changed, 1202 insertions(+), 724 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
