[PATCH v3] mtrr: avoid ifdef'ery with phys_wc_to_mtrr_index()

2015-04-22 Thread Luis R. Rodriguez 
On Tue, Apr 21, 2015 at 01:42:51PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" 
> 
> There is only one user but since we're going to bury
> MTRR next out of access to drivers expose this last
> piece of API to drivers in a general fashion only
> needing io.h for access to helpers.
> 
> Cc: Toshi Kani 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Will Deacon 
> Cc: Thierry Reding 
> Cc: Andrew Morton 
> Cc: Dave Hansen 
> Cc: Greg Kroah-Hartman 
> Cc: Catalin Marinas 
> Cc: Abhilash Kesavan 
> Cc: Matthias Brugger 
> Cc: Cristian Stoica 
> Cc: dri-devel at lists.freedesktop.org
> Cc: Suresh Siddha 
> Cc: Linus Torvalds 
> Cc: Juergen Gross 
> Cc: Daniel Vetter 
> Cc: Andy Lutomirski 
> Cc: Dave Airlie 
> Cc: Antonino Daplas 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Tomi Valkeinen 
> Cc: Ville Syrjälä 
> Cc: Mel Gorman 
> Cc: Vlastimil Babka 
> Cc: Borislav Petkov 
> Cc: Davidlohr Bueso 
> Cc: x86 at kernel.org
> Cc: linux-fbdev at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Luis R. Rodriguez 
> ---
>  arch/x86/include/asm/io.h   |  3 +++
>  arch/x86/include/asm/mtrr.h |  5 -
>  arch/x86/kernel/cpu/mtrr/main.c |  6 +++---
>  drivers/gpu/drm/drm_ioctl.c | 14 +-
>  include/linux/io.h  |  6 ++
>  5 files changed, 13 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 4afc05f..a2b9740 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -339,6 +339,9 @@ extern bool xen_biovec_phys_mergeable(const struct 
> bio_vec *vec1,
>  #define IO_SPACE_LIMIT 0x
>  
>  #ifdef CONFIG_MTRR
> +extern int __must_check arch_phys_wc_index(int handle);
> +#define arch_phys_wc_index arch_phys_wc_index
> +
>  extern int __must_check arch_phys_wc_add(unsigned long base,
>unsigned long size);
>  extern void arch_phys_wc_del(int handle);
> diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
> index da8dff1..27e3dc0 100644
> --- a/arch/x86/include/asm/mtrr.h
> +++ b/arch/x86/include/asm/mtrr.h
> @@ -48,7 +48,6 @@ extern void mtrr_aps_init(void);
>  extern void mtrr_bp_restore(void);
>  extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
>  extern int amd_special_default_mtrr(void);
> -extern int phys_wc_to_mtrr_index(int handle);
>  #  else
>  static inline u8 mtrr_type_lookup(u64 addr, u64 end, u8 *uniform)
>  {
> @@ -85,10 +84,6 @@ static inline int mtrr_trim_uncached_memory(unsigned long 
> end_pfn)
>  static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
>  {
>  }
> -static inline int phys_wc_to_mtrr_index(int handle)
> -{
> - return -1;
> -}
>  
>  #define mtrr_ap_init() do {} while (0)
>  #define mtrr_bp_init() do {} while (0)
> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> index 12abdbe..d8c106c 100644
> --- a/arch/x86/kernel/cpu/mtrr/main.c
> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> @@ -580,7 +580,7 @@ void arch_phys_wc_del(int handle)
>  EXPORT_SYMBOL(arch_phys_wc_del);
>  
>  /*
> - * phys_wc_to_mtrr_index - translates arch_phys_wc_add's return value
> + * arch_phys_wc_index - translates arch_phys_wc_add's return value
>   * @handle: Return value from arch_phys_wc_add
>   *
>   * This will turn the return value from arch_phys_wc_add into an mtrr
> @@ -590,14 +590,14 @@ EXPORT_SYMBOL(arch_phys_wc_del);
>   * in printk line.  Alas there is an illegitimate use in some ancient
>   * drm ioctls.
>   */
> -int phys_wc_to_mtrr_index(int handle)
> +int arch_phys_wc_index(int handle)
>  {
>   if (handle < MTRR_TO_PHYS_WC_OFFSET)
>   return -1;
>   else
>   return handle - MTRR_TO_PHYS_WC_OFFSET;
>  }
> -EXPORT_SYMBOL_GPL(phys_wc_to_mtrr_index);
> +EXPORT_SYMBOL_GPL(arch_phys_wc_index);
>  
>  /*
>   * HACK ALERT!
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 266dcd6..0a95782 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -36,9 +36,6 @@
>  
>  #include 
>  #include 
> -#ifdef CONFIG_X86
> -#include 
> -#endif
>  
>  static int drm_version(struct drm_device *dev, void *data,
>  struct drm_file *file_priv);
> @@ -197,16 +194,7 @@ static int drm_getmap(struct drm_device *dev, void *data,
>   map->type = r_list->map->type;
>   map->flags = r_list->map->flags;
>   map->handle = (void *)(unsigned long) r_list->user_token;
> -
> -#ifdef CONFIG_X86
> - /*
> -  * There appears to be exactly one user of the mtrr index: dritest.
> -  * It's easy enough to keep it working on non-PAT systems.
> -  */
> - map->mtrr = phys_wc_to_mtrr_index(r_list->map->mtrr);
> -#else
> - map->mtrr = -1;
> -#endif
> + map->mtrr = arch_phys_wc_index(r_list->map->mtrr);
>  
>   mutex_unlock(>struct_mutex);
>  
> diff --git a/include/linux/io.h b/include/linux/io.h
> index

nouveau regression on G5 Dual Core

2015-04-22 Thread Olaf Hering 
On Wed, Apr 22, Olaf Hering wrote:

> I will see which commit leads to the failure that exists since v3.19-rc4.

c2c2f6cb79141ca22f84c36887fd867373c35c4e +
c7e873f85fb60b1af589ac1b0c62353cfe0bbb29 leads to this output:

[   47.367618] nouveau  [  DEVICE][:0a:00.0] BOOT0  : 0x043100a4
[   47.367626] nouveau  [  DEVICE][:0a:00.0] Chipset: NV43 (NV43)
[   47.367629] nouveau  [  DEVICE][:0a:00.0] Family : NV40
[   47.367894] nouveau :0a:00.0: Invalid ROM contents
[   47.367929] nouveau ![   VBIOS][:0a:00.0] unable to locate usable image
[   47.367933] nouveau E[  DEVICE][:0a:00.0] failed to create 0x1001, 
-22
[   47.367937] nouveau E[ DRM] failed to create 0x0080, -22
[   47.368852] nouveau: probe of :0a:00.0 failed with error -22


And using the commit prior the breakage ad4a362^ (which is e897242) leads to
this output and a working console:

[   28.099484] nouveau  [  DEVICE][:0a:00.0] BOOT0  : 0x043100a4
[   28.099491] nouveau  [  DEVICE][:0a:00.0] Chipset: NV43 (NV43)
[   28.099494] nouveau  [  DEVICE][:0a:00.0] Family : NV40
[   28.099610] nouveau  [   VBIOS][:0a:00.0] checking OpenFirmware for 
image...
[   28.099636] nouveau  [   VBIOS][:0a:00.0] ... checksum invalid
[   28.099639] nouveau  [   VBIOS][:0a:00.0] checking PRAMIN for image...
[   28.099645] nouveau  [   VBIOS][:0a:00.0] ... signature not found
[   28.099648] nouveau  [   VBIOS][:0a:00.0] checking PROM for image...
[   28.191159] nouveau  [   VBIOS][:0a:00.0] ... signature not found
[   28.191162] nouveau  [   VBIOS][:0a:00.0] checking ACPI for image...
[   28.191166] nouveau  [   VBIOS][:0a:00.0] ... signature not found
[   28.191169] nouveau  [   VBIOS][:0a:00.0] checking PCIROM for image...
[   28.191207] nouveau :0a:00.0: Invalid ROM contents
[   28.191229] nouveau  [   VBIOS][:0a:00.0] ... signature not found
[   28.191232] nouveau  [   VBIOS][:0a:00.0] checking PLATFORM for image...
[   28.191236] nouveau  [   VBIOS][:0a:00.0] ... signature not found
[   28.191239] nouveau  [   VBIOS][:0a:00.0] using image from OpenFirmware
[   28.191279] nouveau  [   VBIOS][:0a:00.0] BIT signature found
[   28.191284] nouveau  [   VBIOS][:0a:00.0] version 05.43.02.75.00
[   28.191629] u3msi: allocated virq 0x1a (hw 0x9) addr 0xf8004090
[   28.191647] nouveau  [ PMC][:0a:00.0] MSI interrupts enabled
[   28.191705] nouveau  [ PFB][:0a:00.0] RAM type: DDR1
[   28.191708] nouveau  [ PFB][:0a:00.0] RAM size: 256 MiB
[   28.191711] nouveau  [ PFB][:0a:00.0]ZCOMP: 378880 tags
[   28.250490] nouveau  [  PTHERM][:0a:00.0] FAN control: toggle
[   28.250515] nouveau  [  PTHERM][:0a:00.0] internal sensor: no
[   28.270373] nouveau  [ CLK][:0a:00.0] 20: core 300 MHz shader 300 
MHz memory 500 MHz
[   28.270398] nouveau  [ CLK][:0a:00.0] --: core 300 MHz shader 300 
MHz memory 500 MHz
[   28.270556] nouveau :0a:00.0: Using 32-bit DMA via iommu
[   28.270649] [TTM] Zone  kernel: Available graphics memory: 1003278 kiB
[   28.270652] [TTM] Initializing pool allocator
[   28.270687] nouveau  [ DRM] VRAM: 252 MiB
[   28.270690] nouveau  [ DRM] GART: 512 MiB
[   28.270712] nouveau  [ DRM] TMDS table version 1.1
[   28.270716] nouveau  [ DRM] DCB version 3.0
[   28.270720] nouveau  [ DRM] DCB outp 00: 01000100 0028
[   28.270723] nouveau  [ DRM] DCB outp 01: 03000102 
[   28.270727] nouveau  [ DRM] DCB outp 02: 04011210 0028
[   28.270730] nouveau  [ DRM] DCB outp 03: 02111212 02000100
[   28.270733] nouveau  [ DRM] DCB outp 04: 02011211 0020c070
[   28.270736] nouveau  [ DRM] DCB conn 00: 1030
[   28.270740] nouveau  [ DRM] DCB conn 01: 2130
[   28.272297] nouveau  [ I2C][:0a:00.0] detected TMDS transmitter: 
sil164
[   28.277738] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   28.277742] [drm] Driver supports precise vblank timestamp query.
[   28.277750] nouveau  [ DRM] 0x14C5: Parsing digital output script table
[   28.331954] nouveau  [ DRM] MM: using M2MF for buffer copies
[   28.331997] nouveau  [ DRM] Setting dpms mode 3 on TV encoder (output 4)
[   28.377539] nouveau  [ DRM] allocated 1920x1080 fb: 0x9000, bo 
c0007b911400
[   28.400310] nouveau  [ DRM] 0x14C5: Parsing digital output script table
[   28.450037] Console: switching to colour frame buffer device 240x67
[   28.451900] nouveau :0a:00.0: fb0: nouveaufb frame buffer device
[   28.451903] nouveau :0a:00.0: registered panic notifier
[   28.456097] [drm] Initialized nouveau 1.2.1 20120801 for :0a:00.0 on 
minor 0


Olaf

What happened to the patch for module reference counting when using dma-buf API

2015-04-22 Thread Sumit Semwal 
Hi Volker,

On 22 April 2015 at 17:21, Volker Vogelhuber
 wrote:
> I just stumbled across the same problem the patch from Tomasz Stanislawski
> (https://lkml.org/lkml/2012/8/8/163) would solve over two years ago. But it
> seems like it hasn't been merged into mainline. Why not? Is there any other
> possibility to avoid modules being released while other modules still use
> dma buffers of that module?
>

I think the only reason it didn't get merged was because Tomasz didn't
post out the next version of the patch, with the feedback received for
v1.

I know that Tomasz has moved away from working on this area, so if
you'd like to, please feel free to submit an updated/rebased version
for review.

If you wouldn't like to do that for any reason, please let me know,
and I could cook it up instead.

> regards,
>Volker
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Thanks and regards,
Sumit Semwal
Kernel Subteam Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs

[PATCH] nouveau: add coherent BO attribute

2015-04-22 Thread Alexandre Courbot 
On Sun, Mar 15, 2015 at 5:41 PM, Alexandre Courbot  
wrote:
> On 03/14/2015 04:33 AM, Maarten Lankhorst wrote:
>>
>> Hey,
>>
>> Op 13-03-15 om 07:27 schreef Alexandre Courbot:
>>>
>>> Add a flag allowing Nouveau to specify that an object should be coherent
>>> at allocation time. This is required for some class of objects like
>>> fences which are randomly-accessed by both the CPU and GPU. This flag
>>> instructs the kernel driver to make sure the object remains coherent
>>> even on architectures for which coherency is not guaranteed by the bus.
>>>
>>> Signed-off-by: Alexandre Courbot 
>>
>> I don't see a problem with this patch, but similar patches to intel to
>> libdrm have been shot down when the changes weren't in an official kernel
>> yet, so I think this should wait until the change is at least in drm-next.
>> ;-)
>
>
> Sounds good. I will ping you again once the kernel change reaches -next.

Hi Marteen,

The kernel change required for this patch is now in -next. Do you
think we can merge it now?

nouveau regression on G5 Dual Core

2015-04-22 Thread Olaf Hering 
On Mon, Mar 30, Olaf Hering wrote:

> On Sat, Mar 28, Olaf Hering wrote:
> 
> > On Sat, Mar 28, Olaf Hering wrote:
> > 
> > > I just updated the kernel from some 3.18 based state to 4.0-rc5+. The
> > 
> > 3.19 is already broken, will bisect next week.
> 
> After a first run I was able to boot prior the first bad commit, which caused 
> a
> crash on boot.  Now I have to find the commit which actually allows boot 
> again,
> but with the white screen.
> 
> Ben, was ad4a362635353f7ceb66f4038269770fee1025fa tested on a pmac?

c7e873f85fb60b1af589ac1b0c62353cfe0bbb29 fixed the crash, but not the
failure to read the ROM contents.

So what exactly did ad4a362635353f7ceb66f4038269770fee1025fa change?

A kernel build from ad4a362635353f7ceb66f4038269770fee1025fa plus the fix
c7e873f85fb60b1af589ac1b0c62353cfe0bbb29 gives this in dmesg:

[   29.621628] nouveau  [  DEVICE][:0a:00.0] BOOT0  : 0x043100a4
[   29.621635] nouveau  [  DEVICE][:0a:00.0] Chipset: NV43 (NV43)
[   29.621638] nouveau  [  DEVICE][:0a:00.0] Family : NV40
[   29.713302] nouveau  [   VBIOS][:0a:00.0] using image from PROM
[   29.713616] nouveau  [   VBIOS][:0a:00.0] version 00.00.00.00.00
[   29.713689] nouveau W[   VBIOS][:0a:00.0] DCB table not found
[   29.713698] nouveau W[   VBIOS][:0a:00.0] DCB table not found
[   29.713733] nouveau W[   VBIOS][:0a:00.0] 0x[ ]: init data not found
[   29.713783] u3msi: allocated virq 0x1a (hw 0x9) addr 0xf8004090
[   29.713808] nouveau  [ PMC][:0a:00.0] MSI interrupts enabled
[   29.713868] nouveau  [ PFB][:0a:00.0] RAM type: DDR1
[   29.713871] nouveau  [ PFB][:0a:00.0] RAM size: 256 MiB
[   29.713874] nouveau  [ PFB][:0a:00.0]ZCOMP: 378880 tags
[   29.740738] nouveau W[   VBIOS][:0a:00.0] DCB table not found
[   29.740746] nouveau W[   VBIOS][:0a:00.0] DCB table not found
[   29.740755] nouveau W[   VBIOS][:0a:00.0] DCB table not found
[   29.740760] nouveau W[   VBIOS][:0a:00.0] DCB table not found
[   29.740763] nouveau W[   VBIOS][:0a:00.0] DCB table not found
[   29.740767] nouveau  [  PTHERM][:0a:00.0] FAN control: none / external
[   29.740770] nouveau W[   VBIOS][:0a:00.0] DCB table not found
[   29.740773] nouveau W[   VBIOS][:0a:00.0] DCB table not found
[   29.740788] nouveau  [  PTHERM][:0a:00.0] internal sensor: no
[   29.760655] nouveau  [ CLK][:0a:00.0] --: core 300 MHz shader 300 
MHz memory 500 MHz
[   29.760722] nouveau W[   VBIOS][:0a:00.0] DCB table not found
[   29.760796] nouveau :0a:00.0: Using 32-bit DMA via iommu
[   29.760891] [TTM] Zone  kernel: Available graphics memory: 1003278 kiB
[   29.760894] [TTM] Initializing pool allocator
[   29.760928] nouveau  [ DRM] VRAM: 252 MiB
[   29.760931] nouveau  [ DRM] GART: 512 MiB
[   29.760959] [TTM] Finalizing pool allocator
[   29.760989] [TTM] Zone  kernel: Used memory at exit: 0 kiB
[   29.762856] insmod (775) used greatest stack depth: 6080 bytes left


I will see which commit leads to the failure that exists since v3.19-rc4.


Olaf


> root at g5:~/work/kernel/linux # git bisect log 
> git bisect start
> # good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18
> git bisect good b2776bf7149bddd1f4161f14f79520f17fc1d71d
> # bad: [bfa76d49576599a4b9f9b7a71f23d73d6dcff735] Linux 3.19
> git bisect bad bfa76d49576599a4b9f9b7a71f23d73d6dcff735
> # good: [54850e73e86e3bc092680d1bdb84eb322f982ab1] zram: change parameter 
> from vaild_io_request()
> git bisect good 54850e73e86e3bc092680d1bdb84eb322f982ab1
> # bad: [dab363f938a53ddaee60bfecc1aebdbb3d3af5f0] Merge tag 
> 'staging-3.19-rc1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> git bisect bad dab363f938a53ddaee60bfecc1aebdbb3d3af5f0
> # good: [26178ec11ef3c6c814bf16a0a2b9c2f7242e3c64] x86: mm: consolidate 
> VM_FAULT_RETRY handling
> git bisect good 26178ec11ef3c6c814bf16a0a2b9c2f7242e3c64
> # good: [1b4bcf1fedbe7dcd98d9d35dfc947f033a398c4d] staging: comedi: 
> addi_tcw.h: provide generic defines for the ADDI-DATA TCW
> git bisect good 1b4bcf1fedbe7dcd98d9d35dfc947f033a398c4d
> # good: [030794a368946b98a8252d3172f5f2a1b0e4fb0e] drm/exynos: Fix DSI 
> resuming fail because power domain being off
> git bisect good 030794a368946b98a8252d3172f5f2a1b0e4fb0e
> # bad: [59ea90543f57a40827d7d1e528d657b8cc7161b1] drm/i915: Implement GPU 
> reset for 915/945
> git bisect bad 59ea90543f57a40827d7d1e528d657b8cc7161b1
> # bad: [37025602f6abc5919c7d5a8517bc7d6ea08acc57] drm/nouveau/platform: add 
> GPU speedo information to nouveau platform
> git bisect bad 37025602f6abc5919c7d5a8517bc7d6ea08acc57
> # good: [33f86ff62c4368c8d6bf3c76dc2fa416e3f90213] Merge branch 
> 'amdkfd-next-3.19' of git://people.freedesktop.org/~gabbayo/linux into 
> drm-next
> git bisect good 33f86ff62c4368c8d6bf3c76dc2fa416e3f90213
> # bad: [1f89b4756fb83f385ac0e277b092774c01a5ab9c] drm/gm204/disp: initial 
> support
> git bisect bad 1f89b4756fb83f385ac0e277b092774c01a5ab9c

[PATCH 2/5] drm: Add edid_corrupt flag for Displayport Link CTS 4.2.2.6

2015-04-22 Thread Alex Deucher 
On Tue, Apr 21, 2015 at 2:09 PM, Todd Previte  wrote:
> Displayport compliance test 4.2.2.6 requires that a source device be capable 
> of
> detecting a corrupt EDID. The test specification states that the sink device
> sets up the EDID with an invalid checksum. To do this, the sink sets up an
> invalid EDID header, expecting the source device to generate the checksum and
> compare it to the value stored in the last byte of the block data.
>
> Unfortunately, the DRM EDID reading and parsing functions are actually too 
> good
> in this case; the header is fixed before the checksum is computed and thus the
> test never sees the invalid checksum. This results in a failure to pass the
> compliance test.
>
> To correct this issue, when the EDID code detects that the header is invalid,
> a flag is set to indicate that the EDID is corrupted. In this case, it sets
> edid_corrupt flag and continues with its fix-up code. This flag is also set in
> the case of a more seriously damaged header (fixup score less than the
> threshold). For consistency, the edid_corrupt flag is also set when the
> checksum is invalid as well.
>
> V2:
> - Removed the static bool global
> - Added a bool to the drm_connector struct to reaplce the static one for
>   holding the status of raw edid header corruption detection
> - Modified the function signature of the is_valid function to take an
>   additional parameter to store the corruption detected value
> - Fixed the other callers of the above is_valid function
> V3:
> - Updated the commit message to be more clear about what and why this
>   patch does what it does.
> - Added comment in code to clarify the operations there
> - Removed compliance variable and check_link_status update; those
>   have been moved to a later patch
> - Removed variable assignment from the bottom of the test handler
> V4:
> - Removed i915 tag from subject line as the patch is not i915-specific
> V5:
> - Moved code causing a compilation error to this patch where the variable
>   is actually declared
> - Maintained blank lines / spacing so as to not contaminate the patch
> V6:
> - Removed extra debug messages
> - Added documentation to for the added parameter on drm_edid_block_valid
> - Fixed more whitespace issues in check_link_status
> - Added a clear of the header_corrupt flag to the end of the test handler
>   in intel_dp.c
> - Changed the usage of the new function prototype in several places to use
>   NULL where it is not needed by compliance testing
> V7:
> - Updated to account for long_pulse flag propagation
> V8:
> - Removed clearing of header_corrupt flag from the test handler in intel_dp.c
> - Added clearing of header_corrupt flag in the drm_edid_block_valid function
> V9:
> - Renamed header_corrupt flag to edid_corrupt to more accurately reflect its
>   value and purpose
> - Updated commit message
> V10:
> - Updated for versioning and patch swizzle
> - Revised the title to more accurately reflect the nature and contents of
>   the patch
> - Fixed formatting/whitespace problems
> - Added set flag when computed checksum is invalid
>
> Signed-off-by: Todd Previte 
> Cc: dri-devel at lists.freedesktop.org

Seems reasonable.

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_edid.c  | 32 ++--
>  drivers/gpu/drm/drm_edid_load.c |  7 +--
>  include/drm/drm_crtc.h  |  8 +++-
>  3 files changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 53bc7a6..be6713c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1041,13 +1041,15 @@ static bool drm_edid_is_zero(const u8 *in_edid, int 
> length)
>   * @raw_edid: pointer to raw EDID block
>   * @block: type of block to validate (0 for base, extension otherwise)
>   * @print_bad_edid: if true, dump bad EDID blocks to the console
> + * @edid_corrupt: if true, the header or checksum is invalid
>   *
>   * Validate a base or extension EDID block and optionally dump bad blocks to
>   * the console.
>   *
>   * Return: True if the block is valid, false otherwise.
>   */
> -bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
> +bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
> + bool *edid_corrupt)
>  {
> u8 csum;
> struct edid *edid = (struct edid *)raw_edid;
> @@ -1060,11 +1062,22 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, 
> bool print_bad_edid)
>
> if (block == 0) {
> int score = drm_edid_header_is_valid(raw_edid);
> -   if (score == 8) ;
> -   else if (score >= edid_fixup) {
> +   if (score == 8) {
> +   if (edid_corrupt)
> +   *edid_corrupt = 0;
> +   } else if (score >= edid_fixup) {
> +   /* Displayport Link CTS Core 1.2 rev1.1 test 4.2.2.6
> +* The corrupt

[PATCH 00/11] Enable gpu switching on the MacBook Pro

2015-04-22 Thread Lukas Wunner 
Hi Matthew,

On Tue, Apr 21, 2015 at 08:49:35PM +0100, Matthew Garrett wrote:
> My testing suggested that changing the DDC lines didn't change auxch, so 
> this approach doesn't work for eDP. Have you found otherwise?

I only have a MacBookPro9,1 available for testing, which was the last
non-retina and thus uses LVDS. So I can vouch for proper functioning
of the patchset on pre-retinas, not on retinas (which use eDP because
dual channel LVDS maxes out 2048×1536 at 60 Hz, the retinas have 2880x1800).

Background:
The last non-retina (MacBookPro9,1) and the first retina (MacBookPro10,1)
were sold alongside each other, from June 2012 to October 2013.
The following generation (MacBookPro11, October 2013) was retina only.
Pre-retina MacBookPros with dual GPUs Intel/Nvidia or Intel/AMD were
available starting with the MacBookPro6, April 2010.

I cannot verify that gmux doesn't switch auxch but I understand you
worked around this by stashing the EDID after nouveau has read it and
retrieving the stashed version from i915:
http://www.codon.org.uk/~mjg59/tmp/retina_patches/0016-vga_switcheroo-Allow-stashing-of-panel-data.patch
http://www.codon.org.uk/~mjg59/tmp/retina_patches/0025-i915-Use-vga_switcheroo-to-obtain-and-stash-EDID-DPC.patch
http://www.codon.org.uk/~mjg59/tmp/retina_patches/0026-nouveau-Use-vga_switcheroo-to-obtain-and-stash-EDID-.patch

It would be great if someone with a retina MBP could test my patchset,
and if it doesn't work, try it with these three patches applied on top.

Thanks,

Lukas

[PATCH RFC v9 11/20] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver

2015-04-22 Thread Heiko Stübner 
Am Donnerstag, 16. April 2015, 11:09:58 schrieb Archit Taneja:
> On 04/09/2015 02:13 PM, Thierry Reding wrote:
> > On Thu, Feb 12, 2015 at 02:01:34PM +0800, Liu Ying wrote:
> > [...]
> > 
> >> diff --git a/drivers/gpu/drm/bridge/dw_mipi_dsi.c
> >> b/drivers/gpu/drm/bridge/dw_mipi_dsi.c> 
> > [...]
> > 
> >> +struct dw_mipi_dsi {
> >> +  struct mipi_dsi_host dsi_host;
> >> +  struct drm_connector connector;
> >> +  struct drm_encoder *encoder;
> >> +  struct drm_bridge *bridge;
> >> +  struct drm_panel *panel;
> >> +  struct device *dev;
> >> +
> >> +  void __iomem *base;
> >> +
> >> +  struct clk *pllref_clk;
> >> +  struct clk *cfg_clk;
> >> +  struct clk *pclk;
> >> +
> >> +  unsigned int lane_mbps; /* per lane */
> >> +  u32 channel;
> >> +  u32 lanes;
> >> +  u32 format;
> >> +  struct drm_display_mode *mode;
> >> +
> >> +  const struct dw_mipi_dsi_plat_data *pdata;
> >> +
> >> +  bool enabled;
> >> +};
> > 
> > While reviewing this I kept thinking whether this is really the right
> > architectural design. This driver is a MIPI DSI host, a connector and
> > a bridge, all in one. But it seems to me like it should really be an
> > encoder/connector and a MIPI DSI host. Why the need for a bridge? The
> > bridge abstraction targets blocks outside of the SoC, but it is my
> > understanding that these DesignWare IP blocks are designed into SoCs.
> 
> The msm driver uses bridges for blocks within the SoC too. We have too
> many sub blocks in the display controller that use up crtcs and encoder
> entities. A bridge is the only option one has if an encoder in the
> display chain is already taken.
> 
> In the above designware configuration, if some one created a board that
> used an external chip to further convert DSI to some other output
> format, then we would be completely exhausted of all entities.
> 
> I posted a patch that allows us to create a chain of bridges for such
> cases. It seems to work well as an interim solution. Ideally, it would
> be better if we could make bridge a special case of an encoder, and let
> one encoder connect to another encoder.
> 
> Such a thing would also help us unify i2c slave encoders and bridge
> drivers too. A chip designed as an i2c slave encoder would work well
> with a drm driver that doesn't have an encoder, but won't work for SoCs
> SoCs that already have an encoder and were expecting a bridge entity
> instead.

Yeah, having encoder-after-encoder chains would be great. I have the same 
issue on Rockchip where on the rk3288 the lvds-IP hogs the lcd-pins of the soc 
which are used both for panels as well as external encoders, while on the 
older Rockchip SoCs these pins are used by external encoders directly.

So in my current (pending review) patchset the lvds acts as encoder for panels 
and as bridge if external encoders are in use.

What happened to the patch for module reference counting when using dma-buf API

2015-04-22 Thread Volker Vogelhuber 
I just stumbled across the same problem the patch from Tomasz 
Stanislawski (https://lkml.org/lkml/2012/8/8/163) would solve over two 
years ago. But it seems like it hasn't been merged into mainline. Why 
not? Is there any other possibility to avoid modules being released 
while other modules still use dma buffers of that module?

regards,
Volker

[PATCH libdrm 0/5] modetest: fix misc when terminates modetest

2015-04-22 Thread Joonyoung Shim 
Hi Emil,

On 04/22/2015 05:16 AM, Emil Velikov wrote:
> Hi Joonyoung,
> 
> On 13/04/15 08:31, Joonyoung Shim wrote:
>> Hi all,
>>
>> This patchset is to fix properly about buffer and framebuffer resources
>> when terminates modetest of libdrm.
>>
> The series looks great (incl. the MAKE_RGB_INFO fix) and barring any
> objections I'll push it by the end of the week. Just a small sidenote -
> some of the commit messages are a bit hard to read. Hope you don't mind
> if I change them slightly before pushing.

It's ok, i guess i should thank you.

Thanks.

[Intel-gfx] [PATCH -next] drm/i915/audio: remove duplicated include from intel_audio.c

2015-04-22 Thread John Hunter 
Sure, but I need Daniel to admit that, because maybe include the two header
file make it easier to understand.
And after checked other files in drm/i915, I found that a lot other file do
the
same thing(include both header file). So I will just wait Daniel to wait up
and
give me the order :-)

On Wed, Apr 22, 2015 at 10:35 AM, yongjun_wei at trendmicro.com.cn <
yongjun_wei at trendmicro.com.cn> wrote:

>  Hi John,
>
>
>
> Feel free to submit a new patch.
>
>
>
> Regards,
>
> Yongjun Wei
>
>
>
> *From:* John Hunter [mailto:zhjwpku at gmail.com]
> *Sent:* 2015年4月22日 10:30
> *To:* weiyj_lk at 163.com; Daniel Vetter; Jani Nikula; David Airlie; Yongjun
> Wei (RD-CN); intel-gfx at lists.freedesktop.org;
> dri-devel at lists.freedesktop.org; open list
> *Subject:* Re: [Intel-gfx] [PATCH -next] drm/i915/audio: remove
> duplicated include from intel_audio.c
>
>
>
> Hi,
>
>
>
> I think maybe we should remove both of the two lines:
>
> #include "intel_drv.h"
>
> #include "i915_drv.h"
>
> Because we have* two* "intel_drv.h" and *one* "i915_drv.h", and
>
> "i915_drv.h" has already been included in the "intel_drv.h".
>
>
>
> I not sure whether i am right. If you need me to do the patch,
>
> let me know.
>
>
>
>
>
> On Thu, Apr 16, 2015 at 10:30 PM, Daniel Vetter  wrote:
>
> On Thu, Apr 16, 2015 at 09:11:08PM +0800, weiyj_lk at 163.com wrote:
> > From: Wei Yongjun 
> >
> > Remove duplicated include.
> >
> > Signed-off-by: Wei Yongjun 
>
> Queued for -next, thanks for the patch.
> -Daniel
>
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> > index 2396cc7..d00d488 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -28,7 +28,6 @@
> >
> >  #include 
> >  #include 
> > -#include "intel_drv.h"
> >  #include "i915_drv.h"
> >
> >  /**
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
>
>
> --
>
> Best regards
>
> Junwang Zhao
>
> Microprocessor Research and Develop Center
>
> Department of Computer Science 
>
> Peking University
>
> Beijing, 100871, PRC
>
> ===
>
> This message has been analyzed by Deep Discovery Email Inspector.
>
>
>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail or
> telephone and delete the original message from your mail system.
>
>


-- 
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science 
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150422/8fd9604a/attachment.html>

[Intel-gfx] [PATCH -next] drm/i915/audio: remove duplicated include from intel_audio.c

2015-04-22 Thread John Hunter 
Hi,

I think maybe we should remove both of the two lines:
#include "intel_drv.h"
#include "i915_drv.h"
Because we have* two* "intel_drv.h" and *one* "i915_drv.h", and
"i915_drv.h" has already been included in the "intel_drv.h".

I not sure whether i am right. If you need me to do the patch,
let me know.


On Thu, Apr 16, 2015 at 10:30 PM, Daniel Vetter  wrote:

> On Thu, Apr 16, 2015 at 09:11:08PM +0800, weiyj_lk at 163.com wrote:
> > From: Wei Yongjun 
> >
> > Remove duplicated include.
> >
> > Signed-off-by: Wei Yongjun 
>
> Queued for -next, thanks for the patch.
> -Daniel
>
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> > index 2396cc7..d00d488 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -28,7 +28,6 @@
> >
> >  #include 
> >  #include 
> > -#include "intel_drv.h"
> >  #include "i915_drv.h"
> >
> >  /**
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>



-- 
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science 
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150422/21dacf66/attachment.html>

[PATCH v4] mtrr: avoid ifdef'ery with phys_wc_to_mtrr_index()

2015-04-22 Thread Luis R. Rodriguez 
From: "Luis R. Rodriguez" 

There is only one user but since we're going to bury
MTRR next out of access to drivers expose this last
piece of API to drivers in a general fashion only
needing io.h for access to helpers.

Cc: Toshi Kani 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Will Deacon 
Cc: Thierry Reding 
Cc: Andrew Morton 
Cc: Dave Hansen 
Cc: Greg Kroah-Hartman 
Cc: Catalin Marinas 
Cc: Abhilash Kesavan 
Cc: Matthias Brugger 
Cc: Cristian Stoica 
Cc: dri-devel at lists.freedesktop.org
Cc: Suresh Siddha 
Cc: Linus Torvalds 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: Ville Syrjälä 
Cc: Mel Gorman 
Cc: Vlastimil Babka 
Cc: Borislav Petkov 
Cc: Davidlohr Bueso 
Cc: x86 at kernel.org
Cc: linux-fbdev at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---

This v4 adds a missing #endif.

 arch/x86/include/asm/io.h   |  3 +++
 arch/x86/include/asm/mtrr.h |  5 -
 arch/x86/kernel/cpu/mtrr/main.c |  6 +++---
 drivers/gpu/drm/drm_ioctl.c | 14 +-
 include/linux/io.h  |  7 +++
 5 files changed, 14 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 4afc05f..a2b9740 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -339,6 +339,9 @@ extern bool xen_biovec_phys_mergeable(const struct bio_vec 
*vec1,
 #define IO_SPACE_LIMIT 0x

 #ifdef CONFIG_MTRR
+extern int __must_check arch_phys_wc_index(int handle);
+#define arch_phys_wc_index arch_phys_wc_index
+
 extern int __must_check arch_phys_wc_add(unsigned long base,
 unsigned long size);
 extern void arch_phys_wc_del(int handle);
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index da8dff1..27e3dc0 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -48,7 +48,6 @@ extern void mtrr_aps_init(void);
 extern void mtrr_bp_restore(void);
 extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
 extern int amd_special_default_mtrr(void);
-extern int phys_wc_to_mtrr_index(int handle);
 #  else
 static inline u8 mtrr_type_lookup(u64 addr, u64 end, u8 *uniform)
 {
@@ -85,10 +84,6 @@ static inline int mtrr_trim_uncached_memory(unsigned long 
end_pfn)
 static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
 {
 }
-static inline int phys_wc_to_mtrr_index(int handle)
-{
-   return -1;
-}

 #define mtrr_ap_init() do {} while (0)
 #define mtrr_bp_init() do {} while (0)
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 12abdbe..d8c106c 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -580,7 +580,7 @@ void arch_phys_wc_del(int handle)
 EXPORT_SYMBOL(arch_phys_wc_del);

 /*
- * phys_wc_to_mtrr_index - translates arch_phys_wc_add's return value
+ * arch_phys_wc_index - translates arch_phys_wc_add's return value
  * @handle: Return value from arch_phys_wc_add
  *
  * This will turn the return value from arch_phys_wc_add into an mtrr
@@ -590,14 +590,14 @@ EXPORT_SYMBOL(arch_phys_wc_del);
  * in printk line.  Alas there is an illegitimate use in some ancient
  * drm ioctls.
  */
-int phys_wc_to_mtrr_index(int handle)
+int arch_phys_wc_index(int handle)
 {
if (handle < MTRR_TO_PHYS_WC_OFFSET)
return -1;
else
return handle - MTRR_TO_PHYS_WC_OFFSET;
 }
-EXPORT_SYMBOL_GPL(phys_wc_to_mtrr_index);
+EXPORT_SYMBOL_GPL(arch_phys_wc_index);

 /*
  * HACK ALERT!
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 266dcd6..0a95782 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -36,9 +36,6 @@

 #include 
 #include 
-#ifdef CONFIG_X86
-#include 
-#endif

 static int drm_version(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
@@ -197,16 +194,7 @@ static int drm_getmap(struct drm_device *dev, void *data,
map->type = r_list->map->type;
map->flags = r_list->map->flags;
map->handle = (void *)(unsigned long) r_list->user_token;
-
-#ifdef CONFIG_X86
-   /*
-* There appears to be exactly one user of the mtrr index: dritest.
-* It's easy enough to keep it working on non-PAT systems.
-*/
-   map->mtrr = phys_wc_to_mtrr_index(r_list->map->mtrr);
-#else
-   map->mtrr = -1;
-#endif
+   map->mtrr = arch_phys_wc_index(r_list->map->mtrr);

mutex_unlock(>struct_mutex);

diff --git a/include/linux/io.h b/include/linux/io.h
index 986f2bf..04cce4d 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -111,6 +111,13 @@ static inline void arch_phys_wc_del(int handle)
 }

 #define arch_phys_wc_add arch_phys_wc_add
+#ifndef arch_phys_wc_index
+static inline int arch_phys_wc_index(int handle)
+{
+   return -1;
+}

[Bug 89944] GPU crash in Civilization 5

2015-04-22 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=89944

Marek Olšák  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Marek Olšák  ---
(In reply to Sami Liedes from comment #9)
> Tested; cannot reproduce problem with latest mesa (28d9e904) and llvm
> (r234939).

Ok. Closing then.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150422/d6988053/attachment-0001.html>

[Bug 81382] Text console blanking does not go away

2015-04-22 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=81382

--- Comment #37 from Christophe Migliorini <mig+freedesktop at 
chene.vingt-et-un-cinq.fr> ---
Apparently only "set the default backlight level to something reasonable" patch
was applied to 3.13, so I don't have the "radeon_encoder_add_backlight"
function, thus this won't work at all.

Would you suggest I first apply the patch published here on 2014-09-17?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150422/f731ccb3/attachment.html>

[PATCH libdrm] Add missing includes

2015-04-22 Thread Greg Hackmann 
On Tue, Apr 21, 2015 at 11:31 AM, Emil Velikov  
wrote:
>
> I'm not sure why I haven't hit this while building with Android-x86's
> bionic, although it's the right thing to do.

Maybe a difference in bionic versions?  I know the bionic team made
some recent (post-5.1) changes that unintentionally exposed a handful
of other missing #includes in our tree.

> From a quick look I cannot see libdrm in the AOSP build. Are you
> experimenting with a libdrm based hwcompositor again :-)

Yeah.  That's where I want to end up in the long term, anyway.  I've
said publicly that we'd eventually like to converge with upstream on
this, and I still mean it.  :)

