On 22/04/2016 13:30, Andrew Baumann wrote:
>> From: Sylvain Garrigues [mailto:sylv...@sylvaingarrigues.com]
>> Sent: Friday, 22 April 2016 13:27
>>
>> Le 22 avr. 2016 à 13:22, Andrew Baumann
>> a écrit :
+stl_le_phys(&s->dma_as, value + 16, tmp_xres * tmp_yres
+ * (tmp_bpp
On 22 April 2016 at 12:42, Sylvain Garrigues
wrote:
> As the framebuffer settings are copied into the result message before it is
> reconfigured, inconsistent behavior can happen when, for instance, you set
> with
> a single message the width, height, and depth, and ask at the same time to
> allo
On 2 May 2016 at 22:21, Sylvain Garrigues wrote:
> Hello,
>
> Shall we commit this patch?
Hi; this is on my list of patches to deal with, but QEMU
is still in code freeze for the upcoming 2.6 release.
When we reopen the tree after release it will go in
shortly after that.
thanks
-- PMM
Hello,
Shall we commit this patch?
Very best,
Sylvain
> Le 22 avr. 2016 à 14:42, Sylvain Garrigues a
> écrit :
>
> As the framebuffer settings are copied into the result message before it is
> reconfigured, inconsistent behavior can happen when, for instance, you set
> with
> a single messa
Le 22 avr. 2016 à 13:30, Andrew Baumann a écrit :
> But I won't be merging this patch (hopefully Peter can do that?), so it's
> probably best if you make the tweak and resend with my Reviewed-by.
Made the tweak and resent the patch with your reviewed-by.
Have a good day.
As the framebuffer settings are copied into the result message before it is
reconfigured, inconsistent behavior can happen when, for instance, you set with
a single message the width, height, and depth, and ask at the same time to
allocate the buffer and get the pitch and the size.
In this case, t
> From: Sylvain Garrigues [mailto:sylv...@sylvaingarrigues.com]
> Sent: Friday, 22 April 2016 13:27
>
> Le 22 avr. 2016 à 13:22, Andrew Baumann
> a écrit :
> >> +stl_le_phys(&s->dma_as, value + 16, tmp_xres * tmp_yres
> >> + * (tmp_bpp >> 3));
> >
> > Personal style nit: I prefer * 8
Le 22 avr. 2016 à 13:22, Andrew Baumann a écrit :
>> +stl_le_phys(&s->dma_as, value + 16, tmp_xres * tmp_yres *
>> + (tmp_bpp >> 3));
>
> Personal style nit: I prefer * 8 rather than >> 3, because it's more
> immediately obvious what you're computing, a trivial optimisation for the
> From: Qemu-devel [mailto:qemu-devel-
> bounces+andrew.baumann=microsoft@nongnu.org] On Behalf Of Sylvain
> Garrigues
> Sent: Thursday, 21 April 2016 12:42
>
> As the framebuffer settings are copied into the result message before it is
> reconfigured, inconsistent behavior can happen when, fo
Le 21 avr. 2016 à 15:42, Peter Maydell a écrit :
>
> There may be something we can do here to make FreeBSD's life
> easier, but we definitely can't do it on the eve of a release.
I didn’t know it was release day, my timing is not perfect then, sorry about
that, I didn’t intend to put stress on
On 21 April 2016 at 14:15, Sylvain Garrigues
wrote:
> Le 21 avr. 2016 à 14:54, Peter Maydell a écrit :
>> On 21 April 2016 at 13:50, Sylvain Garrigues
>> wrote:
>>> BTW, would be great to be able to set the load addr on the command
>>> line, wouldn’t it?
>>
>> The booting protocol does not manda
Le 21 avr. 2016 à 14:54, Peter Maydell a écrit :
> On 21 April 2016 at 13:50, Sylvain Garrigues
> wrote:
>> It does prevent FreeBSD to boot correctly.
>>
>> With that patch and
>> #define KERNEL_LOAD_ADDR 0x0020
>> in arm/boot/boot.c, official FreeBSD RPI2 images boot like a charm :-)
>
> T
On 21 April 2016 at 13:50, Sylvain Garrigues
wrote:
> It does prevent FreeBSD to boot correctly.
>
> With that patch and
> #define KERNEL_LOAD_ADDR 0x0020
> in arm/boot/boot.c, official FreeBSD RPI2 images boot like a charm :-)
This is the kind of thing that is useful to mention in the commit
It does prevent FreeBSD to boot correctly.
With that patch and
#define KERNEL_LOAD_ADDR 0x0020
in arm/boot/boot.c, official FreeBSD RPI2 images boot like a charm :-)
BTW, would be great to be able to set the load addr on the command line,
wouldn’t it?
> Le 21 avr. 2016 à 14:45, Peter Mayd
On 21 April 2016 at 11:41, Sylvain Garrigues
wrote:
> As the framebuffer settings are copied into the result message before
> it is reconfigured, inconsistent behavior can happen when, for instance,
> you set with a sinle message the width, height, and depth, and ask at
> the same time to allocate
As the framebuffer settings are copied into the result message before it is
reconfigured, inconsistent behavior can happen when, for instance, you set with
a sinle message the width, height, and depth, and ask at the same time to
allocate the buffer and get the pitch and the size.
In this case,
16 matches
Mail list logo
