…
> kmemdup_array() function has integer overflow checking built it. …
built-in?
Regards,
Markus
I see the problem that initramfs need to build a module dependency chain,
but lima does not call any symbol from simpleondemand governor module.
softdep module seems to be optional while our dependency is hard one,
can we just add MODULE_INFO(depends, _depends), or create a new
macro called
er_probe(amifb_driver, amifb_probe);
+MODULE_DESCRIPTION("Amiga builtin chipset frame buffer driver");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:amiga-video");
---
base-commit: 6ba59ff4227927d3a8530fc2973b80e94b54d58f
change-id: 20240617-md-m68k-drivers-video-fbdev-amifb-3f65d4a6ed79
dy,
u32 width,
}
EXPORT_SYMBOL_GPL(c2p_planar);
+MODULE_DESCRIPTION("Fast C2P (Chunky-to-Planar) Conversion");
MODULE_LICENSE("GPL");
---
base-commit: 6ba59ff4227927d3a8530fc2973b80e94b54d58f
change-id: 20240617-md-m68k-drivers-video-fbdev-c2p_planar-51300ac55802
amdgpu can handle async flips on overlay planes, so mark it as true
during the plane initialization.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Replace the generic "is this plane primary" for a plane::async_flip
check, so DRM follows the plane restrictions set by the driver.
Signed-off-by: André Almeida
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
This driver can perfom async flips on primary planes, so enable it.
Signed-off-by: André Almeida
---
drivers/gpu/drm/vc4/vc4_plane.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index
This driver can perfom async flips on primary planes, so enable it.
Signed-off-by: André Almeida
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
This driver can perfom async flips on primary planes, so enable it.
Signed-off-by: André Almeida
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 3 +++
drivers/gpu/drm/i915/display/skl_universal_plane.c | 1 +
2 files changed, 4 insertions(+)
diff --git
This driver can perfom async flips on primary planes, so enable it.
Signed-off-by: André Almeida
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
Drivers have different capabilities on what plane types they can or
cannot perform async flips. Create a plane::async_flip field so each
driver can choose which planes they allow doing async flips.
Signed-off-by: André Almeida
---
include/drm/drm_plane.h | 5 +
1 file changed, 5
This driver can perfom async flips on primary planes, so enable it.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
Allow userspace to use explicit synchronization with atomic async flips.
That means that the flip will wait for some hardware fence, and then
will flip as soon as possible (async) in regard of the vblank.
Signed-off-by: André Almeida
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++-
1 file
AMD hardware can do async flips with overlay planes, but currently there's no
easy way to enable that in DRM. To solve that, this patchset creates a new
drm_plane field, bool async_flip, that allows drivers to choose which plane can
or cannot do async flips. This is latter used on
Hi,
On Mon, Jun 17, 2024 at 3:26 PM Dmitry Baryshkov
wrote:
>
> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, Jun 17, 2024 at 10:46:13PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Jun 17, 2024 at 09:46:29AM +0200, Roger Pau Monné wrote:
> > On Sun, Jun 16, 2024 at 08:38:19PM -0400, Demi Marie Obenour wrote:
> > > In both cases, the device
Dominique MARTINET wrote on Tue, Jun 18, 2024 at 08:45:38AM +0900:
> I'm thinking the last few values just affect a very small % of the
> values, but would need to check with a proper scope if I can get a hold
> of the clock line...
> Does any of you happen to have any datasheet for these
On Fri, 7 Jun 2024 23:00:04 +1200
Ryan Walklin wrote:
Hi Ryan,
> The DE33 is a newer version of the Allwinner Display Engine IP block,
> found in the H616, H618, H700 and T507 SoCs. DE2 and DE3 are already
> supported by the mainline driver.
>
> Notable features (from the H616 datasheet and
Thanks for the replies, replying to both mails at once.
Adam Ford wrote on Mon, Jun 17, 2024 at 08:28:58AM -0500:
> > Commit 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY") already
> > "fixed" the samsung hdmi phy driver to return the next frequency if an
> > exact match hasn't been found
On Mon, Jun 17, 2024 at 03:51:13PM GMT, Rob Clark wrote:
> 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
On Mon, Jun 17, 2024 at 03:51:12PM GMT, Rob Clark wrote:
> 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 +
>
On Mon, Jun 17, 2024 at 03:51:11PM GMT, Rob Clark wrote:
> 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
On Mon, Jun 17, 2024 at 03:28:59PM GMT, Rob Clark wrote:
> 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
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 +
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 +--
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
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 +++
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
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
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
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
>
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 +
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 +--
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
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 +++
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,
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
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
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
> ---
>
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
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
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
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
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
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
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:
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
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=211807
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
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 = >dsi->dev;
> -
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
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 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
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 +,
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
>
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 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':
>
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
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
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
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
> -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;
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
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:
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.
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
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
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
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
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
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
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
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
>> >> >> 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
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:
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
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
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
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
>>
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
> > >
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
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 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
>
在 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
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
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
-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
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
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
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
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 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
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 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
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 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:
>
> > *
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
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.
1 - 100 of 229 matches
Mail list logo