[Intel-gfx] [PATCH -next] drm/i915/audio: remove duplicated include from intel_audio.c

2015-04-22 Thread yongjun_...@trendmicro.com.cn 
Hi John,

Feel free to submit a new patch.

Regards,
Yongjun Wei

From: John Hunter [mailto:zhjw...@gmail.com]
Sent: 2015年4月22日 10:30
To: weiyj_lk at 163.com; Daniel Vetter; Jani Nikula; David Airlie; Yongjun Wei 
(RD-CN); intel-gfx at lists.freedesktop.org; dri-devel at 
lists.freedesktop.org; open list
Subject: Re: [Intel-gfx] [PATCH -next] drm/i915/audio: remove duplicated 
include from intel_audio.c

Hi,

I think maybe we should remove both of the two lines:
#include "intel_drv.h"
#include "i915_drv.h"
Because we have two "intel_drv.h" and one "i915_drv.h", and
"i915_drv.h" has already been included in the "intel_drv.h".

I not sure whether i am right. If you need me to do the patch,
let me know.


On Thu, Apr 16, 2015 at 10:30 PM, Daniel Vetter mailto:daniel at ffwll.ch>> wrote:
On Thu, Apr 16, 2015 at 09:11:08PM +0800, weiyj_lk at 163.com<mailto:weiyj_lk 
at 163.com> wrote:
> From: Wei Yongjun mailto:yongjun_wei at 
> trendmicro.com.cn>>
>
> Remove duplicated include.
>
> Signed-off-by: Wei Yongjun  trendmicro.com.cn<mailto:yongjun_wei at trendmicro.com.cn>>

Queued for -next, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_audio.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 2396cc7..d00d488 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -28,7 +28,6 @@
>
>  #include 
>  #include 
> -#include "intel_drv.h"
>  #include "i915_drv.h"
>
>  /**
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org<mailto:Intel-gfx at lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel at lists.freedesktop.org<mailto:dri-devel at lists.freedesktop.org>
http://lists.freedesktop.org/mailman/listinfo/dri-devel



--
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science 
Peking University
Beijing, 100871, PRC

===

This message has been analyzed by Deep Discovery Email Inspector.




TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150422/9c630c28/attachment-0001.html>