> -Original Message-
> From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com]
> Sent: Thursday, July 31, 2014 21:38 PM
> > I think in hvfb_on_panic() we should be able to get the
> > hvfb_info pointer by
> > hvfb_info = container_of(nb, struct hv_fb_panic_nb, nb).
> >
> > If you like that or
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com]
Sent: Thursday, July 31, 2014 21:38 PM
I think in hvfb_on_panic() we should be able to get the
hvfb_info pointer by
hvfb_info = container_of(nb, struct hv_fb_panic_nb, nb).
If you like that or have a better
On 31/07/14 13:11, Dexuan Cui wrote:
>> -Original Message-
>> From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com]
>> Sent: Wednesday, July 30, 2014 22:24 PM
>>> +static struct fb_info *hvfb_info;
>>
>> Static variables like these are usually a no-no. This prevents you from
>> having
> -Original Message-
> From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com]
> Sent: Wednesday, July 30, 2014 22:24 PM
> > +static struct fb_info *hvfb_info;
>
> Static variables like these are usually a no-no. This prevents you from
> having multiple device instances.
I agree.
> > static
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com]
Sent: Wednesday, July 30, 2014 22:24 PM
+static struct fb_info *hvfb_info;
Static variables like these are usually a no-no. This prevents you from
having multiple device instances.
I agree.
static uint
On 31/07/14 13:11, Dexuan Cui wrote:
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com]
Sent: Wednesday, July 30, 2014 22:24 PM
+static struct fb_info *hvfb_info;
Static variables like these are usually a no-no. This prevents you from
having multiple device
On 09/07/14 06:04, Dexuan Cui wrote:
> Currently the VSC has no chance to notify the VSP of the dirty rectangle on VM
> panic because the notification work is done in a workqueue, and in panic() the
> kernel typically ends up in an infinite loop, and a typical kernel config has
>
On 09/07/14 06:04, Dexuan Cui wrote:
Currently the VSC has no chance to notify the VSP of the dirty rectangle on VM
panic because the notification work is done in a workqueue, and in panic() the
kernel typically ends up in an infinite loop, and a typical kernel config has
> -Original Message-
> From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, July 24, 2014 11:53 AM
> > So, hi Greg and all,
> > If you think the patch itself is OK, may I know if it's OK for the patch to
> > go
> > into Greg's char-misc.git tree, as some
-Original Message-
From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
Sent: Thursday, July 24, 2014 11:53 AM
So, hi Greg and all,
If you think the patch itself is OK, may I know if it's OK for the patch to
go
into Greg's char-misc.git tree, as some other
On Thu, Jul 24, 2014 at 01:54:58AM +, Dexuan Cui wrote:
> Ping again -- any one has further comment for the v3 version?
>
> It looks the framebuffer layer's Tomi and Jean-Christophe are out recently?
> Recently I don't see mail from them since Jul 1 and Jul 8 in the lists.
>
> Though the
Ping again -- any one has further comment for the v3 version?
It looks the framebuffer layer's Tomi and Jean-Christophe are out recently?
Recently I don't see mail from them since Jul 1 and Jul 8 in the lists.
Though the patch belongs to driver/video/fbdev/, it only changes hyper-v stuff
and
Ping again -- any one has further comment for the v3 version?
It looks the framebuffer layer's Tomi and Jean-Christophe are out recently?
Recently I don't see mail from them since Jul 1 and Jul 8 in the lists.
Though the patch belongs to driver/video/fbdev/, it only changes hyper-v stuff
and
On Thu, Jul 24, 2014 at 01:54:58AM +, Dexuan Cui wrote:
Ping again -- any one has further comment for the v3 version?
It looks the framebuffer layer's Tomi and Jean-Christophe are out recently?
Recently I don't see mail from them since Jul 1 and Jul 8 in the lists.
Though the patch
14 matches
Mail list logo