On Tue, Jun 11, 2024 at 02:40:37PM +0530, Vignesh Raman wrote:
> Add job that runs igt on top of vkms.
>
> Acked-by: Maíra Canal
> Acked-by: Helen Koike
> Signed-off-by: Vignesh Raman
> Acked-by: Jessica Zhang
> Tested-by: Jessica Zhang
> Acked-by: Maxime Ripard
> Signed-off-by: Helen Koike
…
> +++ b/drivers/net/ethernet/intel/hbl_cn/common/hbl_cn.c
> @@ -0,0 +1,5954 @@
…
> +int hbl_cn_read_spmu_counters(struct hbl_cn_port *cn_port, u64 out_data[],
> u32 *num_out_data)
> +{
…
> + mutex_lock(&cn_port->cnt_lock);
> + rc = port_funcs->spmu_sample(cn_port, *num_out_data, out_data
://gitlab.freedesktop.org/drm/xe/kernel.git drm-xe-next
patch link:
https://lore.kernel.org/r/20240614102548.4364-9-thomas.hellstrom%40linux.intel.com
patch subject: [PATCH v4 08/12] drm/ttm: Add a virtual base class for graphics
memory backup
config: x86_64-randconfig-161-20240617
(https://download
On Wed, Jun 12, 2024 at 09:52:40AM -0700, Doug Anderson wrote:
> Sima,
>
> On Wed, Jun 12, 2024 at 8:13 AM Daniel Vetter wrote:
> >
> > > > I ran the coccinelle script we started with, and here are the results:
> > > >
> > > > ./drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:1640:25-39: ERROR: KMS driver
>
Hi Dmitry,
Thanks for reviewing the patches!
On 17/06/24 17:29, Dmitry Baryshkov wrote:
> On Mon, Jun 17, 2024 at 04:23:03PM GMT, Aradhya Bhatia wrote:
>> Update the Phy initialized state to "not initialized" when the driver
>> (and the hardware by extension) gets suspended. This will allow the P
On 6/13/24 02:35, Mina Almasry wrote:
Convert netmem to be a union of struct page and struct netmem. Overload
the LSB of struct netmem* to indicate that it's a net_iov, otherwise
it's a page.
Currently these entries in struct page are rented by the page_pool and
used exclusively by the net stack
On Wed, Jun 12, 2024 at 09:00:29AM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, Jun 12, 2024 at 8:11 AM Daniel Vetter wrote:
> >
> > > The problem is that the ordering is wrong, I think. Even if the OS was
> > > calling driver shutdown functions in the perfect order (which I'm not
> > > convince
On Thu, Jun 13, 2024 at 11:22:04AM +0300, Omer Shpigelman wrote:
> Add an RDMA driver of Gaudi ASICs family for AI scaling.
> The driver itself is agnostic to the ASIC in action, it operates according
> to the capabilities that were passed on device initialization.
> The device is initialized by th
On Mon, Jun 17, 2024 at 07:55:10AM -0500, Lucas De Marchi wrote:
> On Sun, Jun 16, 2024 at 09:03:48AM GMT, Andi Shyti wrote:
> > Commit 05da7d9f717b ("drm/i915/gem: Downgrade stolen lmem setup
> > warning") returns '0' from i915_gem_stolen_lmem_setup(), but it's
> > supposed to return a pointer to
On Wed, Jun 12, 2024 at 10:22:49AM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, Jun 12, 2024 at 9:47 AM Linus Walleij
> wrote:
> >
> > On Wed, Jun 12, 2024 at 5:11 PM Daniel Vetter wrote:
> > > On Wed, Jun 12, 2024 at 07:49:31AM -0700, Doug Anderson wrote:
> > (...)
> > > > The problem is that
On Wed, Jun 12, 2024 at 11:47:05PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Export drm_plane_has_format() so that drivers can use it.
>
> Reviewed-by: Jani Nikula
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_crtc_internal.h | 2 --
> drivers/gpu/drm/drm_plane.c
Hi
Am 17.06.24 um 16:04 schrieb Daniel Vetter:
On Thu, Jun 13, 2024 at 12:18:55PM +0200, Thomas Zimmermann wrote:
Hi
Am 13.06.24 um 12:14 schrieb Thomas Zimmermann:
Hi
Am 12.06.24 um 17:00 schrieb Daniel Vetter:
On Wed, Jun 12, 2024 at 10:37:14AM +0200, Thomas Zimmermann wrote:
Hi Javier
在 2024-06-17星期一的 15:59 +0200，Christian König写道：
> Am 17.06.24 um 15:43 schrieb Icenowy Zheng:
> > 在 2024-06-17星期一的 15:09 +0200，Christian König写道：
> > > Am 17.06.24 um 15:03 schrieb Icenowy Zheng:
> > > > 在 2024-06-17星期一的 14:35 +0200，Christian König写道：
> > > > > Am 17.06.24 um 12:58 schrieb Icenowy
On Thu, Jun 13, 2024 at 12:17:00AM -0500, Mario Limonciello wrote:
> If the lid on a laptop is closed when eDP connectors are populated
> then it remains enabled when the initial framebuffer configuration
> is built.
>
> When creating the initial framebuffer configuration detect the
> lid status a
On Thu, Jun 13, 2024 at 02:42:02PM -0700, Vivek Kasireddy wrote:
> Currently, some drivers (e.g, Udmabuf) that want to longterm-pin
> the pages/folios associated with a memfd, do so by simply taking a
> reference on them. This is not desirable because the pages/folios
> may reside in Movable zone o
Am 17.06.24 um 16:30 schrieb Icenowy Zheng:
在 2024-06-17星期一的 15:59 +0200，Christian König写道：
Am 17.06.24 um 15:43 schrieb Icenowy Zheng:
在 2024-06-17星期一的 15:09 +0200，Christian König写道：
Am 17.06.24 um 15:03 schrieb Icenowy Zheng:
在 2024-06-17星期一的 14:35 +0200，Christian König写道：
Am 17.06.24 um 1
On 6/13/24 02:35, Mina Almasry wrote:
Implement a memory provider that allocates dmabuf devmem in the form of
net_iov.
The provider receives a reference to the struct netdev_dmabuf_binding
via the pool->mp_priv pointer. The driver needs to set this pointer for
the provider in the net_iov.
The p
On 6/17/24 03:47, Tomi Valkeinen wrote:
> Hi Sean,
>
> On 03/05/2024 22:29, Sean Anderson wrote:
>> This series cleans up the zyqnmp_dp IRQ and locking situation. Once
>> that's done, it adds debugfs support. The intent is to enable compliance
>> testing or to help debug signal-integrity issues.
>
在 2024-06-17星期一的 16:42 +0200，Christian König写道：
> Am 17.06.24 um 16:30 schrieb Icenowy Zheng:
> > 在 2024-06-17星期一的 15:59 +0200，Christian König写道：
> > > Am 17.06.24 um 15:43 schrieb Icenowy Zheng:
> > > > 在 2024-06-17星期一的 15:09 +0200，Christian König写道：
> > > > > Am 17.06.24 um 15:03 schrieb Icenowy
On Wed, Jun 12, 2024 at 6:37 PM Douglas Anderson wrote:
>
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
> won't be cleanly powered of
On Mon, Jun 17, 2024 at 04:05:57PM +0200, Markus Elfring wrote:
> …
> > +++ b/drivers/net/ethernet/intel/hbl_cn/common/hbl_cn.c
> > @@ -0,0 +1,5954 @@
> …
> > +int hbl_cn_read_spmu_counters(struct hbl_cn_port *cn_port, u64 out_data[],
> > u32 *num_out_data)
> > +{
> …
> > + mutex_lock(&cn_port->
On Mon, Jun 17, 2024 at 01:52:58PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Attempt to use kvmalloc to avoid kmalloc warnings on larger allocations.
>
> It might make sense to try and make a limit for the number of objects allowed
> here.
>
> [ cut here ]
> WAR
Am 17.06.24 um 16:57 schrieb Icenowy Zheng:
在 2024-06-17星期一的 16:42 +0200，Christian König写道：
Am 17.06.24 um 16:30 schrieb Icenowy Zheng:
在 2024-06-17星期一的 15:59 +0200，Christian König写道：
Am 17.06.24 um 15:43 schrieb Icenowy Zheng:
在 2024-06-17星期一的 15:09 +0200，Christian König写道：
...
In this cas
On 4/17/24 07:40, Dave Airlie wrote:
From: Dave Airlie
I'm pretty sure this optimisation is actually not a great idea,
and is racy with other things waiting for fences.
Yes, I tried to use it in the past on scheduler tear down, to have an
indicator whether all jobs had the chance to finish.
On 23/05/2024 6:52 pm, Rob Clark wrote:
From: Rob Clark
Add an io-pgtable method to walk the pgtable returning the raw PTEs that
would be traversed for a given iova access.
Have to say I'm a little torn here - with my iommu-dma hat on I'm not
super enthusiastic about adding any more overhead
On Mon, Jun 17, 2024 at 01:41:59PM +, Hoosier, Matt wrote:
> Hi,
>
> There is a discussion ongoing over in the compositor world about the
> implication of this cautionary wording found in the documentation for the
> DRM_MODE_CONNECTOR_WRITEBACK connectors:
>
> > * "WRITEBACK_OUT_FENCE_PTR
On 6/14/24 18:08, Christophe JAILLET wrote:
"struct nouveau_job_ops" is not modified in these drivers.
Constifying this structure moves some data to a read-only section, so
increase overall security.
In order to do it, "struct nouveau_job" and "struct nouveau_job_args" also
need to be adjusted
On Mon, Jun 17, 2024 at 07:57:47PM +0530, Shiva Kiran K wrote:
> Remove unnecessary parentheses in `if` statements.
> Reported by checkpatch.pl
As per the many times this came up in the past (see the mailing list
archives), checkpatch is wrong here.
sorry,
greg k-h
Only export struct fb_info.fix.smem_start if that is required by the
user and the memory does not come from vmalloc().
Setting struct fb_info.fix.smem_start breaks systems where DMA
memory is backed by vmalloc address space. An example error is
shown below.
[3.536043] [ cut here ]
On Mon, Jun 17, 2024 at 04:22:11PM GMT, Andi Shyti wrote:
On Mon, Jun 17, 2024 at 07:55:10AM -0500, Lucas De Marchi wrote:
On Sun, Jun 16, 2024 at 09:03:48AM GMT, Andi Shyti wrote:
> Commit 05da7d9f717b ("drm/i915/gem: Downgrade stolen lmem setup
> warning") returns '0' from i915_gem_stolen_lmem
Am 17.06.24 um 17:35 schrieb Xi Ruoyao:
On Mon, 2024-06-17 at 22:30 +0800, Icenowy Zheng wrote:
Two consecutive writes to the same bus address are perfectly legal
from
the PCIe specification and can happen all the time, even without this
specific hw workaround.
Yes I know it, and I am not from
On 6/17/24 11:33, Dan Carpenter wrote:
Use kmemdup_array() because we're allocating an array.
The main difference between kmemdup() and kmemdup_array() is that the
kmemdup_array() function has integer overflow checking built it. The
"args->in_sync.count" variable is a u32 so integer overflows w
Prepare to factorize probe function.
Signed-off-by: Marc Gonzalez
---
drivers/gpu/drm/bridge/simple-bridge.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
b/drivers/gpu/drm/bridge/simple-bridge.c
index 5813a2c4fc5
The TI TDP158 is an AC-Coupled HDMI signal to TMDS Redriver supporting
DVI 1.0 and HDMI 1.4b and 2.0b output signals.
Signed-off-by: Marc Gonzalez
---
drivers/gpu/drm/bridge/simple-bridge.c | 64 --
1 file changed, 61 insertions(+), 3 deletions(-)
diff --git a/dr
-bridge.yaml | 4 +
drivers/gpu/drm/bridge/simple-bridge.c | 85 +-
2 files changed, 71 insertions(+), 18 deletions(-)
---
base-commit: 17b591a4a192a8a11faad30520b8f6a9137ac514
change-id: 20240617-tdp158-418200d6cc0b
Best regards,
--
Marc Gonzalez
Once probe uses only devm functions, remove() becomes unnecessary.
Signed-off-by: Marc Gonzalez
---
drivers/gpu/drm/bridge/simple-bridge.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
b/drivers/gpu/drm/bridge/simple-brid
In default mode, this device works transparently.
Signed-off-by: Marc Gonzalez
---
Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml | 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
b/Documentation/dev
在 2024-06-17星期一的 15:59 +0200，Christian König写道：
> Am 17.06.24 um 15:43 schrieb Icenowy Zheng:
> > 在 2024-06-17星期一的 15:09 +0200，Christian König写道：
> > > Am 17.06.24 um 15:03 schrieb Icenowy Zheng:
> > > > 在 2024-06-17星期一的 14:35 +0200，Christian König写道：
> > > > > Am 17.06.24 um 12:58 schrieb Icenowy
On Mon, Jun 17, 2024 at 06:02:59PM +0200, Marc Gonzalez wrote:
> In default mode, this device works transparently.
Please explain what makes this device incompatible with the existing
ones. For example, why not make the new compatible fall back to
ti,ths8134?
>
> Signed-off-by: Marc Gonzalez
>
Hi Dominique,
Am Montag, dem 17.06.2024 um 15:16 +0900 schrieb Dominique MARTINET:
> Adam Ford wrote on Sat, Feb 03, 2024 at 10:52:50AM -0600:
> > From: Lucas Stach
> >
> > Add a simple wrapper driver for the DWC HDMI bridge driver that
> > implements the few bits that are necessary to abstract
On 6/13/24 02:35, Mina Almasry wrote:
In tcp_recvmsg_locked(), detect if the skb being received by the user
is a devmem skb. In this case - if the user provided the MSG_SOCK_DEVMEM
flag - pass it to tcp_recvmsg_devmem() for custom handling.
tcp_recvmsg_devmem() copies any data in the skb header
On Mon, Jun 17, 2024 at 10:21:10AM +0200, Philipp Stanner wrote:
> On Fri, 2024-06-14 at 11:14 -0500, Bjorn Helgaas wrote:
> > On Fri, Jun 14, 2024 at 10:09:46AM +0200, Philipp Stanner wrote:
> ...
> > > Apparently INTx is "old IRQ management" and should be done through
> > > pci_alloc_irq_vectors
Hi,
On Mon, Jun 17, 2024 at 05:16:36PM +0200, Daniel Vetter wrote:
>On Mon, Jun 17, 2024 at 01:41:59PM +, Hoosier, Matt wrote:
>> Hi,
>>
>> There is a discussion ongoing over in the compositor world about the
>> implication of this cautionary wording found in the documentation for the
>> DRM
Hi Lucas,
Do you have any idea on how not to break userspace if we expose a render node?
Cheers,
Tomeu
On Wed, Jun 12, 2024 at 4:26 PM Tomeu Vizoso wrote:
>
> On Mon, May 20, 2024 at 1:19 PM Daniel Stone wrote:
> >
> > Hi,
> >
> > On Mon, 20 May 2024 at 08:39, Tomeu Vizoso wrote:
> > > On Fr
On 6/15/2024 5:35 AM, Konrad Dybcio wrote:
On 14.06.2024 12:33 PM, Dmitry Baryshkov wrote:
On Fri, Jun 14, 2024 at 01:55:46AM GMT, Konrad Dybcio wrote:
[...]
GCC_HDMI_CLKREF_CLK is a child of xo, so you can drop the latter.
It would also be worth confirming whether it's really powering th
On Fri, Jun 14, 2024 at 03:02:09AM +1000, Ben Skeggs wrote:
> NVIDIA has been exploring ways to better support the effort for an
> upstream kernel mode driver for GPUs that are capable of running GSP-RM
> firmware, since the introduction[1] to Nova.
>
> Use cases have been identified for which sep
Hi Thomas,
On Fri, Apr 19, 2024 at 10:34 AM Thomas Zimmermann wrote:
> Implement fbdev emulation with fbdev-dma. Fbdev-dma now supports
> damage handling, which is required by rcar-du. Avoids the overhead of
> fbdev-generic's additional shadow buffering. No functional changes.
>
> Signed-off-by:
>> >> >> There is a discussion ongoing over in the compositor world about the
>> >> >> implication
>> Hi,
>>
>> On Mon, Jun 17, 2024 at 05:16:36PM +0200, Daniel Vetter wrote:
>> >On Mon, Jun 17, 2024 at 01:41:59PM +, Hoosier, Matt wrote:
>> >> Hi,
>> >>
>> >> There is a discussion ongoing ove
Hi Thomas,
On Mon, 17 Jun 2024, Thomas Zimmermann wrote:
Only export struct fb_info.fix.smem_start if that is required by the
user and the memory does not come from vmalloc().
Setting struct fb_info.fix.smem_start breaks systems where DMA
memory is backed by vmalloc address space. An ex
On 6/13/24 02:35, Mina Almasry wrote:
Abstrace the memory type from the page_pool so we can later add support
for new memory types. Convert the page_pool to use the new netmem type
abstraction, rather than use struct page directly.
As of this patch the netmem type is a no-op abstraction: it's al
On 6/11/24 07:34, Christoph Hellwig wrote:
On Fri, Jun 07, 2024 at 02:45:55PM +0100, Pavel Begunkov wrote:
On 6/5/24 09:24, Christoph Hellwig wrote:
On Mon, Jun 03, 2024 at 03:52:32PM +0100, Pavel Begunkov wrote:
The question for Christoph is what exactly is the objection here? Why we
would no
On Mon, 17 Jun 2024 14:55:22 +0300, Dmitry Baryshkov wrote:
> On Mon, Jun 17, 2024 at 01:23:48PM GMT, Jean Delvare wrote:
> > Hi Dmitry,
> >
> > Thanks for your feedback.
> >
> > On Mon, 17 Jun 2024 12:57:19 +0300, Dmitry Baryshkov wrote:
> > > On Mon, Jun 17, 2024 at 10:30:30AM GMT, Jean Delva
Hi
On 6/17/2024 9:54 AM, Brian Starkey wrote:
Hi,
On Mon, Jun 17, 2024 at 05:16:36PM +0200, Daniel Vetter wrote:
On Mon, Jun 17, 2024 at 01:41:59PM +, Hoosier, Matt wrote:
Hi,
There is a discussion ongoing over in the compositor world about the
implication of this cautionary wording fou
Hi all,
Today's linux-next merge of the drm tree got conflicts in:
drivers/gpu/drm/xe/xe_gt_idle.c
drivers/gpu/drm/xe/xe_guc_pc.c
between commits:
2470b141bfae2 ("drm/xe: move disable_c6 call")
7c877115da419 ("drm/xe/xe_gt_idle: use GT forcewake domain assertion")
from the drm-intel-fi
On Mon, Jun 17, 2024 at 10:46:07AM -0500, Lucas De Marchi wrote:
> On Mon, Jun 17, 2024 at 04:22:11PM GMT, Andi Shyti wrote:
> > On Mon, Jun 17, 2024 at 07:55:10AM -0500, Lucas De Marchi wrote:
> > > On Sun, Jun 16, 2024 at 09:03:48AM GMT, Andi Shyti wrote:
> > > > Commit 05da7d9f717b ("drm/i915/ge
On 17/6/24 23:55, Daniel Vetter wrote:
On Fri, Jun 14, 2024 at 03:02:09AM +1000, Ben Skeggs wrote:
NVIDIA has been exploring ways to better support the effort for an
upstream kernel mode driver for GPUs that are capable of running GSP-RM
firmware, since the introduction[1] to Nova.
Use cases h
Hi Jonathan,
Commit 05da7d9f717b ("drm/i915/gem: Downgrade stolen lmem setup
warning") produces two sparse warnings. The first one being a bit
more sever as it might cause a segmentation fault.
The difference between v1 and v2 is that the patch should return
a NULL, which won't cause any issues.
Commit 05da7d9f717b ("drm/i915/gem: Downgrade stolen lmem setup
warning") returns '0' from i915_gem_stolen_lmem_setup(), but it's
supposed to return a pointer to the intel_memory_region
structure.
Sparse complains with the following message:
>> drivers/gpu/drm/i915/gem/i915_gem_stolen.c:943:32: s
Commit 05da7d9f717b ("drm/i915/gem: Downgrade stolen lmem setup
warning") adds a debug message where the "lmem_size" and
"dsm_base" variables are printed using the %lli identifier.
However, these variables are defined as resource_size_t, which
are unsigned long for 32-bit machines and unsigned lon
> -Original Message-
> From: Tomi Valkeinen
> Sent: Monday, June 17, 2024 12:44 AM
> To: Klymenko, Anatoliy ; Laurent Pinchart
> ; Maarten Lankhorst
> ; Maxime Ripard
> ; Thomas Zimmermann ;
> David Airlie ; Daniel Vetter ;
> Simek, Michal
> Cc: dri-devel@lists.freedesktop.org; linux-ar
Le mercredi 12 juin 2024 à 23:25 +0300, Laurent Pinchart a écrit :
> On Wed, Jun 12, 2024 at 03:43:58PM -0400, Nicolas Dufresne wrote:
> > Le mercredi 12 juin 2024 à 13:37 +0900, Tomasz Figa a écrit :
> > > > Why is this flag needed ? Given that the usage model requires the V4L2
> > > > device to b
On Mon, Jun 17, 2024 at 05:43:49PM +, Omer Shpigelman wrote:
> On 6/13/24 22:18, Leon Romanovsky wrote:
> > [Some people who received this message don't often get email from
> > l...@kernel.org. Learn why this is important at
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On Thu
On 6/10/24 23:15, Jason Gunthorpe wrote:
On Mon, Jun 10, 2024 at 08:20:08PM +0100, Pavel Begunkov wrote:
On 6/10/24 16:16, David Ahern wrote:
There is no reason you shouldn't be able to use your fast io_uring
completion and lifecycle flow with DMABUF backed memory. Those are not
widly differe
On 18/6/24 03:30, Danilo Krummrich wrote:
On Fri, Jun 14, 2024 at 03:02:09AM +1000, Ben Skeggs wrote:
NVIDIA has been exploring ways to better support the effort for an
upstream kernel mode driver for GPUs that are capable of running GSP-RM
firmware, since the introduction[1] to Nova.
Use case
On Wed, Jun 12, 2024 at 02:12:39PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-intel tree, today's linux-next build (i386
> defconfig) failed like this:
>
> x86_64-linux-gnu-ld: drivers/gpu/drm/i915/display/intel_vrr.o: in function
> `intel_vrr_compute_config':
> intel_vrr
On Mon, 17 Jun 2024 at 17:16, Aradhya Bhatia wrote:
>
> Hi Dmitry,
>
> Thanks for reviewing the patches!
>
> On 17/06/24 17:29, Dmitry Baryshkov wrote:
> > On Mon, Jun 17, 2024 at 04:23:03PM GMT, Aradhya Bhatia wrote:
> >> Update the Phy initialized state to "not initialized" when the driver
> >>
On Mon, Jun 17, 2024 at 06:02:59PM GMT, Marc Gonzalez wrote:
> In default mode, this device works transparently.
>
> Signed-off-by: Marc Gonzalez
> ---
> Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml | 4
> 1 file changed, 4 insertions(+)
>
> diff --git
> a/Documenta
On Mon, Jun 17, 2024 at 05:36:34PM GMT, Hoosier, Matt wrote:
> >> >> >> There is a discussion ongoing over in the compositor world about the
> >> >> >> implication
> >> Hi,
> >>
> >> On Mon, Jun 17, 2024 at 05:16:36PM +0200, Daniel Vetter wrote:
> >> >On Mon, Jun 17, 2024 at 01:41:59PM +, Hoo
On Mon, Jun 17, 2024 at 11:28:35AM GMT, Abhinav Kumar wrote:
> Hi
>
> On 6/17/2024 9:54 AM, Brian Starkey wrote:
> > Hi,
> >
> > On Mon, Jun 17, 2024 at 05:16:36PM +0200, Daniel Vetter wrote:
> > > On Mon, Jun 17, 2024 at 01:41:59PM +, Hoosier, Matt wrote:
> > > > Hi,
> > > >
> > > > There i
On Mon, Jun 17, 2024 at 06:03:00PM GMT, Marc Gonzalez wrote:
> Prepare to factorize probe function.
what and why?
The patch itself LGTM
>
> Signed-off-by: Marc Gonzalez
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
On Fri, Jun 14, 2024 at 4:47 AM wrote:
>
> From: Carsten Haitzler
>
> In a few places (core drm + AMD kfd driver), the ioctl handling uses a
> temporary 128 byte buffer on the stack to copy to/from user. ioctl data
> can have structs with types of much larger sizes than a byte and a
> system may
Hi,
On Sat, Jun 15, 2024 at 2:40 AM Tejas Vipin wrote:
>
> @@ -168,48 +147,38 @@ static int rm692e5_prepare(struct drm_panel *panel)
> struct rm692e5_panel *ctx = to_rm692e5_panel(panel);
> struct drm_dsc_picture_parameter_set pps;
> struct device *dev = &ctx->dsi->dev;
>
https://bugzilla.kernel.org/show_bug.cgi?id=211807
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
Panfrost DRM driver uses devfreq to perform DVFS, while using simple_ondemand
devfreq governor by default. This causes driver initialization to fail on
boot when simple_ondemand governor isn't built into the kernel statically,
as a result of the missing module dependency and, consequently, the req
Lima DRM driver uses devfreq to perform DVFS, while using simple_ondemand
devfreq governor by default. This causes driver initialization to fail on
boot when simple_ondemand governor isn't built into the kernel statically,
as a result of the missing module dependency and, consequently, the require
Am Samstag, 15. Juni 2024, 19:03:53 CEST schrieb Jonas Karlman:
> Similar to DCLK_LCDC on RK3328, the DCLK_VOP on RK3228 is typically
> parented by the hdmiphy clk and it is expected that the DCLK_VOP and
> hdmiphy clk rate are kept in sync.
>
> Use CLK_SET_RATE_PARENT and CLK_SET_RATE_NO_REPARENT
On 6/17/24 2:04 AM, Borislav Petkov wrote:
On Sat, Jun 15, 2024 at 06:25:11PM -0700, Alexey Makhalov wrote:
0-DAY CI Kernel Test automation reported an issue:
ld: drivers/base/regmap/regmap-spi.o: in function `regmap_spi_read':
regmap-spi.c:(.text+0xf): undefined reference to `spi_wr
On 6/17/24 2:07 AM, Borislav Petkov wrote:
On Sat, Jun 15, 2024 at 06:25:10PM -0700, Alexey Makhalov wrote:
VMWARE_HYPERCALL alternative will not work as intended without
VMware guest code initialization.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/20240615
On 2024-06-17 22:50, Jonas Karlman wrote:
On 2024-06-17 22:30, Heiko Stübner wrote:
Am Samstag, 15. Juni 2024, 19:03:53 CEST schrieb Jonas Karlman:
Similar to DCLK_LCDC on RK3328, the DCLK_VOP on RK3228 is typically
parented by the hdmiphy clk and it is expected that the DCLK_VOP and
hdmiphy cl
On Mon, Jun 17, 2024 at 01:48:38PM -0700, Alexey Makhalov wrote:
> > Don't get discouraged, though, when fixing something that is not in our
> > immediate area of interest!
> >
> > :-)
>
> Lesson learned and noted for next time to address only related/new warnings
> and errors. Thanks!
I actually
Hi Heiko,
On 2024-06-17 22:30, Heiko Stübner wrote:
> Am Samstag, 15. Juni 2024, 19:03:53 CEST schrieb Jonas Karlman:
>> Similar to DCLK_LCDC on RK3328, the DCLK_VOP on RK3228 is typically
>> parented by the hdmiphy clk and it is expected that the DCLK_VOP and
>> hdmiphy clk rate are kept in sync.
On Mon, Jun 17, 2024 at 01:51:23PM -0700, Alexey Makhalov wrote:
> Not really a gcc related, but the matter of a config file. It is
> reproducible if CONFIG_HYPERVISOR_GUEST not set, but CONFIG_DRM_VMWGFX=y.
> And this combination was allowed before the fix.
Using their config:
$ grep -E "(CONFIG
Haha, got it!
On Mon, Jun 17, 2024 at 2:02 PM Borislav Petkov wrote:
> On Mon, Jun 17, 2024 at 01:48:38PM -0700, Alexey Makhalov wrote:
> > > Don't get discouraged, though, when fixing something that is not in our
> > > immediate area of interest!
> > >
> > > :-)
> >
> > Lesson learned and noted
On Mon, Jun 17, 2024 at 08:18:14PM GMT, Jean Delvare wrote:
> On Mon, 17 Jun 2024 14:55:22 +0300, Dmitry Baryshkov wrote:
> > On Mon, Jun 17, 2024 at 01:23:48PM GMT, Jean Delvare wrote:
> > > Hi Dmitry,
> > >
> > > Thanks for your feedback.
> > >
> > > On Mon, 17 Jun 2024 12:57:19 +0300, Dmitry B
On Mon, Jun 17, 2024 at 06:03:01PM GMT, Marc Gonzalez wrote:
> Once probe uses only devm functions, remove() becomes unnecessary.
Breves vibrantesque sententiae
With the hope of getting an expanded commit message:
Reviewed-by: Dmitry Baryshkov
>
> Signed-off-by: Marc Gonzalez
> ---
> drive
From: Rob Clark
Split the single flat gpulist table into per-gen tables that exist in
their own per-gen files, and start moving more info into the device
table. This at least gets all the big tables of register settings out
of the heart of the a6xx_gpu code. Probably more could be moved, to
rem
From: Rob Clark
Split into a separate table per generation, in preparation to move each
gen's device table to it's own file.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 67 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 10
2 files change
On Mon, Jun 17, 2024 at 08:38:20PM GMT, Andi Shyti wrote:
On Mon, Jun 17, 2024 at 10:46:07AM -0500, Lucas De Marchi wrote:
On Mon, Jun 17, 2024 at 04:22:11PM GMT, Andi Shyti wrote:
> On Mon, Jun 17, 2024 at 07:55:10AM -0500, Lucas De Marchi wrote:
> > On Sun, Jun 16, 2024 at 09:03:48AM GMT, Andi
From: Rob Clark
Split each gen's gpu table into it's own file. Only code-motion, no
functional change.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 5 +
drivers/gpu/drm/msm/adreno/a2xx_catalog.c | 52 ++
drivers/gpu/drm/msm/adreno/a3xx_catalog.c | 81 +++
dr
From: Rob Clark
Move the hwcg tables into the hw catalog.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 619 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 617 -
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 -
3 files chang
From: Rob Clark
Introduce a6xx_info where we can stash gen specific stuff without
polluting the toplevel adreno_info struct.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 65 +--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +--
drivers/gpu/drm/
From: Rob Clark
Move the CP_PROTECT settings into the hw catalog.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 247 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 257 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +
drive
On Mon, Jun 17, 2024 at 06:03:02PM GMT, Marc Gonzalez wrote:
> The TI TDP158 is an AC-Coupled HDMI signal to TMDS Redriver supporting
> DVI 1.0 and HDMI 1.4b and 2.0b output signals.
>
> Signed-off-by: Marc Gonzalez
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 64
> +
On 6/17/24 2:17 PM, Borislav Petkov wrote:
On Mon, Jun 17, 2024 at 01:51:23PM -0700, Alexey Makhalov wrote:
Not really a gcc related, but the matter of a config file. It is
reproducible if CONFIG_HYPERVISOR_GUEST not set, but CONFIG_DRM_VMWGFX=y.
And this combination was allowed before the fi
From: Rob Clark
Split the single flat gpulist table into per-gen tables that exist in
their own per-gen files, and start moving more info into the device
table. This at least gets all the big tables of register settings out
of the heart of the a6xx_gpu code. Probably more could be moved, to
rem
From: Rob Clark
Split into a separate table per generation, in preparation to move each
gen's device table to it's own file.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 67 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 10
2 files change
From: Rob Clark
Split each gen's gpu table into it's own file. Only code-motion, no
functional change.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 5 +
drivers/gpu/drm/msm/adreno/a2xx_catalog.c | 52 ++
drivers/gpu/drm/msm/adreno/a3xx_catalog.c | 81 +++
dr
From: Rob Clark
Move the hwcg tables into the hw catalog.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 619 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 617 -
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 -
3 files chang
From: Rob Clark
Introduce a6xx_info where we can stash gen specific stuff without
polluting the toplevel adreno_info struct.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 65 +--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +--
drivers/gpu/drm/
From: Rob Clark
Move the CP_PROTECT settings into the hw catalog.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 247 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 257 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +
drive
101 - 200 of 228 matches
Mail list logo
