Re: [PATCH] treewide: Fix typo compatability - compatibility

2015-05-27 Thread Daniel Vetter
On Wed, May 27, 2015 at 03:05:42PM +0300, Laurent Pinchart wrote:
 Even though 'compatability' has a dedicated entry in the Wiktionary,
 it's listed as 'Mispelling of compatibility'. Fix it.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  arch/metag/include/asm/elf.h | 2 +-
  arch/powerpc/kvm/book3s.c| 2 +-
  arch/sparc/include/uapi/asm/pstate.h | 2 +-
  drivers/gpu/drm/drm_atomic_helper.c  | 4 ++--
  drivers/media/dvb-frontends/au8522_dig.c | 2 +-
  drivers/net/wireless/ipw2x00/ipw2100.h   | 2 +-
  6 files changed, 7 insertions(+), 7 deletions(-)
 
 I can split this into one patch per subsystem, but that seems a bit overkill.
 Can someone take it ?

Acked-by: Daniel Vetter daniel.vet...@ffwll.ch for the atomic_helper.c
part.
-Daniel

 
 diff --git a/arch/metag/include/asm/elf.h b/arch/metag/include/asm/elf.h
 index d2baf6961794..87b0cf1e0acb 100644
 --- a/arch/metag/include/asm/elf.h
 +++ b/arch/metag/include/asm/elf.h
 @@ -11,7 +11,7 @@
  #define R_METAG_RELBRANCH4
  #define R_METAG_GETSETOFF5
  
 -/* Backward compatability */
 +/* Backward compatibility */
  #define R_METAG_REG32OP1 6
  #define R_METAG_REG32OP2 7
  #define R_METAG_REG32OP3 8
 diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
 index 453a8a47a467..cb14dd78a2e7 100644
 --- a/arch/powerpc/kvm/book3s.c
 +++ b/arch/powerpc/kvm/book3s.c
 @@ -901,7 +901,7 @@ int kvmppc_core_check_processor_compat(void)
  {
   /*
* We always return 0 for book3s. We check
 -  * for compatability while loading the HV
 +  * for compatibility while loading the HV
* or PR module
*/
   return 0;
 diff --git a/arch/sparc/include/uapi/asm/pstate.h 
 b/arch/sparc/include/uapi/asm/pstate.h
 index 4b6b998afd99..cf832e14aa05 100644
 --- a/arch/sparc/include/uapi/asm/pstate.h
 +++ b/arch/sparc/include/uapi/asm/pstate.h
 @@ -88,7 +88,7 @@
  #define VERS_MAXTL   _AC(0xff00,UL) /* Max Trap Level.   */
  #define VERS_MAXWIN  _AC(0x001f,UL) /* Max RegWindow Idx.*/
  
 -/* Compatability Feature Register (%asr26), SPARC-T4 and later  */
 +/* Compatibility Feature Register (%asr26), SPARC-T4 and later  */
  #define CFR_AES  _AC(0x0001,UL) /* Supports AES 
 opcodes */
  #define CFR_DES  _AC(0x0002,UL) /* Supports DES 
 opcodes */
  #define CFR_KASUMI   _AC(0x0004,UL) /* Supports KASUMI opcodes  
 */
 diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
 b/drivers/gpu/drm/drm_atomic_helper.c
 index b82ef6262469..12c5b79b0e8f 100644
 --- a/drivers/gpu/drm/drm_atomic_helper.c
 +++ b/drivers/gpu/drm/drm_atomic_helper.c
 @@ -751,7 +751,7 @@ crtc_set_mode(struct drm_device *dev, struct 
 drm_atomic_state *old_state)
   * This function shuts down all the outputs that need to be shut down and
   * prepares them (if required) with the new mode.
   *
 - * For compatability with legacy crtc helpers this should be called before
 + * For compatibility with legacy crtc helpers this should be called before
   * drm_atomic_helper_commit_planes(), which is what the default commit 
 function
   * does. But drivers with different needs can group the modeset commits 
 together
   * and do the plane commits at the end. This is useful for drivers doing 
 runtime
 @@ -776,7 +776,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_modeset_disables);
   * This function enables all the outputs with the new configuration which 
 had to
   * be turned off for the update.
   *
 - * For compatability with legacy crtc helpers this should be called after
 + * For compatibility with legacy crtc helpers this should be called after
   * drm_atomic_helper_commit_planes(), which is what the default commit 
 function
   * does. But drivers with different needs can group the modeset commits 
 together
   * and do the plane commits at the end. This is useful for drivers doing 
 runtime
 diff --git a/drivers/media/dvb-frontends/au8522_dig.c 
 b/drivers/media/dvb-frontends/au8522_dig.c
 index 5d06c99b0e97..edadcc7eea6c 100644
 --- a/drivers/media/dvb-frontends/au8522_dig.c
 +++ b/drivers/media/dvb-frontends/au8522_dig.c
 @@ -922,7 +922,7 @@ module_param(debug, int, 0644);
  MODULE_PARM_DESC(debug, Enable verbose debug messages);
  
  module_param(zv_mode, int, 0644);
 -MODULE_PARM_DESC(zv_mode, Turn on/off ZeeVee modulator compatability mode 
 (default:on).\n
 +MODULE_PARM_DESC(zv_mode, Turn on/off ZeeVee modulator compatibility mode 
 (default:on).\n
   \t\ton - modified AU8522 QAM256 initialization.\n
   \t\tProvides faster lock when using ZeeVee modulator based sources);
  
 diff --git a/drivers/net/wireless/ipw2x00/ipw2100.h 
 b/drivers/net/wireless/ipw2x00/ipw2100.h
 index c6d78790cb0d..193947865efd 100644
 --- a/drivers/net/wireless/ipw2x00/ipw2100.h
 +++ b/drivers/net/wireless/ipw2x00/ipw2100.h
 @@ -746,7 +746,7 @@ struct

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

2014-12-08 Thread Daniel Vetter
On Mon, Dec 08, 2014 at 10:55:01AM +0100, Gerd Hoffmann wrote:
 On Sa, 2014-12-06 at 12:17 +0800, Jike Song wrote:
  I don't know that is exactly needed, we also need to have Windows
  driver considered.  However, I'm quite confident that, if things gonna
  work for IGD passthrough, it gonna work for GVT-g.
 
 I'd suggest to focus on q35 emulation.  q35 is new enough that a version
 with integrated graphics exists, so the gap we have to close is *much*
 smaller.
 
 In case guests expect a northbridge matching the chipset generation of
 the graphics device (which I'd expect is the case, after digging a bit
 in the igd and agpgart linux driver code) I think we should add proper
 device emulation for them, i.e. comply q35-pcihost with
 sandybridge-pcihost + ivybridge-pcihost + haswell-pcihost instead of
 just copying over the pci ids from the host.  Most likely all those
 variants can share most of the emulation code.

I don't think i915.ko should care about either northbridge nor pch on
para-virtualized platforms. We do noodle around in there for the oddball
memory controller setting and for some display stuff. But neither of that
really applies to paravirtualized hw. And if there's any case like that we
should  patch it out (like we do with some of the runtime pm code
already).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

2014-12-05 Thread Daniel Vetter
On Fri, Dec 05, 2014 at 09:50:21AM +0100, Gerd Hoffmann wrote:
  
  https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
 
 /me goes read this.
 
 A few comments on the kernel stuff (brief look so far, also
 compile-tested only, intel gfx on my test machine is too old).
 
  * Noticed the kernel bits don't even compile when configured as
module.  Everything (vgt, i915, kvm) must be compiled into the
kernel.
  * Design approach still seems to be i915 on vgt not the other way
around.

Yeah done a quick read-through of just the i915 bits too, same comment. I
guess this is just the first RFC and the redesign we've discussed about
already with xengt is in progress somewhere?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html