From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Dexuan Cui <decui@microsoft.com>
Cc: "linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"driverdev-devel@linuxdriverproject.org"
<driverdev-devel@linuxdriverproject.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"olaf@aepfle.de" <olaf@aepfle.de>,
"apw@canonical.com" <apw@canonical.com>,
"plagnioj@jcrosoft.com" <plagnioj@jcrosoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
"dan.carpenter@oracle.com" <dan.carpenter@oracle.com>
Subject: Re: [PATCH v3] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
Date: Thu, 31 Jul 2014 13:38:11 +0000 [thread overview]
Message-ID: <53DA46C3.9080905@ti.com> (raw)
In-Reply-To: <EE124450C0AAF944A40DD71E61F878C98F6F78@SINEX14MBXC417.southpacific.corp.microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]
On 31/07/14 13:11, Dexuan Cui wrote:
>> -----Original Message-----
>> From: Tomi Valkeinen [mailto:tomi.valkeinen@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 screen_width = HVFB_WIDTH;
>>> static uint screen_height = HVFB_HEIGHT;
>>> static uint screen_depth;
>>> static uint screen_fb_size;
>>>
>>> +/* If true, the VSC notifies the VSP on every framebuffer change */
>>> +static bool synchronous_fb;
>>> +
>>
>> Same comment here.
>>
>> However, if (and only if) the driver is already designed to work only
>> with single device instance, then this patch is probably ok. But even
> IMO the host should only provide at most 1 synthetic video device to a VM. :-)
>
>> then, I'd prefer this to be handled without static variables so that the
>> driver could eventually be changed to support multiple device instances.
>
> Hi Tomi,
> Maybe we can remove these static stuff:
> +static struct fb_info *hvfb_info;
> +static struct notifier_block hvfb_panic_nb = {
> + .notifier_call = hvfb_on_panic,
> +};
> by kmalloc()-ing a new struct:
> struct hv_fb_panic_nb {
> struct fb_info *hvfb_info;
> struct notifier_block nb;
> }
> ?
> 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 idea, please let me know so
> I can make a new patch.
To be honest, I haven't been using notifiers much. But the above looks
ok to me.
Or maybe you can add the notifier_block and the synchronous_fb to
hvfb_par? From the notifier_block pointer you could then get hvfp_par,
and from there hvfb_info.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Dexuan Cui <decui@microsoft.com>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"dan.carpenter@oracle.com" <dan.carpenter@oracle.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"driverdev-devel@linuxdriverproject.org"
<driverdev-devel@linuxdriverproject.org>,
"plagnioj@jcrosoft.com" <plagnioj@jcrosoft.com>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
"olaf@aepfle.de" <olaf@aepfle.de>,
"apw@canonical.com" <apw@canonical.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
KY Srinivasan <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>
Subject: Re: [PATCH v3] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic
Date: Thu, 31 Jul 2014 16:38:11 +0300 [thread overview]
Message-ID: <53DA46C3.9080905@ti.com> (raw)
In-Reply-To: <EE124450C0AAF944A40DD71E61F878C98F6F78@SINEX14MBXC417.southpacific.corp.microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]
On 31/07/14 13:11, Dexuan Cui wrote:
>> -----Original Message-----
>> From: Tomi Valkeinen [mailto:tomi.valkeinen@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 screen_width = HVFB_WIDTH;
>>> static uint screen_height = HVFB_HEIGHT;
>>> static uint screen_depth;
>>> static uint screen_fb_size;
>>>
>>> +/* If true, the VSC notifies the VSP on every framebuffer change */
>>> +static bool synchronous_fb;
>>> +
>>
>> Same comment here.
>>
>> However, if (and only if) the driver is already designed to work only
>> with single device instance, then this patch is probably ok. But even
> IMO the host should only provide at most 1 synthetic video device to a VM. :-)
>
>> then, I'd prefer this to be handled without static variables so that the
>> driver could eventually be changed to support multiple device instances.
>
> Hi Tomi,
> Maybe we can remove these static stuff:
> +static struct fb_info *hvfb_info;
> +static struct notifier_block hvfb_panic_nb = {
> + .notifier_call = hvfb_on_panic,
> +};
> by kmalloc()-ing a new struct:
> struct hv_fb_panic_nb {
> struct fb_info *hvfb_info;
> struct notifier_block nb;
> }
> ?
> 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 idea, please let me know so
> I can make a new patch.
To be honest, I haven't been using notifiers much. But the above looks
ok to me.
Or maybe you can add the notifier_block and the synchronous_fb to
hvfb_par? From the notifier_block pointer you could then get hvfp_par,
and from there hvfb_info.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-07-31 13:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-09 2:04 [PATCH v3] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic Dexuan Cui
2014-07-09 3:04 ` Dexuan Cui
2014-07-24 1:54 ` Dexuan Cui
2014-07-24 3:53 ` gregkh
2014-07-24 3:53 ` gregkh
2014-07-25 7:15 ` Dexuan Cui
2014-07-25 7:15 ` Dexuan Cui
2014-07-30 14:24 ` Tomi Valkeinen
2014-07-30 14:24 ` Tomi Valkeinen
2014-07-31 10:11 ` Dexuan Cui
2014-07-31 10:11 ` Dexuan Cui
2014-07-31 13:38 ` Tomi Valkeinen [this message]
2014-07-31 13:38 ` Tomi Valkeinen
2014-08-01 10:22 ` Dexuan Cui
2014-08-01 10:22 ` Dexuan Cui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53DA46C3.9080905@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=apw@canonical.com \
--cc=dan.carpenter@oracle.com \
--cc=decui@microsoft.com \
--cc=driverdev-devel@linuxdriverproject.org \
--cc=gregkh@linuxfoundation.org \
--cc=haiyangz@microsoft.com \
--cc=jasowang@redhat.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olaf@aepfle.de \
--cc=plagnioj@jcrosoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.