Re: linux-next: Tree for May 6 (nouveau)

2010-05-06 Thread Randy Dunlap 
On Thu, 6 May 2010 15:15:02 +1000 Stephen Rothwell wrote:

 Hi all,
 
 Changes since 20100505:


When CONFIG_ACPI_BUTTON=m:

drivers/built-in.o: In function `nouveau_connector_detect':
nouveau_connector.c:(.text+0x1d81cf): undefined reference to `acpi_lid_open'


#ifdef CONFIG_ACPI
if (!nouveau_ignorelid  !acpi_lid_open())
status = connector_status_unknown;
#endif


Do you want that to be
#ifdef CONFIG_ACPI_BUTTON
?
That will still only be built when CONFIG_ACPI_BUTTON=y (not =m).

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] nouveau: fix acpi_lid_open undefined

2010-05-23 Thread Randy Dunlap 
From: Randy Dunlap randy.dun...@oracle.com

When CONFIG_ACPI_BUTTON=m (and probably when ACPI_BUTTON is not enabled)
and NOUVEAU is built-in (not as a loadable module):

nouveau_connector.c:(.text+0xe17ce): undefined reference to `acpi_lid_open'

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/nouveau/nouveau_connector.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-next-20100522.orig/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ linux-next-20100522/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -241,7 +241,8 @@ nouveau_connector_detect(struct drm_conn
if (nv_encoder  nv_connector-native_mode) {
unsigned status = connector_status_connected;
 
-#ifdef CONFIG_ACPI
+#if defined(CONFIG_ACPI_BUTTON) || \
+   (defined(CONFIG_ACPI_BUTTON_MODULE)  defined(MODULE))
if (!nouveau_ignorelid  !acpi_lid_open())
status = connector_status_unknown;
 #endif
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH -next] nouveau: fix acpi_lid_open undefined

2010-05-24 Thread Randy Dunlap 
On 05/24/10 06:59, Matthew Garrett wrote:
 On Mon, May 24, 2010 at 06:53:51AM -0700, Randy Dunlap wrote:
 On 05/24/10 05:56, Matthew Garrett wrote:
 Won't this result in a behavioural difference? The desirable outcome is 

 It could, yes.

 that that configuration be impossible, not for that configuration to 
 build but be buggy.

 so nouveau should depend on (or select, if ACPI is enabled) ACPI_BUTTON?
 
 There's an argument that it doesn't need to depend on it, but if button 
 is a module then nouveau has to be. Except the inverse isn't true. 
 Kconfig is hard, let's weep gently.

Maybe Dave can weep with us when he is back at work...


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] drm: ttm_page_alloc, fix all sparse warnings

2010-06-28 Thread Randy Dunlap 
From: Randy Dunlap randy.dun...@oracle.com

Fix all sparse warnings in ttm_page_alloc.c.

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/gpu/drm/ttm/ttm_page_alloc.c:819:26: warning: non-ANSI function 
declaration of function 'ttm_page_alloc_fini'
drivers/gpu/drm/ttm/ttm_page_alloc.c:499:21: warning: incorrect type in 
argument 1 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:499:21:expected restricted gfp_t 
[usertype] gfp_mask
drivers/gpu/drm/ttm/ttm_page_alloc.c:499:21:got int [signed] gfp_flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:670:25: warning: incorrect type in 
initializer (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:670:25:expected int [signed] gfp_flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:670:25:got restricted gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:675:27: warning: invalid assignment: |=
drivers/gpu/drm/ttm/ttm_page_alloc.c:675:27:left side has type int
drivers/gpu/drm/ttm/ttm_page_alloc.c:675:27:right side has type restricted 
gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:680:35: warning: invalid assignment: |=
drivers/gpu/drm/ttm/ttm_page_alloc.c:680:35:left side has type int
drivers/gpu/drm/ttm/ttm_page_alloc.c:680:35:right side has type restricted 
gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:682:35: warning: invalid assignment: |=
drivers/gpu/drm/ttm/ttm_page_alloc.c:682:35:left side has type int
drivers/gpu/drm/ttm/ttm_page_alloc.c:682:35:right side has type restricted 
gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:685:29: warning: incorrect type in 
argument 1 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:685:29:expected restricted gfp_t 
[usertype] gfp_mask
drivers/gpu/drm/ttm/ttm_page_alloc.c:685:29:got int [signed] gfp_flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:793:54: warning: incorrect type in 
argument 2 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:793:54:expected int [signed] flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:793:54:got restricted gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:795:54: warning: incorrect type in 
argument 2 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:795:54:expected int [signed] flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:795:54:got restricted gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:797:69: warning: incorrect type in 
argument 2 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:797:69:expected int [signed] flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:797:69:got restricted gfp_t
drivers/gpu/drm/ttm/ttm_page_alloc.c:800:69: warning: incorrect type in 
argument 2 (different base types)
drivers/gpu/drm/ttm/ttm_page_alloc.c:800:69:expected int [signed] flags
drivers/gpu/drm/ttm/ttm_page_alloc.c:800:69:got restricted gfp_t
--- linux-next-20100625.orig/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ linux-next-20100625/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -67,7 +67,7 @@ struct ttm_page_pool {
spinlock_t  lock;
boolfill_lock;
struct list_headlist;
-   int gfp_flags;
+   gfp_t   gfp_flags;
unsignednpages;
char*name;
unsigned long   nfrees;
@@ -476,7 +476,7 @@ static void ttm_handle_caching_state_fai
  * This function is reentrant if caller updates count depending on number of
  * pages returned in pages array.
  */
-static int ttm_alloc_new_pages(struct list_head *pages, int gfp_flags,
+static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
int ttm_flags, enum ttm_caching_state cstate, unsigned count)
 {
struct page **caching_array;
@@ -667,7 +667,7 @@ int ttm_get_pages(struct list_head *page
 {
struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
struct page *p = NULL;
-   int gfp_flags = GFP_USER;
+   gfp_t gfp_flags = GFP_USER;
int r;
 
/* set zero flag for page allocation if required */
@@ -771,7 +771,7 @@ void ttm_put_pages(struct list_head *pag
ttm_page_pool_free(pool, page_count);
 }
 
-static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, int flags,
+static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, gfp_t flags,
char *name)
 {
spin_lock_init(pool-lock);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for July 8 (nouveau)

2010-07-08 Thread Randy Dunlap 
On Thu, 8 Jul 2010 15:10:22 +1000 Stephen Rothwell wrote:

 Hi all,
 
 Changes since 20100707:
 
 The i.MX tree mismerge has been fixed.
 
 The omap tree gained a conflict (involving serveral files) against the
 arm tree.
 
 


Should nouveau depend on PCI?
It has build errors when PCI is disabled:

drivers/gpu/drm/nouveau/nouveau_bios.c: In function 'load_vbios_pci':
drivers/gpu/drm/nouveau/nouveau_bios.c:167: error: implicit declaration of 
function 'pci_enable_rom'
drivers/gpu/drm/nouveau/nouveau_bios.c:171: error: implicit declaration of 
function 'pci_map_rom'
drivers/gpu/drm/nouveau/nouveau_bios.c:171: warning: assignment makes pointer 
from integer without a cast
drivers/gpu/drm/nouveau/nouveau_bios.c:175: error: implicit declaration of 
function 'pci_unmap_rom'
drivers/gpu/drm/nouveau/nouveau_bios.c:178: error: implicit declaration of 
function 'pci_disable_rom'

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Any SYSRQ key to force mode switch to console mode when using KMS?

2010-09-24 Thread Randy Dunlap 
On Thu, 23 Sep 2010 18:31:32 +0200 Uwe Bonnes wrote:

[just adding cc's]

  Randy == Randy Dunlap rdun...@xenotime.net writes:
 
 
 Randy Is CONFIG_DRM_KMS_HELPER enabled in your kernel .config file?  If
 Randy not, we need to find out how to enable it (there is no kconfig
 Randy prompt for it).
 
 Yes, it is enabled
 
 Randy Can you check if Alt-Sysrq-H (help) lists V for force-fb(V)?
 Yes, it is listed.
 
 And yes, my last experiments where with ALT-CTL-sysreq, so doomed for non
 function due to operator error.
 
 However:
 When running X, X.Org X Server 1.9.0 on Thinkpad R50 RV250, Alt-Sysrq-v
 switches to an all-black display. By console switching with ALT-CLT-F1 I
 get back to the booting console and ALT-CLT-F7 brings me back to X.  Running
 on the console and calling Alt-Sysrq-v prints
  SysRq : Restore framebuffer console
 
 Is there some omission by the distribution or my setup that Alt-Sysrq-v when
 running X results in an all-black screen?
 
 And when I hit the hibernate problem, the screen stays black even with a
 console switch after Alt-Sysrq-v
 
 Bye
 -- 
 Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
 
 Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 - Tel. 06151 162516  Fax. 06151 164321 --


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] gpu/drm: fix build errors and kconfig dependency warnings

2010-10-13 Thread Randy Dunlap 
On Wed, 13 Oct 2010 15:45:22 +1100 Stephen Rothwell wrote:

 Hi all,
 
 Changes since 20101012:
 
 The drm tree gained a conflict against the kgdb tree.


ERROR: hwmon_device_unregister [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
ERROR: hwmon_device_register [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
ERROR: video_output_unregister [drivers/acpi/video.ko] undefined!
ERROR: video_output_register [drivers/acpi/video.ko] undefined!

The latter 2 are simple to fix:
in drivers/gpu/drm/nouveau/Kconfig, for config DRM_NOUVEAU:

@@ -11,6 +11,7 @@ config DRM_NOUVEAU
select FRAMEBUFFER_CONSOLE if !EMBEDDED
select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT
select ACPI_VIDEO if ACPI
+   select VIDEO_OUTPUT_CONTROL if ACPI
help
  Choose this option for open-source nVidia support.


The first 2 are a problem.  I'd like to add depends on HWMON to DRM_NOUVEAU,
but doing so gives:

drivers/video/Kconfig:30:error: recursive dependency detected!
drivers/video/Kconfig:30:   symbol FB is selected by DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:22: symbol DRM_KMS_HELPER is selected by DRM_NOUVEAU
drivers/gpu/drm/nouveau/Kconfig:1:  symbol DRM_NOUVEAU depends on HWMON
drivers/hwmon/Kconfig:5:symbol HWMON is selected by THINKPAD_ACPI
drivers/platform/x86/Kconfig:232:   symbol THINKPAD_ACPI depends on INPUT
drivers/input/Kconfig:8:symbol INPUT is selected by VT
drivers/char/Kconfig:7: symbol VT is selected by FB_STI
drivers/video/Kconfig:636:  symbol FB_STI depends on FB

so that must not be the right thing to do.  Aha, that change along with
changing all select FB (in drivers/gpu/drm/*) to depends on FB
fixes the kconfig warnings.  But feel free to fix it some other way.

My working patch is below.

---
From: Randy Dunlap randy.dun...@oracle.com

Fix drm and drm/nouveau kconfigs so that build succeeds and
kconfig warnings are eliminated.

Fixes these build errors:
ERROR: hwmon_device_unregister [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
ERROR: hwmon_device_register [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
ERROR: video_output_unregister [drivers/acpi/video.ko] undefined!
ERROR: video_output_register [drivers/acpi/video.ko] undefined!

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
---
 drivers/gpu/drm/Kconfig |2 +-
 drivers/gpu/drm/nouveau/Kconfig |5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

--- linux-next-20101013.orig/drivers/gpu/drm/nouveau/Kconfig
+++ linux-next-20101013/drivers/gpu/drm/nouveau/Kconfig
@@ -1,16 +1,17 @@
 config DRM_NOUVEAU
tristate Nouveau (nVidia) cards
-   depends on DRM  PCI
+   depends on DRM  PCI  HWMON
+   depends on FB
 select FW_LOADER
select DRM_KMS_HELPER
select DRM_TTM
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-   select FB
select FRAMEBUFFER_CONSOLE if !EMBEDDED
select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT
select ACPI_VIDEO if ACPI
+   select VIDEO_OUTPUT_CONTROL if ACPI
help
  Choose this option for open-source nVidia support.
 
--- linux-next-20101013.orig/drivers/gpu/drm/Kconfig
+++ linux-next-20101013/drivers/gpu/drm/Kconfig
@@ -22,7 +22,7 @@ menuconfig DRM
 config DRM_KMS_HELPER
tristate
depends on DRM
-   select FB
+   depends on FB
select FRAMEBUFFER_CONSOLE if !EMBEDDED
help
  FB and CRTC helpers for KMS drivers.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RESEND] drm: include missing types header to drm_mode.h

2010-10-22 Thread Randy Dunlap 
On Fri, 22 Oct 2010 16:55:17 -0700 Andrew Morton wrote:

 On Fri, 22 Oct 2010 10:13:19 -0300
 Davidlohr Bueso d...@gnu.org wrote:
 
  drm: include missing types header to drm_mode.h
  
  Signed-off-by: Davidlohr Bueso d...@gnu.org
  ---
   include/drm/drm_mode.h |2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
  
  diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
  index 0fc7397..eddd7f4 100644
  --- a/include/drm/drm_mode.h
  +++ b/include/drm/drm_mode.h
  @@ -24,6 +24,8 @@
* IN THE SOFTWARE.
*/
   
  +#include linux/types.h
  +
   #ifndef _DRM_MODE_H
   #define _DRM_MODE_H
   
 
 Does this fix a build error?  If so, please send along the compiler
 error output.


Every build that has CONFIG_HEADERS_CHECK=y reports the following:

linux-next-20101022/X64/usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} 
type without #include linux/types.h
linux-next-20101022/X64/usr/include/drm/i915_drm.h:120: found 
__[us]{8,16,32,64} type without #include linux/types.h
linux-next-20101022/X64/usr/include/drm/mga_drm.h:260: found __[us]{8,16,32,64} 
type without #include linux/types.h
linux-next-20101022/X64/usr/include/drm/radeon_drm.h:758: found 
__[us]{8,16,32,64} type without #include linux/types.h
linux-next-20101022/X64/usr/include/drm/via_drm.h:117: found __[us]{8,16,32,64} 
type without #include linux/types.h
linux-next-20101022/X64/usr/include/scsi/scsi_netlink.h:108: found 
__[us]{8,16,32,64} type without #include linux/types.h
linux-next-20101022/X64/usr/include/linux/resource.h:49: found 
__[us]{8,16,32,64} type without #include linux/types.h


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/4] drm: fix headers to include linux/types.h

2010-12-01 Thread Randy Dunlap 
On Thu, 2 Dec 2010 05:55:59 +1000 Dave Airlie wrote:

 On Thu, Dec 2, 2010 at 5:38 AM, Andrew Morton a...@linux-foundation.org 
 wrote:
  On Wed, 1 Dec 2010 17:54:18 +0100
  Julien Cristau jcris...@debian.org wrote:
 
  On Wed, Dec  1, 2010 at 17:10:42 +0200, Alexander Shishkin wrote:
 
   For headers that get exported to userland and make use of u32 style
   type names, it is advised to include linux/types.h.
  
   This fixes 5 headers_check warnings.
  
  How many times does this need to be NAKed?
 
  Until someone gets a clue and puts comments in there explaining this?
 
 how about someone fixing the dumb scripts to understand that C header
 includes aren't single level.

Still, drm is an exception here, so it needs to be documented as such.


 Like 10 people have posted this patch and not one has come back with a
 fix for the app after I pointed it out, like really if people think
 they can write C good enough to send kernel patches,
 maybe they could put some more effort in and actually fix a real problem.
 
 We should start hashing signed-off-by's so people can't get any glory from 
 them.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.37-rc8 (no fb)

2010-12-29 Thread Randy Dunlap 
On Wed, 29 Dec 2010 12:16:01 -0800 Jesse Barnes wrote:

 On Wed, 29 Dec 2010 11:40:04 -0800
 Linus Torvalds torva...@linux-foundation.org wrote:
 
  On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap randy.dun...@oracle.com 
  wrote:
  
   The only significant difference that I can see in the kernel message log
   is this:
  
  Hmm. I suspect that difference should have gone away with commit
  92971021c6328 (Revert drm: Don't try and disable an encoder that was
  never enabled), but clearly that didn't fix your blank screen.
  
  Does reverting commit 448f53a1ede54eb854d036abf54573281412d650
  (drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks) fix it for
  you? It does for some people..
  
  Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
  we please just disable spread-spectrum entirely? Or perhaps only if we
  notice that it was enabled already? Or something?
 
 Randy, Jeff and Alex, does the below help at all?  If so, it may be the
 minimal fix we want for 2.6.37.
 
 diff --git a/drivers/gpu/drm/i915/intel_bios.c 
 b/drivers/gpu/drm/i915/intel_bios
 index 2b20786..d27d016 100644
 --- a/drivers/gpu/drm/i915/intel_bios.c
 +++ b/drivers/gpu/drm/i915/intel_bios.c
 @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv,
 dev_priv-int_tv_support = general-int_tv_support;
 dev_priv-int_crt_support = general-int_crt_support;
 dev_priv-lvds_use_ssc = general-enable_ssc;
 +   /* force disable until we can parse this correctly */
 +   if (IS_GEN5(dev) || IS_GEN6(dev))
 +   dev_priv-lvds_use_ssc = 0;
  
 if (dev_priv-lvds_use_ssc) {
 if (IS_I85X(dev))
 
 
 -- 

Ugh, looks like I have confused things horribly.  Sorry about this.

2.6.37-rc8 with no patches works for me.  My original report was incorrect --
I was using -rc7 when I thought I was using -rc8.  :(

Regrets,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts:  http://www.xenotime.net/linux/recipes/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.37-rc8 (no fb)

2010-12-29 Thread Randy Dunlap 
On Wed, 29 Dec 2010 14:46:14 -0800 Jesse Barnes wrote:

   diff --git a/drivers/gpu/drm/i915/intel_bios.c 
   b/drivers/gpu/drm/i915/intel_bios
   index 2b20786..d27d016 100644
   --- a/drivers/gpu/drm/i915/intel_bios.c
   +++ b/drivers/gpu/drm/i915/intel_bios.c
   @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private 
   *dev_priv,
   dev_priv-int_tv_support = general-int_tv_support;
   dev_priv-int_crt_support = general-int_crt_support;
   dev_priv-lvds_use_ssc = general-enable_ssc;
   +   /* force disable until we can parse this correctly */
   +   if (IS_GEN5(dev) || IS_GEN6(dev))
   +   dev_priv-lvds_use_ssc = 0;

   if (dev_priv-lvds_use_ssc) {
   if (IS_I85X(dev))
   
   
   -- 
  
  Ugh, looks like I have confused things horribly.  Sorry about this.
  
  2.6.37-rc8 with no patches works for me.  My original report was incorrect 
  --
  I was using -rc7 when I thought I was using -rc8.  :(
 
 Can you confirm that the above doesn't break your setup just in case we
 need to apply it?


Yes, confirmed, my test platform still works with this patch applied.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts:  http://www.xenotime.net/linux/recipes/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: (Short?) merge window reminder

2011-05-23 Thread Randy Dunlap 
On Mon, 23 May 2011 21:25:25 +0200 (CEST) Thomas Gleixner wrote:

 On Mon, 23 May 2011, Linus Torvalds wrote:
  PS. The voices in my head also tell me that the numbers are getting
  too big. I may just call the thing 2.8.0. And I almost guarantee that
  this PS is going to result in more discussion than the rest, but when
  the voices tell me to do things, I listen.
 
 So the voices tell you to avoid .42 ?

They tell him to avoid the question to which 42 is the answer.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: (Short?) merge window reminder

2011-05-23 Thread Randy Dunlap 
On Mon, 23 May 2011 19:17:21 -0400 Ted Ts'o wrote:

 On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote:
  On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote:
  
   I really hope there's also a voice that tells you to wait until .42 before
   cutting 3.0.0! :-)
  
  So I'm toying with 3.0 (and in that case, it really would be 3.0,
  not 3.0.0 - the stable team would get the third digit rather than
  the fourth one.
 
 If we change from 2.6.X to 3.X, then if we don't change anything else,
 then successive stable release will cause the LINUX_VERSION_CODE to be
 incremented.  This isn't necessary bad, but it would be a different
 from what we have now.


It's just another little thing to break several scripts...


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] ttm: Fix spelling mistakes and remove unused #ifdef

2011-06-07 Thread Randy Dunlap 
On Tue,  7 Jun 2011 14:35:52 -0400 Konrad Rzeszutek Wilk wrote:

 . and some comments to make it easier to understand.
 
 Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
  drivers/gpu/drm/ttm/ttm_page_alloc.c |   14 +++---
  include/drm/ttm/ttm_bo_api.h |3 ---
  include/drm/ttm/ttm_bo_driver.h  |6 +++---
  include/drm/ttm/ttm_memory.h |2 +-
  include/drm/ttm/ttm_object.h |4 ++--
  include/drm/ttm/ttm_page_alloc.h |2 +-
  6 files changed, 14 insertions(+), 17 deletions(-)
 
 diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
 b/drivers/gpu/drm/ttm/ttm_page_alloc.c
 index 9d9d929..3277965 100644
 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
 +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
 @@ -355,7 +355,7 @@ restart:
   if (nr_free)
   goto restart;
  
 - /* Not allowed to fall tough or break because
 + /* Not allowed to fall through or break because
* following context is inside spinlock while we are
* outside here.
*/
 @@ -554,7 +554,7 @@ out:
  }
  
  /**
 - * Fill the given pool if there isn't enough pages and requested number of
 + * Fill the given pool if there isn't enough pages and the requested number 
 of

   aren't

   * pages is small.
   */
  static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool,
 @@ -575,7 +575,7 @@ static void ttm_page_pool_fill_locked(struct 
 ttm_page_pool *pool,
   pool-fill_lock = true;
  
   /* If allocation request is small and there is not enough

are not enough

 -  * pages in pool we fill the pool first */
 +  * pages in a pool we fill the pool up first. */
   if (count  _manager-options.small
count  pool-npages) {
   struct list_head new_pages;
 @@ -612,9 +612,9 @@ static void ttm_page_pool_fill_locked(struct 
 ttm_page_pool *pool,
  }
  
  /**
 - * Cut count nubmer of pages from the pool and put them to return list
 + * Cut out a number of pages from the pool and put them on the return list.

No, it wants 'count' or count in there, like:

 * Cut 'count' number of pages from the pool and put them on the return list.

   *
 - * @return count of pages still to allocate to fill the request.
 + * @return count of pages still required to fulfill the request.
   */
  static unsigned ttm_page_pool_get_pages(struct ttm_page_pool *pool,
   struct list_head *pages, int ttm_flags,
 @@ -635,7 +635,7 @@ static unsigned ttm_page_pool_get_pages(struct 
 ttm_page_pool *pool,
   goto out;
   }
   /* find the last pages to include for requested number of pages. Split
 -  * pool to begin and halves to reduce search space. */
 +  * pool to begin and halve it to reduce search space. */
   if (count = pool-npages/2) {
   i = 0;
   list_for_each(p, pool-list) {
 @@ -649,7 +649,7 @@ static unsigned ttm_page_pool_get_pages(struct 
 ttm_page_pool *pool,
   break;
   }
   }
 - /* Cut count number of pages from pool */
 + /* Cut the count number of pages from the pool */

Not any better IMO.  How about:
/* Cut count number of pages from the pool */
or
/* Cut 'count' number of pages from the pool */

   list_cut_position(pages, pool-list, p);
   pool-npages -= count;
   count = 0;

[snip]



---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] bugfix and cleanup patches in the TTM code for 3.1.

2011-06-08 Thread Randy Dunlap 
On Wed, 8 Jun 2011 19:30:22 +0200 Rafał Miłecki wrote:

 Hi Konrad,
 
 2011/6/8 Konrad Rzeszutek Wilk konrad.w...@oracle.com:
  The bug-fix ttm: Do not increment the amount of pages in a pool by the 
  current amount
  I never observed, but found while looking at the code. The cleanup patch:
  ttm: Fix spelling mistakes and remove unused #ifdef, I had posted earlier 
  and Randy
  Dunlap graciously added some extra cleanups - which I have rolled in.
 
 This is safe to put comments to the patch in the following place:
 
 
 Signed-off-by: (...)
 ---
 RIGHT HERE
 ---
  drivers/(...)
 
 
 When applying such a patch comments will not be visible in git log.
 You may find this easier method of commenting your patches.

Yes, it would remove the temptation to make a patch 0/small_number
that several people are (sadly) using recently.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu/stub: try to make help text readable

2011-08-06 Thread Randy Dunlap 
From: Randy Dunlap rdun...@xenotime.net

I couldn't parse the STUB_POULSBO help text and the module names
were misleading, so try to make it more readable, use corrected
module names, and spell acpi as ACPI.

Signed-off-by: Randy Dunlap rdun...@xenotime.net
Cc: Lee, Chun-Yi j...@novell.com
Cc: Lee, Chun-Yi joeyli.ker...@gmail.com
Cc: Dave Airlie airl...@redhat.com
---
 drivers/gpu/stub/Kconfig |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- linux-3.0-git22.orig/drivers/gpu/stub/Kconfig
+++ linux-3.0-git22/drivers/gpu/stub/Kconfig
@@ -12,7 +12,7 @@ config STUB_POULSBO
help
  Choose this option if you have a system that has Intel GMA500
  (Poulsbo) integrated graphics. If M is selected, the module will
- be called Poulsbo. This driver is a stub driver for Poulsbo that
- will call poulsbo.ko to enable the acpi backlight control sysfs
- entry file because there have no poulsbo native driver can support
+ be called poulsbo. This driver is a stub driver for Poulsbo that
+ will call psb_gfx.ko to enable the ACPI backlight control sysfs
+ entry file because there is no poulsbo native driver that supports
  intel opregion.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] drm: fix kconfig unmet dependency warning

2011-08-10 Thread Randy Dunlap 
From: Randy Dunlap rdun...@xenotime.net

Fix kconfig unmet dependency warning.  BACKLIGHT_CLASS_DEVICE depends on
BACKLIGHT_LCD_SUPPORT, so select the latter along with the former.

warning: (DRM_RADEON_KMS  DRM_I915  STUB_POULSBO  FB_BACKLIGHT  
PANEL_SHARP_LS037V7DW01  PANEL_ACX565AKM  USB_APPLEDISPLAY  FB_OLPC_DCON 
 ASUS_LAPTOP  SONY_LAPTOP  THINKPAD_ACPI  EEEPC_LAPTOP  ACPI_ASUS  
ACPI_CMPC  SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE which has unmet direct 
dependencies (HAS_IOMEM  BACKLIGHT_LCD_SUPPORT)

Signed-off-by: Randy Dunlap rdun...@xenotime.net
---
 drivers/gpu/drm/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- lnx-31-rc1.orig/drivers/gpu/drm/Kconfig
+++ lnx-31-rc1/drivers/gpu/drm/Kconfig
@@ -96,6 +96,7 @@ config DRM_I915
select FB_CFB_IMAGEBLIT
# i915 depends on ACPI_VIDEO when ACPI is enabled
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
+   select BACKLIGHT_LCD_SUPPORT if ACPI
select BACKLIGHT_CLASS_DEVICE if ACPI
select VIDEO_OUTPUT_CONTROL if ACPI
select INPUT if ACPI
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH -next] drm: fix kconfig unmet dependency warning

2011-08-10 Thread Randy Dunlap 
On Wed, 10 Aug 2011 14:24:01 -0700 Randy Dunlap wrote:

Sorry, this applies to mainline, not linux-next.


 From: Randy Dunlap rdun...@xenotime.net
 
 Fix kconfig unmet dependency warning.  BACKLIGHT_CLASS_DEVICE depends on
 BACKLIGHT_LCD_SUPPORT, so select the latter along with the former.
 
 warning: (DRM_RADEON_KMS  DRM_I915  STUB_POULSBO  FB_BACKLIGHT  
 PANEL_SHARP_LS037V7DW01  PANEL_ACX565AKM  USB_APPLEDISPLAY  
 FB_OLPC_DCON  ASUS_LAPTOP  SONY_LAPTOP  THINKPAD_ACPI  EEEPC_LAPTOP 
  ACPI_ASUS  ACPI_CMPC  SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE 
 which has unmet direct dependencies (HAS_IOMEM  BACKLIGHT_LCD_SUPPORT)
 
 Signed-off-by: Randy Dunlap rdun...@xenotime.net
 ---
  drivers/gpu/drm/Kconfig |1 +
  1 file changed, 1 insertion(+)
 
 --- lnx-31-rc1.orig/drivers/gpu/drm/Kconfig
 +++ lnx-31-rc1/drivers/gpu/drm/Kconfig
 @@ -96,6 +96,7 @@ config DRM_I915
   select FB_CFB_IMAGEBLIT
   # i915 depends on ACPI_VIDEO when ACPI is enabled
   # but for select to work, need to select ACPI_VIDEO's dependencies, ick
 + select BACKLIGHT_LCD_SUPPORT if ACPI
   select BACKLIGHT_CLASS_DEVICE if ACPI
   select VIDEO_OUTPUT_CONTROL if ACPI
   select INPUT if ACPI
 --


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for Nov 29 (drm)

2011-11-30 Thread Randy Dunlap 
On 11/28/2011 08:20 PM, Stephen Rothwell wrote:
 Hi all,
 
 Changes since 2028:
 
 The drm tree lost its build failure but gained another for which I
 applied a patch.


ERROR: drm_helper_get_fb_bpp_depth [drivers/gpu/drm/vmwgfx/vmwgfx.ko] 
undefined!

Full x86_64 randconfig file is attached.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.2.0-rc3 Kernel Configuration
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT=elf64-x86-64
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
# CONFIG_ZONE_DMA is not set
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11
# CONFIG_KTIME_SCALAR is not set
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
CONFIG_LOCALVERSION=
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME=(none)
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_FHANDLE=y
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y

#
# RCU Subsystem
#
CONFIG_TINY_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_TRACE is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_BOOST=y
CONFIG_RCU_BOOST_PRIO=1
CONFIG_RCU_BOOST_DELAY=500
CONFIG_IKCONFIG=m
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_CGROUPS is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
CONFIG_USER_NS=y
# CONFIG_PID_NS is not set
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_RELAY=y
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
# CONFIG_ELF_CORE is not set
# CONFIG_PCSPKR_PLATFORM is not set
CONFIG_HAVE_PCSPKR_PLATFORM=y
# CONFIG_BASE_FULL is not set
# CONFIG_FUTEX is not set
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_SHMEM is not set
# CONFIG_AIO is not set
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_PERF_COUNTERS is not set
CONFIG_DEBUG_PERF_USE_VMALLOC=y
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_PCI_QUIRKS is not set
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_OPROFILE=m
CONFIG_OPROFILE_EVENT_MULTIPLEX=y
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
# CONFIG_JUMP_LABEL is not set
CONFIG_UPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y

Re: linux-next: Tree for Nov 29 (drm)

2011-11-30 Thread Randy Dunlap 
On 11/30/2011 09:16 AM, Sérgio Basto wrote:
 Randy, not dri-de...@lists.sourceforge.net, anymore 
 now is dri-devel@lists.freedesktop.org

Argh, thanks.
That was thunderbird trying to be too helpful. :(


 On Tue, 2011-11-29 at 12:33 -0800, Randy Dunlap wrote: 
 On 11/28/2011 08:20 PM, Stephen Rothwell wrote:
 Hi all,

 Changes since 2028:

 The drm tree lost its build failure but gained another for which I
 applied a patch.


 ERROR: drm_helper_get_fb_bpp_depth [drivers/gpu/drm/vmwgfx/vmwgfx.ko] 
 undefined!

 Full x86_64 randconfig file is attached.

 --
 -- ___ Dri-devel mailing list 
 dri-de...@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/dri-devel
 


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] vgaarb.h: fix build warnings

2012-01-30 Thread Randy Dunlap 
From: Randy Dunlap rdun...@xenotime.net

Fix build warnings by providing a struct stub since no fields of
the struct are used:

include/linux/vgaarb.h:66:9: warning: 'struct pci_dev' declared inside 
parameter list
include/linux/vgaarb.h:66:9: warning: its scope is only this definition or 
declaration, which is probably not what you want
include/linux/vgaarb.h:99:34: warning: 'struct pci_dev' declared inside 
parameter list
include/linux/vgaarb.h:109:6: warning: 'struct pci_dev' declared inside 
parameter list
include/linux/vgaarb.h:121:8: warning: 'struct pci_dev' declared inside 
parameter list
include/linux/vgaarb.h:140:37: warning: 'struct pci_dev' declared inside 
parameter list

Signed-off-by: Randy Dunlap rdun...@xenotime.net
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
---
 include/linux/vgaarb.h |2 ++
 1 file changed, 2 insertions(+)

--- linux-next-20120130.orig/include/linux/vgaarb.h
+++ linux-next-20120130/include/linux/vgaarb.h
@@ -47,6 +47,8 @@
  */
 #define VGA_DEFAULT_DEVICE (NULL)
 
+struct pci_dev;
+
 /* For use by clients */
 
 /**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm: i915 hangcheck/GPU errors

2012-03-06 Thread Randy Dunlap 
Hi,

My Toshiba Portege (Intel Core i5) hangs every few days.
Sometimes I can see no log messages/reasons for it.
Sometimes there are messages about X receiving potentially
fatal signals.

Today's hang appears to have some useful info (maybe).

Mar  6 09:01:45 dragon kernel: [137308.704424] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Mar  6 09:01:45 dragon kernel: [137308.704552] [drm] capturing error event; 
look for more information in /debug/dri/0/i915_error_state
Mar  6 09:01:45 dragon kernel: [137308.718950] [drm:i915_wait_request] *ERROR* 
i915_wait_request returns -11 (awaiting 16513584 at 16513581, next 16513585)
Mar  6 09:02:13 dragon kernel: [137336.754647] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Mar  6 09:02:13 dragon kernel: [137336.754698] [drm:i915_wait_request] *ERROR* 
i915_wait_request returns -11 (awaiting 16517081 at 16517078, next 16517082)

...

Mar  6 09:05:44 dragon kernel: [137548.071904] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Mar  6 09:05:44 dragon kernel: [137548.071951] [drm:i915_wait_request] *ERROR* 
i915_wait_request returns -11 (awaiting 16550939 at 16550936, next 16550940)
Mar  6 09:05:57 dragon kernel: [137560.924459] X/1399: potentially unexpected 
fatal signal 6.
Mar  6 09:05:57 dragon kernel: [137560.924463] 
Mar  6 09:05:57 dragon kernel: [137560.924466] CPU 1 
Mar  6 09:05:57 dragon kernel: [137560.924468] Modules linked in: usblp 
snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq 
snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 af_packet acpi_cpufreq mperf lp 
ppdev parport_pc parport snd_hda_codec_hdmi snd_hda_codec_realtek uvcvideo 
videobuf2_core videobuf2_vmalloc videobuf2_memops usbhid hid mousedev 
snd_hda_codec arc4 snd_hwdep iwlwifi toshiba_acpi psmouse snd_pcm snd_timer 
sparse_keymap ehci_hcd battery serio_raw mac80211 evdev thermal ac xhci_hcd 
snd_page_alloc wmi power_supply e1000e mei(C) sdhci_pci sdhci mmc_core 
firmware_class cfg80211 rfkill processor sg rtc_cmos loop unix [last unloaded: 
snd_hda_intel]
Mar  6 09:05:57 dragon kernel: [137560.924560] 
Mar  6 09:05:58 dragon kernel: [137560.924564] Pid: 1399, comm: X Tainted: G
 C   3.3.0-rc5 #2 TOSHIBA PORTEGE R835/Portable PC
Mar  6 09:05:58 dragon kernel: [137560.924572] RIP: 0033:[7f57463c7035]  
[7f57463c7035] 0x7f57463c7034
Mar  6 09:05:58 dragon kernel: [137560.924581] RSP: 002b:7fff0ac33758  
EFLAGS: 3206
Mar  6 09:05:58 dragon kernel: [137560.924585] RAX:  RBX: 
 RCX: 
Mar  6 09:05:58 dragon kernel: [137560.924589] RDX: 0006 RSI: 
0577 RDI: 0577
Mar  6 09:05:58 dragon kernel: [137560.924593] RBP: 7fff0ac341a0 R08: 
7f57464ee8e0 R09: 00411e40
Mar  6 09:05:59 dragon kernel: [137560.924597] R10: 0008 R11: 
3206 R12: 0037
Mar  6 09:06:00 dragon kernel: [137560.924600] R13: 7fff0ac33a80 R14: 
004f R15: 0007
Mar  6 09:06:00 dragon kernel: [137560.924604] FS:  7f57487a18a0() 
GS:88014a60() knlGS:
Mar  6 09:06:02 dragon kernel: [137560.924609] CS:  0010 DS:  ES:  CR0: 
80050033
Mar  6 09:06:02 dragon kernel: [137560.924612] CR2: 00418ff0 CR3: 
00013d059000 CR4: 000406e0
Mar  6 09:06:02 dragon kernel: [137560.924616] DR0:  DR1: 
 DR2: 
Mar  6 09:06:02 dragon kernel: [137560.924620] DR3:  DR6: 
0ff0 DR7: 0400
Mar  6 09:06:03 dragon kernel: [137560.924624] Process X (pid: 1399, threadinfo 
88013e9cc000, task 88012412)
Mar  6 09:06:03 dragon kernel: [137560.924627] 
Mar  6 09:06:03 dragon kernel: [137560.924630] Call Trace:

/end


Any ideas/suggestions?



look for more information in /debug/dri/0/i915_error_state

Where is that file?  in debugfs or somewhere else?

thanks,
-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH -next] vgaarb.h: fix build warnings

2012-03-13 Thread Randy Dunlap 
On 01/30/2012 11:43 AM, Randy Dunlap wrote:

This patch is still needed in linux-next of 20120313.


 From: Randy Dunlap rdun...@xenotime.net
 
 Fix build warnings by providing a struct stub since no fields of
 the struct are used:
 
 include/linux/vgaarb.h:66:9: warning: 'struct pci_dev' declared inside 
 parameter list
 include/linux/vgaarb.h:66:9: warning: its scope is only this definition or 
 declaration, which is probably not what you want
 include/linux/vgaarb.h:99:34: warning: 'struct pci_dev' declared inside 
 parameter list
 include/linux/vgaarb.h:109:6: warning: 'struct pci_dev' declared inside 
 parameter list
 include/linux/vgaarb.h:121:8: warning: 'struct pci_dev' declared inside 
 parameter list
 include/linux/vgaarb.h:140:37: warning: 'struct pci_dev' declared inside 
 parameter list
 
 Signed-off-by: Randy Dunlap rdun...@xenotime.net
 Cc:   David Airlie airl...@linux.ie
 Cc:   dri-devel@lists.freedesktop.org
 ---
  include/linux/vgaarb.h |2 ++
  1 file changed, 2 insertions(+)
 
 --- linux-next-20120130.orig/include/linux/vgaarb.h
 +++ linux-next-20120130/include/linux/vgaarb.h
 @@ -47,6 +47,8 @@
   */
  #define VGA_DEFAULT_DEVICE (NULL)
  
 +struct pci_dev;
 +
  /* For use by clients */
  
  /**
 



-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for Apr 17 (pci-sysfs.c and vga_switcheroo.c)

2012-04-17 Thread Randy Dunlap 
On 04/16/2012 09:42 PM, Stephen Rothwell wrote:

 Hi all,
 
 Changes since 20120416:


When CONFIG_VGA_ARB is not enabled:

drivers/built-in.o: In function `boot_vga_show':
pci-sysfs.c:(.text+0x1060f): undefined reference to `vga_default_device'


and

drivers/built-in.o: In function `boot_vga_show':
pci-sysfs.c:(.text+0x8cc2): undefined reference to `vga_default_device'
drivers/built-in.o: In function `vga_switcheroo_register_client':
(.text+0x76671): undefined reference to `vga_default_device'
drivers/built-in.o: In function `vga_switchto_stage1':
vga_switcheroo.c:(.text+0x767f4): undefined reference to 
`vga_set_default_device'


-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for May 8 (gpu/drm/gma500)

2012-05-08 Thread Randy Dunlap 
On 05/08/2012 01:15 AM, Stephen Rothwell wrote:

 Hi all,
 
 There will be no linux-next tomorrow.
 
 Changes since 20120507:



When CONFIG_ACPI is not enabled:

drivers/gpu/drm/gma500/opregion.c:269:3: error: implicit declaration of 
function 'register_acpi_notifier'
drivers/gpu/drm/gma500/opregion.c:288:3: error: implicit declaration of 
function 'unregister_acpi_notifier'

-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for May 18 (drm drivers and vgacon)

2012-05-18 Thread Randy Dunlap 
On 05/18/2012 01:49 AM, Stephen Rothwell wrote:

 Hi all,
 
 Changes since 201205017:


When CONFIG_VGA_CONSOLE is not enabled:

drivers/gpu/drm/cirrus/cirrus_drv.c:87:2: error: implicit declaration of 
function 'vgacon_text_force'
drivers/gpu/drm/ast/ast_drv.c:224:2: error: implicit declaration of function 
'vgacon_text_force'
drivers/gpu/drm/mgag200/mgag200_drv.c:96:2: error: implicit declaration of 
function 'vgacon_text_force'


-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 3.4.0+ - Linus GIT -- drivers/built-in.o: In function `nouveau_acpi_edid': (.text+0x112337): undefined reference to `acpi_video_get_edid'

