On 20/12/2023 10:47, Arnd Bergmann wrote:
On Wed, Dec 20, 2023, at 09:54, John Paul Adrian Glaubitz wrote:
On Wed, 2023-12-20 at 08:36 +, Arnd Bergmann wrote:
All of these were found through inspection rather than testing,
so there is a good chance that other fatal kernel bugs prevent
On 18/05/2022 19:30, Thomas Zimmermann wrote:
Open Firmware provides basic display output via the 'display' node.
DT platform code already provides a device that represents the node's
framebuffer. Add a DRM driver for the device. The display mode and
color format is pre-initialized by the
act on other
side-effect
>> architectures.
>> So far the analysis tells that this change is OK for other arch's.
>> but testing would be good.
>>
>> Signed-off-by: Sam Ravnborg
>> Reported-by: Mark Cave-Ayland
>> Tested-by: Mark Cave-Ayland
>>
On 07/07/2020 20:52, Sam Ravnborg wrote:
> Hi Gerd.
>
> On Tue, Jul 07, 2020 at 09:03:41AM +0200, Gerd Hoffmann wrote:
>>> Yes, that's correct - I can confirm that the simplified diff below works:
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>>
On 07/07/2020 08:03, Gerd Hoffmann wrote:
>> Yes, that's correct - I can confirm that the simplified diff below works:
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 5609e164805f..83af05fac604 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>
On 04/07/2020 15:52, Sam Ravnborg wrote:
> Hi Mark.
>
> On Sat, Jul 04, 2020 at 03:16:47PM +0100, Mark Cave-Ayland wrote:
>> On 04/07/2020 14:41, Sam Ravnborg wrote:
>>
>>> I think what is happening is that the bochs driver request a shadow copy
>>>
On 04/07/2020 14:41, Sam Ravnborg wrote:
> I think what is happening is that the bochs driver request a shadow copy
> for the frambuffer. And with the change to fbops we now use the cfb_
> functions to write to the shadow framebuffer - which is not in any IO
> space. So this does not work.
>
>
On 04/07/2020 12:11, Mark Cave-Ayland wrote:
> According to gdbstub the destination address in $g3 looks like this:
>
> Breakpoint 1, 0x007ad8e4 in cfb_imageblit ()
> (gdb) i r $g3
> g3 0x10022 4297195520
>
>
> The 0x10022 address sti
On 04/07/2020 08:23, Sam Ravnborg wrote:
> I tried to take a look at this - came up with the following untested
> hack.
> The idea is that we in mode_config can specify if we need the cfb
> variants. (I do not know what cfb is acronym for?)
> Then when we setup the framebuffer we select the
On 03/07/2020 22:57, Mark Cave-Ayland wrote:
> Hi all,
>
> I've been receiving reports that newer sparc64 kernels have started to panic
> on boot
> under qemu-system-sparc64 with bochs_drm enabled which I was able to confirm
> locally
> building git master:
>
>
&
Hi all,
I've been receiving reports that newer sparc64 kernels have started to panic on
boot
under qemu-system-sparc64 with bochs_drm enabled which I was able to confirm
locally
building git master:
[9.007161] [drm] Found bochs VGA, ID 0xb0c5.
[9.007840] [drm] Framebuffer size 16384
On 03/07/17 09:55, Gerd Hoffmann wrote:
> Hi,
>
>> Hopefully Gerd has experience using bochs_drm with other non-x86
>> systems
>> and can comment further.
>
> Just pushed to drm-misc-next, fix is correct. bochs video memory is a
> pci bar, and the framebuffer is stored there.
>
> Using sys
On 03/07/17 09:11, Daniel Vetter wrote:
> On Sun, Jul 02, 2017 at 10:52:43PM +0100, Mark Cave-Ayland wrote:
>> The current drm_fb_helper_sys helpers referenced in fb_ops assume that the
>> video memory is in system RAM. This is not the case for sparc which uses
>> dire
the framebuffer.
Switching fb_ops over to use the drm_fb_helper_cfb helpers ensures that the
correct accesses are used on sparc, fixing the panic and allowing the
bochs_drm module to function under qemu-system-sparc64.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
---
drivers/gpu/drm
Hi all,
I'm one of the QEMU SPARC maintainers and I've been investigating why
enabling the fb console via the bochs_drm module causes a panic on
startup. The reproducer with QEMU 2.9 is easy:
$ ./qemu-system-sparc64 -m 512 -kernel rel-sparc/vmlinux -append
'console=ttyS0' -serial stdio
This
15 matches
Mail list logo
