Cc:
Bcc:
Subject: Xen requirements for GPU virtualization via virtio-GPU
Reply-To:
X-Mutt-Fcc: =INBOX,=xen-devel,=Sent
X-Mutt-PGP: S
Recently, AMD submitted patches to the dri-devel mailing list to support
using application-provided buffers in virtio-GPU. This feature is
called Shared Virtual
> Subject: Re: [syzbot] [mm?] kernel BUG in alloc_hugetlb_folio_reserve
>
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:69e858e0b8b2 Merge tag 'uml-for-linus-6.14-rc1' of git://g..
> git tree: upstream
> console+strace: https://syzkaller.appspot.com/x/log.t
Hi,
2025년 2월 1일 (토) 오전 1:56, Bjorn Helgaas 님이 작성:
>
> I don't know this code at all, so this is likely just noise, but the
> wait_event_timeout() usage in decon_wait_for_vblank() looks funny to
> me.
>
> decon_wait_for_vblank() waits on wait_vsync_queue for wait_vsync_event
> to be cleared.
>
> Bu
Hello!
I'm working on getting a modeset to happen via atomic commit and I've got most
of my code done already but there's one small thing I'm getting hung up on.
In order to display something I need to dedicate a CRTC to a connector, but not
all CRTCs can be used for all connectors. As far as I
syzbot has found a reproducer for the following issue on:
HEAD commit:69e858e0b8b2 Merge tag 'uml-for-linus-6.14-rc1' of git://g..
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1431cb2458
kernel config: https://syzkaller.appspot.com/x/.config?x=d033b14
On 2/1/25 5:52 AM, Danilo Krummrich wrote:
On Fri, Jan 31, 2025 at 08:01:00PM -0800, John Hubbard wrote:
On 1/31/25 2:04 PM, Danilo Krummrich wrote:
...
+/// Enum representation of the GPU generation.
+#[derive(Debug)]
+pub(crate) enum CardType {
+/// Turing
+TU100 = 0x160,
+/// Am
Changes the sharp-ls060t1sx01 panel to use multi style functions for
improved error handling.
Signed-off-by: Tejas Vipin
---
.../gpu/drm/panel/panel-sharp-ls060t1sx01.c | 59 +--
1 file changed, 16 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sharp-
This is a workaround to this issue:
https://gitlab.freedesktop.org/drm/amd/-/issues/3701
Signed-off-by: poscat
---
drivers/gpu/drm/amd/display/dc/dcn31/dcn31_panel_cntl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_panel_cntl.c
Hi Detlev,
On 1/30/25 5:45 PM, Detlev Casanova wrote:
From: Sugar Zhang
Register the dw-hdmi-qp bridge driver as an HDMI audio codec.
The register values computation functions (for n) are based on the
downstream driver, as well as the register writing functions.
The driver uses the generic H
Hi Detlev,
On 1/30/25 5:45 PM, Detlev Casanova wrote:
Use the simple-audio-card driver with the hdmi0 QP node as CODEC and
the i2s5 device as CPU.
The simple-audio-card,mclk-fs value is set to 128 as it is done in
the downstream driver.
The #sound-dai-cells value is set to 0 in the hdmi0 node
In the function "wled_probe", the "wled->name" is dynamically allocated
(wled_probe -> wled_configure -> devm_kasprintf), which is possible
to be null.
In the call trace: wled_probe -> devm_backlight_device_register
-> backlight_device_register, this "name" variable is directly
dereferenced withou
> +cc Kajtar, who has kindly smoke tested this series on real hardware and
> confirmed things are working ostensibly the same as before.
>
> On this basis I will be un-RFC'ing this and, if Kajtar can reply to
> confirm, will add a Tested-by tag to patch 3/3.
No problem, I'm glad I could help. Usi
Fixes: 989863d7cbe5 ("drm/nouveau/pmu: select implementation based on available
firmware")
Signed-off-by: Aaron Kling
---
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
b/drivers
[Resend to make the automation happy ... thanks for the hint.]
On 2025-01-29 10:51, Hans Verkuil wrote:
> Jens (aka Farblos), can you test this patch?
TL;DR: Your patch fixes the issue on my system, thanks.
Tested-by: Farblos
Details:
### build #13 - stock 6.12.10 kernel
[~]$ uname -a
Linu
On Mon, Jan 13, 2025 at 11:15:48PM +, Lorenzo Stoakes wrote:
> With the introduction of mapping_wrprotect_page() there is no need to use
> folio_mkclean() in order to write-protect mappings of frame buffer pages,
> and therefore no need to inappropriately set kernel-allocated page->index,
> map
On Wed, Jan 29, 2025 at 05:07:52PM +0200, Andy Shevchenko wrote:
> On Tue, Jan 28, 2025 at 06:43:26PM +0200, Andy Shevchenko wrote:
> > On Tue, Jan 28, 2025 at 05:08:08PM +0100, Marek Szyprowski wrote:
> > > On 21.01.2025 14:29, Andy Shevchenko wrote:
> > > > On Tue, Jan 21, 2025 at 08:33:09AM +010
(This time sent in reply to the correct series...)
On Fri, Jan 31, 2025 at 06:28:58PM +, Lorenzo Stoakes wrote:
> With the introduction of mapping_wrprotect_page() there is no need to use
> folio_mkclean() in order to write-protect mappings of frame buffer pages,
> and therefore no need to ina
Andrew - Ugh sorry - please disregard the below, I sent it to the wrong
thread. It's Saturday and I'm tired and brain not working :>)
Let me resend this against the correct non-RFC thread!
On Sat, Feb 01, 2025 at 05:01:15PM +, Lorenzo Stoakes wrote:
> On Mon, Jan 13, 2025 at 11:15:48PM +,
Simplify zap_shader_load_mdt() by using of_get_available_child_by_name().
Signed-off-by: Biju Das
---
This patch is only compile tested and depend upon[1]
[1]
https://lore.kernel.org/all/20250201093126.7322-1-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++--
1 fi
On Sat, Feb 01, 2025 at 01:12:35PM +0100, Danilo Krummrich wrote:
> On Sat, Feb 01, 2025 at 09:33:28AM +0100, Greg KH wrote:
> > On Fri, Jan 31, 2025 at 11:04:24PM +0100, Danilo Krummrich wrote:
> > > +impl Gpu {
> > > +pub(crate) fn new(pdev: &pci::Device, bar: Devres) ->
> > > Result> {
> >
Hello,
I was exploring the Linux kernel code and came across the following
functions marked with //TODO in mmhub_v3_0_2.c:
static void mmhub_v3_0_2_update_medium_grain_clock_gating(struct
amdgpu_device *adev, bool enable) { //TODO }
static void mmhub_v3_0_2_update_medium_grain_light_sleep(struct
On Fri, Jan 31, 2025 at 08:01:00PM -0800, John Hubbard wrote:
> On 1/31/25 2:04 PM, Danilo Krummrich wrote:
> > Add the initial nova-core driver stub.
> >
> > nova-core is intended to serve as a common base for nova-drm (the
> > corresponding DRM driver) and the vGPU manager VFIO driver, serving a
Since the initial commit 57692c94dcbe ("drm/v3d: Introduce a new DRM driver
for Broadcom V3D V3.x+") the struct v3d_dev reserved a pointer for
an optional V3D clock. But there wasn't any code, which fetched it.
So add the missing clock handling before accessing any V3D registers.
Signed-off-by: St
On Sat, Feb 01, 2025 at 09:33:28AM +0100, Greg KH wrote:
> On Fri, Jan 31, 2025 at 11:04:24PM +0100, Danilo Krummrich wrote:
> > +impl Gpu {
> > +pub(crate) fn new(pdev: &pci::Device, bar: Devres) ->
> > Result> {
> > +let spec = GpuSpec::new(&bar)?;
> > +let fw = Firmware::new
On Sat, Feb 01, 2025 at 09:14:48AM +0100, Karol Herbst wrote:
> On Fri, Jan 31, 2025 at 11:04 PM Danilo Krummrich wrote:
> > +impl pci::Driver for NovaCore {
> > +type IdInfo = ();
> > +const ID_TABLE: pci::IdTable = &PCI_TABLE;
> > +
> > +fn probe(pdev: &mut pci::Device, _info: &Self:
Simplify tegra_dc_rgb_probe() by using of_get_available_child_by_name().
Signed-off-by: Biju Das
---
This patch is only compile tested and depend upon[1]
[1]
https://lore.kernel.org/all/20250201093126.7322-1-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/tegra/rgb.c | 6 +++---
1 file changed,
Hi!
> > I now got my feet a little wet with hid-bpf regarding something else, and
> > with that knowledge I would leave the long arrays in the beginning in the
> > kernel code for the time being:
> >
> > sirius_16_ansii_kbl_mapping and sirius_16_iso_kbl_mapping are required
> > during initializat
On Fri, Jan 31, 2025 at 11:04:24PM +0100, Danilo Krummrich wrote:
> +impl Gpu {
> +pub(crate) fn new(pdev: &pci::Device, bar: Devres) -> Result PinInit> {
> +let spec = GpuSpec::new(&bar)?;
> +let fw = Firmware::new(pdev.as_ref(), &spec, "535.113.01")?;
> +
> +dev_info!(
On Fri, Jan 31, 2025 at 11:04 PM Danilo Krummrich wrote:
>
> Add the initial nova-core driver stub.
>
> nova-core is intended to serve as a common base for nova-drm (the
> corresponding DRM driver) and the vGPU manager VFIO driver, serving as a
> hard- and firmware abstraction layer for GSP-based
On Sat, Feb 1, 2025 at 9:14 AM Karol Herbst wrote:
>
> On Fri, Jan 31, 2025 at 11:04 PM Danilo Krummrich wrote:
> >
> > Add the initial nova-core driver stub.
> >
> > nova-core is intended to serve as a common base for nova-drm (the
> > corresponding DRM driver) and the vGPU manager VFIO driver,
30 matches
Mail list logo