2012-07-30 Thread Randy Dunlap 
On 05/31/2012 12:10 AM, Miles Lane wrote:

 I suspect this is due to a dependency not enforced in the Kconfig logic?
 
   LD  init/built-in.o
 drivers/built-in.o: In function `nouveau_acpi_edid':
 (.text+0x112337): undefined reference to `acpi_video_get_edid'




This build error still happens in Linux 3.5.
It is attempting to call a symbol in a loadable module from
a builtin driver.


CONFIG_ACPI_VIDEO=m
CONFIG_VIDEO_OUTPUT_CONTROL=m

If I use change CONFIG_VIDEO_OUTPUT_CONTROL to y,
CONFIG_ACPI_VIDEO also changes to y, so the relevant
functions are all builtin, and there is no build problem.


I guess that this line in drivers/gpu/drm/nouveau/Kconfig:

select ACPI_VIDEO if ACPI  X86  BACKLIGHT_CLASS_DEVICE  
VIDEO_OUTPUT_CONTROL  INPUT

sets ACPI_VIDEO=m since VIDEO_OUTPUT_CONTROL=m, even though all of the
other symbols are =y.

xconfig tells me:

Selects: FW_LOADER [=y]  DRM_KMS_HELPER [=y]  DRM_TTM [=y]  
FB_CFB_FILLRECT [=y]  FB_CFB_COPYAREA [=y]  FB_CFB_IMAGEBLIT [=y]  FB 
[=y]  FRAMEBUFFER_CONSOLE [=y]  FB_BACKLIGHT [=y]  ACPI_VIDEO [=m]  
ACPI_WMI [=y]  MXM_WMI [=y]  POWER_SUPPLY [=y]




