Hi Joonas:
Thanks for you time and comments. :) See my replies below.
On 02/23/16 20:42, Joonas Lahtinen wrote:
Hi,
Code is looking a lot better.
A general question still; why you seem to be preferring multi-stage
alloc and destroy?
Are there going to be scenarios when things will be
On 02/24/16 16:08, Tian, Kevin wrote:
From: Wang, Zhi A
Sent: Thursday, February 18, 2016 7:42 PM
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
new file mode 100644
index 000..52cfa32
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
[...]
+
+#include
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Tuesday, February 23, 2016 8:42 PM
>
> Hi,
>
> Code is looking a lot better.
>
> A general question still; why you seem to be preferring multi-stage
> alloc and destroy?
One reason for multi-stage, IMO, is that GVT needs
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Tuesday, February 23, 2016 8:54 PM
> > diff --git a/drivers/gpu/drm/i915/gvt/Makefile
> > b/drivers/gpu/drm/i915/gvt/Makefile
> > new file mode 100644
> > index 000..959305f
> > --- /dev/null
> > +++
A one more note below.
On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote:
> This patch introduces the very basic framework of GVT-g device model,
> includes basic prototypes, definitions, initialization.
>
> v2:
> - Introduce i915_gvt.c.
> It's necessary to introduce the stubs between i915 driver
Hi,
Code is looking a lot better.
A general question still; why you seem to be preferring multi-stage
alloc and destroy?
Are there going to be scenarios when things will be allocated but not
initialized? I don't see a such use scenario.
I wouldn't split the init functions down as much as you
This patch introduces the very basic framework of GVT-g device model,
includes basic prototypes, definitions, initialization.
v2:
- Introduce i915_gvt.c.
It's necessary to introduce the stubs between i915 driver and GVT-g host,
as GVT-g components is configurable in kernel config. When disabled,
