Re: [PATCH] drm: Fix build error caused by missing drm_nomodeset.o
On 11/27/21 20:26, Daniel Vetter wrote:
> On Sat, Nov 27, 2021 at 08:19:10PM +0100, Javier Martinez Canillas wrote:
>> The patch for commit ("6a2d2ddf2c34 drm: Move nomodeset kernel parameter
>> to the DRM subsystem") was generated with config 'diff.noprefix true'.
>>
>> But later was applied using 'cat nomodeset.mbox | dim apply-branch' on a
>> machine with 'diff.noprefix false'. And command 'git am --scissors -3' as
>
> Huh that's a dangerous setting, I guess a dim patch to check for this and
> very loudly complain would be good? Care to type that up? It's no big
> deal because strange git settings for dim is pretty much a game of
> whack-a-mole, but we should tackle them when they pop up.
>
Sure.
>> used by the dim tool doesn't handle that case well, since the 3-way merge
>> wrongly resolves the path for new file drivers/gpu/drm/drm_nomodeset.c as
>> gpu/drm/drm_nomodeset.c instead.
>>
>> It led to the following build error as reported by the kernel test robot:
>>
>> make[4]: *** No rule to make target 'drivers/gpu/drm/drm_nomodeset.o',
>> needed by 'drivers/gpu/drm/built-in.a'.
>>
>> Fixes: ("6a2d2ddf2c34 drm: Move nomodeset kernel parameter to the DRM
>> subsystem")
>> Reported-by: kernel test robot
>> Signed-off-by: Javier Martinez Canillas
>
> Build testing before pushing should be done, not the other way round :-)
>
Yes, sorry about that. I wrongly assumed that the tools would do the correct
thing but I will make sure to build test before pushing in the future.
> Also this is pretty much why we want gitlab CI and real branches.
>
> Reviewed-by: Daniel Vetter
>> ---
Thanks!
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH] drm: Fix build error caused by missing drm_nomodeset.o
On Sat, Nov 27, 2021 at 08:19:10PM +0100, Javier Martinez Canillas wrote:
> The patch for commit ("6a2d2ddf2c34 drm: Move nomodeset kernel parameter
> to the DRM subsystem") was generated with config 'diff.noprefix true'.
>
> But later was applied using 'cat nomodeset.mbox | dim apply-branch' on a
> machine with 'diff.noprefix false'. And command 'git am --scissors -3' as
Huh that's a dangerous setting, I guess a dim patch to check for this and
very loudly complain would be good? Care to type that up? It's no big
deal because strange git settings for dim is pretty much a game of
whack-a-mole, but we should tackle them when they pop up.
> used by the dim tool doesn't handle that case well, since the 3-way merge
> wrongly resolves the path for new file drivers/gpu/drm/drm_nomodeset.c as
> gpu/drm/drm_nomodeset.c instead.
>
> It led to the following build error as reported by the kernel test robot:
>
> make[4]: *** No rule to make target 'drivers/gpu/drm/drm_nomodeset.o',
> needed by 'drivers/gpu/drm/built-in.a'.
>
> Fixes: ("6a2d2ddf2c34 drm: Move nomodeset kernel parameter to the DRM
> subsystem")
> Reported-by: kernel test robot
> Signed-off-by: Javier Martinez Canillas
Build testing before pushing should be done, not the other way round :-)
Also this is pretty much why we want gitlab CI and real branches.
Reviewed-by: Daniel Vetter
> ---
>
> {gpu => drivers/gpu}/drm/drm_nomodeset.c | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename {gpu => drivers/gpu}/drm/drm_nomodeset.c (100%)
>
> diff --git a/gpu/drm/drm_nomodeset.c b/drivers/gpu/drm/drm_nomodeset.c
> similarity index 100%
> rename from gpu/drm/drm_nomodeset.c
> rename to drivers/gpu/drm/drm_nomodeset.c
> --
> 2.33.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm: Fix build error caused by missing drm_nomodeset.o
The patch for commit ("6a2d2ddf2c34 drm: Move nomodeset kernel parameter
to the DRM subsystem") was generated with config 'diff.noprefix true'.
But later was applied using 'cat nomodeset.mbox | dim apply-branch' on a
machine with 'diff.noprefix false'. And command 'git am --scissors -3' as
used by the dim tool doesn't handle that case well, since the 3-way merge
wrongly resolves the path for new file drivers/gpu/drm/drm_nomodeset.c as
gpu/drm/drm_nomodeset.c instead.
It led to the following build error as reported by the kernel test robot:
make[4]: *** No rule to make target 'drivers/gpu/drm/drm_nomodeset.o', needed
by 'drivers/gpu/drm/built-in.a'.
Fixes: ("6a2d2ddf2c34 drm: Move nomodeset kernel parameter to the DRM
subsystem")
Reported-by: kernel test robot
Signed-off-by: Javier Martinez Canillas
---
{gpu => drivers/gpu}/drm/drm_nomodeset.c | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename {gpu => drivers/gpu}/drm/drm_nomodeset.c (100%)
diff --git a/gpu/drm/drm_nomodeset.c b/drivers/gpu/drm/drm_nomodeset.c
similarity index 100%
rename from gpu/drm/drm_nomodeset.c
rename to drivers/gpu/drm/drm_nomodeset.c
--
2.33.1
AMDGPU - What is correct combination of kernel CONFIG options?
Hi, I am trying to compile a Linux 5.15 kernel with the amdgpu driver for a Radeon RX 6600. For reference, Fedora's 5.15.4-201.fc35.x86_64 kernel appears to work for me and be stable, and so I am confident that my hardware is OK, even if my motherboard is quite old (PCIE 2.0, I believe). However, I am struggling to configure a stable amdgpu driver for a 5.15.x kernel of my own, and suspect that I have missed at least one significant CONFIG setting. My amdgpu module has all the same module dependencies as the Fedora kernel, and my kernel boots as far as the GNOME login screen, but then the GNOME desktop fails to appear and my dmesg log fills with messages about failing to start the parser. My .config file currently includes: CONFIG_DRM_AMDGPU=m CONFIG_DRM_AMDGPU_CIK=y CONFIG_DRM_AMDGPU_USERPTR=y CONFIG_DRM_AMD_DC=y CONFIG_DRM_AMD_DC_DCN=y CONFIG_DRM_AMD_DC_HDCP=y CONFIG_DRM_AMD_SECURE_DISPLAY=y CONFIG_HSA_AMD=y CONFIG_HSA_AMD_SVM=y CONFIG_DRM_AMD_ACP=y and I have also added: CONFIG_AMD_IOMMU=y CONFIG_AMD_IOMMU_V2=m Are there any other (say) CONFIG_AMD_xxx options I need which I have missed please? My motherboard has an Intel CPU and so I have not included AMD config options by default. Thanks, Chris P.S. AFAIK I shouldn't need AMDGPU_CIK for my RX 6600, but have kept it so that I can still swap back to an older card if necessary.
Re: [PATCH 11/15] iio: buffer-dma: Boost performance using write-combine cache setting
On Thu, 25 Nov 2021 17:29:58 + Paul Cercueil wrote: > Hi Jonathan, > > Le dim., nov. 21 2021 at 17:43:20 +, Paul Cercueil > a écrit : > > Hi Jonathan, > > > > Le dim., nov. 21 2021 at 15:00:37 +, Jonathan Cameron > > a écrit : > >> On Mon, 15 Nov 2021 14:19:21 + > >> Paul Cercueil wrote: > >> > >>> We can be certain that the input buffers will only be accessed by > >>> userspace for reading, and output buffers will mostly be accessed > >>> by > >>> userspace for writing. > >> > >> Mostly? Perhaps a little more info on why that's not 'only'. > > > > Just like with a framebuffer, it really depends on what the > > application does. Most of the cases it will just read sequentially an > > input buffer, or write sequentially an output buffer. But then you > > get the exotic application that will try to do something like alpha > > blending, which means read+write. Hence "mostly". > > > >>> > >>> Therefore, it makes more sense to use only fully cached input > >>> buffers, > >>> and to use the write-combine cache coherency setting for output > >>> buffers. > >>> > >>> This boosts performance, as the data written to the output buffers > >>> does > >>> not have to be sync'd for coherency. It will halve performance if > >>> the > >>> userspace application tries to read from the output buffer, but > >>> this > >>> should never happen. > >>> > >>> Since we don't need to sync the cache when disabling CPU access > >>> either > >>> for input buffers or output buffers, the .end_cpu_access() > >>> callback can > >>> be dropped completely. > >> > >> We have an odd mix of coherent and non coherent DMA in here as you > >> noted, > >> but are you sure this is safe on all platforms? > > > > The mix isn't safe, but using only coherent or only non-coherent > > should be safe, yes. > > > >> > >>> > >>> Signed-off-by: Paul Cercueil > >> > >> Any numbers to support this patch? The mapping types are performance > >> optimisations so nice to know how much of a difference they make. > > > > Output buffers are definitely faster in write-combine mode. On a > > ZedBoard with a AD9361 transceiver set to 66 MSPS, and buffer/size > > set to 8192, I would get about 185 MiB/s before, 197 MiB/s after. > > > > Input buffers... early results are mixed. On ARM32 it does look like > > it is slightly faster to read from *uncached* memory than reading > > from cached memory. The cache sync does take a long time. > > > > Other architectures might have a different result, for instance on > > MIPS invalidating the cache is a very fast operation, so using cached > > buffers would be a huge win in performance. > > > > Setups where the DMA operations are coherent also wouldn't require > > any cache sync and this patch would give a huge win in performance. > > > > I'll run some more tests next week to have some fresh numbers. > > I think I mixed things up before, because I get different results now. > > Here are some fresh benchmarks, triple-checked, using libiio's > iio_readdev and iio_writedev tools, with 64K samples buffers at 61.44 > MSPS (max. theorical throughput: 234 MiB/s): > iio_readdev -b 65536 cf-ad9361-lpc voltage0 voltage1 | pv > /dev/null > pv /dev/zero | iio_writedev -b 65536 cf-ad9361-dds-core-lpc voltage0 > voltage1 There is a bit of a terminology confusion going on here. I think for the mappings you mean cacheable vs non-cacheable but maybe I'm misunderstanding. That doesn't necessarily correspond to coherency. Non cached memory is always coherent because all caches miss. Non-cacheable can be related to coherency of course. Also beware that given hardware might not implement non-cacheable if it knows all possible accesses are IO-coherent. Affect is the same and if implemented correctly it will not hurt performance significantly. firmware should be letting the OS know if the device does coherent DMA or not... dma-coherent in dt. It might be optional for a given piece of DMA engine but I've not seen that.. I'm not sure I see how you can do a mixture of cacheable for reads and write combine (which means uncacheable) for writes... > > Coherent mapping: > - fileio: > read: 125 MiB/s > write:141 MiB/s > - dmabuf: > read: 171 MiB/s > write:210 MiB/s > > Coherent reads + Write-combine writes: > - fileio: > read: 125 MiB/s > write:141 MiB/s > - dmabuf: > read: 171 MiB/s > write:210 MiB/s > > Non-coherent mapping: > - fileio: > read: 119 MiB/s > write:124 MiB/s > - dmabuf: > read: 159 MiB/s > write:124 MiB/s > > Non-coherent reads + write-combine writes: > - fileio: > read: 119 MiB/s > write:140 MiB/s > - dmabuf: > read: 159 MiB/s > write:210 MiB/s > > Non-coherent mapping with no cache sync: > - fileio: > read: 156 MiB/s > write:123 MiB/s > - dmabuf: > read:
Re: [PATCH 04/15] iio: buffer-dma: Enable buffer write support
On Sun, 21 Nov 2021 17:19:32 +
Paul Cercueil wrote:
> Hi Jonathan,
>
> Le dim., nov. 21 2021 at 14:20:49 +, Jonathan Cameron
> a écrit :
> > On Mon, 15 Nov 2021 14:19:14 +
> > Paul Cercueil wrote:
> >
> >> Adding write support to the buffer-dma code is easy - the write()
> >> function basically needs to do the exact same thing as the read()
> >> function: dequeue a block, read or write the data, enqueue the block
> >> when entirely processed.
> >>
> >> Therefore, the iio_buffer_dma_read() and the new
> >> iio_buffer_dma_write()
> >> now both call a function iio_buffer_dma_io(), which will perform
> >> this
> >> task.
> >>
> >> The .space_available() callback can return the exact same value as
> >> the
> >> .data_available() callback for input buffers, since in both cases we
> >> count the exact same thing (the number of bytes in each available
> >> block).
> >>
> >> Signed-off-by: Paul Cercueil
> > Hi Paul,
> >
> > There are a few changes in here, such as the bytes_used value being
> > set that
> > I'm not following the reasoning behind. More info on those?
> > Also good to provide something about those in this patch description.
> >
> > Thanks,
> >
> > Jonathan
> >
> >
> >> ---
> >> drivers/iio/buffer/industrialio-buffer-dma.c | 75
> >> +++-
> >> include/linux/iio/buffer-dma.h | 7 ++
> >> 2 files changed, 66 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c
> >> b/drivers/iio/buffer/industrialio-buffer-dma.c
> >> index abac88f20104..d6b2e0cf 100644
> >> --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> >> +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> >> @@ -179,7 +179,8 @@ static struct iio_dma_buffer_block
> >> *iio_dma_buffer_alloc_block(
> >>}
> >>
> >>block->size = size;
> >> - block->state = IIO_BLOCK_STATE_DEQUEUED;
> >> + block->bytes_used = size;
> >> + block->state = IIO_BLOCK_STATE_DONE;
> >
> > I don't know why these are here - some more info?
>
> When using an input buffer the block->bytes_used is unconditionally
> reset in iio_dmaengine_buffer_submit_block(), so this was fine until
> now.
>
> When using an output buffer the block->bytes_used can actually (with
> the new API) be specified by the user, so we don't want
> iio_dmaengine_buffer_submit_block() to unconditionally override it.
> Which means that in the case where we have an output buffer in fileio
> mode, we do need block->bytes_used to be initialized to the buffer's
> size since it won't be set anywhere else.
Makes sense. Thanks for the explanation.
>
> About the change in block->state: in patch [01/15] we removed the
> incoming/outgoing queues, and while the "enqueued" state is still
> useful to know which buffers have to be submitted when the buffer is
> enabled, the "dequeued" state is not useful anymore since there is no
> more distinction vs. the "done" state.
>
> I believe this change should be moved to patch [01/15] then, and I
> should go further and remove the IIO_BLOCK_STATE_DEQUEUED completely.
Complete removal would indeed be a more 'obvious' change, so I'd support
that assuming now disadvantages we havent' thought of yet.
>
> >>block->queue = queue;
> >>INIT_LIST_HEAD(>head);
> >>kref_init(>kref);
> >> @@ -195,6 +196,18 @@ static void _iio_dma_buffer_block_done(struct
> >> iio_dma_buffer_block *block)
> >>block->state = IIO_BLOCK_STATE_DONE;
> >> }
> >>
> >> +static void iio_dma_buffer_queue_wake(struct iio_dma_buffer_queue
> >> *queue)
> >> +{
> >> + __poll_t flags;
> >> +
> >> + if (queue->buffer.direction == IIO_BUFFER_DIRECTION_IN)
> >> + flags = EPOLLIN | EPOLLRDNORM;
> >> + else
> >> + flags = EPOLLOUT | EPOLLWRNORM;
> >> +
> >> + wake_up_interruptible_poll(>buffer.pollq, flags);
> >> +}
> >> +
> >> /**
> >>* iio_dma_buffer_block_done() - Indicate that a block has been
> >> completed
> >>* @block: The completed block
> >> @@ -212,7 +225,7 @@ void iio_dma_buffer_block_done(struct
> >> iio_dma_buffer_block *block)
> >>spin_unlock_irqrestore(>list_lock, flags);
> >>
> >>iio_buffer_block_put_atomic(block);
> >> - wake_up_interruptible_poll(>buffer.pollq, EPOLLIN |
> >> EPOLLRDNORM);
> >> + iio_dma_buffer_queue_wake(queue);
> >> }
> >> EXPORT_SYMBOL_GPL(iio_dma_buffer_block_done);
> >>
> >> @@ -241,7 +254,7 @@ void iio_dma_buffer_block_list_abort(struct
> >> iio_dma_buffer_queue *queue,
> >>}
> >>spin_unlock_irqrestore(>list_lock, flags);
> >>
> >> - wake_up_interruptible_poll(>buffer.pollq, EPOLLIN |
> >> EPOLLRDNORM);
> >> + iio_dma_buffer_queue_wake(queue);
> >> }
> >> EXPORT_SYMBOL_GPL(iio_dma_buffer_block_list_abort);
> >>
> >> @@ -334,7 +347,8 @@ int iio_dma_buffer_request_update(struct
> >> iio_buffer *buffer)
> >>queue->fileio.blocks[i] = block;
> >>}
> >>
> >> -
Re: [PATCH 03/15] iio: buffer-dma: Use round_down() instead of rounddown()
On Mon, 22 Nov 2021 10:00:19 + Paul Cercueil wrote: > Hi Jonathan, > > Le dim., nov. 21 2021 at 14:08:23 +, Jonathan Cameron > a écrit : > > On Mon, 15 Nov 2021 14:19:13 + > > Paul Cercueil wrote: > > > >> We know that the buffer's alignment will always be a power of two; > >> therefore, we can use the faster round_down() macro. > >> > >> Signed-off-by: Paul Cercueil > > *groan*. I don't want to know where the naming of these two came > > from but that > > is spectacular... > > > > Anyhow, happy to pick up 1-3 now if you like as all are good cleanup > > of > > existing code. > > I think you can pick 2-3 now; I will do some changes to patch [01/15] > in the V2. Applied, 2+3 to the togreg branch of iio.git and pushed out as testing for all the normal reasons. Thanks, Jonathan > > Cheers, > -Paul > >
Re: [PATCH 11/15] iio: buffer-dma: Boost performance using write-combine cache setting
On Sun, 21 Nov 2021 17:43:20 +
Paul Cercueil wrote:
> Hi Jonathan,
>
> Le dim., nov. 21 2021 at 15:00:37 +, Jonathan Cameron
> a écrit :
> > On Mon, 15 Nov 2021 14:19:21 +
> > Paul Cercueil wrote:
> >
> >> We can be certain that the input buffers will only be accessed by
> >> userspace for reading, and output buffers will mostly be accessed by
> >> userspace for writing.
> >
> > Mostly? Perhaps a little more info on why that's not 'only'.
>
> Just like with a framebuffer, it really depends on what the application
> does. Most of the cases it will just read sequentially an input buffer,
> or write sequentially an output buffer. But then you get the exotic
> application that will try to do something like alpha blending, which
> means read+write. Hence "mostly".
Ok. That makes sense though I hope no one actually does it, we can't
prevent them doing so.
>
> >>
> >> Therefore, it makes more sense to use only fully cached input
> >> buffers,
> >> and to use the write-combine cache coherency setting for output
> >> buffers.
> >>
> >> This boosts performance, as the data written to the output buffers
> >> does
> >> not have to be sync'd for coherency. It will halve performance if
> >> the
> >> userspace application tries to read from the output buffer, but this
> >> should never happen.
> >>
> >> Since we don't need to sync the cache when disabling CPU access
> >> either
> >> for input buffers or output buffers, the .end_cpu_access() callback
> >> can
> >> be dropped completely.
> >
> > We have an odd mix of coherent and non coherent DMA in here as you
> > noted,
> > but are you sure this is safe on all platforms?
>
> The mix isn't safe, but using only coherent or only non-coherent should
> be safe, yes.
yup
>
> >
> >>
> >> Signed-off-by: Paul Cercueil
> >
> > Any numbers to support this patch? The mapping types are performance
> > optimisations so nice to know how much of a difference they make.
>
> Output buffers are definitely faster in write-combine mode. On a
> ZedBoard with a AD9361 transceiver set to 66 MSPS, and buffer/size set
> to 8192, I would get about 185 MiB/s before, 197 MiB/s after.
>
> Input buffers... early results are mixed. On ARM32 it does look like it
> is slightly faster to read from *uncached* memory than reading from
> cached memory. The cache sync does take a long time.
>
> Other architectures might have a different result, for instance on MIPS
> invalidating the cache is a very fast operation, so using cached
> buffers would be a huge win in performance.
>
> Setups where the DMA operations are coherent also wouldn't require any
> cache sync and this patch would give a huge win in performance.
>
> I'll run some more tests next week to have some fresh numbers.
Great.
Thanks,
Jonathan
>
> Cheers,
> -Paul
>
> >> ---
> >> drivers/iio/buffer/industrialio-buffer-dma.c | 82
> >> +---
> >> 1 file changed, 54 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c
> >> b/drivers/iio/buffer/industrialio-buffer-dma.c
> >> index 92356ee02f30..fb39054d8c15 100644
> >> --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> >> +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> >> @@ -229,8 +229,33 @@ static int iio_buffer_dma_buf_mmap(struct
> >> dma_buf *dbuf,
> >>if (vma->vm_ops->open)
> >>vma->vm_ops->open(vma);
> >>
> >> - return dma_mmap_pages(dev, vma, vma->vm_end - vma->vm_start,
> >> - virt_to_page(block->vaddr));
> >> + if (block->queue->buffer.direction == IIO_BUFFER_DIRECTION_IN) {
> >> + /*
> >> + * With an input buffer, userspace will only read the data and
> >> + * never write. We can mmap the buffer fully cached.
> >> + */
> >> + return dma_mmap_pages(dev, vma, vma->vm_end - vma->vm_start,
> >> + virt_to_page(block->vaddr));
> >> + } else {
> >> + /*
> >> + * With an output buffer, userspace will only write the data
> >> + * and should rarely (if never) read from it. It is better to
> >> + * use write-combine in this case.
> >> + */
> >> + return dma_mmap_wc(dev, vma, block->vaddr, block->phys_addr,
> >> +vma->vm_end - vma->vm_start);
> >> + }
> >> +}
> >> +
> >> +static void iio_dma_buffer_free_dmamem(struct iio_dma_buffer_block
> >> *block)
> >> +{
> >> + struct device *dev = block->queue->dev;
> >> + size_t size = PAGE_ALIGN(block->size);
> >> +
> >> + if (block->queue->buffer.direction == IIO_BUFFER_DIRECTION_IN)
> >> + dma_free_coherent(dev, size, block->vaddr, block->phys_addr);
> >> + else
> >> + dma_free_wc(dev, size, block->vaddr, block->phys_addr);
> >> }
> >>
> >> static void iio_buffer_dma_buf_release(struct dma_buf *dbuf)
> >> @@ -243,9 +268,7 @@ static void
Re: [PATCH 01/12] dt-bindings: display: rockchip: Add compatible for rk3568 HDMI
Hi, Am Mittwoch, 17. November 2021, 15:33:36 CET schrieb Sascha Hauer: > From: Benjamin Gaignard > > Define a new compatible for rk3568 HDMI. > This version of HDMI hardware block needs two new clocks hclk_vio and hclk > to provide phy reference clocks. > > Signed-off-by: Benjamin Gaignard > Reviewed-by: Rob Herring > Link: > https://lore.kernel.org/r/20210707120323.401785-2-benjamin.gaign...@collabora.com > Signed-off-by: Sascha Hauer > --- > .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > index da3b889ad8fcd..53fa42479d5b7 100644 > --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > @@ -23,6 +23,7 @@ properties: >- rockchip,rk3288-dw-hdmi >- rockchip,rk3328-dw-hdmi >- rockchip,rk3399-dw-hdmi > + - rockchip,rk3568-dw-hdmi > >reg-io-width: > const: 4 > @@ -49,8 +50,11 @@ properties: >- vpll >- enum: >- grf > + - hclk_vio I don't believe this clock should be here: (1) the rk3568 dts node later in the series doesn't use it at all (2) generally vio-clocks are part of the interconnect where the ip block connects to, so right now we just enable it as critical on all socs and if someone actually models the interconnect (where also the qos [quality of service configs] nodes would play into), it would need to be included there. Heiko > + - vpll > + - enum: > + - hclk >- vpll > - - const: vpll > >ddc-i2c-bus: > $ref: /schemas/types.yaml#/definitions/phandle >
[Bug 205089] amdgpu : drm:amdgpu_cs_ioctl : Failed to initialize parser -125
https://bugzilla.kernel.org/show_bug.cgi?id=205089 David Nichols (da...@qore.org) changed: What|Removed |Added CC||da...@qore.org --- Comment #29 from David Nichols (da...@qore.org) --- Also seeing it on Ubuntu 21.10 on aarch64: Kernel: 5.15.0 Mesa: mesa_22.0~git250600 Hardware: GPU: AMD RX 580 (8GB) CPU: 16 Core Arm Cortex A72 SoC: NXP LX2160A (SolidRun HoneyComb system) Running 2 games: flightgear and endless-sky -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 211425] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting
https://bugzilla.kernel.org/show_bug.cgi?id=211425 Andreas (icedragon...@web.de) changed: What|Removed |Added Kernel Version|5.15|5.15.5 Severity|normal |blocking --- Comment #23 from Andreas (icedragon...@web.de) --- I tried a lot different configurations: A) A different cable DP-to-DP instead DP-to-miniDP (both 4k and 60Hz capable): makes no difference B) The issue can still be triggered and it recovers after 2x20 seconds with the error message above until at least 5.15.2! C) Beginning from kernel 5.15.3 it can be still triggered, BUT it did not recover any more until reboot! Also the Error message are changed to: [147325.153678] BUG: workqueue lockup - pool cpus=7 node=0 flags=0x0 nice=-20 stuck for 32s! [147325.153694] Showing busy workqueues and worker pools: [147325.153697] workqueue events: flags=0x0 [147325.153700] pwq 30: cpus=15 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 [147325.153706] in-flight: 127037:dbs_work_handler [147325.153735] workqueue events_highpri: flags=0x10 [147325.153740] pwq 15: cpus=7 node=0 flags=0x0 nice=-20 active=2/256 refcnt=3 [147325.153745] in-flight: 477:dm_irq_work_func [147325.153749] pending: dm_irq_work_func [147325.153851] pool 15: cpus=7 node=0 flags=0x0 nice=-20 hung=32s workers=2 idle: 59 [147325.153856] pool 30: cpus=15 node=0 flags=0x0 nice=0 hung=0s workers=2 idle: 110635 D) from 5.15.4 to 5.15.5 it still occurs and hangs until reboot, BUT in addition I can not find any error message in the kernel log (like above) any more! Also no error message with activated debug symbols! Because the occurring can not be controlled, this makes a stable use of kernel 5.15.3 and newer impossible!!! -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v5 0/6] Cleanups for the nomodeset kernel command line parameter logic
On 11/12/21 14:32, Javier Martinez Canillas wrote: > There is a lot of historical baggage on this parameter. It is defined in > the vgacon driver as nomodeset, but its set function is called text_mode() > and the value queried with a function named vgacon_text_force(). > > All this implies that it's about forcing text mode for VGA, yet it is not > used in neither vgacon nor other console driver. The only users for these > are DRM drivers, that check for the vgacon_text_force() return value to > determine whether the driver should be loaded or not. > > That makes it quite confusing to read the code, because the variables and > function names don't reflect what they actually do and also are not in the > same subsystem as the drivers that make use of them. > > This patch-set attempts to cleanup the code by moving the nomodseset param > to the DRM subsystem and do some renaming to make their intention clearer. > I have pushed these patches to the drm-misc-next branch. Thanks a lot everyone for the help with this series! Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=211277 --- Comment #84 from kolAflash (kolafl...@kolahilft.de) --- @James I was able to compile! Looks like this was some fault of mine. (I'm usually building out of source directory and did something wrong...) Now I'm testing the current v5.10.82 with the provided attachment 299697 patches. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=211277 --- Comment #83 from kolAflash (kolafl...@kolahilft.de) --- Hi James, (In reply to James Zhu from comment #82) > [...] > $ grep -rn "amdgpu_amdkfd.h\|kgd2kfd_resume_iommu" > drivers/gpu/drm/amd/amdkfd/kfd_device.c > 31:#include "amdgpu_amdkfd.h" > 604: kfd->pci_atomic_requested = amdgpu_amdkfd_have_atomics_support(kgd); > 792:if (kgd2kfd_resume_iommu(kfd)) > 940:int kgd2kfd_resume_iommu(struct kfd_dev *kfd) the line numbers you're quoting are for Linux v5.12.19 (0e6f651912bdd027a6d730b68d6d1c3f4427c0ae) + the attachment-299697 patch. > Looks we are using different 5.10, should we use 5.10 stable for adding this > backport patches?. > 754 | if (kgd2kfd_resume_iommu(kfd)) > | ^~~~ > | kgd2kfd_resume_mm I'm testing with Linux v5.10.80 (f884bb85b8d877d4e0c670403754813a7901705b) + the attachment-299697 patch. And there it's line number 754. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] agp: parisc-agp: fix section mismatch warning
Am Samstag, 27. November 2021, 05:57:57 CET schrieb Randy Dunlap: > Fix section mismatch warning in parisc-agp: Too late ;) https://lore.kernel.org/linux-parisc/20211126154754.263487-1-del...@gmx.de/ signature.asc Description: This is a digitally signed message part.
Re: [PATCH] agp: parisc-agp: fix section mismatch warning
On 11/27/21 11:56, Rolf Eike Beer wrote: > Am Samstag, 27. November 2021, 05:57:57 CET schrieb Randy Dunlap: >> Fix section mismatch warning in parisc-agp: Thanks Randy! > Too late ;) > > https://lore.kernel.org/linux-parisc/20211126154754.263487-1-del...@gmx.de/ Being late doesn't matter! I'm really happy about all patches which are sent in for parisc and in the past often I applied the late-sent-in patches instead of mine, simply because the commit message was much better than mine. So, patches are always welcome. Helge