-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 3.5.x boot hang after conflicting fb hw usage driver vs VESA VGA - removing generic driver

2012-08-17 Thread Randy Dunlap 
On 08/17/2012 03:25 PM, Justin M. Forbes wrote:

 for driver, we have verified cases on inteldrmfb, radeondrmfb, and
 cirrusdrmfb.
 
 This is the last message displayed before the system hangs.  This seems
 to be hitting a large number of users in Fedora, though certainly not
 everyone.  This started happening with the 3.5 updates, and is still an
 issue.  It appears to be a race condition, because various things have
 allowed boot to continue for some users, though there is no clear work
 around. Has anyone else run across this?  Any ideas.  For more
 background we have the following bugs:
 
 inteldrmfb:
 https://bugzilla.redhat.com/show_bug.cgi?id=843826
 
 radeondrmfb:
 https://bugzilla.redhat.com/show_bug.cgi?id=845745
 
 cirrusdrmfb kvm:
 https://bugzilla.redhat.com/show_bug.cgi?id=843860
 
 It should be noted that the conflicting fb hw usage message is not new,
 it has been around for a while, but this is the last message seen before
 the hang.


Hi,  (adding dri-devel mailing list)


I started seeing this problem on 3.5-rc6.

AFAICT, the system is not actually hung, it's just that no output
is showing up on the real (physical) output device (display) -- it's
going somewhere else (or to the bit bucket).

-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 3.5.x boot hang after conflicting fb hw usage driver vs VESA VGA - removing generic driver

2012-08-17 Thread Randy Dunlap 
On 08/17/2012 03:55 PM, Dave Airlie wrote:

 On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie airl...@gmail.com wrote:
 On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap rdun...@xenotime.net wrote:
 On 08/17/2012 03:25 PM, Justin M. Forbes wrote:

 for driver, we have verified cases on inteldrmfb, radeondrmfb, and
 cirrusdrmfb.

 This is the last message displayed before the system hangs.  This seems
 to be hitting a large number of users in Fedora, though certainly not
 everyone.  This started happening with the 3.5 updates, and is still an
 issue.  It appears to be a race condition, because various things have
 allowed boot to continue for some users, though there is no clear work
 around. Has anyone else run across this?  Any ideas.  For more
 background we have the following bugs:

 inteldrmfb:
 https://bugzilla.redhat.com/show_bug.cgi?id=843826

 radeondrmfb:
 https://bugzilla.redhat.com/show_bug.cgi?id=845745

 cirrusdrmfb kvm:
 https://bugzilla.redhat.com/show_bug.cgi?id=843860

 It should be noted that the conflicting fb hw usage message is not new,
 it has been around for a while, but this is the last message seen before
 the hang.


 Hi,  (adding dri-devel mailing list)


 I started seeing this problem on 3.5-rc6.

 AFAICT, the system is not actually hung, it's just that no output
 is showing up on the real (physical) output device (display) -- it's
 going somewhere else (or to the bit bucket).


 Can we bisect this at all?

I'll try.

 I worry the intel one will bisect to where we moved the conflict
 resolution earlier, but I'd like to see if applying that patch earlier
 causes the issue, since radeon has it.

 I haven't reproduced this on any hw I own, I also can't get it under qemu.
 
 I'm also wondering whether this grub2 related in some way, grub2 is
 starting to mess with the graphics adapter pointlessly.


I'm using lilo, not grub.

-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 3.5.x boot hang after conflicting fb hw usage driver vs VESA VGA - removing generic driver

2012-08-19 Thread Randy Dunlap 
On 08/17/12 15:55, Dave Airlie wrote:

 On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie airl...@gmail.com wrote:
 On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap rdun...@xenotime.net wrote:
 On 08/17/2012 03:25 PM, Justin M. Forbes wrote:

 for driver, we have verified cases on inteldrmfb, radeondrmfb, and
 cirrusdrmfb.

 This is the last message displayed before the system hangs.  This seems
 to be hitting a large number of users in Fedora, though certainly not
 everyone.  This started happening with the 3.5 updates, and is still an
 issue.  It appears to be a race condition, because various things have
 allowed boot to continue for some users, though there is no clear work
 around. Has anyone else run across this?  Any ideas.  For more
 background we have the following bugs:

 inteldrmfb:
 https://bugzilla.redhat.com/show_bug.cgi?id=843826

 radeondrmfb:
 https://bugzilla.redhat.com/show_bug.cgi?id=845745

 cirrusdrmfb kvm:
 https://bugzilla.redhat.com/show_bug.cgi?id=843860

 It should be noted that the conflicting fb hw usage message is not new,
 it has been around for a while, but this is the last message seen before
 the hang.


 Hi,  (adding dri-devel mailing list)


 I started seeing this problem on 3.5-rc6.

 AFAICT, the system is not actually hung, it's just that no output
 is showing up on the real (physical) output device (display) -- it's
 going somewhere else (or to the bit bucket).


 Can we bisect this at all?

I guess I'll have to try again.  My first attempt did not
prove anything, I think because the conflict does not happen
100% of the time (i.e., it feels like a timing problem).

 I worry the intel one will bisect to where we moved the conflict
 resolution earlier, but I'd like to see if applying that patch earlier
 causes the issue, since radeon has it.

Do you know of a specific commit that I could revert and test?

 I haven't reproduced this on any hw I own, I also can't get it under qemu.
 
 I'm also wondering whether this grub2 related in some way, grub2 is
 starting to mess with the graphics adapter pointlessly.
 
 Dave.



-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 3.5.x boot hang after conflicting fb hw usage driver vs VESA VGA - removing generic driver

2012-08-20 Thread Randy Dunlap 
On 08/19/2012 10:22 PM, Dave Airlie wrote:

 On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap rdun...@xenotime.net wrote:
 On 08/17/12 15:55, Dave Airlie wrote:

 On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie airl...@gmail.com wrote:
 On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap rdun...@xenotime.net wrote:
 On 08/17/2012 03:25 PM, Justin M. Forbes wrote:

 for driver, we have verified cases on inteldrmfb, radeondrmfb, and
 cirrusdrmfb.

 This is the last message displayed before the system hangs.  This seems
 to be hitting a large number of users in Fedora, though certainly not
 everyone.  This started happening with the 3.5 updates, and is still an
 issue.  It appears to be a race condition, because various things have
 allowed boot to continue for some users, though there is no clear work
 around. Has anyone else run across this?  Any ideas.  For more
 background we have the following bugs:

 inteldrmfb:
 https://bugzilla.redhat.com/show_bug.cgi?id=843826

 radeondrmfb:
 https://bugzilla.redhat.com/show_bug.cgi?id=845745

 cirrusdrmfb kvm:
 https://bugzilla.redhat.com/show_bug.cgi?id=843860

 It should be noted that the conflicting fb hw usage message is not new,
 it has been around for a while, but this is the last message seen before
 the hang.


 Hi,  (adding dri-devel mailing list)


 I started seeing this problem on 3.5-rc6.

 AFAICT, the system is not actually hung, it's just that no output
 is showing up on the real (physical) output device (display) -- it's
 going somewhere else (or to the bit bucket).


 Can we bisect this at all?

 I guess I'll have to try again.  My first attempt did not
 prove anything, I think because the conflict does not happen
 100% of the time (i.e., it feels like a timing problem).

 I worry the intel one will bisect to where we moved the conflict
 resolution earlier, but I'd like to see if applying that patch earlier
 causes the issue, since radeon has it.

 Do you know of a specific commit that I could revert and test?
 
 9f846a16d213523fbe6daea17e20df6b8ac5a1e5
 
 might work, but it just changes the timing mostly.
 
 also testing 3.4 with that on top would be good.


That commit doesn't apply cleanly to 3.4, but reverting
it on 3.5-rc6 (where I first saw the problem) allows me to boot
3.5-rc6 multiple times without a problem.

Maybe Justin can get more stable testing done also..

thanks,
-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for Oct 5 (nouveau)

2012-10-05 Thread Randy Dunlap 
On 10/04/2012 09:54 PM, Stephen Rothwell wrote:

 Hi all,
 
 Do not add stuff destined for v3.8 to your linux-next included branches
 until after v3.7-rc1 is released.
 
 Changes since 201201004:
 


on x86_64, when CONFIG_AGP is not enabled:

  CC [M]  drivers/gpu/drm/nouveau/nouveau_bo.o
drivers/gpu/drm/nouveau/nouveau_bo.c: In function 'nouveau_ttm_tt_create':
drivers/gpu/drm/nouveau/nouveau_bo.c:463:3: error: implicit declaration of 
function 'ttm_agp_tt_create'
drivers/gpu/drm/nouveau/nouveau_bo.c:463:3: warning: return makes pointer from 
integer without a cast
make[5]: *** [drivers/gpu/drm/nouveau/nouveau_bo.o] Error 1


-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] drm: fix radeon printk format warnings

2012-10-10 Thread Randy Dunlap 
From: Randy Dunlap rdun...@xenotime.net

Fix printk format warnings in gpu/drm/radeon/:

drivers/gpu/drm/radeon/radeon_atpx_handler.c:151:3: warning: format '%lu' 
expects type 'long unsigned int', but argument 2 has type 'size_t'
drivers/gpu/drm/radeon/radeon_acpi.c:204:3: warning: format '%lu' expects type 
'long unsigned int', but argument 2 has type 'size_t'
drivers/gpu/drm/radeon/radeon_acpi.c:488:3: warning: format '%lu' expects type 
'long unsigned int', but argument 2 has type 'size_t'

Signed-off-by: Randy Dunlap rdun...@xenotime.net
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/radeon/radeon_acpi.c |4 ++--
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

