f time, before removing it entirely? I don't see any documentation
on the deprecation process, but I've seen it done in other cases. If you
grep through all the kernel Kconfig files, you'll see entries tagged with
DEPRECATED. Also the driver should be updated to out
Hi Uwe
On Tue, Sep 09, 2025 at 03:49:22PM +0200, Uwe Kleine-König wrote:
On Fri, Aug 01, 2025 at 08:32:20AM +0200, Uwe Kleine-König wrote:
On Thu, Jul 31, 2025 at 10:47:18AM +0200, Michael Grzeschik wrote:
> diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_b
From: Michael Kelley Sent: Thursday, September 4, 2025 10:36 PM
>
> From: Thomas Zimmermann Sent: Thursday, September 4,
> 2025 7:56 AM
> >
> > Compositors often depend on vblanks to limit their display-update
> > rate. Without, they see vblank events ASAP, which
earlier testing. I'll keep running this
test kernel for a while to see if anything anomalous occurs.
For Patches 1, 2, and 4 of the series on a Hyper-V guest,
Tested-by: Michael Kelley
[4]
https://lore.kernel.org/dri-devel/20250523161522.409504-1-mhkli...@outlook.com/T/#m2e288dddaf7b3c025bb
From: Mukesh R Sent: Wednesday, September 3, 2025
7:17 PM
>
> On 9/2/25 07:42, Michael Kelley wrote:
> > From: Mukesh Rathor Sent: Wednesday, August
> > 27, 2025 6:00 PM
> >>
> >> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
&g
e development. The
Hyper-V VMBus frame buffer device functionality is what it is, and
isn't likely to be getting enhancements.
I suggest that we assume it's not necessary to add a "disable"
function, and proceed with Thomas' proposed changes to the Hyper-V
DRM driver. Adding "disable" now risks breaking something due
to effects we're unaware of. If in the future the need arises to mark
the device not active, the "disable" function can be added after
a clarifying conversation with the Hyper-V team.
If anyone at Microsoft wants to chime in, please do so. :-)
Michael
Hi,
On Fri Aug 29, 2025 at 12:52 AM CEST, Doug Anderson wrote:
> > On Thu, Aug 21, 2025 at 5:23 AM Michael Walle wrote:
> > >
> > > The bridge has three bootstrap pins which are sampled to determine the
> > > frequency of the external reference clock. The driver
From: Mukesh Rathor Sent: Wednesday, August 27,
2025 6:00 PM
Same comment about patch "Subject:" prefix.
> CONFIG_HYPERV is an umbrella config option involved in enabling hyperv
s/hyperv/Hyper-V/
> support and build of modules like hyperv-balloon, hyperv-vmbus, etc..
With CONFIG_HYPERV and C
From: Mukesh Rathor Sent: Wednesday, August 27,
2025 6:00 PM
>
Even though this patch touches multiple subdirectories under "drivers",
I'd suggest the patch "Subject:" prefix should be "Drivers: hv:" (not
"hyper-v:")
to be consistent with historical usage.
> Somehow vmbus driver is hinged on
_HYPERV_VMBUS
a default value, such as whatever CONFIG_HYPERV is set to. But
I'm not sure how to fix the first issue, except by continuing to
allow CONFIG_HYPERV=m.
See additional minor comments in Patches 1 and 2.
Michael
>
> For now, hv_common.c is left as is to reduce conflicts
On Wed, Aug 27, 2025 at 04:51:37PM +0300, Dmitry Osipenko wrote:
> On 8/27/25 16:33, Michael S. Tsirkin wrote:
> > On Wed, Aug 27, 2025 at 03:52:05PM +0300, Dmitry Osipenko wrote:
> >> On 8/27/25 11:12, Honglei Huang wrote:
> >>> From: Honglei Huang
> >&
ion,
> > + VIRTIO_GPU_SHM_ID_HOST_VISIBLE)) {
> > if (!devm_request_mem_region(&vgdev->vdev->dev,
> > vgdev->host_visible_region.addr,
> > vgdev->host_visible
. Waiting 20us after
asserting the EN line resolves this issue.
Signed-off-by: Michael Walle
Reviewed-by: Douglas Anderson
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti
gt; have directly checked VP type in dispc but since the structure is defined
> in tidss_oldi.c , we have to add additional member to tidss_device
> structure.
>
> [0]:
> https://lore.kernel.org/all/20250528122544.817829-1-aradhya.bha...@linux.dev/
> [1]: https://lore.kern
Hi,
On Thu Aug 14, 2025 at 11:18 AM CEST, Stephan Gerhold wrote:
> Michael had a somewhat related problem in the PVR driver recently [1],
> where of_clk_set_defaults() needs to be called a second time from the PVR
> driver (after the GPU has been powered on) to make the assigned-cl
create a short flicker if the
backlight was already preinitialised.
We fix the flicker by moving the pwm_apply after the default duty_cycle
can be calculated.
Signed-off-by: Michael Grzeschik
---
drivers/video/backlight/pwm_bl.c | 16 +---
1 file changed, 9 insertions(+), 7
adhya.bha...@linux.dev/
[1]: https://lore.kernel.org/all/da6tt575z82d.3mpk8hg5gr...@kernel.org/
For this series:
Tested-by: Michael Walle # on am67a
-michael
fine with changing it to the wrapper struct. It's your/the
maintainers call :)
-michael
> In the long term it may be that more and more components of the DRM
> subsystem become dynamically allocated like bridges and panels [0] have
> recently become. So at some point
Hi Andrew,
On Wed Jul 16, 2025 at 6:17 PM CEST, Andrew Davis wrote:
> On 7/16/25 8:47 AM, Michael Walle wrote:
> > The AM62P and the J722S features the same BXS-4 GPU as the J721S2. Add a
> > new SoC specific compatible.
> >
>
> If the GPU is the same, and the inte
On Thu, Jul 17, 2025 at 10:41:59AM +0800, jiang.pe...@zte.com.cn wrote:
> From: Peng Jiang
>
> Fix kernel-doc descriptions in virtio_dma_buf.c to fix W=1 warnings:
>
> drivers/virtio/virtio_dma_buf.c:41 function parameter 'dma_buf' not described
> in 'virtio_dma_buf_attach'
> drivers/virtio/vir
On Sat, Jul 05, 2025 at 10:58:03AM +0800, jiang.pe...@zte.com.cn wrote:
> From: Peng Jiang
>
> Fix kernel-doc descriptions in virtio_dma_buf.c to fix W=1 warnings:
>
> drivers/virtio/virtio_dma_buf.c:41 function parameter 'dma_buf' not described
> in 'virtio_dma_buf_attach'
> drivers/virtio/vir
The J722S features a BXS-4 GPU. Add the node for it.
Signed-off-by: Michael Walle
---
.../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am62p
The J722S won't let you set the clock frequency if there is no device
using it. Thus, the assigned-clocks property won't work per se.
As a workaround, set the clock again during the probing of the driver.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/imagination/pvr_de
The AM62P and the J722S features the same BXS-4 GPU as the J721S2. Add a
new SoC specific compatible.
Signed-off-by: Michael Walle
---
Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpu/img
limitation, set the clock again in the .probe() of the GPU driver
after turning the device on.
This was tested on an AM67A.
Michael Walle (3):
dt-bindings: gpu: img: Add AM62P SoC specific compatible
drm/imagination: fix clock control on the J722S
arm64: dts: ti: add GPU node
.../devicet
ned-off-by: Michael Walle
---
drivers/gpu/drm/tidss/tidss_encoder.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c
b/drivers/gpu/drm/tidss/tidss_encoder.c
index 95b4aeff2775..81a04f767770 100644
--- a/drivers/gpu/drm/tidss/tidss
clk based on the HW capabilities" [1].
That is, it was working with v3 of your DSI patch series, but not
with v4. I'll need this patch together with v4 to get DSI working.
Maybe that helps,
-michael
[1]
https://lore.kernel.org/all/20250402-cdns-dsi-impro-v2-3-4a093eaa5...@ideasonboard.com/
signature.asc
Description: PGP signature
ual
> >> to the values in "ti_sn_bridge_dsiclk_lut" (supported frequencies), and
> >> you would fallback to "001" register value.
> >
> >> Rest of time, I guess it depends on reading the status from GPIO and
> >> changing the register.
> >
> > Not "rest of the time", the reading of the strapping option from the
> > GPIO always happens if an external refclk is detected. It's part of
> > the chip after all. It will just sometimes be overwritten by the
> > linux driver.
> >
> >> Is the latter one your usecase?
> >
> > My use case is that the GPIO setting is wrong on my board (it's really
> > non-existent) and I'm relying on the linux driver to set the correct
> > frequency.
> >
> > HTH,
> > -michael
signature.asc
Description: PGP signature
From: Michael Kelley Sent: Thursday, June 5, 2025 10:39 AM
>
> From: Thomas Zimmermann Sent: Thursday, June 5, 2025
> 8:36 AM
> >
> > Hi
> >
> > Am 04.06.25 um 23:43 schrieb Michael Kelley:
> > [...]
> > > Nonetheless, there's an underlyi
ase?
My use case is that the GPIO setting is wrong on my board (it's really
non-existent) and I'm relying on the linux driver to set the correct
frequency.
HTH,
-michael
From: Thomas Zimmermann Sent: Thursday, June 5, 2025 8:36
AM
>
> Hi
>
> Am 04.06.25 um 23:43 schrieb Michael Kelley:
> [...]
> > Nonetheless, there's an underlying issue. A main cause of the difference
> > is the number of messages to Hyper-V to update dirty r
From: Michael Kelley Sent: Tuesday, June 3, 2025 10:25 AM
>
> From: David Hildenbrand Sent: Tuesday, June 3, 2025 12:55
> AM
> >
> > On 03.06.25 03:49, Michael Kelley wrote:
> > > From: David Hildenbrand Sent: Monday, June 2, 2025
> > > 2:48 AM
>
From: Simona Vetter Sent: Wednesday, June 4, 2025 7:46
AM
>
> On Wed, Jun 04, 2025 at 10:12:45AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 03.06.25 um 19:50 schrieb Michael Kelley:
> > > From: Thomas Zimmermann Sent: Monday, June 2, 2025
> > &
From: Thomas Zimmermann Sent: Monday, June 2, 2025 11:25
PM
>
> Hi
>
> Am 03.06.25 um 03:49 schrieb Michael Kelley:
> [...]
> >> Will the VMA have VM_PFNMAP or VM_MIXEDMAP set? PFN_SPECIAL is a
> >> horrible hack.
> >>
> >> In another thread,
From: David Hildenbrand Sent: Tuesday, June 3, 2025 12:55 AM
>
> On 03.06.25 03:49, Michael Kelley wrote:
> > From: David Hildenbrand Sent: Monday, June 2, 2025 2:48
> > AM
> >>
> >> On 23.05.25 18:15, mhkelle...@gmail.com wrote:
> >>> From: Mich
From: David Hildenbrand Sent: Monday, June 2, 2025 2:48 AM
>
> On 23.05.25 18:15, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > Current defio code works only for framebuffer memory that is allocated
> > with vmalloc(). The code assumes that the under
On Mon, Jun 02, 2025 at 08:40:20PM +0200, Michael Klein wrote:
On Mon, Jun 02, 2025 at 11:55:44AM +0200, Maxime Ripard wrote:
On Mon, May 26, 2025 at 11:13:01PM +0200, Michael wrote:
On Mon, May 26, 2025 at 07:30:35PM +0200, Maxime Ripard wrote:
On Mon, May 12, 2025 at 10:27:06PM +0200
On Mon, Jun 02, 2025 at 11:55:44AM +0200, Maxime Ripard wrote:
On Mon, May 26, 2025 at 11:13:01PM +0200, Michael wrote:
On Mon, May 26, 2025 at 07:30:35PM +0200, Maxime Ripard wrote:
> On Mon, May 12, 2025 at 10:27:06PM +0200, Michael wrote:
> > with v6.9 and later there is no outp
vm_mixed_ok(). But this may be dubious usage, and should not
be a blocker to your elimination of pfn_t. I'll either add
vmf_insert_special_mkwrite() or figure out an equivalent. Anyone
with suggestions in that direction would be appreciated as I'm
not an mm expert.
Michael
[1]
https://lore.kernel.org/linux-hyperv/20250523161522.409504-1-mhkli...@outlook.com/
; For all these reasons, add support for the OLDI TXes as DRM bridges.
>
> Signed-off-by: Aradhya Bhatia
> Signed-off-by: Aradhya Bhatia
Tested-by: Michael Walle # on am67a
(with local patches from downstream for DSS support)
Thanks,
-michael
signature.asc
Description: PGP signature
ck.
FWIW, I'm seeing exactly 300MHz on the AM67A (the FCLK is 2.1GHz
according
to k3conf).
-michael
Aradhya, Devarsh, do you remember how the clocking goes here? Or if
it's
in the TRM, please point me to it...
I think what you described is correct, if any specific questions I
. Waiting 20us after
asserting the EN line resolves this issue.
Signed-off-by: Michael Walle
---
I couldn't find a good commit for a Fixes: tag and I'm not sure how
fixes are handled in drm.
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 11 +++
1 file changed, 11 insertions(+)
di
h (or I just didn't find it yet).
So, if the soc.dtsi has them already connected, then the
board.dts/panel.dtso would still need to explicitly delete those
properties to get the 2 OLDI TXes to work independently.
Yeah looks like that should really be a board property.
-michael
tcrtc->hw_videoport,
> +adjusted_mode->clock * 1000);
> + if (rate < 0)
> + return -EINVAL;
> +
> + adjusted_mode->clock = rate / 1000;
While after this statement, adjusted_mod
port@0 {
> +reg = <0>;
> +oldi0_in: endpoint {
> + remote-endpoint = <&dpi0_out0>;
> +};
> +
Hi Aradhya,
On Mon May 26, 2025 at 4:17 PM CEST, Aradhya Bhatia wrote:
> Thank you for reviewing and testing the patches! =)
Thank you for your dedication to bring this feature upstream :)
> On 26/05/25 15:05, Michael Walle wrote:
> >
> >> +static int get_oldi_mode(struct
Hi,
On Mon, May 26, 2025 at 07:30:35PM +0200, Maxime Ripard wrote:
On Mon, May 12, 2025 at 10:27:06PM +0200, Michael wrote:
with v6.9 and later there is no output on the BananaPI HDMI connector.
I have bisected the issue to the following commit:
358e76fd613a ("drm/sun4i: hdmi: Consol
On Mon, May 12, 2025 at 10:27:07PM +0200, Michael wrote:
with v6.9 and later there is no output on the BananaPI HDMI connector.
I have bisected the issue to the following commit:
358e76fd613a ("drm/sun4i: hdmi: Consolidate atomic_check and mode_valid")
With
link is reported as "OLDI_MODE_SINGLE_LINK".
I'll dig deeper into this tomorrow.
-michael
> +
> + if (of_property_read_u32(companion, "reg", &companion_reg))
> + return OLDI_MODE_UNSUPPORTED;
> +
> + if (companion_reg >
The panel lacked the connector type which causes a warning. Adding the
connector type reveals wrong bus_flags and bits per pixel. Fix all of
it.
Fixes: 1319f2178bdf ("drm/panel-simple: add Evervision VGG644804 panel entry")
Signed-off-by: Michael Walle
---
drivers/gpu/drm/panel/pane
horizontal
timings are only for one half of the panel.
[1]
https://www.fortec-integrated.de/fileadmin/pdf/produkte/TFT-Displays/AUO/P238HAN01.0_Datasheet.pdf
Signed-off-by: Michael Walle
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff
Add AUO P238HAN01 23.8" 1920x1080 LVDS panel compatible string.
Signed-off-by: Michael Walle
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.ya
On Tue, May 13, 2025 at 12:18:44PM +0200, Gerd Hoffmann wrote:
> > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > b/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > index e32e680c7197..71c6ccad4b99 100644
> > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > +++ b/drivers/gpu/drm/virtio/virt
; For all these reasons, add support for the OLDI TXes as DRM bridges.
>
> Reviewed-by: Tomi Valkeinen
> Tested-by: Alexander Sverdlin
> Signed-off-by: Aradhya Bhatia
> Signed-off-by: Aradhya Bhatia
Tested-by: Michael Walle # on a j722s/am67a
FWIW, I have a few downstream patches
th clock=0, causing the function to return MODE_NOCLOCK.
In the old sun4i_hdmi_mode_valid() before the patch, mode->clock is
always!=0, maybe that gives someone a hint.
--
Michael
On Tue, Apr 22, 2025 at 06:49:04PM +0200, Eric Auger wrote:
> Hi Gerd, Michael,
>
> On 4/16/25 3:57 PM, Gerd Hoffmann wrote:
> > On Tue, Apr 15, 2025 at 10:00:48AM -0400, Michael S. Tsirkin wrote:
> >> On Tue, Apr 15, 2025 at 01:16:32PM +0200, Gerd Hoffmann wrote:
> >
ce from trying to use that
MMIO space and failing. It's a hack but probably better than
leaving things as they currently are.
The problem can currently happen only on x86/x64 VMs,
but will probably be possible on arm64 VMs as well at some
point in the future.
Any input is appreciated. Thanks.
Michael
[1]
https://lore.kernel.org/linux-hyperv/20231009211845.3136536-9-a...@kernel.org/
On Tue, Apr 15, 2025 at 01:16:32PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > +static void virtio_gpu_shutdown(struct virtio_device *vdev)
> > +{
> > + /*
> > +* drm does its own synchronization on shutdown.
> > +* Do nothing here, opt out of device reset.
> > +*/
>
> I think a call
From: Christoph Hellwig Sent: Thursday, April 10, 2025 12:42 AM
>
> On Wed, Apr 09, 2025 at 02:10:26PM +, Michael Kelley wrote:
> > Hmmm. What's the reference to "as told last time"? I don't think I've had
> > this conversation before.
>
>
ce_shutdown()")
Cc: Eric Auger
Cc: Jocelyn Falempe
Signed-off-by: Michael S. Tsirkin
---
changes from v1 RFC:
tested by Eric
fixed up commit log and comments as suggested by Jocelyn
drivers/gpu/drm/virtio/virtgpu_drv.c | 9 +
drivers/virtio/virtio.c | 6 ++
includ
On Thu, Apr 10, 2025 at 02:51:47PM +0200, Jocelyn Falempe wrote:
> > > So it looks like the shutdown is called in the middle of console drawing,
> > > so
> > > either wait for it to finish, or let drm handle the shutdown, like your
> > > patch does.
The cleanest approach is actually just fixing s
On Thu, Apr 10, 2025 at 02:33:26PM +0200, Jocelyn Falempe wrote:
> On 10/04/2025 09:16, Michael S. Tsirkin wrote:
> > It looks like GPUs are used by panic after shutdown is invoked.
> > Thus, breaking virtio gpu in the shutdown callback is not a good idea -
> > guest hangs at
ing buffers, it looks like
GPU can just have a NOP there.
Fixes: 8bd2fa086a04 ("virtio: break and reset virtio devices on
device_shutdown()")
Cc: Eric Auger
Signed-off-by: Michael S. Tsirkin
---
Can someone who knows more about DRM and shutdown please tell me if this
is a good i
From: Christoph Hellwig Sent: Wednesday, April 9, 2025 3:50 AM
>
> On Tue, Apr 08, 2025 at 11:36:44AM -0700, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > Export vmf_insert_mixed_mkwrite() for use by fbdev deferred I/O code,
>
> But they are usi
Move to using the new API devm_drm_panel_alloc() to allocate the
panel.
Signed-off-by: Anusha Srivatsa
Reviewed-by: Michael Walle
-michael
From: Helge Deller Sent: Saturday, March 8, 2025 6:59 PM
>
> On 2/19/25 00:01, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
[snip]
> >
> > Reported-by: Thomas Tai
> > Fixes: c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen
o_cleanup(info);
>
> - unregister_framebuffer(info);
> cancel_delayed_work_sync(&par->dwork);
>
> vmbus_close(hdev->channel);
> hv_set_drvdata(hdev, NULL);
> -
> - hvfb_putmem(info);
> - framebuffer_release(info);
> }
>
> static int hvfb_suspend(struct hv_device *hdev)
> --
> 2.43.0
Reviewed-by: Michael Kelley
Tested-by: Michael Kelley
> vmbus_close(hdev->channel);
> error1:
> @@ -1226,7 +1226,7 @@ static void hvfb_remove(struct hv_device *hdev)
> vmbus_close(hdev->channel);
> hv_set_drvdata(hdev, NULL);
>
> - hvfb_putmem(hdev, info);
> + hvfb_putmem(info);
> framebuffer_release(info);
> }
>
> --
> 2.43.0
Reviewed-by: Michael Kelley
Tested-by: Michael Kelley
From: Vivek Kasireddy
We need to determine if the client is new enough to support multiple
codecs -- which might include any of the Gstreamer based ones.
v2: (suggestions and fixups from Frediano)
- Add is_gl_client() method to DisplayChannelClient instead of a
dcc_is_gl_client() function.
- A
add dmabuf encoding if `drm/drm_fourcc.h` is present and
gstreamer is at least 1.24 due to
`gst_video_dma_drm_fourcc_to_format()`.
Signed-off-by: Michael Scherle
---
meson.build| 10 +-
server/gstreamer-encoder.c | 34 +++---
2 files changed
Oh I made a mistake and send this to the wrong mailing list, I'm
so sorry, I wanted to send it to the spice devel.
On 27.02.25 12:03, Michael Scherle wrote:
> This merge request is based on Vivek Kasireddy's
> [PATCH v8 0/6] dcc: Create a stream for non-gl/remote clients th
From: Vivek Kasireddy
For remote (or non-gl) clients, if a valid gl_draw stream exists,
then we first extract the dmabuf fd associated with the scanout and
share it with the encoder along with other key parameters such as
stride, width and height. Once the encoder finishes creating an
encoded buf
This brings in the following changes:
common: Add a udev helper to identify GPU Vendor
build: Avoid Meson warning
Drop Python 2 from m4/spice-deps.m4
Stop using Python six package
codegen: Use context manager when opening files
Signed-off-by: Michael Scherle
Prevent a freeze that occurs if the video stream is stopped while a
gl draw is in progress (e.g., when the client requests a new codec).
Ensure proper cleanup of the ongoing gl draw.
Signed-off-by: Michael Scherle
---
server/dcc-send.cpp | 4
1 file changed, 4 insertions(+)
diff --git a
From: Vivek Kasireddy
Once it is determined that an Intel GPU is available/active (after
looking into udev's database), we try to see if there is a h/w
based encoder (element) available (in Gstreamer's registry cache)
for the user selected video codec. In other words, if we find that
the Intel Me
ver/display-channel.cpp:2074:display_channel_create_surface:
condition `!display->priv->surfaces[surface_id]' failed
Rebase all patches on master
v2:
Update all patches to address review comments from Frediano
Tested this series with msdkh264enc/dec plugins that will be added
in anothe
From: Vivek Kasireddy
This patch adds a new function to enable the creation of Gst memory with
the dmabuf fd as the source by using a dmabuf allocator. And, it also
adds a mechanism to register and invoke any callbacks once the Gst memory
object is no longer used by the pipeline.
This patch also
From: Vivek Kasireddy
For non-gl/remote clients, if there is no stream associated with
the DisplayChannel, then we create a new stream. Otherwise, we
just update the current stream's timestamp.
v2: (suggestions and fixups from Frediano)
- Moved the gl_draw_stream object from DCC to DC
- Moved th
From: Vivek Kasireddy
We need to convert the scanout's drm format to the correct Gstreamer
format while configuring the pipeline. This can be done using
gst_video_dma_drm_fourcc_to_format() API, which will take the drm
fourcc value and return the appropriate Gst format.
Signed-off-by: Vivek Kasi
From: Vivek Kasireddy
We do not want to stop a stream associated with gl_draw as a result
of timeout because we may not get another opportunity to create a
new stream if the current one gets stopped. However, when the
stream does get stopped for other reasons, we need to clear the
gl_draw_stream
nly to get the device pointer,
which is already stored in info->device. hvfb_release_phymem()
would also need to be updated to take a struct device instead of
struct hv_device. But if you made those changes, then the
container_of() to get the hdev wouldn't be needed either.
A similar simplificat
From: Saurabh Singh Sengar Sent: Monday, February
24, 2025 5:30 AM
>
> On Mon, Feb 24, 2025 at 12:38:22AM +, Michael Kelley wrote:
> > From: Saurabh Singh Sengar Sent: Sunday,
> > February 23, 2025 6:10 AM
> > >
> > > On Sat, Feb 22, 2025 at 08
From: Saurabh Singh Sengar Sent: Sunday, February
23, 2025 6:10 AM
>
> On Sat, Feb 22, 2025 at 08:16:53PM +, Michael Kelley wrote:
> > From: Saurabh Singh Sengar Sent: Saturday,
> > February 22, 2025 9:27 AM
> > >
[anip]
> > >
> > > I
From: Saurabh Singh Sengar Sent: Saturday,
February 22, 2025 9:27 AM
>
> On Wed, Feb 19, 2025 at 05:22:36AM +, Michael Kelley wrote:
> > From: Saurabh Sengar Sent: Saturday, February
> > 15,
> 2025 1:21 AM
> > >
> > > When a Hyper-V framebuffer devi
ry_SYSCALL_64_after_hwframe+0x76/0x7e
For all three cases, I think the memory freeing and iounmap() operations
can be moved to the new hvfb_destroy() function so that the memory
is cleaned up only when there aren't any users. While these additional
changes could be done as a separate patch, it see
From: Michael Kelley Sent: Monday, February 10, 2025
1:36 PM
>
> From: thomas@oracle.com Sent: Monday, February
> 10, 2025 7:08 AM
> >
> >
> >
> > >> Then the question is why the efifb driver doesn't work in the kdump
> > >> ker
On Thu, Feb 13, 2025 at 04:49:14PM +0100, Sergio Lopez wrote:
> There's an incresing number of machines supporting multiple page sizes
> and, on these machines, the host and a guest can be running with
> different pages sizes.
>
> In addition to this, there might be devices that have a required an
From: Saurabh Singh Sengar Sent: Wednesday,
February 12, 2025 7:07 PM
>
> On Thu, Feb 13, 2025 at 01:35:22AM +, Michael Kelley wrote:
> > From: Saurabh Singh Sengar Sent: Monday,
> > February 10, 2025 8:52 AM
> > >
> > [snip]
> > > > > >
r,
> > > but maybe you are doing something different.
> > >
> > > FWIW, there is yet another issue where after doing two unbind/bind
> > > cycles of the hyperv_fb driver, there's an error about freeing a
> > > non-existent resource. I know what that
From: Maxim Levitsky Sent: Monday, February 10, 2025 3:57
PM
>
> On Mon, 2025-02-10 at 21:35 +, Michael Kelley wrote:
> > From: thomas@oracle.com Sent: Monday, February
> > 10, 2025 7:08 AM
> > >
> > >
> > > > > Then the questio
From: Thomas Zimmermann Sent: Monday, February 10, 2025
11:35 PM
>
> Hi
>
> Am 10.02.25 um 20:34 schrieb mhkelle...@gmail.com:
> > From: Michael Kelley
> >
> > When a Hyper-V DRM device is probed, the driver allocates MMIO space for
> > the vram, and maps
From: Saurabh Singh Sengar Sent: Monday, February
10, 2025 8:52 AM
>
> On Mon, Feb 10, 2025 at 06:58:25AM -0800, Saurabh Singh Sengar wrote:
> > On Mon, Feb 10, 2025 at 02:28:35PM +0000, Michael Kelley wrote:
> > > From: Saurabh Singh Sengar Sent: Monday,
> >
From: Saurabh Singh Sengar Sent: Monday, February
10, 2025 7:33 PM
>
> On Mon, Feb 10, 2025 at 11:34:41AM -0800, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > When a Hyper-V DRM device is probed, the driver allocates MMIO space for
> > the vram,
ent, I modified the kdumpctl shell
> > script to add the "-c" option to kexec, but in that case the value "0x0"
> > is passed as the framebuffer address, which is wrong. Furthermore,
> > the " screen_info.orig_video_isVGA" value (which I mentioned earlier
From: Saurabh Singh Sengar Sent: Monday, February
10, 2025 4:41 AM
>
> On Sun, Feb 09, 2025 at 03:52:52PM -0800, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > When a Hyper-V framebuffer device is removed, or the driver is unbound
> > from a devic
From: Saurabh Singh Sengar Sent: Friday, February 7,
2025 6:06 AM
>
> Thanks Michael, for the analysis.
>
> I have tried the kdump steps on Oracle 9.4, 6.13.0 kernel as well. Although I
> couldn't see
> the soft lockup issue I see some other VMBus failures. But I
From: Michael Kelley Sent: Thursday, February 6, 2025
1:00 PM
>
> From: Michael Kelley
> >
> > From: Thomas Tai Sent: Thursday, January 30, 2025
> > 12:44 PM
> > >
> > > > -----Original Message-
> > > > From: Michael
From: Michael Kelley
>
> From: Thomas Tai Sent: Thursday, January 30, 2025
> 12:44 PM
> >
> > > -Original Message-
> > > From: Michael Kelley Sent: Thursday, January 30,
> > > 2025 3:20 PM
> > >
> > > From:
From: Thomas Tai Sent: Thursday, January 30, 2025 12:44
PM
>
> > -Original Message-
> > From: Michael Kelley
> > Sent: Thursday, January 30, 2025 3:20 PM
> > To: Thomas Tai ; mhkelle...@gmail.com;
> > haiya...@microsoft.com; wei@kernel.org; d
From: Thomas Tai Sent: Thursday, January 30, 2025 10:50
AM
>
> Sorry for the typo in the subject title. It should have been 'hyperv_fb soft
> lockup on
> Azure Gen2 VM when taking kdump or executing kexec'
>
> Thomas
>
> >
> > Hi Michael,
> >
1 - 100 of 1103 matches
Mail list logo
