b frame buffer device
>>
>> There is no virgl support because it's a virtio-gpu-device and not
>> virtio-gpu-device-gl that is PCI-only in Qemu. Hence everything seems good.
>>
>> I'd appreciate if you could give s390x a test.. I never touched s390x
>> and it wil
video/fbdev/Kconfig | 7 +-
> include/linux/aperture.h | 56 +
> 11 files changed, 440 insertions(+), 166 deletions(-)
> create mode 100644 Documentation/driver-api/aperture.rst
> create mode 100644 drivers/video/aperture.c
> create mode 100644 include/linux/aperture.h
>
series
Tested-by: Laszlo Ersek
(on top of Fedora's 5.18.5-100.fc35.x86_64)
Thanks,
Laszlo
On 08/21/19 13:12, Gerd Hoffmann wrote:
> We must make sure our scatterlist segments are not too big, otherwise
> we might see swiotlb failures (happens with sev, also reproducable with
> swiotlb=force).
>
> Suggested-by: Laszlo Ersek
> Signed-off-by: Gerd Hoffmann
> -
> Driver needs to explicitly call drm_dev_set_unique() to keep it working.
>
> Cc: Daniel Vetter
> Cc: Gerd Hoffmann
> Cc: Hans de Goede
> Cc: Laszlo Ersek
> Signed-off-by: Emil Velikov
> ---
> drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 31
> 1 file cha
On 04/04/18 19:29, Laszlo Ersek wrote:
> Hi Emil,
>
> On 04/03/18 19:13, Emil Velikov wrote:
>> On 29 March 2018 at 12:17, Laszlo Ersek <ler...@redhat.com> wrote:
>>> On 03/28/18 16:35, Emil Velikov wrote:
>>>> On 28 March 2018 at 11:27, Laszlo Ersek <l
Hi Emil,
On 04/03/18 19:13, Emil Velikov wrote:
> On 29 March 2018 at 12:17, Laszlo Ersek <ler...@redhat.com> wrote:
>> On 03/28/18 16:35, Emil Velikov wrote:
>>> On 28 March 2018 at 11:27, Laszlo Ersek <ler...@redhat.com> wrote:
>>>> On 03/28/18 03:2
On 03/28/18 16:35, Emil Velikov wrote:
> On 28 March 2018 at 11:27, Laszlo Ersek <ler...@redhat.com> wrote:
>> On 03/28/18 03:24, Emil Velikov wrote:
>>> Gents, can someone double-check this please? Just in case.
>>
>> I guess I should test whether this series
on drm_set_busid IOCTL setting
> the busid, so we don't need to fallback to dev->unique - see commit
> 5c484cee7ef9c4fd29fa0ba09640d55960977145
>
> With that in place we can remove the local workaround.
>
> Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
> Cc: Gerd Hoffmann &
On 10/03/16 22:34, Daniel Vetter wrote:
> On Mon, Oct 3, 2016 at 9:36 PM, Laszlo Ersek wrote:
>> On 10/03/16 21:12, Daniel Vetter wrote:
>>> On Mon, Oct 3, 2016 at 4:15 PM, Laszlo Ersek wrote:
>>>> With kernel commit a325725633c2 applied, the drmGetBusid() call in
&
On 10/03/16 21:12, Daniel Vetter wrote:
> On Mon, Oct 3, 2016 at 4:15 PM, Laszlo Ersek wrote:
>> With kernel commit a325725633c2 applied, the drmGetBusid() call in
>> get_drm_info() [hw/xfree86/os-support/linux/lnx_platform.c] returns
>> "virtio0".
>>
il Velikov
Cc: Gerd Hoffmann
Cc: Gustavo Padovan
Cc: Hans de Goede
Cc: Joachim Frieben
Cc: stable at vger.kernel.org
Reported-by: Joachim Frieben
Fixes: a325725633c26aa66ab940f762a6b0778edf76c0
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1366842
Signed-off-by: Laszlo Ersek
Revi
On 10/03/16 19:28, Emil Velikov wrote:
> On 3 October 2016 at 18:08, Laszlo Ersek wrote:
>> On 10/03/16 18:43, Emil Velikov wrote:
>>> Earlier commit was removing all the users of drm_platform_set_busid and
>>> removed the virtio hunk (which uses the PCI version of t
On 10/03/16 19:08, Laszlo Ersek wrote:
> On 10/03/16 18:43, Emil Velikov wrote:
>> Earlier commit was removing all the users of drm_platform_set_busid and
>> removed the virtio hunk (which uses the PCI version of the function) by
>> mistake.
>>
>> This in itself
; the busid, which in the case below lead to the failure to detect
> the (correct) device and ultimately the X server failing to start.
>
> Fixes: a325725633c ("drm: Lobotomize set_busid nonsense for !pci
> drivers")
> Cc: Daniel Vetter
> Cc: Laszlo Ersek
>
On 10/03/16 17:00, Emil Velikov wrote:
> On 3 October 2016 at 15:27, Laszlo Ersek wrote:
> [snip]
>> the v3 patch accidentally removed the similarly customized set_busid
>> callback for amdgpu -- drm_pci_set_busid(). Emil caught that error in
>> review, hence the v
On 10/03/16 16:15, Laszlo Ersek wrote:
> On 10/03/16 13:34, Emil Velikov wrote:
>> On 30 September 2016 at 18:26, Laszlo Ersek wrote:
>>> On 09/30/16 18:38, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 30-09-16 17:33, Laszlo Ersek wrote:
&
On 10/03/16 13:34, Emil Velikov wrote:
> On 30 September 2016 at 18:26, Laszlo Ersek wrote:
>> On 09/30/16 18:38, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 30-09-16 17:33, Laszlo Ersek wrote:
>>>> On 09/30/16 16:59, Hans de Goede wrote:
>>>
On 10/03/16 14:46, Emil Velikov wrote:
> On 3 October 2016 at 13:14, Laszlo Ersek wrote:
>> On 10/03/16 13:34, Emil Velikov wrote:
>>> On 30 September 2016 at 18:26, Laszlo Ersek wrote:
>>
>>>> This setup (modulo the kernel of course) was known to work
On 10/03/16 13:34, Emil Velikov wrote:
> On 30 September 2016 at 18:26, Laszlo Ersek wrote:
>> This setup (modulo the kernel of course) was known to work, but now the
>> X server actually segfaults (apparently in the
>> xf86PlatformDeviceCheckBusID() function). Please find
On 09/30/16 18:38, Hans de Goede wrote:
> Hi,
>
> On 30-09-16 17:33, Laszlo Ersek wrote:
>> On 09/30/16 16:59, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 30-09-16 16:51, Laszlo Ersek wrote:
>>>> On 09/30/16 12:35, Hans de Goede wrote:
>&
On 09/30/16 16:59, Hans de Goede wrote:
> Hi,
>
> On 30-09-16 16:51, Laszlo Ersek wrote:
>> On 09/30/16 12:35, Hans de Goede wrote:
>>
>>> Attached are 2 patches against the xserver which should fix this,
>>> please give them a try.
>>
>> Sorry a
On 09/30/16 12:35, Hans de Goede wrote:
> Attached are 2 patches against the xserver which should fix this,
> please give them a try.
Sorry about the delay.
The patches don't seem to fix the issue for me. Please see the Xorg log
attached.
I tested the patches as follows. Given that my
On 09/30/16 10:28, Hans de Goede wrote:
> Hi,
>
> On 30-09-16 05:09, Laszlo Ersek wrote:
>> Hello Daniel,
>>
>> On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
>>> We already have a fallback in place to fill out the unique from
>&g
Hello Daniel,
On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
> We already have a fallback in place to fill out the unique from
> dev->unique, which is set to something reasonable in drm_dev_alloc.
>
> Which means we only need to have a special set_busid for pci devices,
> to
24 matches
Mail list logo
