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
>>> inde
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
> > index 5609e164805f..83af05fac604 100644
> > --- a/d
> Thanks Gerd - I've just tested the diff below with memcpy_toio() and that
> works too:
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 5609e164805f..4d05b0ab1592 100644
> --- 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
>> +++
> 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
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -399,7 +399,
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
>>> for the frambuffer. And with the change to fbop
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
> > for the frambuffer. And with the change to fbops we now use the cfb_
> > functions to write to t
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.
>
> So
Hi Mark.
On Sat, Jul 04, 2020 at 02:09:38PM +0100, Mark Cave-Ayland wrote:
> 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 0
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 still isn't right. On sun4u the
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 releva
Hi Mark.
Thanks for the report and the informative pointers.
On Fri, Jul 03, 2020 at 10:57:46PM +0100, 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
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:
>
>
> [9.007161] [drm] Found bo
13 matches
Mail list logo