--- linux-next-20121010.orig/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ linux-next-20121010/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -148,7 +148,7 @@ static int radeon_atpx_verify_interface(
 
size = *(u16 *) info-buffer.pointer;
if (size  8) {
-   printk(ATPX buffer is too small: %lu\n, size);
+   printk(ATPX buffer is too small: %zu\n, size);
err = -EINVAL;
goto out;
}
--- linux-next-20121010.orig/drivers/gpu/drm/radeon/radeon_acpi.c
+++ linux-next-20121010/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -201,7 +201,7 @@ static int radeon_atif_verify_interface(
 
size = *(u16 *) info-buffer.pointer;
if (size  12) {
-   DRM_INFO(ATIF buffer is too small: %lu\n, size);
+   DRM_INFO(ATIF buffer is too small: %zu\n, size);
err = -EINVAL;
goto out;
}
@@ -485,7 +485,7 @@ static int radeon_atcs_verify_interface(
 
size = *(u16 *) info-buffer.pointer;
if (size  8) {
-   DRM_INFO(ATCS buffer is too small: %lu\n, size);
+   DRM_INFO(ATCS buffer is too small: %zu\n, size);
err = -EINVAL;
goto out;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mmotm 2012-10-24-17-15 uploaded (drm/i915)

2012-10-25 Thread Randy Dunlap 
On 10/24/2012 05:16 PM, a...@linux-foundation.org wrote:

 The mm-of-the-moment snapshot 2012-10-24-17-15 has been uploaded to
 
http://www.ozlabs.org/~akpm/mmotm/
 
 mmotm-readme.txt says
 
 README for mm-of-the-moment:
 
 http://www.ozlabs.org/~akpm/mmotm/
 


on i386:

ERROR: __build_bug_on_failed [drivers/gpu/drm/i915/i915.ko] undefined!

Full randconfig file is attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 3.7.0-rc2-mm1 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT=elf32-i386
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
CONFIG_LOCALVERSION=
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME=(none)
# CONFIG_SYSVIPC is not set
# CONFIG_FHANDLE is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set

#
# RCU Subsystem
#
CONFIG_TINY_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_BOOST=y
CONFIG_RCU_BOOST_PRIO=1
CONFIG_RCU_BOOST_DELAY=500
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
CONFIG_UIDGID_CONVERTED=y
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
CONFIG_RD_LZO=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
# CONFIG_PRINTK is not set
# CONFIG_BUG is not set
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
# CONFIG_FUTEX is not set
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
# CONFIG_AIO is not set
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
# CONFIG_SLUB is not set
CONFIG_SLOB=y
# CONFIG_PROFILING is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
# CONFIG_KPROBES is not set
# CONFIG_JUMP_LABEL is not set
CONFIG_UPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y

Re: linux-next: Tree for Nov 14 (gpu/drm/i915)

2012-11-14 Thread Randy Dunlap 
On 11/13/2012 09:30 PM, Stephen Rothwell wrote:

 Hi all,
 
 News: next-20121115 (i.e. tomorrow) will be the last release until
 next-20121126 (which should be just be after -rc7, I guess - assuming
 that Linus does not release v3.7 before then), so if you want something
 in linux-next for a reasonable amount of testing, it should probably be
 committed tomorrow.
 
 Changes since 20121113:
 



on i386:

ERROR: __build_bug_on_failed [drivers/gpu/drm/i915/i915.ko] undefined!

Reference to that symbol is found in
i915_gem_execbuffer.o.  Reference to BUILD_BUG_ON() is found in
i915_gem_execbuffer.c:

static struct eb_objects *
eb_create(int size)
{
struct eb_objects *eb;
int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head)));


-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for Feb 12 (drm_pci.c)

2013-02-12 Thread Randy Dunlap 
On 02/11/13 21:09, Stephen Rothwell wrote:
 Hi all,
 
 Changes since 20130211:
 


when CONFIG_PCI is not enabled (on x86_64):

  CC [M]  drivers/gpu/drm/drm_pci.o
drivers/gpu/drm/drm_pci.c: In function 'drm_pcie_get_speed_cap_mask':
drivers/gpu/drm/drm_pci.c:485:2: error: implicit declaration of function 
'pcie_capability_read_dword' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[4]: *** [drivers/gpu/drm/drm_pci.o] Error 1



-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: fix new kernel-doc warnings

2013-03-05 Thread Randy Dunlap 
From: Randy Dunlap rdun...@infradead.org

Fix new kernel-doc warnings in drm_edid.c: convert doxygen(?) to
kernel-doc to match the rest of the file's documentation.

Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 
'adapter'
Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 
'buf'
Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 
'block'
Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 
'len'
Warning(drivers/gpu/drm/drm_edid.c:1138): No description found for parameter 
'adapter'
Warning(drivers/gpu/drm/drm_edid.c:1467): No description found for parameter 
'connector'
Warning(drivers/gpu/drm/drm_edid.c:1467): No description found for parameter 
'edid'
Warning(drivers/gpu/drm/drm_edid.c:1467): No description found for parameter 
'revision'
Warning(drivers/gpu/drm/drm_edid.c:1467): Excess function parameter 
'timing_level' description in 'drm_mode_std'
Warning(drivers/gpu/drm/drm_edid.c:2010): No description found for parameter 
'connector'
Warning(drivers/gpu/drm/drm_edid.c:2072): No description found for parameter 
'connector'
Warning(drivers/gpu/drm/drm_edid.c:2237): No description found for parameter 
'edid'
Warning(drivers/gpu/drm/drm_edid.c:2616): No description found for parameter 
'edid'
Warning(drivers/gpu/drm/drm_edid.c:2658): No description found for parameter 
'edid'

Signed-off-by: Randy Dunlap rdun...@infradead.org
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org

---
 drivers/gpu/drm/drm_edid.c |   30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

--- lnx-39-rc1.orig/drivers/gpu/drm/drm_edid.c
+++ lnx-39-rc1/drivers/gpu/drm/drm_edid.c
@@ -982,12 +982,13 @@ EXPORT_SYMBOL(drm_edid_is_valid);
 
 #define DDC_SEGMENT_ADDR 0x30
 /**
- * Get EDID information via I2C.
+ * drm_do_probe_ddc_edid - Get EDID information via I2C.
  *
- * \param adapter : i2c device adaptor
- * \param buf : EDID data buffer to be filled
- * \param len : EDID data buffer length
- * \return 0 on success or -1 on failure.
+ * @adapter : i2c device adaptor
+ * @buf : EDID data buffer to be filled
+ * @block   : block number
+ * @len : EDID data buffer length
+ * return   : 0 on success or -1 on failure.
  *
  * Try to fetch EDID information by calling i2c driver function.
  */
@@ -1128,10 +1129,10 @@ out:
 }
 
 /**
- * Probe DDC presence.
+ * drm_probe_ddc - Probe DDC presence.
  *
- * \param adapter : i2c device adaptor
- * \return 1 on success
+ * @adapter : i2c device adaptor
+ * return   : 1 on success
  */
 bool
 drm_probe_ddc(struct i2c_adapter *adapter)
@@ -1455,8 +1456,10 @@ bad_std_timing(u8 a, u8 b)
 
 /**
  * drm_mode_std - convert standard mode info (width, height, refresh) into mode
+ * @connector: attached connector
+ * @edid: EDID block
  * @t: standard timing params
- * @timing_level: standard timing level
+ * @revision: EDID revision
  *
  * Take the standard timing params (in this case width, aspect, and refresh)
  * and convert them into a real mode using CVT/GTF/DMT.
@@ -1999,7 +2002,8 @@ do_established_modes(struct detailed_tim
 }
 
 /**
- * add_established_modes - get est. modes from EDID and add them
+ * add_established_modes - get established modes from EDID and add them
+ * @connector: attached connector
  * @edid: EDID block to scan
  *
  * Each EDID block contains a bitmap of the supported established modes list
@@ -2062,6 +2066,7 @@ do_standard_modes(struct detailed_timing
 
 /**
  * add_standard_modes - get std. modes from EDID and add them
+ * @connector: attached connector
  * @edid: EDID block to scan
  *
  * Standard modes can be calculated using the appropriate standard (DMT,
@@ -2231,7 +2236,8 @@ add_detailed_modes(struct drm_connector
 #define EDID_CEA_VCDB_QS   (1  6)
 
 /**
- * Search EDID for CEA extension block.
+ * drm_find_cea_extension - Search EDID for CEA extension block.
+ * @edid: EDID block to search
  */
 u8 *drm_find_cea_extension(struct edid *edid)
 {
@@ -2604,6 +2610,7 @@ EXPORT_SYMBOL(drm_detect_hdmi_monitor);
 
 /**
  * drm_detect_monitor_audio - check monitor audio capability
+ * @edid: EDID block
  *
  * Monitor should have CEA extension block.
  * If monitor has 'basic audio', but no CEA audio blocks, it's 'basic
@@ -2649,6 +2656,7 @@ EXPORT_SYMBOL(drm_detect_monitor_audio);
 
 /**
  * drm_rgb_quant_range_selectable - is RGB quantization range selectable?
+ * @edid: EDID block
  *
  * Check whether the monitor reports the RGB quantization range selection
  * as supported. The AVI infoframe can then be used to inform the monitor
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mmotm 2013-04-17-16-02 uploaded (gpu/drm/qxl)

2013-04-18 Thread Randy Dunlap 
On 04/17/13 16:03, a...@linux-foundation.org wrote:
 The mm-of-the-moment snapshot 2013-04-17-16-02 has been uploaded to
 
http://www.ozlabs.org/~akpm/mmotm/
 


I saw this in linux-next a few days ago and forgot to post it.

When CONFIG_DEBUG_FS is not enabled:


drivers/gpu/drm/qxl/qxl_ttm.c:568:33: error: 'qxl_mm_dump_table' undeclared 
(first use in this function)
drivers/gpu/drm/qxl/qxl_debugfs.c:76:2: error: implicit declaration of function 
'drm_debugfs_create_files' [-Werror=implicit-function-declaration]
drivers/gpu/drm/qxl/qxl_debugfs.c:84:2: error: implicit declaration of function 
'drm_debugfs_remove_files' [-Werror=implicit-function-declaration]


-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] gpu: fix printk format warning in i915_gem.c

2013-06-19 Thread Randy Dunlap 
From: Randy Dunlap rdun...@infradead.org

Fix printk format warning in i915_gem.c:

drivers/gpu/drm/i915/i915_gem.c:3113:3: warning: format '%ld' expects argument 
of type 'long int', but argument 5 has type 'size_t' [-Wformat]

Signed-off-by: Randy Dunlap rdun...@infradead.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: David Airlie airl...@linux.ie
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_gem.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20130619.orig/drivers/gpu/drm/i915/i915_gem.c
+++ linux-next-20130619/drivers/gpu/drm/i915/i915_gem.c
@@ -3110,7 +3110,7 @@ i915_gem_object_bind_to_gtt(struct drm_i
 * before evicting everything in a vain attempt to find space.
 */
if (obj-base.size  gtt_max) {
-   DRM_ERROR(Attempting to bind an object larger than the 
aperture: object=%zd  %s aperture=%ld\n,
+   DRM_ERROR(Attempting to bind an object larger than the 
aperture: object=%zd  %s aperture=%zu\n,
  obj-base.size,
  map_and_fenceable ? mappable : total,
  gtt_max);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for Aug 30 (nouveau)

2013-09-09 Thread Randy Dunlap 
On 08/30/13 12:59, Randy Dunlap wrote:
 On 08/29/13 03:00, Stephen Rothwell wrote:
 Hi all,

 
 
 on x86_64:
 
 ERROR: nouveau_switcheroo_optimus_dsm [drivers/gpu/drm/nouveau/nouveau.ko] 
 undefined!
 
 
 Full randconfig file is attached.
 
 

This build error still happens in linux-next of 20130906.

-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] nouveau: fix build eror when VGA_SWITCHEROO is not enabled

2013-09-12 Thread Randy Dunlap 
From: Randy Dunlap rdun...@infradead.org

Fix nouveau build error on x86, when ACPI is enabled but
VGA_SWITCHEROO is not enabled, by providing a stub function.

drivers/built-in.o: In function `nouveau_pmops_runtime_suspend':
nouveau_drm.c:(.text+0x3aac89): undefined reference to 
`nouveau_switcheroo_optimus_dsm'

Signed-off-by: Randy Dunlap rdun...@infradead.org
---
 drivers/gpu/drm/nouveau/nouveau_acpi.c |1 +
 1 file changed, 1 insertion(+)

--- linux-next-20130911.orig/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ linux-next-20130911/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -373,6 +373,7 @@ void nouveau_unregister_dsm_handler(void
 #else
 void nouveau_register_dsm_handler(void) {}
 void nouveau_unregister_dsm_handler(void) {}
+void nouveau_switcheroo_optimus_dsm(void) {}
 #endif
 
 /* retrieve the ROM in 4k blocks */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu: host1x: use %pa to print dma_addr_t

2013-09-17 Thread Randy Dunlap 
On 09/16/13 17:06, Olof Johansson wrote:
 On Mon, Sep 16, 2013 at 8:54 AM, Joe Perches j...@perches.com wrote:
 On Mon, 2013-09-16 at 08:46 -0700, Olof Johansson wrote:
 On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding
 thierry.red...@gmail.com wrote:
 On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote:
 This removes two warnings where dma_addr_t variables were printed using
 %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t:

   drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects 
 argument of type 'unsigned int', but argument 5 has type 'dma_addr_t'
   drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects 
 argument of type 'unsigned int', but argument 3 has type 'dma_addr_t'

 Hi Olof,

 I can't reproduce this. Does this perhaps depend on some other patch?
 When I enable LPAE I do see similar warnings in drivers/iommu/tegra-*.c
 and those can indeed be fixed using an equivalent patch.

 You need to enable LPAE on a platform that also selects
 ARCH_DMA_ADDR_T_64BIT, I don't think tegra does. If you do it with
 multi_v7_defconfig you'll see them.

 However, see discussion on another of the emails in the series; I'll
 have to introduce a new format specifier instead.

 Or not.

 I don't know whether or not the dma_addr_t really needs a
 fixed 18 byte output length for 64 bit uses.

 I think always using a cast for dma_addr_t addresses like:

 printk(dma_addr_t: %#llx\n, (u64)addr);

 would probably work just fine.
 
 Sigh. Any color would do. I just want to get rid of the mostly-bogus
 warnings that makes it harder to spot real problems, I really don't
 care how they're resolved.
 
 None of the affected platforms today use 64-bit DMA anyway, so casting
 down to u32 is equally acceptable. I'll repost with that instead.

Casting to u64 and using %llx is preferred for this throughout the kernel,
not u32.

That way you would never have to 'fix' those when those platforms use
64-bit DMA (this is where you say that they never will :).



-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: Tree for Oct 20 (gpu/drm/i915)

2016-10-20 Thread Randy Dunlap 
On 10/19/16 20:20, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20161019:
> 

on i386: when CONFIG_ACPI is not enabled:

../drivers/gpu/drm/i915/gvt/opregion.c: In function 'intel_gvt_init_opregion':
../drivers/gpu/drm/i915/gvt/opregion.c:183:2: error: implicit declaration of 
function 'acpi_os_ioremap' [-Werror=implicit-function-declaration]
  gvt->opregion.opregion_va = acpi_os_ioremap(gvt->opregion.opregion_pa,
  ^
../drivers/gpu/drm/i915/gvt/opregion.c:183:28: warning: assignment makes 
pointer from integer without a cast [enabled by default]
  gvt->opregion.opregion_va = acpi_os_ioremap(gvt->opregion.opregion_pa,
^
../drivers/gpu/drm/i915/gvt/gtt.c: In function 'read_pte64':
../drivers/gpu/drm/i915/gvt/gtt.c:277:2: warning: left shift count >= width of 
type [enabled by default]
  pte |= ioread32(addr + 4) << 32;
  ^
../drivers/gpu/drm/i915/gvt/gtt.c: In function 'gen8_gtt_get_pfn':
../drivers/gpu/drm/i915/gvt/gtt.c:360:3: warning: left shift count >= width of 
type [enabled by default]
   pfn = (e->val64 & ADDR_4K_MASK) >> 12;
   ^
../drivers/gpu/drm/i915/gvt/gtt.c: In function 'gen8_gtt_set_pfn':
../drivers/gpu/drm/i915/gvt/gtt.c:373:3: warning: left shift count >= width of 
type [enabled by default]
   e->val64 &= ~ADDR_4K_MASK;
   ^
../drivers/gpu/drm/i915/gvt/gtt.c:374:3: warning: left shift count >= width of 
type [enabled by default]
   pfn &= (ADDR_4K_MASK >> 12);
   ^
../drivers/gpu/drm/i915/gvt/gtt.c: In function 'gen8_gma_to_pml4_index':
../drivers/gpu/drm/i915/gvt/gtt.c:436:1: warning: right shift count >= width of 
type [enabled by default]
 DEFINE_PPGTT_GMA_TO_INDEX(gen8, pml4, (gma >> 39 & 0x1ff));
 ^
  CC  drivers/gpu/drm/radeon/si_smc.o
In file included from ../drivers/gpu/drm/i915/i915_drv.h:46:0,
 from ../drivers/gpu/drm/i915/gvt/gtt.c:36:
../drivers/gpu/drm/i915/gvt/gtt.c: In function 'intel_gvt_create_scratch_page':
../drivers/gpu/drm/i915/gvt/gtt.c:1945:47: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
   gvt_err("fail to translate vaddr:0x%llx\n", (u64)vaddr);
   ^
../include/drm/drmP.h:201:43: note: in definition of macro 'DRM_ERROR'
  drm_printk(KERN_ERR, DRM_UT_NONE, fmt, ##__VA_ARGS__)
   ^
../drivers/gpu/drm/i915/gvt/gtt.c:1945:3: note: in expansion of macro 'gvt_err'
   gvt_err("fail to translate vaddr:0x%llx\n", (u64)vaddr);
   ^



-- 
~Randy

linux-next: Tree for Sep 28 (drivers/gpu/drm/amd/amdgpu/amdgpu.ko)

2016-09-28 Thread Randy Dunlap 
On 09/27/16 23:56, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160927:
> 

on i386:

ERROR: "amd_set_clockgating_by_smu" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] 
undefined!


Full randconfig file is attached.

-- 
~Randy
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.8.0-rc8 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_KERNEL_LZ4=y
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
CONFIG_IRQ_TIME_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_KTHREAD_PRIO=0
CONFIG_RCU_NOCB_CPU=y
CONFIG_RCU_NOCB_CPU_NONE=y
# CONFIG_RCU_NOCB_CPU_ZERO is not set
# CONFIG_RCU_NOCB_CPU_ALL is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=m
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_CGROUP_SCHED=y
# CONFIG_FAIR_GROUP_SCHED is not set
CONFIG_RT_GROUP_SCHED=y
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CPUSETS is not set
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
# CONFIG_CGROUP_PERF is not set
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
CONFIG_RD_BZIP2=y
# CONFIG_RD_LZMA is not set
CONFIG_RD_XZ=y
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
# CONFIG_MULTIUSER is not set
CONFIG_SGETMASK_SYSCALL=y
# CONFIG_SYSFS_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_ABSOLUTE_PERCPU is not set
CONFIG_KALLSYMS_BASE_RELATIVE=y
# CONFIG_PRINTK is not set
CONFIG_BUG=y
# CONFIG_PCSPKR_PLATFORM is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
# CONFIG_TIMERFD is not set

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

2017-01-01 Thread Randy Dunlap 
From: Randy Dunlap <rdun...@infradead.org>

Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and
CONFIG_DRM_NOUVEAU=y.
If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same
kconfig value as LEDS_CLASS.

drivers/built-in.o: In function `nouveau_do_suspend':
nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend'
drivers/built-in.o: In function `nouveau_do_resume':
nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume'
drivers/built-in.o: In function `nouveau_drm_unload':
nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini'
drivers/built-in.o: In function `nouveau_drm_load':
nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init'

BTW, this line in Kbuild:
nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y.

Signed-off-by: Randy Dunlap 
Reported-by: kbuild test robot 
Cc: Martin Peres 
Cc: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- lnx-410-rc2.orig/drivers/gpu/drm/nouveau/Kconfig
+++ lnx-410-rc2/drivers/gpu/drm/nouveau/Kconfig
@@ -1,6 +1,7 @@
 config DRM_NOUVEAU
tristate "Nouveau (NVIDIA) cards"
depends on DRM && PCI
+   depends on LEDS_CLASS || LEDS_CLASS=n
 select FW_LOADER
select DRM_KMS_HELPER
select DRM_TTM

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

2017-01-04 Thread Randy Dunlap 
On 01/04/17 11:29, Jani Nikula wrote:
> On Wed, 04 Jan 2017, Daniel Vetter  wrote:
>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
>>> From: Randy Dunlap 
>>>
>>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and
>>> CONFIG_DRM_NOUVEAU=y.
>>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same
>>> kconfig value as LEDS_CLASS.
>>>
>>> drivers/built-in.o: In function `nouveau_do_suspend':
>>> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend'
>>> drivers/built-in.o: In function `nouveau_do_resume':
>>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume'
>>> drivers/built-in.o: In function `nouveau_drm_unload':
>>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini'
>>> drivers/built-in.o: In function `nouveau_drm_load':
>>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init'
>>>
>>> BTW, this line in Kbuild:
>>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
>>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y.
>>>
>>> Signed-off-by: Randy Dunlap 
>>> Reported-by: kbuild test robot 
>>> Cc: Martin Peres 
>>> Cc: Ben Skeggs 
>>
>> Thrown into drm-misc, thanks.
> 
> Randy, this results in the following recursive dependency using the
> attached config.
> 

Hi,
Please drop the patch for now.  If there is an alternative patch,
that's good.  Otherwise I'll look for a solution.

Thanks.

> BR,
> Jani.
> 
> 
> drivers/usb/Kconfig:39:error: recursive dependency detected!
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/usb/Kconfig:39:   symbol USB is selected by MOUSE_APPLETOUCH
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/input/mouse/Kconfig:187:  symbol MOUSE_APPLETOUCH depends on INPUT
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/input/Kconfig:8:  symbol INPUT is selected by VT
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/tty/Kconfig:12:   symbol VT is selected by FB_STI
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/video/fbdev/Kconfig:678:  symbol FB_STI depends on FB
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/video/fbdev/Kconfig:5:symbol FB is selected by 
> DRM_KMS_FB_HELPER
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/gpu/drm/Kconfig:72:   symbol DRM_KMS_FB_HELPER is selected by 
> DRM_KMS_CMA_HELPER
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/gpu/drm/Kconfig:128:  symbol DRM_KMS_CMA_HELPER is selected by 
> DRM_HDLCD
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/gpu/drm/arm/Kconfig:6:symbol DRM_HDLCD depends on COMMON_CLK
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by X86_INTEL_QUARK
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> arch/x86/Kconfig:554: symbol X86_INTEL_QUARK depends on X86_PLATFORM_DEVICES
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/platform/x86/Kconfig:5:   symbol X86_PLATFORM_DEVICES is selected 
> by DRM_NOUVEAU
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/gpu/drm/nouveau/Kconfig:1:symbol DRM_NOUVEAU depends on LEDS_CLASS
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/leds/Kconfig:16:  symbol LEDS_CLASS is selected by ATH9K_HTC
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/net/wireless/ath/ath9k/Kconfig:158:   symbol ATH9K_HTC depends on USB
> warning: (DRM_NOUVEAU && DRM_I915 && DRM_GMA500) selects ACPI_VIDEO which has 
> unmet direct dependencies (ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT)


-- 
~Randy

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

2017-01-04 Thread Randy Dunlap 
On 01/04/17 19:09, Ilia Mirkin wrote:
> On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap  wrote:
>> On 01/04/17 06:25, Ilia Mirkin wrote:
>>> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter  wrote:
>>>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
>>>>> From: Randy Dunlap 
>>>>>
>>>>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and
>>>>> CONFIG_DRM_NOUVEAU=y.
>>>>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same
>>>>> kconfig value as LEDS_CLASS.
>>>>>
>>>>> drivers/built-in.o: In function `nouveau_do_suspend':
>>>>> nouveau_drm.c:(.text+0x2030b1): undefined reference to 
>>>>> `nouveau_led_suspend'
>>>>> drivers/built-in.o: In function `nouveau_do_resume':
>>>>> nouveau_drm.c:(.text+0x2034ca): undefined reference to 
>>>>> `nouveau_led_resume'
>>>>> drivers/built-in.o: In function `nouveau_drm_unload':
>>>>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini'
>>>>> drivers/built-in.o: In function `nouveau_drm_load':
>>>>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init'
>>>>>
>>>>> BTW, this line in Kbuild:
>>>>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
>>>>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y.
>>>>>
>>>>> Signed-off-by: Randy Dunlap 
>>>>> Reported-by: kbuild test robot 
>>>>> Cc: Martin Peres 
>>>>> Cc: Ben Skeggs 
>>>>
>>>> Thrown into drm-misc, thanks.
>>>> -Daniel
>>>
>>> Wasn't there already a different solution from Martin for this, using
>>> IS_REACHABLE, instead of adding a dependency in Kconfig?
>>
>> nouveau_led.h contains a few lines that are bounded by
>> #if IS_ENABLED(CONFIG_LEDS_CLASS)
>>
>> but that's not sufficient.
>>
>> Is there another patch?
> 
> https://lists.freedesktop.org/archives/nouveau/2016-December/026744.html
> 
> Not sure why it's not upstream yet. I guess Ben missed it?

Ok, if you all are OK with a slightly crippled driver.


-- 
~Randy

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

2017-01-05 Thread Randy Dunlap 
On 01/05/17 00:01, Daniel Vetter wrote:
> On Wed, Jan 04, 2017 at 02:24:51PM -0800, Randy Dunlap wrote:
>> On 01/04/17 11:29, Jani Nikula wrote:
>>> On Wed, 04 Jan 2017, Daniel Vetter  wrote:
>>>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
>>>>> From: Randy Dunlap 
>>>>>
>>>>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and
>>>>> CONFIG_DRM_NOUVEAU=y.
>>>>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same
>>>>> kconfig value as LEDS_CLASS.
>>>>>
>>>>> drivers/built-in.o: In function `nouveau_do_suspend':
>>>>> nouveau_drm.c:(.text+0x2030b1): undefined reference to 
>>>>> `nouveau_led_suspend'
>>>>> drivers/built-in.o: In function `nouveau_do_resume':
>>>>> nouveau_drm.c:(.text+0x2034ca): undefined reference to 
>>>>> `nouveau_led_resume'
>>>>> drivers/built-in.o: In function `nouveau_drm_unload':
>>>>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini'
>>>>> drivers/built-in.o: In function `nouveau_drm_load':
>>>>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init'
>>>>>
>>>>> BTW, this line in Kbuild:
>>>>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
>>>>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y.
>>>>>
>>>>> Signed-off-by: Randy Dunlap 
>>>>> Reported-by: kbuild test robot 
>>>>> Cc: Martin Peres 
>>>>> Cc: Ben Skeggs 
>>>>
>>>> Thrown into drm-misc, thanks.
>>>
>>> Randy, this results in the following recursive dependency using the
>>> attached config.
>>>
>>
>> Hi,
>> Please drop the patch for now.  If there is an alternative patch,
>> that's good.  Otherwise I'll look for a solution.
> 
> Ok, pushed a revert. I guess I'll stop touching Kconfig stuff again for
> the next few months ;-)

:)

That particular circular/recursive dependency is ugly. I spent about
one hour trying/testing various fixes and don't have one.

-- 
~Randy

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

2017-01-04 Thread Randy Dunlap 
On 01/04/17 06:25, Ilia Mirkin wrote:
> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter  wrote:
>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
>>> From: Randy Dunlap 
>>>
>>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and
>>> CONFIG_DRM_NOUVEAU=y.
>>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same
>>> kconfig value as LEDS_CLASS.
>>>
>>> drivers/built-in.o: In function `nouveau_do_suspend':
>>> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend'
>>> drivers/built-in.o: In function `nouveau_do_resume':
>>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume'
>>> drivers/built-in.o: In function `nouveau_drm_unload':
>>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini'
>>> drivers/built-in.o: In function `nouveau_drm_load':
>>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init'
>>>
>>> BTW, this line in Kbuild:
>>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
>>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y.
>>>
>>> Signed-off-by: Randy Dunlap 
>>> Reported-by: kbuild test robot 
>>> Cc: Martin Peres 
>>> Cc: Ben Skeggs 
>>
>> Thrown into drm-misc, thanks.
>> -Daniel
> 
> Wasn't there already a different solution from Martin for this, using
> IS_REACHABLE, instead of adding a dependency in Kconfig?

nouveau_led.h contains a few lines that are bounded by
#if IS_ENABLED(CONFIG_LEDS_CLASS)

but that's not sufficient.

Is there another patch?

-- 
~Randy

[PATCH] dma-buf: fix kernel-doc warning and typos

2016-08-16 Thread Randy Dunlap 
From: Randy Dunlap <rdun...@infradead.org>

Fix dma-buf kernel-doc warning and 2 minor typos in
fence_array_create().

Fixes this warning:
..//drivers/dma-buf/fence-array.c:124: warning: No description found for 
parameter 'signal_on_any'

Signed-off-by: Randy Dunlap 
Cc: Sumit Semwal 
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
---
 drivers/dma-buf/fence-array.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- lnx-48-rc2.orig/drivers/dma-buf/fence-array.c
+++ lnx-48-rc2/drivers/dma-buf/fence-array.c
@@ -106,14 +106,14 @@ const struct fence_ops fence_array_ops =
  * @fences:[in]array containing the fences
  * @context:   [in]fence context to use
  * @seqno: [in]sequence number to use
- * @signal_on_any  [in]signal on any fence in the array
+ * @signal_on_any: [in]signal on any fence in the array
  *
  * Allocate a fence_array object and initialize the base fence with 
fence_init().
  * In case of error it returns NULL.
  *
- * The caller should allocte the fences array with num_fences size
+ * The caller should allocate the fences array with num_fences size
  * and fill it with the fences it wants to add to the object. Ownership of this
- * array is take and fence_put() is used on each fence on release.
+ * array is taken and fence_put() is used on each fence on release.
  *
  * If @signal_on_any is true the fence array signals if any fence in the array
  * signals, otherwise it signals when all fences in the array signal.

linux-next: Tree for Jul 21 (gpu/virtio)

2016-07-21 Thread Randy Dunlap 
On 07/20/16 23:56, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160720:
> 

on x86_64, when CONFIG_FB is not enabled:

ERROR: "remove_conflicting_framebuffers" [drivers/gpu/drm/virtio/virtio-gpu.ko] 
undefined!


-- 
~Randy

linux-next: Tree for Jul 25 (drm/udl without CONFIG_FB)

2016-07-25 Thread Randy Dunlap 
On 07/24/16 23:17, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160724:
> 

on i386, when CONFIG_FB is not enabled:

../drivers/gpu/drm/udl/udl_fb.c: In function 'udl_fb_open':
../drivers/gpu/drm/udl/udl_fb.c:206:23: error: 'struct fb_info' has no member 
named 'fbdefio'
  if (fb_defio && (info->fbdefio == NULL)) {
   ^
../drivers/gpu/drm/udl/udl_fb.c:211:28: error: invalid application of 'sizeof' 
to incomplete type 'struct fb_deferred_io'
   fbdefio = kmalloc(sizeof(struct fb_deferred_io), GFP_KERNEL);
^
../drivers/gpu/drm/udl/udl_fb.c:214:11: error: dereferencing pointer to 
incomplete type
fbdefio->delay = DL_DEFIO_WRITE_DELAY;
   ^
../drivers/gpu/drm/udl/udl_fb.c:215:11: error: dereferencing pointer to 
incomplete type
fbdefio->deferred_io = drm_fb_helper_deferred_io;
   ^
../drivers/gpu/drm/udl/udl_fb.c:218:7: error: 'struct fb_info' has no member 
named 'fbdefio'
   info->fbdefio = fbdefio;
   ^
../drivers/gpu/drm/udl/udl_fb.c: In function 'udl_fb_release':
../drivers/gpu/drm/udl/udl_fb.c:238:38: error: 'struct fb_info' has no member 
named 'fbdefio'
  if ((ufbdev->fb_count == 0) && (info->fbdefio)) {
  ^
../drivers/gpu/drm/udl/udl_fb.c:240:13: error: 'struct fb_info' has no member 
named 'fbdefio'
   kfree(info->fbdefio);
 ^
../drivers/gpu/drm/udl/udl_fb.c:241:7: error: 'struct fb_info' has no member 
named 'fbdefio'
   info->fbdefio = NULL;
   ^



-- 
~Randy

[PATCH] [trivial] drm/i915 Fix typos in i915_gem_fence.c

2016-01-05 Thread Randy Dunlap 
On 01/04/16 19:29, Masanari Iida wrote:
> This patch fix some spelling typos found in Documentation/Docbook
> gpu/ch04s03.html.  This file was generated from comments within
> source, so I have to fix typos in i915_gem_fence.c.
> 
> Signed-off-by: Masanari Iida 
> ---
>  drivers/gpu/drm/i915/i915_gem_fence.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 

Acked-by: Randy Dunlap 

Thanks.


-- 
~Randy

[PATCH -next] gpu: i915: fix build errors when ACPI is not enabled

2016-06-25 Thread Randy Dunlap 
From: Randy Dunlap <rdun...@infradead.org>

Fix build errors when ACPI is not enabled by adding function stubs:

../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_suspend':
../drivers/gpu/drm/i915/i915_drv.c:635:2: error: implicit declaration of 
function 'intel_opregion_unregister' [-Werror=implicit-function-declaration]
  intel_opregion_unregister(dev_priv);
../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_resume':
../drivers/gpu/drm/i915/i915_drv.c:798:2: error: implicit declaration of 
function 'intel_opregion_register' [-Werror=implicit-function-declaration]
  intel_opregion_register(dev_priv);

Signed-off-by: Randy Dunlap 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx at lists.freedesktop.org
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_drv.h |2 ++
 1 file changed, 2 insertions(+)

--- linux-next-20160624.orig/drivers/gpu/drm/i915/i915_drv.h
+++ linux-next-20160624/drivers/gpu/drm/i915/i915_drv.h
@@ -3694,6 +3694,8 @@ extern int intel_opregion_notify_adapter
 extern int intel_opregion_get_panel_type(struct drm_i915_private *dev_priv);
 #else
 static inline int intel_opregion_setup(struct drm_i915_private *dev) { return 
0; }
+static inline void intel_opregion_register(struct drm_i915_private *dev_priv) 
{ }
+static inline void intel_opregion_unregister(struct drm_i915_private 
*dev_priv) { }
 static inline void intel_opregion_init(struct drm_i915_private *dev) { }
 static inline void intel_opregion_fini(struct drm_i915_private *dev) { }
 static inline void intel_opregion_asle_intr(struct drm_i915_private *dev_priv)

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

2014-05-12 Thread Randy Dunlap 
On 05/12/2014 01:58 AM, Daniel Vetter wrote:
> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:

 If we decide to go for property documentation inside the source code then I
 believe we'll have to create our own format, as creating a properties table
 from kerneldoc information extracted from comments is probably not 
 possible.
>>>
>>> Can comeone pick up the ball here and figure out what needs to be done?
>>>
>>> The reason why I want a central place for the documentation is to force
>>> people to collaborate outside their own sandbox when adding properties.
>>> Whether that's docbook or some text file I don't care so much at this
>>> point. The fact that it's a central place should mandate that the
>>> patches changing it will go through dri-devel and so everyone should se
>>> them, and when adding new properties it would make the patch author more
>>> likely to look around a bit before adding another slighty incompatible
>>> version of the same property. If someone has a better suggestion how to
>>> encforce this I'm all ears.
>>>
>>> Of course this idea can still fail if our esteemed maintainer merges
>>> stuff without checking for violations of this policy. Dave, any thoughts
>>> on the subject?
>>
>> Yeah I'm happy to block merging stuff, if we can spot new properties
>> when stuff is posted on dri-devel, so much the better,
>>
>> most drivers still send everything via dri-devel anyways, its only
>> really Intel I have to worry about so far,
> 
> I'll enforce that all prop stuff gets cc: dri-devel and that it has
> updates for the prop docs.
> 
>> But we should definitely add it to the new driver review checklist as well.
>>
>> I'm also on the side of this patch is ugly and makes my eyes burn,
>> please please get a plan to use something else ASAP, I'm willing to
>> merge this but I'm tempted to give it a lifetime of a kernel or two
>> before I burn it.
> 
> Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe
> find someone to do it for me internally ;-)
> -Daniel
> 

I certainly have no objections to making kerneldoc suck less.
There was already an attempt to use asciidoc (like git uses) for kernel-doc
(a few years ago, by Sam Ravnborg).  I support(ed) that effort.

OTOH, I would only want to add another way to do kernel-doc if it can be a
full replacement for all of our docbook usage, i.e., it should provide a
way that we can eliminate docbook and stop using it completely.

thanks,
-- 
~Randy

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

2014-05-12 Thread Randy Dunlap 
On 05/12/2014 08:54 AM, Daniel Vetter wrote:
> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote:
>> On 05/12/2014 01:58 AM, Daniel Vetter wrote:
>>> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
>>>>>>
>>>>>> If we decide to go for property documentation inside the source code 
>>>>>> then I
>>>>>> believe we'll have to create our own format, as creating a properties 
>>>>>> table
>>>>>> from kerneldoc information extracted from comments is probably not 
>>>>>> possible.
>>>>>
>>>>> Can comeone pick up the ball here and figure out what needs to be done?
>>>>>
>>>>> The reason why I want a central place for the documentation is to force
>>>>> people to collaborate outside their own sandbox when adding properties.
>>>>> Whether that's docbook or some text file I don't care so much at this
>>>>> point. The fact that it's a central place should mandate that the
>>>>> patches changing it will go through dri-devel and so everyone should se
>>>>> them, and when adding new properties it would make the patch author more
>>>>> likely to look around a bit before adding another slighty incompatible
>>>>> version of the same property. If someone has a better suggestion how to
>>>>> encforce this I'm all ears.
>>>>>
>>>>> Of course this idea can still fail if our esteemed maintainer merges
>>>>> stuff without checking for violations of this policy. Dave, any thoughts
>>>>> on the subject?
>>>>
>>>> Yeah I'm happy to block merging stuff, if we can spot new properties
>>>> when stuff is posted on dri-devel, so much the better,
>>>>
>>>> most drivers still send everything via dri-devel anyways, its only
>>>> really Intel I have to worry about so far,
>>>
>>> I'll enforce that all prop stuff gets cc: dri-devel and that it has
>>> updates for the prop docs.
>>>
>>>> But we should definitely add it to the new driver review checklist as well.
>>>>
>>>> I'm also on the side of this patch is ugly and makes my eyes burn,
>>>> please please get a plan to use something else ASAP, I'm willing to
>>>> merge this but I'm tempted to give it a lifetime of a kernel or two
>>>> before I burn it.
>>>
>>> Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe
>>> find someone to do it for me internally ;-)
>>> -Daniel
>>>
>>
>> I certainly have no objections to making kerneldoc suck less.
>> There was already an attempt to use asciidoc (like git uses) for kernel-doc
>> (a few years ago, by Sam Ravnborg).  I support(ed) that effort.
> 
> Hm, do you have pointers to those? My google-fu seems lacking ...

I googled for /kernel doc asciidoc ravnborg/ and found several hits for them.

> Ok, let's move this to the top and start discussions. The past few months
> I've written piles of kerneldoc comments for the DRM DocBook (all pulled
> in as kerneldoc, docbook .tmpl has just the chapter structure). DOC:
> sections are really useful to pull all the actual documentation out of the
> docbook xml into kerneldoc.
> 
> But I've also done piles of docs for intel-gpu-tools, which is using
> gtkdoc. And there are some clear deficiencies:
> 
> - No markdown for inline coments. Lack of lists and tables is hurting
>   especially badly. If we add this (and I don't care one iota whether it's

Yes, I've tried to add lists to kernel-doc notation but have failed so far.

>   markdown or asciidoc or something else as long as it's readable plain
>   text in comments) we should be able to move all the existing docbook xml
>   paragraphs/lists/tables into kerneldoc comments.
> 
> - Automatic cross-referencing of functions. If you place e.g. function()
>   or #struct anywhere in a documentation comment gtk-doc automatically
>   inserts a hyperlink to the relevant documentation page across the entire
>   project. Really powerful and makes overview sections much more useful
>   entry points for beginners since they can easily jump back
>   betweeen the high-level overview and low-level per-function
>   documentation.
> 

That's a nice-to-have IMO, but a really nice one.

> - In a really perfect world it would help if kerneldoc could collect
>   structure member kerneldoc from per-member comments. Especially for
>   large structures with lots of comments this would bring the kerneldoc
>   and struct member m

[PATCH 1/4] Documentation: fix typos in drm docbook

2014-05-15 Thread Randy Dunlap 
From:   Masanari Iida 

Fix spelling typo in DocBook/drm.tmpl

Signed-off-by: Masanari Iida 
Signed-off-by: Randy Dunlap 
---
 Documentation/DocBook/drm.tmpl |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- lnx-315-rc2.orig/Documentation/DocBook/drm.tmpl
+++ lnx-315-rc2/Documentation/DocBook/drm.tmpl
@@ -79,7 +79,7 @@
   
 
   This first part of the DRM Developer's Guide documents core DRM code,
-  helper libraries for writting drivers and generic userspace interfaces
+  helper libraries for writing drivers and generic userspace interfaces
   exposed by DRM drivers.
 
   
@@ -459,7 +459,7 @@ char *date;
   providing a solution to every graphics memory-related problems, GEM
   identified common code between drivers and created a support library to
   share it. GEM has simpler initialization and execution requirements than
-  TTM, but has no video RAM management capabitilies and is thus limited to
+  TTM, but has no video RAM management capabilities and is thus limited to
   UMA devices.
 
 
@@ -889,7 +889,7 @@ int (*prime_fd_to_handle)(struct drm_dev
vice versa. Drivers must use the kernel dma-buf buffer sharing 
framework
to manage the PRIME file descriptors. Similar to the mode setting
API PRIME is agnostic to the underlying buffer object manager, as
-   long as handles are 32bit unsinged integers.
+   long as handles are 32bit unsigned integers.
  
  
While non-GEM drivers must implement the operations themselves, GEM
@@ -2356,7 +2356,7 @@ void intel_crt_init(struct drm_device *d
   first create properties and then create and associate individual 
instances
   of those properties to objects. A property can be instantiated multiple
   times and associated with different objects. Values are stored in 
property
-  instances, and all other property information are stored in the propery
+  instances, and all other property information are stored in the property
   and shared between all instances of the property.
 
 
@@ -2697,10 +2697,10 @@ int num_ioctls;
   
 Legacy Support Code
 
-  The section very brievely covers some of the old legacy support code 
which
+  The section very briefly covers some of the old legacy support code which
   is only used by old DRM drivers which have done a so-called shadow-attach
   to the underlying device instead of registering as a real driver. This
-  also includes some of the old generic buffer mangement and command
+  also includes some of the old generic buffer management and command
   submission code. Do not use any of this in new and modern drivers.

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

2014-07-31 Thread Randy Dunlap 
On 05/12/14 11:04, Randy Dunlap wrote:
> On 05/12/2014 08:54 AM, Daniel Vetter wrote:
>> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote:
>>> On 05/12/2014 01:58 AM, Daniel Vetter wrote:
>>>> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
>>>>>>>
>>>>>>> If we decide to go for property documentation inside the source code 
>>>>>>> then I
>>>>>>> believe we'll have to create our own format, as creating a properties 
>>>>>>> table
>>>>>>> from kerneldoc information extracted from comments is probably not 
>>>>>>> possible.
>>>>>>
>>>>>> Can comeone pick up the ball here and figure out what needs to be done?
>>>>>>
>>>>>> The reason why I want a central place for the documentation is to force
>>>>>> people to collaborate outside their own sandbox when adding properties.
>>>>>> Whether that's docbook or some text file I don't care so much at this
>>>>>> point. The fact that it's a central place should mandate that the
>>>>>> patches changing it will go through dri-devel and so everyone should se
>>>>>> them, and when adding new properties it would make the patch author more
>>>>>> likely to look around a bit before adding another slighty incompatible
>>>>>> version of the same property. If someone has a better suggestion how to
>>>>>> encforce this I'm all ears.
>>>>>>
>>>>>> Of course this idea can still fail if our esteemed maintainer merges
>>>>>> stuff without checking for violations of this policy. Dave, any thoughts
>>>>>> on the subject?
>>>>>
>>>>> Yeah I'm happy to block merging stuff, if we can spot new properties
>>>>> when stuff is posted on dri-devel, so much the better,
>>>>>
>>>>> most drivers still send everything via dri-devel anyways, its only
>>>>> really Intel I have to worry about so far,
>>>>
>>>> I'll enforce that all prop stuff gets cc: dri-devel and that it has
>>>> updates for the prop docs.
>>>>
>>>>> But we should definitely add it to the new driver review checklist as 
>>>>> well.
>>>>>
>>>>> I'm also on the side of this patch is ugly and makes my eyes burn,
>>>>> please please get a plan to use something else ASAP, I'm willing to
>>>>> merge this but I'm tempted to give it a lifetime of a kernel or two
>>>>> before I burn it.
>>>>
>>>> Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe
>>>> find someone to do it for me internally ;-)
>>>> -Daniel
>>>>
>>>
>>> I certainly have no objections to making kerneldoc suck less.
>>> There was already an attempt to use asciidoc (like git uses) for kernel-doc
>>> (a few years ago, by Sam Ravnborg).  I support(ed) that effort.
>>
>> Hm, do you have pointers to those? My google-fu seems lacking ...
> 
> I googled for /kernel doc asciidoc ravnborg/ and found several hits for them.
> 
>> Ok, let's move this to the top and start discussions. The past few months
>> I've written piles of kerneldoc comments for the DRM DocBook (all pulled
>> in as kerneldoc, docbook .tmpl has just the chapter structure). DOC:
>> sections are really useful to pull all the actual documentation out of the
>> docbook xml into kerneldoc.
>>
>> But I've also done piles of docs for intel-gpu-tools, which is using
>> gtkdoc. And there are some clear deficiencies:
>>
>> - No markdown for inline coments. Lack of lists and tables is hurting
>>   especially badly. If we add this (and I don't care one iota whether it's
> 
> Yes, I've tried to add lists to kernel-doc notation but have failed so far.
> 
>>   markdown or asciidoc or something else as long as it's readable plain
>>   text in comments) we should be able to move all the existing docbook xml
>>   paragraphs/lists/tables into kerneldoc comments.
>>
>> - Automatic cross-referencing of functions. If you place e.g. function()
>>   or #struct anywhere in a documentation comment gtk-doc automatically
>>   inserts a hyperlink to the relevant documentation page across the entire
>>   project. Really powerful and makes overview sections much more useful
>>   entry points for beginners since they can easily jump back
>>

linux-next: Tree for Jun 19 (drm/i915)

2014-06-19 Thread Randy Dunlap 
On 06/18/14 23:16, Stephen Rothwell wrote:
> Hi all,
> 
> The powerpc allyesconfig is again broken more than usual.
> 
> Changes since 20140618:
> 

on i386:

CONFIG_ACPI is not enabled.

  CC  drivers/gpu/drm/i915/i915_drv.o
../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_freeze':
../drivers/gpu/drm/i915/i915_drv.c:547:2: error: implicit declaration of 
function 'acpi_target_system_state' [-Werror=implicit-function-declaration]
../drivers/gpu/drm/i915/i915_drv.c:547:36: error: 'ACPI_STATE_S3' undeclared 
(first use in this function)
../drivers/gpu/drm/i915/i915_drv.c:547:36: note: each undeclared identifier is 
reported only once for each function it appears in
  CC  net/dccp/qpolicy.o
cc1: some warnings being treated as errors
make[5]: *** [drivers/gpu/drm/i915/i915_drv.o] Error 1



-- 
~Randy

[PATCH 0/3] Reorder drivers/video directory

2014-03-04 Thread Randy Dunlap 
On 03/03/2014 12:45 AM, Tomi Valkeinen wrote:
> On 27/02/14 13:54, Tomi Valkeinen wrote:
>> Hi,
>>
>> This is a re-send of the series, with RFC removed from the subject, and a 
>> bunch
>> of acks added.
>>
>> I'm cc'ing more people, to make sure this doesn't come as a surprise, and to
>> make sure this is not a bad idea, doomed to fail horribly.
>>
>> So this series creates a new directory, drivers/video/fbdev/, to which all
>> fbdev related files are moved. Also, a new directory, 
>> drivers/video/fbdev/core/
>> is created, to which the core fbdev framework files are moved. This makes the
>> drivers/video hierarchy much more clear.
>>
>> Presuming no one has objections to this as such, I wonder what's the least
>> painful way to merge this? Normally, like any other fbdev change? As a 
>> separate
>> pull request, maybe at -rc2 time frame, based on -rc1? Something else?
>>
>>  Tomi
>>
>> Tomi Valkeinen (3):
>>   video: move fbdev to drivers/video/fbdev
>>   fbdev: move fbdev core files to separate directory
>>   video: Kconfig: move drm and fb into separate menus
> 
> I have pushed this to my for-next branch. Let's see what happens... At
> least I'm able to merge the current linux-next without any conflicts.

Thanks, I'm looking at this change in linux-next now.

EXYNOS_VIDEO seems to be a little bit odd.  Can you clarify that for me?
(This is not a change that you introduced.)


In particular, under Graphics support, select Framebuffer Devices.
This lists:
  Support for frame buffer devices -->
  Exynos Video driver support

It appears to me that Exynos either is a Framebuffer Device and should depend
on FB like the other drivers here do OR (actually XOR) it is not a frame buffer
device and it should not be listed here.

Then once that is cleared up :), we don't need 2 levels of menu to get to the
list of FB drivers -- i.e., one of those levels can be removed.

Oh, and if you keep the new menu item "Framebuffer Devices", please spell it
like the other entry (Frame Buffer).


Other than those nits, I like this change very much.  Thanks.

-- 
~Randy

[PATCH 0/3] Reorder drivers/video directory

2014-02-27 Thread Randy Dunlap 
On 02/27/2014 03:54 AM, Tomi Valkeinen wrote:
> Hi,
> 
> This is a re-send of the series, with RFC removed from the subject, and a 
> bunch
> of acks added.
> 
> I'm cc'ing more people, to make sure this doesn't come as a surprise, and to
> make sure this is not a bad idea, doomed to fail horribly.

What does this patch apply to?  I can't get it to apply cleanly to
-rc4 or Linus's current git tree.

I like what I see so far.

Thanks.

> So this series creates a new directory, drivers/video/fbdev/, to which all
> fbdev related files are moved. Also, a new directory, 
> drivers/video/fbdev/core/
> is created, to which the core fbdev framework files are moved. This makes the
> drivers/video hierarchy much more clear.
> 
> Presuming no one has objections to this as such, I wonder what's the least
> painful way to merge this? Normally, like any other fbdev change? As a 
> separate
> pull request, maybe at -rc2 time frame, based on -rc1? Something else?


-- 
~Randy

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

2014-08-01 Thread Randy Dunlap 
On 08/01/14 05:58, Laurent Pinchart wrote:
> Hi Randy,
> 
> On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote:
>> On 05/12/14 11:04, Randy Dunlap wrote:
>>> On 05/12/2014 08:54 AM, Daniel Vetter wrote:
>>>> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote:
>>>>> On 05/12/2014 01:58 AM, Daniel Vetter wrote:
>>>>>> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
>>>>>>>>> If we decide to go for property documentation inside the source code
>>>>>>>>> then I believe we'll have to create our own format, as creating a
>>>>>>>>> properties table from kerneldoc information extracted from comments
>>>>>>>>> is probably not possible.
>>>>>>>>
>>>>>>>> Can comeone pick up the ball here and figure out what needs to be
>>>>>>>> done?
>>>>>>>>
>>>>>>>> The reason why I want a central place for the documentation is to
>>>>>>>> force people to collaborate outside their own sandbox when adding
>>>>>>>> properties. Whether that's docbook or some text file I don't care so
>>>>>>>> much at this point. The fact that it's a central place should mandate
>>>>>>>> that the patches changing it will go through dri-devel and so
>>>>>>>> everyone should se them, and when adding new properties it would make
>>>>>>>> the patch author more likely to look around a bit before adding
>>>>>>>> another slighty incompatible version of the same property. If someone
>>>>>>>> has a better suggestion how to encforce this I'm all ears.
>>>>>>>>
>>>>>>>> Of course this idea can still fail if our esteemed maintainer merges
>>>>>>>> stuff without checking for violations of this policy. Dave, any
>>>>>>>> thoughts on the subject?
>>>>>>>
>>>>>>> Yeah I'm happy to block merging stuff, if we can spot new properties
>>>>>>> when stuff is posted on dri-devel, so much the better,
>>>>>>>
>>>>>>> most drivers still send everything via dri-devel anyways, its only
>>>>>>> really Intel I have to worry about so far,
>>>>>>
>>>>>> I'll enforce that all prop stuff gets cc: dri-devel and that it has
>>>>>> updates for the prop docs.
>>>>>>
>>>>>>> But we should definitely add it to the new driver review checklist as
>>>>>>> well.
>>>>>>>
>>>>>>> I'm also on the side of this patch is ugly and makes my eyes burn,
>>>>>>> please please get a plan to use something else ASAP, I'm willing to
>>>>>>> merge this but I'm tempted to give it a lifetime of a kernel or two
>>>>>>> before I burn it.
>>>>>>
>>>>>> Ok, I'll try to move "make kerneldoc suck less" up the task list and
>>>>>> maybe find someone to do it for me internally ;-)
>>>>>
>>>>> I certainly have no objections to making kerneldoc suck less.
>>>>> There was already an attempt to use asciidoc (like git uses) for
>>>>> kernel-doc (a few years ago, by Sam Ravnborg).  I support(ed) that
>>>>> effort.
>>>>
>>>> Hm, do you have pointers to those? My google-fu seems lacking ...
>>>
>>> I googled for /kernel doc asciidoc ravnborg/ and found several hits for
>>> them.
>>>
>>>> Ok, let's move this to the top and start discussions. The past few months
>>>> I've written piles of kerneldoc comments for the DRM DocBook (all pulled
>>>> in as kerneldoc, docbook .tmpl has just the chapter structure). DOC:
>>>> sections are really useful to pull all the actual documentation out of
>>>> the docbook xml into kerneldoc.
>>>>
>>>> But I've also done piles of docs for intel-gpu-tools, which is using
>>>> gtkdoc. And there are some clear deficiencies:
>>>>
>>>> - No markdown for inline coments. Lack of lists and tables is hurting
>>>>   especially badly. If we add this (and I don't care one iota whether
>>>>   it's
>>>
>>> Yes, I've tried to add lists to kernel-doc notation but have failed so
>>> far.
>>>
>>>

[PATCH] Documentation: DocBook: Rename drm_stub.c to drm_drv.c cause 'make xmldocs' failed

2014-08-10 Thread Randy Dunlap 
On 08/08/14 12:16, Masanari Iida wrote:
> This patch fixed 'make xmldocs' failed on linus's tree and
> linux-next as of 8th/Aug,2014.
> 
> When drm merge for 3.17-rc1 happen,  a file was renamed from
> drm_stub.c to drm_drv.c.
> But Documentation/DocBook/drm.tmpl still have an old file name.
> 
> Signed-off-by: Masanari Iida 

Acked-by: Randy Dunlap 

Thanks.

Linus, please merge as it fixes a DocBook build error.


> ---
>  Documentation/DocBook/drm.tmpl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 1d3756d..bacefc5 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -315,7 +315,7 @@ char *date;
>  drm_dev_unregister() followed by a call to
>  drm_dev_unref().
>
> -!Edrivers/gpu/drm/drm_stub.c
> +!Edrivers/gpu/drm/drm_drv.c
>  
>  
>Driver Load
> 


-- 
~Randy

[PATCH] Documentation: DocBook: Rename drm_stub.c to drm_drv.c cause 'make xmldocs' failed

2014-08-12 Thread Randy Dunlap 
This patch fixed 'make xmldocs' failed on linus's tree and
linux-next as of 8th/Aug,2014.

When drm merge for 3.17-rc1 happen,  a file was renamed from
drm_stub.c to drm_drv.c.
But Documentation/DocBook/drm.tmpl still have an old file name.

Signed-off-by: Masanari Iida 
Signed-off-by: Randy Dunlap 
---
 Documentation/DocBook/drm.tmpl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Linus, please merge since it fixes a fatal DocBook error.


diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 1d3756d..bacefc5 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -315,7 +315,7 @@ char *date;
 drm_dev_unregister() followed by a call to
 drm_dev_unref().
   
-!Edrivers/gpu/drm/drm_stub.c
+!Edrivers/gpu/drm/drm_drv.c
 
 
   Driver Load
-- 
2.1.0.rc0.52.gaa544bf

[PATCH] Documentation: DocBook: Rename drm_stub.c to drm_drv.c cause 'make xmldocs' failed

2014-08-13 Thread Randy Dunlap 
On 08/12/14 18:17, Fabio Estevam wrote:
> On Tue, Aug 12, 2014 at 2:30 PM, Randy Dunlap  
> wrote:
>> This patch fixed 'make xmldocs' failed on linus's tree and
>> linux-next as of 8th/Aug,2014.
>>
>> When drm merge for 3.17-rc1 happen,  a file was renamed from
>> drm_stub.c to drm_drv.c.
>> But Documentation/DocBook/drm.tmpl still have an old file name.
>>
>> Signed-off-by: Masanari Iida 
>> Signed-off-by: Randy Dunlap 
> 
> Isn't the From field missing to indicate Masanari's authorship of this patch?

Hm, yes, I'm afraid that it is.  Sorry about that.

If Linus doesn't merge it, I'll add it to my patch queue or David Airlie
can do that as well.

Thanks.
-- 
~Randy

[PATCH] Documentation: DocBook: Rename drm_stub.c to drm_drv.c cause 'make xmldocs' failed

2014-08-13 Thread Randy Dunlap 
On 08/08/14 12:16, Masanari Iida wrote:
> This patch fixed 'make xmldocs' failed on linus's tree and
> linux-next as of 8th/Aug,2014.
> 
> When drm merge for 3.17-rc1 happen,  a file was renamed from
> drm_stub.c to drm_drv.c.
> But Documentation/DocBook/drm.tmpl still have an old file name.
> 
> Signed-off-by: Masanari Iida 

Applied to my patch queue.  Thanks.

> ---
>  Documentation/DocBook/drm.tmpl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 1d3756d..bacefc5 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -315,7 +315,7 @@ char *date;
>  drm_dev_unregister() followed by a call to
>  drm_dev_unref().
>
> -!Edrivers/gpu/drm/drm_stub.c
> +!Edrivers/gpu/drm/drm_drv.c
>  
>  
>Driver Load
> 


-- 
~Randy

[PATCH] dma-buf: fix kernel-doc warning

2014-08-16 Thread Randy Dunlap 
From: Randy Dunlap <rdun...@infradead.org>

Fix kernel-doc warning, missing parameter description:

Warning(..//include/linux/seqno-fence.h:99): No description found for parameter 
'cond'

Signed-off-by: Randy Dunlap 
Cc: Rob Clark 
Cc: Maarten Lankhorst 
---
 include/linux/seqno-fence.h |1 +
 1 file changed, 1 insertion(+)

Index: lnx-317-rc1/include/linux/seqno-fence.h
===
--- lnx-317-rc1.orig/include/linux/seqno-fence.h
+++ lnx-317-rc1/include/linux/seqno-fence.h
@@ -62,6 +62,7 @@ to_seqno_fence(struct fence *fence)
  * @context: the execution context this fence is a part of
  * @seqno_ofs: the offset within @sync_buf
  * @seqno: the sequence # to signal on
+ * @cond: the fence condition to check
  * @ops: the fence_ops for operations on this seqno fence
  *
  * This function initializes a struct seqno_fence with passed parameters,

[PATCH] drm: fix drm_modeset_lock.h kernel-doc notation

2014-08-16 Thread Randy Dunlap 
From: Randy Dunlap <rdun...@infradead.org>

Fix drm kernel-doc notation to squelch these warnings:

Warning(..//include/drm/drm_modeset_lock.h:41): cannot understand function 
prototype: 'struct drm_modeset_acquire_ctx '
Warning(..//include/drm/drm_modeset_lock.h:66): cannot understand function 
prototype: 'struct drm_modeset_lock '

Need to include the keyword 'struct' for structure descriptions.

Signed-off-by: Randy Dunlap 
---
 include/drm/drm_modeset_lock.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: lnx-317-rc1/include/drm/drm_modeset_lock.h
===
--- lnx-317-rc1.orig/include/drm/drm_modeset_lock.h
+++ lnx-317-rc1/include/drm/drm_modeset_lock.h
@@ -29,7 +29,7 @@
 struct drm_modeset_lock;

 /**
- * drm_modeset_acquire_ctx - locking context (see ww_acquire_ctx)
+ * struct drm_modeset_acquire_ctx - locking context (see ww_acquire_ctx)
  * @ww_ctx: base acquire ctx
  * @contended: used internally for -EDEADLK handling
  * @locked: list of held locks
@@ -56,7 +56,7 @@ struct drm_modeset_acquire_ctx {
 };

 /**
- * drm_modeset_lock - used for locking modeset resources.
+ * struct drm_modeset_lock - used for locking modeset resources.
  * @mutex: resource locking
  * @head: used to hold it's place on state->locked list when
  *part of an atomic update

[PATCH] drm/vmwgfx: select FB when DRM_VMWGFX is selected

2014-08-31 Thread Randy Dunlap 
On 08/31/14 16:07, Max Filippov wrote:
> Otherwise, if FB is not selected build fails at linking step:
>   vmwgfx_fb.c:(.text+0x4098b): undefined reference to `register_framebuffer'
>   vmwgfx_fb.c:(.text+0x409c0): undefined reference to `framebuffer_release'
>   vmwgfx_fb.c:(.text+0x409f4): undefined reference to `unregister_framebuffer'
>   vmwgfx_fb.c:(.text+0x40a0e): undefined reference to `framebuffer_release'
> 
> Patch ae6445ac7475ff05 drm/vmwgfx: depends on FB
> added dependency on FB that was subsequently removed in patch
> 04381b987292256d drm: Move plane helpers into drm_kms_helper.ko
> 
> Signed-off-by: Max Filippov 
> ---
>  drivers/gpu/drm/vmwgfx/Kconfig |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
> index 67720f7..4fba548 100644
> --- a/drivers/gpu/drm/vmwgfx/Kconfig
> +++ b/drivers/gpu/drm/vmwgfx/Kconfig
> @@ -1,6 +1,7 @@
>  config DRM_VMWGFX
>   tristate "DRM driver for VMware Virtual GPU"
>   depends on DRM && PCI
> + select FB
>   select FB_DEFERRED_IO
>   select FB_CFB_FILLRECT
>   select FB_CFB_COPYAREA
> 

My experience with these "select FB_*" things is that this symbol (DRM_VMWGFX)
should still depend on FB.  Has something changed recently to negate that?


-- 
~Randy

[PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body

2015-08-03 Thread Randy Dunlap 
On 07/31/15 14:06, Danilo Cesar Lemes de Paula wrote:
> Describing arguments at top of a struct definition works fine
> for small/medium size structs, but it definitely doesn't work well
> for struct with a huge list of elements.
> 
> Keeping the arguments list inside the struct body makes it easier
> to maintain the documentation.
> ie:
> /**
>  * struct my_struct - short description
>  * @a: first member
>  * @b: second member
>  *
>  * Longer description
>  */
> struct my_struct {
> int a;
> int b;
> /**
>  * @c: This is longer description of C
>  *
>  * You can use paragraphs to describe arguments
>  * using this method.
>  */
> int c;
> };
> 
> This patch allows the use of this kind of syntax. Only one argument
> per comment and user can use how many paragraphs he needs. It should
> start with /**, which is already being used by kernel-doc. If those
> comment doesn't follow those rules, it will be ignored.
> 
> Signed-off-by: Danilo Cesar Lemes de Paula 
> Cc: Randy Dunlap 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Cc: Jonathan Corbet 
> Cc: Herbert Xu 
> Cc: Stephan Mueller 
> Cc: Michal Marek 
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-doc at vger.kernel.org
> Cc: intel-gfx 
> Cc: dri-devel 
> ---
>  scripts/kernel-doc | 80 
> --
>  1 file changed, 78 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 9922e66..9bfa8b9 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -133,6 +133,30 @@ use strict;
>  #
>  # All descriptions can be multiline, except the short function description.
>  #
> +# For really longs structs, you can also describe arguments inside the
> +# body of the struct.
> +# eg.
> +# /**
> +#  * struct my_struct - short description
> +#  * @a: first member
> +#  * @b: second member
> +#  *
> +#  * Longer description
> +#  */
> +# struct my_struct {
> +# int a;
> +# int b;
> +# /**
> +#  * @c: This is longer description of C
> +#  *
> +#  * You can use paragraphs to describe arguments
> +#  * using this method.
> +#  */
> +# int c;
> +# };
> +#
> +# This should be use for arguments only.

used

What are "arguments" in this context?  do you mean struct fields or members?

> +#
>  # You can also add additional sections. When documenting kernel functions you
>  # should document the "Context:" of the function, e.g. whether the functions
>  # can be called form interrupts. Unlike other sections you can end it with an
> @@ -287,9 +311,19 @@ my $lineprefix="";
>  # 2 - scanning field start.
>  # 3 - scanning prototype.
>  # 4 - documentation block
> +# 5 - gathering documentation outside main block
>  my $state;
>  my $in_doc_sect;
>  
> +# Split Doc State
> +# 0 - Invalid (Before start or after finish)
> +# 1 - Is started (the /** was found inside a struct)
> +# 2 - The @parameter header was found, start accepting multi paragraph text.
> +# 3 - Finished (the */ was found)
> +# 4 - Error - Comment without header was found. Spit a warning as it's not
> +# proper kernel-doc and ignore the rest.
> +my $split_doc_state;
> +
>  #declaration types: can be
>  # 'function', 'struct', 'union', 'enum', 'typedef'
>  my $decl_type;
> @@ -304,6 +338,9 @@ my $doc_decl = $doc_com . '(\w+)';
>  my $doc_sect = $doc_com . '([' . $doc_special . ']?[\w\s]+):(.*)';
>  my $doc_content = $doc_com_body . '(.*)';
>  my $doc_block = $doc_com . 'DOC:\s*(.*)?';
> +my $doc_split_start = '^\s*/\*\*\s*$';
> +my $doc_split_sect = '\s*\*\s*(@[\w\s]+):(.*)';
> +my $doc_split_end = '^\s*\*/\s*$';
>  
>  my %constants;
>  my %parameterdescs;
> @@ -2181,6 +2218,7 @@ sub reset_state {
>  $prototype = "";
>  
>  $state = 0;
> +$split_doc_state = 0;
>  }
>  
>  sub tracepoint_munge($) {
> @@ -2453,7 +2491,6 @@ sub process_file($) {
>   }
>   $section = $newsection;
>   } elsif (/$doc_end/) {
> -
>   if (($contents ne "") && ($contents ne "\n")) {
>   dump_section($file, $section, xml_escape($contents));
>   $section = $section_default;
> @@ -2494,8 +2531,47 @@ sub process_file($) {
>   print STDERR "Warning(${file}:$.): bad line: $_";
>   ++$warnings;
>   }
> + } elsif ($state == 5) { # scanning for split parameters
> +
> + # First line (state 1) needs to be a @parameter
> + if ($split_doc_state ==

randconfig build error with next-20141001, in drivers/gpu/drm/i915

2014-10-01 Thread Randy Dunlap 
On 10/01/14 10:57, Jani Nikula wrote:
> On Wed, 01 Oct 2014, Jim Davis  wrote:
>> Building with the attached random configuration file,
>>
>> warning: (VIDEO_TIMBERDALE) selects TIMB_DMA which has unmet direct
>> dependencies (DMADEVICES && MFD_TIMBERDALE)
>> warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG
>> which has unmet direct dependencies (USB_SUPPORT && USB && PM_RUNTIME)
>>
>> drivers/built-in.o: In function `intel_panel_setup_backlight':
>> (.text+0x11855d): undefined reference to `backlight_device_register'
>> drivers/built-in.o: In function `intel_panel_destroy_backlight':
>> (.text+0x118624): undefined reference to `backlight_device_unregister'
>> make: *** [vmlinux] Error 1
> 
> It's the combination:
> 
>> CONFIG_DRM_I915=y
>> CONFIG_BACKLIGHT_CLASS_DEVICE=m
> 
> Not sure what the Kconfig magic spell needs to be when we don't want to
> depend on CONFIG_BACKLIGHT_CLASS_DEVICE but we'll use it if it's enabled
> (y or m).

Something like:

depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n

is what we usually use.


-- 
~Randy

randconfig build error with next-20141001, in drivers/gpu/drm/i915

2014-10-02 Thread Randy Dunlap 
On 10/02/14 00:46, Jani Nikula wrote:
> On Wed, 01 Oct 2014, Randy Dunlap  wrote:
>> On 10/01/14 10:57, Jani Nikula wrote:
>>> On Wed, 01 Oct 2014, Jim Davis  wrote:
>>>> Building with the attached random configuration file,
>>>>
>>>> warning: (VIDEO_TIMBERDALE) selects TIMB_DMA which has unmet direct
>>>> dependencies (DMADEVICES && MFD_TIMBERDALE)
>>>> warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG
>>>> which has unmet direct dependencies (USB_SUPPORT && USB && PM_RUNTIME)
>>>>
>>>> drivers/built-in.o: In function `intel_panel_setup_backlight':
>>>> (.text+0x11855d): undefined reference to `backlight_device_register'
>>>> drivers/built-in.o: In function `intel_panel_destroy_backlight':
>>>> (.text+0x118624): undefined reference to `backlight_device_unregister'
>>>> make: *** [vmlinux] Error 1
>>>
>>> It's the combination:
>>>
>>>> CONFIG_DRM_I915=y
>>>> CONFIG_BACKLIGHT_CLASS_DEVICE=m
>>>
>>> Not sure what the Kconfig magic spell needs to be when we don't want to
>>> depend on CONFIG_BACKLIGHT_CLASS_DEVICE but we'll use it if it's enabled
>>> (y or m).
>>
>> Something like:
>>
>>  depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
>>
>> is what we usually use.
> 
> Oh boy this gets ugly. Trying
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 4e39ab34eb1c..daa453c62aa6 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -3,6 +3,7 @@ config DRM_I915
>   depends on DRM
>   depends on X86 && PCI
>   depends on (AGP || AGP=n)
> + depends on (BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n)
>   select INTEL_GTT
>   select AGP_INTEL if AGP
>   select INTERVAL_TREE
> 
> leads to
> 
> scripts/kconfig/conf --olddefconfig Kconfig
> drivers/gpu/drm/i915/Kconfig:1:error: recursive dependency detected!
> drivers/gpu/drm/i915/Kconfig:1:   symbol DRM_I915 depends on 
> BACKLIGHT_CLASS_DEVICE
> drivers/video/backlight/Kconfig:156:  symbol BACKLIGHT_CLASS_DEVICE is 
> selected by DRM_I915
> 
> because we depend on ACPI_VIDEO when ACPI is enabled, originally done in
> 
> commit ecb4aed78dcf09e48c8c34c8c2fa7f5c69344be6
> Author: Len Brown 
> Date:   Fri Apr 24 11:33:47 2009 -0400
> 
> ACPI, i915: build fix
> 
> Now, trying to fix that with what seems to me like the obvious
> dependency, conveying what we really want
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 4e39ab34eb1c..f5a1ee37603e 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -3,6 +3,7 @@ config DRM_I915
>   depends on DRM
>   depends on X86 && PCI
>   depends on (AGP || AGP=n)
> + depends on ((ACPI && ACPI_VIDEO) || ACPI=n)
>   select INTEL_GTT
>   select AGP_INTEL if AGP
>   select INTERVAL_TREE
> @@ -11,13 +12,6 @@ config DRM_I915
>   select SHMEM
>   select TMPFS
>   select DRM_KMS_HELPER
> - # i915 depends on ACPI_VIDEO when ACPI is enabled
> - # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> - select BACKLIGHT_LCD_SUPPORT if ACPI
> - select BACKLIGHT_CLASS_DEVICE if ACPI
> - select INPUT if ACPI
> - select ACPI_VIDEO if ACPI
> - select ACPI_BUTTON if ACPI
>   help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> 
> leads to more fun
> 
> scripts/kconfig/conf --olddefconfig Kconfig
> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:5:symbol FB is selected by 
> DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:34:   symbol DRM_KMS_FB_HELPER is selected by 
> DRM_I915_FBDEV
> drivers/gpu/drm/i915/Kconfig:40:  symbol DRM_I915_FBDEV depends on 
> DRM_I915
> drivers/gpu/drm/i915/Kconfig:1:   symbol DRM_I915 depends on ACPI_VIDEO
> drivers/acpi/Kconfig:130: symbol ACPI_VIDEO is selected by 
> BACKLIGHT_CLASS_DEVICE
> drivers/video/backlight/Kconfig:156:  symbol BACKLIGHT_CLASS_DEVICE is 
> selected by FB_BACKLIGHT
> drivers/video/fbdev/Kconfig:188:  symbol FB_BACKLIGHT is selected by 
> PMAC_BACKLIGHT
> drivers/macintosh/Kconfig:135:symbol PMAC_BACKLIGHT depends on FB
> 
> and the rabbit hole gets deeper than I thought. I guess it always does.
> 
> At this point the question is whether "depends on ((ACPI && ACPI_VIDEO)
> || ACPI=n)" is worth pursuing and makes more sense than the "select foo
> if ACPI" lines, or do we need to build hacks upon hacks to get this
> fixed.

I certainly prefer the depends that you added to all of those selects.

I'm afraid that I can't help you much here other than to say that if you
can express the driver needs with depends instead of select, you should
come out ahead by removing some of the depth of the rabbit hole.


-- 
~Randy

[PATCH] gpu:drm: Fix typo in Documentation/DocBook/drm.xml

2014-10-20 Thread Randy Dunlap 
On 10/20/14 07:53, Masanari Iida wrote:
> This patch fix spelling typos found in drm.xml.
> It is because the file is generated from comments in
> source codes, I have to fix the typos within source files.
> 
> Signed-off-by: Masanari Iida 

Acked-by: Randy Dunlap 

Thanks.

> ---
>  drivers/gpu/drm/drm_crtc.c | 2 +-
>  drivers/gpu/drm/drm_irq.c  | 4 ++--
>  drivers/gpu/drm/drm_modes.c| 2 +-
>  drivers/gpu/drm/drm_prime.c| 4 ++--
>  drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
>  drivers/gpu/drm/i915/i915_reg.h| 2 +-
>  drivers/gpu/drm/i915/intel_lrc.c   | 2 +-
>  include/drm/drm_dp_mst_helper.h| 2 +-
>  8 files changed, 11 insertions(+), 11 deletions(-)


-- 
~Randy

[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO

2014-10-28 Thread Randy Dunlap 
On 10/27/14 06:13, Tomi Valkeinen wrote:
> On 27/10/14 13:59, Jani Nikula wrote:
> 
>>> While doing 'depends on' instead of 'select' is an "easy" fix for this,
>>> I do dislike it quite a bit. It's a major pain to go around the kernel
>>> config, trying to find all the dependencies that a particular driver
>>> wants. If I need fb-foobar, I should just be able to enable it, instead
>>> of first searching and selecting its minor dependencies individually.
>>
>> Agreed, but I don't think that's specific to this patch.
> 
> Well, no, the generic problem is not specific to this patch, but we can
> avoid the issue with proper use of 'select' (at least in some cases),
> which is specific to this patch.
> 
>>> So, not a NACK, but a "isn't there an another way to fix this?".
>>
>> I think the real answer would be to fix kconfig to also show menu items
>> whose dependencies are not met, and then recursively enabling the
>> dependencies when the item is enabled. Beyond my scope.
>>
>>> Looking at backlight... BACKLIGHT_LCD_SUPPORT seems to be a "meta"
>>> option, it only enables a Kconfig submenu.
>>>
>>> So I think we could just remove the whole BACKLIGHT_LCD_SUPPORT option.
>>> But if we do that, all the items in drivers/video/backlight/Kconfig with
>>> default 'y' or 'm' would get enabled by default, so I think we should
>>> remove the 'default's from that file. That makes sense in any case, as I
>>> don't see why "HP Jornada 700 series LCD Driver" should be "default y".
>>>
>>> BACKLIGHT_CLASS_DEVICE doesn't depend on anything except
>>> BACKLIGHT_LCD_SUPPORT, so after removing BACKLIGHT_LCD_SUPPORT it should
>>> be safe to 'select' BACKLIGHT_CLASS_DEVICE.
>>>
>>> BACKLIGHT_CLASS_DEVICE could be made a hidden option, and the drivers in
>>> drivers/video/backlight/Kconfig which are under BACKLIGHT_CLASS_DEVICE
>>> could be made to select BACKLIGHT_CLASS_DEVICE instead.
>>
>> I think it should be possible to choose between y and m when it's
> 
> If I'm not mistaken, if CONFIG_FOO is 'm', and it 'select's CONFIG_BAR,
> and CONFIG_BAR is tristate, then CONFIG_BAR will be set to 'm'.
> 
>> selected, and it should be possible to enable it when it's not selected
>> by any drivers. I'm not sure a hidden option is good for that.
> 
> Why would you want to enable it if no one uses it? Does
> BACKLIGHT_CLASS_DEVICE enable something even if no driver uses it?
> 
>>> That doesn't exactly fix anything, but I think it makes sense as
>>> BACKLIGHT_CLASS_DEVICE is something that's selected from all around the
>>> kernel, so it should be a selectable "library" instead of a Kconfig menu
>>> option.
>>
>> At least for drm/i915 BACKLIGHT_CLASS_DEVICE is "an option". We use it
>> if it's enabled, but we are just fine if it's not. I've learned the way
>> to express that is
>>
>>  depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
>>
>> but I don't think there's a way to express that in terms of select, is
>> there? The dependency above guarantees there's no DRM_I915=y and
>> BACKLIGHT_CLASS_DEVICE=m combo which would fail. And this, btw, is where
>> this whole patch got started, as select didn't handle that properly.
> 
> If backlight support is considered an option for drm/i915, then I think
> there should be a Kconfig option for i915 to enable backlight support,
> which in turn selects BACKLIGHT_CLASS_DEVICE. And that select will force
> BACKLIGHT_CLASS_DEVICE to be built-in if drm/i915 is built-in.
> 
> Oh, but it doesn't work optimally with modules. The new option needed
> for that would be boolean, so BACKLIGHT_CLASS_DEVICE would always be
> either y or n. Sigh...
> 
>>> I didn't look at the ACPI_VIDEO side, so no idea how messy that is.
>>
>> Basically it's another dependency on BACKLIGHT_CLASS_DEVICE. I can only
>> imagine trying to solve this problem with select is going to end up in
>> recursive dependencies that spread out and need changing about as wide
>> as this patch.
> 
> If ACPI_VIDEO uses select to enable BACKLIGHT_CLASS_DEVICE, then, I
> think, selecting ACPI_VIDEO will also select BACKLIGHT_CLASS_DEVICE. So
> I don't right away see any recursive dependencies. Or what did you have
> in mind?
> 
>> In the end, I agree with the problem you have with this patch, but yet I
>> think it's the right thing to do in terms of expressing the
>> dependencies.
> 
> Well, dri/i915 doesn't exactly depend on backlight, if I understood you
> correctly. Instead, backlight is an option for dri/i915, and you kind of
> hack it to be implemented with that 'depends on BACKLIGHT_CLASS_DEVICE
> || BACKLIGHT_CLASS_DEVICE=n'.
> 
> I guess it's debatable whether drivers should automatically use features
> in the kernel if they happen to be enabled in the Kconfig, or should
> they be individually enabled for that driver. I personally like the
> latter option, as it allows more precise control, but it probably also
> depends on the feature in question.
> 
> I also think the 'depends on BACKLIGHT_CLASS_DEVICE ||
>

drm: i915 hangcheck/GPU errors

2012-03-06 Thread Randy Dunlap 
Hi,

My Toshiba Portege (Intel Core i5) hangs every few days.
Sometimes I can see no log messages/reasons for it.
Sometimes there are messages about X receiving potentially
fatal signals.

Today's hang appears to have some useful info (maybe).

Mar  6 09:01:45 dragon kernel: [137308.704424] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Mar  6 09:01:45 dragon kernel: [137308.704552] [drm] capturing error event; 
look for more information in /debug/dri/0/i915_error_state
Mar  6 09:01:45 dragon kernel: [137308.718950] [drm:i915_wait_request] *ERROR* 
i915_wait_request returns -11 (awaiting 16513584 at 16513581, next 16513585)
Mar  6 09:02:13 dragon kernel: [137336.754647] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Mar  6 09:02:13 dragon kernel: [137336.754698] [drm:i915_wait_request] *ERROR* 
i915_wait_request returns -11 (awaiting 16517081 at 16517078, next 16517082)

...

Mar  6 09:05:44 dragon kernel: [137548.071904] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Mar  6 09:05:44 dragon kernel: [137548.071951] [drm:i915_wait_request] *ERROR* 
i915_wait_request returns -11 (awaiting 16550939 at 16550936, next 16550940)
Mar  6 09:05:57 dragon kernel: [137560.924459] X/1399: potentially unexpected 
fatal signal 6.
Mar  6 09:05:57 dragon kernel: [137560.924463] 
Mar  6 09:05:57 dragon kernel: [137560.924466] CPU 1 
Mar  6 09:05:57 dragon kernel: [137560.924468] Modules linked in: usblp 
snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq 
snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 af_packet acpi_cpufreq mperf lp 
ppdev parport_pc parport snd_hda_codec_hdmi snd_hda_codec_realtek uvcvideo 
videobuf2_core videobuf2_vmalloc videobuf2_memops usbhid hid mousedev 
snd_hda_codec arc4 snd_hwdep iwlwifi toshiba_acpi psmouse snd_pcm snd_timer 
sparse_keymap ehci_hcd battery serio_raw mac80211 evdev thermal ac xhci_hcd 
snd_page_alloc wmi power_supply e1000e mei(C) sdhci_pci sdhci mmc_core 
firmware_class cfg80211 rfkill processor sg rtc_cmos loop unix [last unloaded: 
snd_hda_intel]
Mar  6 09:05:57 dragon kernel: [137560.924560] 
Mar  6 09:05:58 dragon kernel: [137560.924564] Pid: 1399, comm: X Tainted: G
 C   3.3.0-rc5 #2 TOSHIBA PORTEGE R835/Portable PC
Mar  6 09:05:58 dragon kernel: [137560.924572] RIP: 0033:[<7f57463c7035>]  
[<7f57463c7035>] 0x7f57463c7034
Mar  6 09:05:58 dragon kernel: [137560.924581] RSP: 002b:7fff0ac33758  
EFLAGS: 3206
Mar  6 09:05:58 dragon kernel: [137560.924585] RAX:  RBX: 
 RCX: 
Mar  6 09:05:58 dragon kernel: [137560.924589] RDX: 0006 RSI: 
0577 RDI: 0577
Mar  6 09:05:58 dragon kernel: [137560.924593] RBP: 7fff0ac341a0 R08: 
7f57464ee8e0 R09: 00411e40
Mar  6 09:05:59 dragon kernel: [137560.924597] R10: 0008 R11: 
3206 R12: 0037
Mar  6 09:06:00 dragon kernel: [137560.924600] R13: 7fff0ac33a80 R14: 
004f R15: 0007
Mar  6 09:06:00 dragon kernel: [137560.924604] FS:  7f57487a18a0() 
GS:88014a60() knlGS:
Mar  6 09:06:02 dragon kernel: [137560.924609] CS:  0010 DS:  ES:  CR0: 
80050033
Mar  6 09:06:02 dragon kernel: [137560.924612] CR2: 00418ff0 CR3: 
00013d059000 CR4: 000406e0
Mar  6 09:06:02 dragon kernel: [137560.924616] DR0:  DR1: 
 DR2: 
Mar  6 09:06:02 dragon kernel: [137560.924620] DR3:  DR6: 
0ff0 DR7: 0400
Mar  6 09:06:03 dragon kernel: [137560.924624] Process X (pid: 1399, threadinfo 
88013e9cc000, task 88012412)
Mar  6 09:06:03 dragon kernel: [137560.924627] 
Mar  6 09:06:03 dragon kernel: [137560.924630] Call Trace:




Any ideas/suggestions?



"look for more information in /debug/dri/0/i915_error_state"

Where is that file?  in debugfs or somewhere else?

thanks,
-- 
~Randy

[PATCH -next] vgaarb.h: fix build warnings

2012-03-13 Thread Randy Dunlap 
On 01/30/2012 11:43 AM, Randy Dunlap wrote:

This patch is still needed in linux-next of 20120313.


> From: Randy Dunlap 
> 
> Fix build warnings by providing a struct stub since no fields of
> the struct are used:
> 
> include/linux/vgaarb.h:66:9: warning: 'struct pci_dev' declared inside 
> parameter list
> include/linux/vgaarb.h:66:9: warning: its scope is only this definition or 
> declaration, which is probably not what you want
> include/linux/vgaarb.h:99:34: warning: 'struct pci_dev' declared inside 
> parameter list
> include/linux/vgaarb.h:109:6: warning: 'struct pci_dev' declared inside 
> parameter list
> include/linux/vgaarb.h:121:8: warning: 'struct pci_dev' declared inside 
> parameter list
> include/linux/vgaarb.h:140:37: warning: 'struct pci_dev' declared inside 
> parameter list
> 
> Signed-off-by: Randy Dunlap 
> Cc:   David Airlie 
> Cc:   dri-devel at lists.freedesktop.org
> ---
>  include/linux/vgaarb.h |2 ++
>  1 file changed, 2 insertions(+)
> 
> --- linux-next-20120130.orig/include/linux/vgaarb.h
> +++ linux-next-20120130/include/linux/vgaarb.h
> @@ -47,6 +47,8 @@
>   */
>  #define VGA_DEFAULT_DEVICE (NULL)
>  
> +struct pci_dev;
> +
>  /* For use by clients */
>  
>  /**
> 



-- 
~Randy

linux-next: Tree for May 8 (gpu/drm/gma500)

2012-05-08 Thread Randy Dunlap 
On 05/08/2012 01:15 AM, Stephen Rothwell wrote:

> Hi all,
> 
> There will be no linux-next tomorrow.
> 
> Changes since 20120507:



When CONFIG_ACPI is not enabled:

drivers/gpu/drm/gma500/opregion.c:269:3: error: implicit declaration of 
function 'register_acpi_notifier'
drivers/gpu/drm/gma500/opregion.c:288:3: error: implicit declaration of 
function 'unregister_acpi_notifier'

-- 
~Randy

linux-next: Tree for May 18 (drm drivers and vgacon)

2012-05-18 Thread Randy Dunlap 
On 05/18/2012 01:49 AM, Stephen Rothwell wrote:

> Hi all,
> 
> Changes since 201205017:


When CONFIG_VGA_CONSOLE is not enabled:

drivers/gpu/drm/cirrus/cirrus_drv.c:87:2: error: implicit declaration of 
function 'vgacon_text_force'
drivers/gpu/drm/ast/ast_drv.c:224:2: error: implicit declaration of function 
'vgacon_text_force'
drivers/gpu/drm/mgag200/mgag200_drv.c:96:2: error: implicit declaration of 
function 'vgacon_text_force'


-- 
~Randy

linux-next: Tree for Nov 14 (gpu/drm/i915)

2012-11-14 Thread Randy Dunlap 
On 11/13/2012 09:30 PM, Stephen Rothwell wrote:

> Hi all,
> 
> News: next-20121115 (i.e. tomorrow) will be the last release until
> next-20121126 (which should be just be after -rc7, I guess - assuming
> that Linus does not release v3.7 before then), so if you want something
> in linux-next for a reasonable amount of testing, it should probably be
> committed tomorrow.
> 
> Changes since 20121113:
> 



on i386:

ERROR: "__build_bug_on_failed" [drivers/gpu/drm/i915/i915.ko] undefined!

Reference to that symbol is found in
i915_gem_execbuffer.o.  Reference to BUILD_BUG_ON() is found in
i915_gem_execbuffer.c:

static struct eb_objects *
eb_create(int size)
{
struct eb_objects *eb;
int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head)));


-- 
~Randy

linux-next: Tree for Oct 5 (nouveau)

2012-10-05 Thread Randy Dunlap 
On 10/04/2012 09:54 PM, Stephen Rothwell wrote:

> Hi all,
> 
> Do not add stuff destined for v3.8 to your linux-next included branches
> until after v3.7-rc1 is released.
> 
> Changes since 201201004:
> 


on x86_64, when CONFIG_AGP is not enabled:

  CC [M]  drivers/gpu/drm/nouveau/nouveau_bo.o
drivers/gpu/drm/nouveau/nouveau_bo.c: In function 'nouveau_ttm_tt_create':
drivers/gpu/drm/nouveau/nouveau_bo.c:463:3: error: implicit declaration of 
function 'ttm_agp_tt_create'
drivers/gpu/drm/nouveau/nouveau_bo.c:463:3: warning: return makes pointer from 
integer without a cast
make[5]: *** [drivers/gpu/drm/nouveau/nouveau_bo.o] Error 1


-- 
~Randy

[PATCH -next] drm: fix radeon printk format warnings

2012-10-10 Thread Randy Dunlap 
From: Randy Dunlap <rdun...@xenotime.net>

Fix printk format warnings in gpu/drm/radeon/:

drivers/gpu/drm/radeon/radeon_atpx_handler.c:151:3: warning: format '%lu' 
expects type 'long unsigned int', but argument 2 has type 'size_t'
drivers/gpu/drm/radeon/radeon_acpi.c:204:3: warning: format '%lu' expects type 
'long unsigned int', but argument 2 has type 'size_t'
drivers/gpu/drm/radeon/radeon_acpi.c:488:3: warning: format '%lu' expects type 
'long unsigned int', but argument 2 has type 'size_t'

Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/radeon/radeon_acpi.c |4 ++--
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

--- linux-next-20121010.orig/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ linux-next-20121010/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -148,7 +148,7 @@ static int radeon_atpx_verify_interface(

size = *(u16 *) info->buffer.pointer;
if (size < 8) {
-   printk("ATPX buffer is too small: %lu\n", size);
+   printk("ATPX buffer is too small: %zu\n", size);
err = -EINVAL;
goto out;
}
--- linux-next-20121010.orig/drivers/gpu/drm/radeon/radeon_acpi.c
+++ linux-next-20121010/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -201,7 +201,7 @@ static int radeon_atif_verify_interface(

size = *(u16 *) info->buffer.pointer;
if (size < 12) {
-   DRM_INFO("ATIF buffer is too small: %lu\n", size);
+   DRM_INFO("ATIF buffer is too small: %zu\n", size);
err = -EINVAL;
goto out;
}
@@ -485,7 +485,7 @@ static int radeon_atcs_verify_interface(

size = *(u16 *) info->buffer.pointer;
if (size < 8) {
-   DRM_INFO("ATCS buffer is too small: %lu\n", size);
+   DRM_INFO("ATCS buffer is too small: %zu\n", size);
err = -EINVAL;
goto out;
}

[PATCH resend] drm: radeon: fix printk format warnings

2012-10-15 Thread Randy Dunlap 
From: Randy Dunlap <rdun...@xenotime.net>

Fix printk format warnings in gpu/drm/radeon/:

drivers/gpu/drm/radeon/radeon_atpx_handler.c:151:3: warning: format '%lu' 
expects type 'long unsigned int', but argument 2 has type 'size_t'
drivers/gpu/drm/radeon/radeon_acpi.c:204:3: warning: format '%lu' expects type 
'long unsigned int', but argument 2 has type 'size_t'
drivers/gpu/drm/radeon/radeon_acpi.c:488:3: warning: format '%lu' expects type 
'long unsigned int', but argument 2 has type 'size_t'

Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
Originally posted for linux-next, but now needed in mainline.

 drivers/gpu/drm/radeon/radeon_acpi.c |4 ++--
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

--- lnx-37-rc1.orig/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ lnx-37-rc1/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -148,7 +148,7 @@ static int radeon_atpx_verify_interface(

size = *(u16 *) info->buffer.pointer;
if (size < 8) {
-   printk("ATPX buffer is too small: %lu\n", size);
+   printk("ATPX buffer is too small: %zu\n", size);
err = -EINVAL;
goto out;
}
--- lnx-37-rc1.orig/drivers/gpu/drm/radeon/radeon_acpi.c
+++ lnx-37-rc1/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -201,7 +201,7 @@ static int radeon_atif_verify_interface(

size = *(u16 *) info->buffer.pointer;
if (size < 12) {
-   DRM_INFO("ATIF buffer is too small: %lu\n", size);
+   DRM_INFO("ATIF buffer is too small: %zu\n", size);
err = -EINVAL;
goto out;
}
@@ -485,7 +485,7 @@ static int radeon_atcs_verify_interface(

size = *(u16 *) info->buffer.pointer;
if (size < 8) {
-   DRM_INFO("ATCS buffer is too small: %lu\n", size);
+   DRM_INFO("ATCS buffer is too small: %zu\n", size);
err = -EINVAL;
goto out;
}

linux-next: Tree for Oct 16 (readeon_legacy)

2012-10-16 Thread Randy Dunlap 
On 10/15/2012 08:58 PM, Stephen Rothwell wrote:

> Hi all,
> 
> The merge window has closed, feel free to add new stuff again.
> 
> Changes since 201201015:
> 


on x86_64:

drivers/built-in.o: In function `radeon_asic_init':
(.text+0xd3c71): undefined reference to `radeon_legacy_set_backlight_level'
drivers/built-in.o:(.data+0x20490): undefined reference to 
`radeon_legacy_set_backlight_level'
drivers/built-in.o:(.data+0x20498): undefined reference to 
`radeon_legacy_get_backlight_level'
drivers/built-in.o:(.data+0x20710): undefined reference to 
`radeon_legacy_set_backlight_level'
drivers/built-in.o:(.data+0x20718): undefined reference to 
`radeon_legacy_get_backlight_level'
drivers/built-in.o:(.data+0x20990): undefined reference to 
`radeon_legacy_set_backlight_level'
drivers/built-in.o:(.data+0x20998): undefined reference to 
`radeon_legacy_get_backlight_level'
drivers/built-in.o:(.data+0x20c10): undefined reference to 
`radeon_legacy_set_backlight_level'
drivers/built-in.o:(.data+0x20c18): undefined reference to 
`radeon_legacy_get_backlight_level'
drivers/built-in.o:(.data+0x21110): undefined reference to 
`radeon_legacy_set_backlight_level'
drivers/built-in.o:(.data+0x21118): undefined reference to 
`radeon_legacy_get_backlight_level'


Full randconfig file is attached.
CONFIG_BACKLIGHT_CLASS_DEVICE is not enabled.

-- 
~Randy
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: config-r8139
URL:

linux-next: Tree for Oct 18 (drm/i915)

2012-10-18 Thread Randy Dunlap 
On 10/17/2012 08:46 PM, Stephen Rothwell wrote:

> Hi all,
> 
> Changes since 201201017:
> 



on x86_64:

ERROR: "__build_bug_on_failed" [drivers/gpu/drm/i915/i915.ko] undefined!


Full randconfig file is attached.

-- 
~Randy
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: config-r8229
URL:

linux-next: Tree for Oct 17 (drm: panel-simple)

2013-10-18 Thread Randy Dunlap 
On 10/17/13 17:38, Mark Brown wrote:
> Hi all,
> 
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
> 
> git://gitorious.org/thierryreding/linux-next.git
> 
> A next-20131017 tag is also provided for convenience.
> 
> One new conflict today but otherwise uneventful.  x86_64 allmodconfigs
> build after each merge but no other build tests were done.

on i386:

drivers/built-in.o: In function `panel_simple_get_modes':
panel-simple.c:(.text+0xacc69): undefined reference to `drm_mode_set_name'
panel-simple.c:(.text+0xacc76): undefined reference to `drm_mode_probed_add'
panel-simple.c:(.text+0xacc8f): undefined reference to `drm_mode_duplicate'
drivers/built-in.o: In function `panel_simple_probe':
panel-simple.c:(.text+0xace69): undefined reference to `drm_panel_init'
panel-simple.c:(.text+0xace7a): undefined reference to `drm_panel_add'
drivers/built-in.o: In function `panel_simple_remove':
panel-simple.c:(.text+0xad01f): undefined reference to `drm_panel_detach'
panel-simple.c:(.text+0xad026): undefined reference to `drm_panel_remove'


Full randconfig file is attached.


-- 
~Randy
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 3.12.0-rc5 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_FHANDLE=y
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
CONFIG_RCU_FANOUT_EXACT=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=m
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
# CONFIG_PROC_PID_CPUSET is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_USER_NS is not set
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y

linux-next: Tree for Oct 21 (panel-simple.c)

2013-10-21 Thread Randy Dunlap 
On 10/21/13 08:36, Thierry Reding wrote:
> Hi all,
> 
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
> 
> git://gitorious.org/thierryreding/linux-next.git
> 
> A next-20131021 tag is also provided for convenience.
> 
> Gained a couple new conflicts, loads of build failures. I've tried to
> fix the most obvious ones, but as a downside haven't gotten around to
> write up the specifics about the conflicts. I might still do that
> tomorrow, but I figured most people wouldn't have time to look into
> those anyway given that they'll be busy with the conferences.

on i386:

drivers/built-in.o: In function `panel_simple_probe':
panel-simple.c:(.text+0x3c7ca): undefined reference to 
`of_find_backlight_by_node'


Full randconfig file is attached.


-- 
~Randy
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 3.12.0-rc6 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_COMPILE_TEST=y
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_FHANDLE=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set

#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
CONFIG_RCU_FAST_NO_HZ=y
CONFIG_TREE_RCU_TRACE=y
CONFIG_RCU_BOOST=y
CONFIG_RCU_BOOST_PRIO=1
CONFIG_RCU_BOOST_DELAY=500
CONFIG_RCU_NOCB_CPU=y
# CONFIG_RCU_NOCB_CPU_NONE is not set
# CONFIG_RCU_NOCB_CPU_ZERO is not set
CONFIG_RCU_NOCB_CPU_ALL=y
CONFIG_IKCONFIG=m
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
# CONFIG_BUG is not set
CONFIG_PCSPKR_PLATFORM=y
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
# CONFIG_EPOLL

linux-next: Tree for Apr 1 (drivers/gpu/drm/i915)

2014-04-01 Thread Randy Dunlap 
On 04/01/2014 12:39 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Please do not add material intended for v3.16 to your linux-next included
> branches until after v3.15-rc1 is released.
> 
> This tree still fails (more than usual) the powerpc allyesconfig build.
> 
> Changes since 20140331:
> 

for linux-next 0401 and 0331:

drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format '%td' expects 
argument of type 'ptrdiff_t', but argument 5 has type 'long unsigned int' 
[-Wformat]


Just use %td without the (unsigned long) cast.


-- 
~Randy

[PATCH] drm/i915: fix command parser debug print format mismatches

2014-04-02 Thread Randy Dunlap 
On 04/02/2014 01:24 AM, Jani Nikula wrote:
> Drop the cast from the pointer diff to fix:
> 
> drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format '%td' expects
> argument of type 'ptrdiff_t', but argument 5 has type 'long unsigned int'
> [-Wformat]
> 
> While at it, use %u for u32.
> 
> Reported-by: Randy Dunlap 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> Randy, try as I might, I wasn't able to coerce gcc to spit out that
> warning. Please enlighten me! (Does this fix the warn?)

Yes, it does.  Thanks.

Acked-by: Randy Dunlap 


> Thanks for the report.
> ---
>  drivers/gpu/drm/i915/i915_cmd_parser.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 71ac3b4eaa0d..e5c4e99a22fb 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -811,10 +811,10 @@ int i915_parse_cmds(struct intel_ring_buffer *ring,
>   length = ((*cmd & desc->length.mask) + LENGTH_BIAS);
>  
>   if ((batch_end - cmd) < length) {
> - DRM_DEBUG_DRIVER("CMD: Command length exceeds batch 
> length: 0x%08X length=%d batchlen=%td\n",
> + DRM_DEBUG_DRIVER("CMD: Command length exceeds batch 
> length: 0x%08X length=%u batchlen=%td\n",
>*cmd,
>length,
> -  (unsigned long)(batch_end - cmd));
> +  batch_end - cmd);
>   ret = -EINVAL;
>   break;
>   }
> 


-- 
~Randy

linux-next: Tree for Nov 21 (nouveau)

2013-11-21 Thread Randy Dunlap 
On 11/20/13 19:04, Stephen Rothwell wrote:
> Hi all,
> 
> Please do *not* add any v3.14 material to linux-next until after
> v3.13-rc1 is released.
> 
> Changes since 20131120:
> 
> Linus' tree gained a build failure for which I reverted a commit.
> 

on x86_64:

CONFIG_HWMON is not enabled.

drivers/gpu/drm/nouveau/nouveau_hwmon.c: In function 'nouveau_hwmon_init':
drivers/gpu/drm/nouveau/nouveau_hwmon.c:633:2: error: 'hwmon' undeclared (first 
use in this function)


Full randconfig file is attached.


-- 
~Randy
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.12.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_COMPILE_TEST=y
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
CONFIG_FHANDLE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ_FULL_ALL=y
CONFIG_NO_HZ_FULL_SYSIDLE=y
CONFIG_NO_HZ_FULL_SYSIDLE_SMALL=8
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y

#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_CONTEXT_TRACKING=y
CONFIG_RCU_USER_QS=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
CONFIG_RCU_FAST_NO_HZ=y
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_BOOST=y
CONFIG_RCU_BOOST_PRIO=1
CONFIG_RCU_BOOST_DELAY=500
CONFIG_RCU_NOCB_CPU=y
CONFIG_RCU_NOCB_CPU_ALL=y
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_RESOURCE_COUNTERS=y
CONFIG_MEMCG=y
# CONFIG_MEMCG_KMEM is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_MM_OWNER=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
CONFIG_RD_LZMA=y
# CONFIG_RD_XZ is not set
CONFIG_RD_LZO=y
# CONFIG_RD_LZ4 is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_ANON_INODES=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_EXPERT=y
CONFIG_KALLSYMS=y

linux-next: Tree for Nov 21 (nouveau)

2013-11-22 Thread Randy Dunlap 
On 11/22/13 03:37, Adrian Pop wrote:
> Hello!
> 
>> on x86_64:
>>
>> CONFIG_HWMON is not enabled.
>>
>> drivers/gpu/drm/nouveau/nouveau_hwmon.c: In function 'nouveau_hwmon_init':
>> drivers/gpu/drm/nouveau/nouveau_hwmon.c:633:2: error: 'hwmon' undeclared 
>> (first use in this function)
> 
> I've attached a patch that fixes the build for me when using this
> config.
> 

That works.  Thanks.

Acked-by: Randy Dunlap 


-- 
~Randy

linux-next: Tree for Nov 29 (i915/intel_opregion)

2013-11-29 Thread Randy Dunlap 
On 11/28/13 18:45, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20131128:
> 

on x86_64:

CONFIG_ACPI is not enabled.


  CC  drivers/gpu/drm/i915/intel_opregion.o
In file included from drivers/gpu/drm/i915/intel_opregion.c:31:0:
include/linux/acpi_io.h:7:45: error: unknown type name 'acpi_physical_address'
include/linux/acpi_io.h:8:10: error: unknown type name 'acpi_size'
include/linux/acpi_io.h:13:33: error: unknown type name 'acpi_physical_address'
include/linux/acpi_io.h:15:40: warning: 'struct acpi_generic_address' declared 
inside parameter list [enabled by default]
include/linux/acpi_io.h:15:40: warning: its scope is only this definition or 
declaration, which is probably not what you want [enabled by default]
include/linux/acpi_io.h:16:43: warning: 'struct acpi_generic_address' declared 
inside parameter list [enabled by default]
drivers/gpu/drm/i915/intel_opregion.c: In function 'intel_opregion_setup':
drivers/gpu/drm/i915/intel_opregion.c:866:2: error: implicit declaration of 
function 'acpi_os_ioremap' [-Werror=implicit-function-declaration]
drivers/gpu/drm/i915/intel_opregion.c:866:7: warning: assignment makes pointer 
from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
make[5]: *** [drivers/gpu/drm/i915/intel_opregion.o] Error 1


-- 
~Randy

mmotm 2012-10-24-17-15 uploaded (drm/i915)

2012-10-25 Thread Randy Dunlap 
On 10/24/2012 05:16 PM, akpm at linux-foundation.org wrote:

> The mm-of-the-moment snapshot 2012-10-24-17-15 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> http://www.ozlabs.org/~akpm/mmotm/
> 


on i386:

ERROR: "__build_bug_on_failed" [drivers/gpu/drm/i915/i915.ko] undefined!

Full randconfig file is attached.

-- 
~Randy
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: config-r8339
URL:

inux-next: Tree for Sept 26 (gpu/drm/i915)

2012-09-26 Thread Randy Dunlap 
On 09/25/2012 11:44 PM, Stephen Rothwell wrote:

> Hi all,
> 
> Changes since 201209025:
> 



on x86_64:

drivers/gpu/drm/i915/i915_sysfs.c: In function 'i915_teardown_sysfs':
drivers/gpu/drm/i915/i915_sysfs.c:228:49: error: 'rc6_attr_group' undeclared 
(first use in this function)


Full randconfig file is attached.


-- 

~Randy
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: config-r7804
URL:

mmotm 2013-04-17-16-02 uploaded (gpu/drm/qxl)

2013-04-17 Thread Randy Dunlap 
On 04/17/13 16:03, akpm at linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2013-04-17-16-02 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 


I saw this in linux-next a few days ago and forgot to post it.

When CONFIG_DEBUG_FS is not enabled:


drivers/gpu/drm/qxl/qxl_ttm.c:568:33: error: 'qxl_mm_dump_table' undeclared 
(first use in this function)
drivers/gpu/drm/qxl/qxl_debugfs.c:76:2: error: implicit declaration of function 
'drm_debugfs_create_files' [-Werror=implicit-function-declaration]
drivers/gpu/drm/qxl/qxl_debugfs.c:84:2: error: implicit declaration of function 
'drm_debugfs_remove_files' [-Werror=implicit-function-declaration]


-- 
~Randy

linux-next: Tree for Aug 30 (nouveau)

2013-08-30 Thread Randy Dunlap 
On 08/29/13 03:00, Stephen Rothwell wrote:
> Hi all,
> 


on x86_64:

ERROR: "nouveau_switcheroo_optimus_dsm" [drivers/gpu/drm/nouveau/nouveau.ko] 
undefined!


Full randconfig file is attached.


-- 
~Randy
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.11.0-rc7 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_COMPILE_TEST=y
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_FHANDLE=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
# CONFIG_TASK_IO_ACCOUNTING is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
# CONFIG_CPUSETS is not set
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_NAMESPACES is not set
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_EXPERT=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
# CONFIG_BUG is not set
# CONFIG_PCSPKR_PLATFORM is not set
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
# CONFIG_EPOLL is not set
# CONFIG_SIGNALFD is not set
# CONFIG_TIMERFD is not set
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
# CONFIG_AIO is not set
CONFIG_PCI_QUIRKS=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#

[PATCH -next] gpu: fix qxl missing crc32_le

2013-12-20 Thread Randy Dunlap 
From: Randy Dunlap <rdun...@infradead.org>

Fix build error: qxl uses crc32 functions so it needs to select
CRC32.

Also use angle quotes around a kernel header file name.

drivers/built-in.o: In function `qxl_display_read_client_monitors_config':
(.text+0x19d754): undefined reference to `crc32_le'

Signed-off-by: Randy Dunlap 
---
 drivers/gpu/drm/qxl/Kconfig   |1 +
 drivers/gpu/drm/qxl/qxl_display.c |2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

--- linux-next-20131220.orig/drivers/gpu/drm/qxl/qxl_display.c
+++ linux-next-20131220/drivers/gpu/drm/qxl/qxl_display.c
@@ -24,7 +24,7 @@
  */


-#include "linux/crc32.h"
+#include 

 #include "qxl_drv.h"
 #include "qxl_object.h"
--- linux-next-20131220.orig/drivers/gpu/drm/qxl/Kconfig
+++ linux-next-20131220/drivers/gpu/drm/qxl/Kconfig
@@ -8,6 +8,7 @@ config DRM_QXL
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
select DRM_TTM
+   select CRC32
help
  QXL virtual GPU for Spice virtualization desktop integration.
  Do not enable this driver unless your distro ships a corresponding

linux-next: Tree for Feb 12 (drm_pci.c)

2013-02-12 Thread Randy Dunlap 
On 02/11/13 21:09, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20130211:
> 


when CONFIG_PCI is not enabled (on x86_64):

  CC [M]  drivers/gpu/drm/drm_pci.o
drivers/gpu/drm/drm_pci.c: In function 'drm_pcie_get_speed_cap_mask':
drivers/gpu/drm/drm_pci.c:485:2: error: implicit declaration of function 
'pcie_capability_read_dword' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[4]: *** [drivers/gpu/drm/drm_pci.o] Error 1



-- 
~Randy

[PATCH -next] gpu: fix printk format warning in i915_gem.c

2013-06-19 Thread Randy Dunlap 
From: Randy Dunlap <rdun...@infradead.org>

Fix printk format warning in i915_gem.c:

drivers/gpu/drm/i915/i915_gem.c:3113:3: warning: format '%ld' expects argument 
of type 'long int', but argument 5 has type 'size_t' [-Wformat]

Signed-off-by: Randy Dunlap 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: intel-gfx at lists.freedesktop.org
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_gem.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20130619.orig/drivers/gpu/drm/i915/i915_gem.c
+++ linux-next-20130619/drivers/gpu/drm/i915/i915_gem.c
@@ -3110,7 +3110,7 @@ i915_gem_object_bind_to_gtt(struct drm_i
 * before evicting everything in a vain attempt to find space.
 */
if (obj->base.size > gtt_max) {
-   DRM_ERROR("Attempting to bind an object larger than the 
aperture: object=%zd > %s aperture=%ld\n",
+   DRM_ERROR("Attempting to bind an object larger than the 
aperture: object=%zd > %s aperture=%zu\n",
  obj->base.size,
  map_and_fenceable ? "mappable" : "total",
  gtt_max);

[PATCH] drm: fix new kernel-doc warnings

2013-03-05 Thread Randy Dunlap 
From: Randy Dunlap <rdun...@infradead.org>

Fix new kernel-doc warnings in drm_edid.c: convert doxygen(?) to
kernel-doc to match the rest of the file's documentation.

Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 
'adapter'
Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 
'buf'
Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 
'block'
Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 
'len'
Warning(drivers/gpu/drm/drm_edid.c:1138): No description found for parameter 
'adapter'
Warning(drivers/gpu/drm/drm_edid.c:1467): No description found for parameter 
'connector'
Warning(drivers/gpu/drm/drm_edid.c:1467): No description found for parameter 
'edid'
Warning(drivers/gpu/drm/drm_edid.c:1467): No description found for parameter 
'revision'
Warning(drivers/gpu/drm/drm_edid.c:1467): Excess function parameter 
'timing_level' description in 'drm_mode_std'
Warning(drivers/gpu/drm/drm_edid.c:2010): No description found for parameter 
'connector'
Warning(drivers/gpu/drm/drm_edid.c:2072): No description found for parameter 
'connector'
Warning(drivers/gpu/drm/drm_edid.c:2237): No description found for parameter 
'edid'
Warning(drivers/gpu/drm/drm_edid.c:2616): No description found for parameter 
'edid'
Warning(drivers/gpu/drm/drm_edid.c:2658): No description found for parameter 
'edid'

Signed-off-by: Randy Dunlap 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org

---
 drivers/gpu/drm/drm_edid.c |   30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

--- lnx-39-rc1.orig/drivers/gpu/drm/drm_edid.c
+++ lnx-39-rc1/drivers/gpu/drm/drm_edid.c
@@ -982,12 +982,13 @@ EXPORT_SYMBOL(drm_edid_is_valid);

 #define DDC_SEGMENT_ADDR 0x30
 /**
- * Get EDID information via I2C.
+ * drm_do_probe_ddc_edid - Get EDID information via I2C.
  *
- * \param adapter : i2c device adaptor
- * \param buf : EDID data buffer to be filled
- * \param len : EDID data buffer length
- * \return 0 on success or -1 on failure.
+ * @adapter : i2c device adaptor
+ * @buf : EDID data buffer to be filled
+ * @block   : block number
+ * @len : EDID data buffer length
+ * return   : 0 on success or -1 on failure.
  *
  * Try to fetch EDID information by calling i2c driver function.
  */
@@ -1128,10 +1129,10 @@ out:
 }

 /**
- * Probe DDC presence.
+ * drm_probe_ddc - Probe DDC presence.
  *
- * \param adapter : i2c device adaptor
- * \return 1 on success
+ * @adapter : i2c device adaptor
+ * return   : 1 on success
  */
 bool
 drm_probe_ddc(struct i2c_adapter *adapter)
@@ -1455,8 +1456,10 @@ bad_std_timing(u8 a, u8 b)

 /**
  * drm_mode_std - convert standard mode info (width, height, refresh) into mode
+ * @connector: attached connector
+ * @edid: EDID block
  * @t: standard timing params
- * @timing_level: standard timing level
+ * @revision: EDID revision
  *
  * Take the standard timing params (in this case width, aspect, and refresh)
  * and convert them into a real mode using CVT/GTF/DMT.
@@ -1999,7 +2002,8 @@ do_established_modes(struct detailed_tim
 }

 /**
- * add_established_modes - get est. modes from EDID and add them
+ * add_established_modes - get established modes from EDID and add them
+ * @connector: attached connector
  * @edid: EDID block to scan
  *
  * Each EDID block contains a bitmap of the supported "established modes" list
@@ -2062,6 +2066,7 @@ do_standard_modes(struct detailed_timing

 /**
  * add_standard_modes - get std. modes from EDID and add them
+ * @connector: attached connector
  * @edid: EDID block to scan
  *
  * Standard modes can be calculated using the appropriate standard (DMT,
@@ -2231,7 +2236,8 @@ add_detailed_modes(struct drm_connector
 #define EDID_CEA_VCDB_QS   (1 << 6)

 /**
- * Search EDID for CEA extension block.
+ * drm_find_cea_extension - Search EDID for CEA extension block.
+ * @edid: EDID block to search
  */
 u8 *drm_find_cea_extension(struct edid *edid)
 {
@@ -2604,6 +2610,7 @@ EXPORT_SYMBOL(drm_detect_hdmi_monitor);

 /**
  * drm_detect_monitor_audio - check monitor audio capability
+ * @edid: EDID block
  *
  * Monitor should have CEA extension block.
  * If monitor has 'basic audio', but no CEA audio blocks, it's 'basic
@@ -2649,6 +2656,7 @@ EXPORT_SYMBOL(drm_detect_monitor_audio);

 /**
  * drm_rgb_quant_range_selectable - is RGB quantization range selectable?
+ * @edid: EDID block
  *
  * Check whether the monitor reports the RGB quantization range selection
  * as supported. The AVI infoframe can then be used to inform the monitor

linux-next: Tree for Dec 16 (gpu/drm/vc4)

2015-12-16 Thread Randy Dunlap 
On 12/15/15 21:43, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20151215:
> 

on i386, when CONFIG_PM_SLEEP is not enabled:

../drivers/gpu/drm/vc4/vc4_v3d.c: In function 'vc4_v3d_set_power':
../drivers/gpu/drm/vc4/vc4_v3d.c:157:29: error: called object is not a function 
or function pointer
   return pm_generic_poweroff(>v3d->pdev->dev);
 ^
../drivers/gpu/drm/vc4/vc4_v3d.c:159:27: error: called object is not a function 
or function pointer
   return pm_generic_resume(>v3d->pdev->dev);
   ^



-- 
~Randy

  1   2   3   4   5   6   7   8   9   >