[PATCH] dma-buf: Correct dummy function declarations.

[Sumit Semwal]

While testing, I found that we need to correct some of the dummy declarations. 
When I send my pull request to Linus, I wish to squash these changes into the 
original patches from Daniel. Could you please review?

Best regards,
~Sumit

=

Dummy functions for the newly added cpu access ops are needed for compilation
when dma-buf framework is not compiled-in.

Also, the introduction of flags in dma_buf_fd  needs to be added to dummy
functions as well.

Signed-off-by: Sumit Semwal 
---
 include/linux/dma-buf.h |   26 +-
 1 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index f08028e..779aaf9 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -189,7 +189,7 @@ static inline struct dma_buf *dma_buf_export(void *priv,
return ERR_PTR(-ENODEV);
 }

-static inline int dma_buf_fd(struct dma_buf *dmabuf)
+static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
 {
return -ENODEV;
 }
@@ -216,36 +216,36 @@ static inline void dma_buf_unmap_attachment(struct 
dma_buf_attachment *attach,
return;
 }

-static inline int dma_buf_begin_cpu_access(struct dma_buf *,
-  size_t, size_t,
-  enum dma_data_direction)
+static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
+  size_t start, size_t len,
+  enum dma_data_direction dir)
 {
return -ENODEV;
 }

-static inline void dma_buf_end_cpu_access(struct dma_buf *,
- size_t, size_t,
- enum dma_data_direction)
+static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
+ size_t start, size_t len,
+ enum dma_data_direction dir)
 {
 }

-static inline void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long)
+static inline void *dma_buf_kmap_atomic(struct dma_buf *db, unsigned long pnum)
 {
return NULL;
 }

-static inline void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long,
-void *)
+static inline void dma_buf_kunmap_atomic(struct dma_buf *db, unsigned long 
pnum,
+void *vaddr)
 {
 }

-static inline void *dma_buf_kmap(struct dma_buf *, unsigned long)
+static inline void *dma_buf_kmap(struct dma_buf *db, unsigned long pnum)
 {
return NULL;
 }

-static inline void dma_buf_kunmap(struct dma_buf *, unsigned long,
- void *)
+static inline void dma_buf_kunmap(struct dma_buf *db, unsigned long pnum,
+ void *vaddr)
 {
 }
 #endif /* CONFIG_DMA_SHARED_BUFFER */
-- 
1.7.5.4

Regression: black screen on VGA w/ nouveau in Linux 3.3

[Maciej Rutecki]

On poniedzia?ek, 19 marca 2012 o 15:35:48 Nick Bowler wrote:
> Hi folks,
> 
> Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output
> on my card w/ nouveau is totally black (both at the console and in X).
> Almost everything appears to work normally: DPMS works, modesetting
> works, DDC works... all messages indicate that things are working --
> just the image is completely black.
> 
> The VGA is one of two outputs in use: the other (DVI) output works
> normally.  The card also has an unused TV-out port, FWIW.
> 
> The card is an NV36 generation (Geforce FX5700 AGP).  This is a
> regression from Linux 3.2 -- unfortunately, bisection has proved
> extremely difficult because the intermediate kernels git is asking me
> to test panic immediately on boot (and compiling Linux takes a fairly
> long time on this box too).  The failed attempt went like this:
> 
>   git bisect start 'drivers/gpu'
>   # bad: [c16fa4f2ad19908a47c63d8fa436a1178438c7e7] Linux 3.3
>   git bisect bad c16fa4f2ad19908a47c63d8fa436a1178438c7e7
>   # good: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
>   git bisect good 805a6af8dba5dfdd35ec35dc52ec0122400b2610
>   # skip: [5d56fe5fd794a98c4f446f8665fd06b82e93ff64] Merge branch
> 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6
> into drm-core-next git bisect skip
> 5d56fe5fd794a98c4f446f8665fd06b82e93ff64
>   # good: [dffc9ceb55695f121adc57dd1fde7304c3afe81e] gma500: kill virtual
> mapping support git bisect good dffc9ceb55695f121adc57dd1fde7304c3afe81e
>   # skip: [5c2a5ce689c99037771a6c110374461781a6f042] drm: add missing
> exports for i810 driver. git bisect skip
> 5c2a5ce689c99037771a6c110374461781a6f042
>   # skip: [44517c44496062180a6376cc704b33129441ce60] drm/radeon/kms: Add an
> MSI quirk for Dell RS690 git bisect skip
> 44517c44496062180a6376cc704b33129441ce60
> 
>   (I stopped at this point)
> 
> I'm running the latest git xf86-video-nouveau, but since the issue
> occurs at the console it's probably not too important...
> 
> Let me know if you need any more info,

I created a Bugzilla entry at 
https://bugzilla.kernel.org/show_bug.cgi?id=42983
for your bug/regression report, please add your address to the CC list in 
there, thanks!

-- 
Maciej Rutecki
http://www.mrutecki.pl

[Bug 45366] Radeon gpu lockups

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45366

--- Comment #6 from Ernst Sj?strand  2012-03-23 13:43:10 
PDT ---
I can now reproduce this consistenly I think:
Install Ubuntu Precise
Add xorg-edgers ppa
Create a 2:nd user
Log in as user 1
Switch to user 2
Switch to user 1

Then when you have unlocked user 1's screen with your password and it redraws
the desktop I get a GPU reset loop.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45760] World of warcraft 4.3 slow down after a hour of game

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45760

--- Comment #8 from Pablo  2012-03-23 12:50:31 PDT ---
Sorry, I forgot the specs in the title, FYI in WOW 3.3.5a this is not happening

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 42983] Regression: black screen on VGA w/ nouveau in Linux 3.3

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=42983


Maciej Rutecki  changed:

   What|Removed |Added

 Blocks||42644




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 42983] New: Regression: black screen on VGA w/ nouveau in Linux 3.3

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=42983

   Summary: Regression: black screen on VGA w/ nouveau in Linux
3.3
   Product: Drivers
   Version: 2.5
Kernel Version: 3.3
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: maciej.rutecki at gmail.com
CC: florian at mickler.org, rjw at sisk.pl,
maciej.rutecki at gmail.com
Regression: Yes


Subject: Regression: black screen on VGA w/ nouveau in Linux 3.3
Submitter  : Nick Bowler 
Date   : 2012-03-19 14:35
Message-ID : 20120319143548.GA27172 at elliptictech.com
References : http://marc.info/?l=linux-kernel=133216782310186=2

This entry is being used for tracking a regression from 3.2. Please don't
close it until the problem is fixed in the mainline.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 45760] World of warcraft 4.3 slow down after a hour of game

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45760

--- Comment #7 from Pablo  2012-03-23 12:48:24 PDT ---
I have a hd 4670, I couldn't see something like that in WOW.
are you using WOTLK?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] dma-buf: Correct dummy function declarations.

[Daniel Vetter]

On Fri, Mar 23, 2012 at 09:19:17PM +0530, Sumit Semwal wrote:
> While testing, I found that we need to correct some of the dummy 
> declarations. When I send my pull request to Linus, I wish to squash these 
> changes into the original patches from Daniel. Could you please review?
> 
> Best regards,
> ~Sumit
> 
> =
> 
> Dummy functions for the newly added cpu access ops are needed for compilation
> when dma-buf framework is not compiled-in.
> 
> Also, the introduction of flags in dma_buf_fd  needs to be added to dummy
> functions as well.
> 
> Signed-off-by: Sumit Semwal 

Sorry for fumbling the compile-testing for the !DMA_BUF case here.

Acked-by: Daniel Vetter 

Cheers, Daniel

> ---
>  include/linux/dma-buf.h |   26 +-
>  1 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index f08028e..779aaf9 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -189,7 +189,7 @@ static inline struct dma_buf *dma_buf_export(void *priv,
>   return ERR_PTR(-ENODEV);
>  }
>  
> -static inline int dma_buf_fd(struct dma_buf *dmabuf)
> +static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
>  {
>   return -ENODEV;
>  }
> @@ -216,36 +216,36 @@ static inline void dma_buf_unmap_attachment(struct 
> dma_buf_attachment *attach,
>   return;
>  }
>  
> -static inline int dma_buf_begin_cpu_access(struct dma_buf *,
> -size_t, size_t,
> -enum dma_data_direction)
> +static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
> +size_t start, size_t len,
> +enum dma_data_direction dir)
>  {
>   return -ENODEV;
>  }
>  
> -static inline void dma_buf_end_cpu_access(struct dma_buf *,
> -   size_t, size_t,
> -   enum dma_data_direction)
> +static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> +   size_t start, size_t len,
> +   enum dma_data_direction dir)
>  {
>  }
>  
> -static inline void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long)
> +static inline void *dma_buf_kmap_atomic(struct dma_buf *db, unsigned long 
> pnum)
>  {
>   return NULL;
>  }
>  
> -static inline void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long,
> -  void *)
> +static inline void dma_buf_kunmap_atomic(struct dma_buf *db, unsigned long 
> pnum,
> +  void *vaddr)
>  {
>  }
>  
> -static inline void *dma_buf_kmap(struct dma_buf *, unsigned long)
> +static inline void *dma_buf_kmap(struct dma_buf *db, unsigned long pnum)
>  {
>   return NULL;
>  }
>  
> -static inline void dma_buf_kunmap(struct dma_buf *, unsigned long,
> -   void *)
> +static inline void dma_buf_kunmap(struct dma_buf *db, unsigned long pnum,
> +   void *vaddr)
>  {
>  }
>  #endif /* CONFIG_DMA_SHARED_BUFFER */
> -- 
> 1.7.5.4
> 

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 46713] HDMI audio played back at a wrong rate

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #23 from Vincenzov  2012-03-23 11:50:50 
PDT ---
sudo avivotool regset 0x05b0 0x00271000


works good whit 1920 x 1080

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36421] RV710: GPU lockup running portal2 in wine.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36421

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Alex Deucher  2012-03-23 11:26:33 PDT 
---
Please reopen if this is still an issue.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 46713] HDMI audio played back at a wrong rate

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #22 from Vincenzov  2012-03-23 11:24:09 
PDT ---
vincenzo at AthlonII-260:~$ sudo avivotool regset 0x05b0 0x00138800
OLD: 0x05b0 (05b0)  0x00075300 (48)
NEW: 0x05b0 (05b0)  0x00138800 (128)

work only 1280x720

slow with 1920 x 1080

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 46713] HDMI audio played back at a wrong rate

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #21 from Vincenzov  2012-03-23 11:00:19 
PDT ---
ok
1280x720 radeon 5450 works

avivotool regset 0x05b0 0x00138800

works good

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 46713] HDMI audio played back at a wrong rate

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #20 from Vincenzov  2012-03-23 10:36:52 
PDT ---
Hi, i have same problem hdmi audio slow. Radeon 5450.
But dual screen hdmi+crt 1920 x 1080 audio works fine.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36421] RV710: GPU lockup running portal2 in wine.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36421

--- Comment #8 from Vladimir Ysikov  2012-03-23 
10:15:54 PDT ---
I have not tested it for a long time and I can't say when the error is gone.
mesa-8.0 & mesa-git no error on ArchLinux x86, Radeon HD 4850. Tested Portal,
HL2 (Episode One/Two), Team Fortress 2, Left 4 Dead 2.

Can this be closed?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

radeon + DVI->mDP converter + mDP display blank screen issue since 3.0

[Lennert Buytenhek]

On Fri, Mar 23, 2012 at 10:59:27AM -0400, Alex Deucher wrote:

> > Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
> > to a 27" Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
> > to Mini DisplayPort converter has started to stop giving screen
> > output on switching from text mode to graphical framebuffer during
> > system startup.
> >
> > I finally had some time to look at this, and it seems to have stopped
> > working after this commit:
> >
> > ? ? ? ?commit df271bec805b42527d864777ed035fcbb42e76c0
> > ? ? ? ?Author: Alex Deucher 
> > ? ? ? ?Date: ? Fri May 20 04:34:15 2011 -0400
> >
> > ? ? ? ? ? ?drm/radeon/kms: properly handle bpc >8 in atom command tables
> >
> > ? ? ? ? ? ?Signed-off-by: Alex Deucher 
> > ? ? ? ? ? ?Signed-off-by: Dave Airlie 
> >
> > ...and with the patch below (i.e. reverting part of the commit above)
> > applied to 3.3 I get screen output again.
> >
> > Even though the monitor seems to have an 8 bit panel, it reports 10
> > bits per channel in its EDID:
> >
> > ? ? ? ?[...]
> > ? ? ? ?Manufacturer: APP Model 9226 Serial Number 41959462
> > ? ? ? ?Made week 38 of 2010
> > ? ? ? ?EDID version: 1.4
> > ? ? ? ?Digital display
> > ? ? ? ?10 bits per primary color channel
> > ? ? ? ?DisplayPort interface
> > ? ? ? ?Maximum image size: 60 cm x 34 cm
> > ? ? ? ?[...]
> >
> > The (active, dual link) DVI->mDP converter spec sheet says it supports
> > 24 bit color, and I'm guessing that it can't deal with 30. ?Is the
> > converter at fault here for passing through the EDID unchanged?
> >
> > Also, what would be the right way to handle this, a kernel command
> > line or module option to limit color depth or something like that?
> > ("Buy a video card with DP output." is a valid answer, I suppose.)
> >
> > I have no clue at all about graphics, and I have no idea whatsoever
> > what I'm doing here, but I just wanted to post this somewhere for
> > Google to find in case someone else runs into this!
> 
> I've inquired with out display team on how to best handle this.  In
> the meantime, it's probably best to just default to 8 bpc.  Does the
> attached patch fix your issue?

I've been using the patch below in a custom Fedora 17 kernel RPM, and
that seems to fix the issue.  Your patch seems to be a superset of
this patch, so logically, your patch should do the trick as well. :)


thanks,
Lennert


diff -up linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig 
linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
--- linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig   
2012-03-22 14:52:20.538854547 +0100
+++ linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
2012-03-22 14:55:39.740794113 +0100
@@ -550,8 +550,6 @@ static u32 atombios_adjust_pll(struct dr
if (encoder->crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
-   if (connector && connector->display_info.bpc)
-   bpc = connector->display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder, 
mode->clock);
if ((radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT 
| ATOM_DEVICE_DFP_SUPPORT)) ||
@@ -922,7 +920,6 @@ static void atombios_crtc_set_pll(struct
struct radeon_connector_atom_dig *dig_connector =
radeon_connector->con_priv;
int dp_clock;
-   bpc = connector->display_info.bpc;

switch (encoder_mode) {
case ATOM_ENCODER_MODE_DP_MST:



> From 22ca454eb749968f266d6788a5f4778acc08cc66 Mon Sep 17 00:00:00 2001
> From: Alex Deucher 
> Date: Fri, 23 Mar 2012 10:54:45 -0400
> Subject: [PATCH] drm/radeon/kms/atom: force bpc to 8 for now
> 
> Using the bpc (bits per color) specified by the monitor
> can cause problems in some cases.  Until we get a better
> handle on how to deal with those cases, just use a bpc of 8.
> 
> Reported-by: Lennert Buytenhek 
> Signed-off-by: Alex Deucher 
> Cc: stable at kernel.org
> ---
>  drivers/gpu/drm/radeon/atombios_crtc.c |8 +---
>  drivers/gpu/drm/radeon/atombios_dp.c   |3 +++
>  drivers/gpu/drm/radeon/atombios_encoders.c |4 ++--
>  3 files changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index 083b3ea..b5ff1f7 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -588,8 +588,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>   if (encoder->crtc == crtc) {
>   radeon_encoder = to_radeon_encoder(encoder);
>   connector = radeon_get_connector_for_encoder(encoder);
> -  

radeon + DVI->mDP converter + mDP display blank screen issue since 3.0

[Alex Deucher]

? ? ? ? ? ?switch (encoder_mode) {
>> ? ? ? ? ? ? ? ?case ATOM_ENCODER_MODE_DP_MST:
>>
>>
>>
>>> From 22ca454eb749968f266d6788a5f4778acc08cc66 Mon Sep 17 00:00:00 2001
>>> From: Alex Deucher 
>>> Date: Fri, 23 Mar 2012 10:54:45 -0400
>>> Subject: [PATCH] drm/radeon/kms/atom: force bpc to 8 for now
>>>
>>> Using the bpc (bits per color) specified by the monitor
>>> can cause problems in some cases. ?Until we get a better
>>> handle on how to deal with those cases, just use a bpc of 8.
>>>
>>> Reported-by: Lennert Buytenhek 
>>> Signed-off-by: Alex Deucher 
>>> Cc: stable at kernel.org
>>> ---
>>> ?drivers/gpu/drm/radeon/atombios_crtc.c ? ? | ? ?8 +---
>>> ?drivers/gpu/drm/radeon/atombios_dp.c ? ? ? | ? ?3 +++
>>> ?drivers/gpu/drm/radeon/atombios_encoders.c | ? ?4 ++--
>>> ?3 files changed, 10 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
>>> b/drivers/gpu/drm/radeon/atombios_crtc.c
>>> index 083b3ea..b5ff1f7 100644
>>> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
>>> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
>>> @@ -588,8 +588,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>>> ? ? ? ? ? ? ? if (encoder->crtc == crtc) {
>>> ? ? ? ? ? ? ? ? ? ? ? radeon_encoder = to_radeon_encoder(encoder);
>>> ? ? ? ? ? ? ? ? ? ? ? connector = radeon_get_connector_for_encoder(encoder);
>>> - ? ? ? ? ? ? ? ? ? ? if (connector && connector->display_info.bpc)
>>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? bpc = connector->display_info.bpc;
>>> + ? ? ? ? ? ? ? ? ? ? /* if (connector && connector->display_info.bpc)
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? bpc = connector->display_info.bpc; */
>>> ? ? ? ? ? ? ? ? ? ? ? encoder_mode = atombios_get_encoder_mode(encoder);
>>> ? ? ? ? ? ? ? ? ? ? ? is_duallink = radeon_dig_monitor_is_duallink(encoder, 
>>> mode->clock);
>>> ? ? ? ? ? ? ? ? ? ? ? if ((radeon_encoder->devices & 
>>> (ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) ||
>>> @@ -965,7 +965,9 @@ static void atombios_crtc_set_pll(struct drm_crtc 
>>> *crtc, struct drm_display_mode
>>> ? ? ? ? ? ? ? struct radeon_connector_atom_dig *dig_connector =
>>> ? ? ? ? ? ? ? ? ? ? ? radeon_connector->con_priv;
>>> ? ? ? ? ? ? ? int dp_clock;
>>> - ? ? ? ? ? ? bpc = connector->display_info.bpc;
>>> +
>>> + ? ? ? ? ? ? /* if (connector->display_info.bpc)
>>> + ? ? ? ? ? ? ? ? ? ? bpc = connector->display_info.bpc; */
>>>
>>> ? ? ? ? ? ? ? switch (encoder_mode) {
>>> ? ? ? ? ? ? ? case ATOM_ENCODER_MODE_DP_MST:
>>> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
>>> b/drivers/gpu/drm/radeon/atombios_dp.c
>>> index 6c62be2..c57d856 100644
>>> --- a/drivers/gpu/drm/radeon/atombios_dp.c
>>> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
>>> @@ -405,10 +405,13 @@ static void dp_get_adjust_train(u8 
>>> link_status[DP_LINK_STATUS_SIZE],
>>> ?/* get bpc from the EDID */
>>> ?static int convert_bpc_to_bpp(int bpc)
>>> ?{
>>> +#if 0
>>> ? ? ? if (bpc == 0)
>>> ? ? ? ? ? ? ? return 24;
>>> ? ? ? else
>>> ? ? ? ? ? ? ? return bpc * 3;
>>> +#endif
>>> + ? ? return 24;
>>> ?}
>>>
>>> ?/* get the max pix clock supported by the link rate and lane num */
>>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
>>> b/drivers/gpu/drm/radeon/atombios_encoders.c
>>> index 468b874..e607c4d 100644
>>> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
>>> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
>>> @@ -541,7 +541,7 @@ atombios_dig_encoder_setup(struct drm_encoder *encoder, 
>>> int action, int panel_mo
>>> ? ? ? ? ? ? ? dp_clock = dig_connector->dp_clock;
>>> ? ? ? ? ? ? ? dp_lane_count = dig_connector->dp_lane_count;
>>> ? ? ? ? ? ? ? hpd_id = radeon_connector->hpd.hpd;
>>> - ? ? ? ? ? ? bpc = connector->display_info.bpc;
>>> + ? ? ? ? ? ? /* bpc = connector->display_info.bpc; */
>>> ? ? ? }
>>>
>>> ? ? ? /* no dig encoder assigned */
>>> @@ -1159,7 +1159,7 @@ atombios_external_encoder_setup(struct drm_encoder 
>>> *encoder,
>>> ? ? ? ? ? ? ? dp_lane_count = dig_connector->dp_lane_count;
>>> ? ? ? ? ? ? ? connector_object_id =
>>> ? ? ? ? ? ? ? ? ? ? ? (radeon_connector->connector_object_id & 
>>> OBJECT_ID_MASK) >> OBJECT_ID_SHIFT;
>>> - ? ? ? ? ? ? bpc = connector->display_info.bpc;
>>> + ? ? ? ? ? ? /* bpc = connector->display_info.bpc; */
>>> ? ? ? }
>>>
>>> ? ? ? memset(, 0, sizeof(args));
>>> --
>>> 1.7.7.5
>>>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-kms-improve-bpc-handling-v2.patch
Type: text/x-patch
Size: 7359 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120323/bf72eaab/attachment-0001.bin>

radeon + DVI->mDP converter + mDP display blank screen issue since 3.0

[Alex Deucher]

t; handle on how to deal with those cases, just use a bpc of 8.
>>
>> Reported-by: Lennert Buytenhek 
>> Signed-off-by: Alex Deucher 
>> Cc: stable at kernel.org
>> ---
>> ?drivers/gpu/drm/radeon/atombios_crtc.c ? ? | ? ?8 +---
>> ?drivers/gpu/drm/radeon/atombios_dp.c ? ? ? | ? ?3 +++
>> ?drivers/gpu/drm/radeon/atombios_encoders.c | ? ?4 ++--
>> ?3 files changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
>> b/drivers/gpu/drm/radeon/atombios_crtc.c
>> index 083b3ea..b5ff1f7 100644
>> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
>> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
>> @@ -588,8 +588,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>> ? ? ? ? ? ? ? if (encoder->crtc == crtc) {
>> ? ? ? ? ? ? ? ? ? ? ? radeon_encoder = to_radeon_encoder(encoder);
>> ? ? ? ? ? ? ? ? ? ? ? connector = radeon_get_connector_for_encoder(encoder);
>> - ? ? ? ? ? ? ? ? ? ? if (connector && connector->display_info.bpc)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? bpc = connector->display_info.bpc;
>> + ? ? ? ? ? ? ? ? ? ? /* if (connector && connector->display_info.bpc)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? bpc = connector->display_info.bpc; */
>> ? ? ? ? ? ? ? ? ? ? ? encoder_mode = atombios_get_encoder_mode(encoder);
>> ? ? ? ? ? ? ? ? ? ? ? is_duallink = radeon_dig_monitor_is_duallink(encoder, 
>> mode->clock);
>> ? ? ? ? ? ? ? ? ? ? ? if ((radeon_encoder->devices & 
>> (ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) ||
>> @@ -965,7 +965,9 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
>> struct drm_display_mode
>> ? ? ? ? ? ? ? struct radeon_connector_atom_dig *dig_connector =
>> ? ? ? ? ? ? ? ? ? ? ? radeon_connector->con_priv;
>> ? ? ? ? ? ? ? int dp_clock;
>> - ? ? ? ? ? ? bpc = connector->display_info.bpc;
>> +
>> + ? ? ? ? ? ? /* if (connector->display_info.bpc)
>> + ? ? ? ? ? ? ? ? ? ? bpc = connector->display_info.bpc; */
>>
>> ? ? ? ? ? ? ? switch (encoder_mode) {
>> ? ? ? ? ? ? ? case ATOM_ENCODER_MODE_DP_MST:
>> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
>> b/drivers/gpu/drm/radeon/atombios_dp.c
>> index 6c62be2..c57d856 100644
>> --- a/drivers/gpu/drm/radeon/atombios_dp.c
>> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
>> @@ -405,10 +405,13 @@ static void dp_get_adjust_train(u8 
>> link_status[DP_LINK_STATUS_SIZE],
>> ?/* get bpc from the EDID */
>> ?static int convert_bpc_to_bpp(int bpc)
>> ?{
>> +#if 0
>> ? ? ? if (bpc == 0)
>> ? ? ? ? ? ? ? return 24;
>> ? ? ? else
>> ? ? ? ? ? ? ? return bpc * 3;
>> +#endif
>> + ? ? return 24;
>> ?}
>>
>> ?/* get the max pix clock supported by the link rate and lane num */
>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
>> b/drivers/gpu/drm/radeon/atombios_encoders.c
>> index 468b874..e607c4d 100644
>> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
>> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
>> @@ -541,7 +541,7 @@ atombios_dig_encoder_setup(struct drm_encoder *encoder, 
>> int action, int panel_mo
>> ? ? ? ? ? ? ? dp_clock = dig_connector->dp_clock;
>> ? ? ? ? ? ? ? dp_lane_count = dig_connector->dp_lane_count;
>> ? ? ? ? ? ? ? hpd_id = radeon_connector->hpd.hpd;
>> - ? ? ? ? ? ? bpc = connector->display_info.bpc;
>> + ? ? ? ? ? ? /* bpc = connector->display_info.bpc; */
>> ? ? ? }
>>
>> ? ? ? /* no dig encoder assigned */
>> @@ -1159,7 +1159,7 @@ atombios_external_encoder_setup(struct drm_encoder 
>> *encoder,
>> ? ? ? ? ? ? ? dp_lane_count = dig_connector->dp_lane_count;
>> ? ? ? ? ? ? ? connector_object_id =
>> ? ? ? ? ? ? ? ? ? ? ? (radeon_connector->connector_object_id & 
>> OBJECT_ID_MASK) >> OBJECT_ID_SHIFT;
>> - ? ? ? ? ? ? bpc = connector->display_info.bpc;
>> + ? ? ? ? ? ? /* bpc = connector->display_info.bpc; */
>> ? ? ? }
>>
>> ? ? ? memset(, 0, sizeof(args));
>> --
>> 1.7.7.5
>>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-kms-improve-bpc-handling.patch
Type: text/x-patch
Size: 6939 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120323/f50976a0/attachment.bin>

[Bug 47765] Corrupt rendering to a window between 57 and 63 pixels high

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47765

--- Comment #3 from Tvrtko Ursulin  2012-03-23 
08:28:01 PDT ---
Created attachment 58939
  --> https://bugs.freedesktop.org/attachment.cgi?id=58939
Screenshot showing corrupted mesa-demos/tri rendering

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 47765] Corrupt rendering to a window between 57 and 63 pixels high

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47765

--- Comment #2 from Tvrtko Ursulin  2012-03-23 
08:22:20 PDT ---
(In reply to comment #1)
> Does any of the mesa demo reproduce the bug ?

/usr/lib64/mesa/tri shows it if you resize the window right.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] exynos: add module name.

[Inki Dae]

exynos drm driver have been added to mainline so this patch adds
module name for exynos to modetest and vbltest.

this patch is based on commit id below:
c50cc24690938db53cd91ae9ff2fa0958693f80d

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 tests/modetest/modetest.c |2 +-
 tests/vbltest/vbltest.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 229ab8a..884e6e4 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -721,7 +721,7 @@ int main(int argc, char **argv)
int c;
int encoders = 0, connectors = 0, crtcs = 0, framebuffers = 0;
int test_vsync = 0;
-   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx" };
+   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos" };
char *modeset = NULL;
int i, count = 0;
struct connector con_args[2];
diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
index 903ca0f..4fccd59 100644
--- a/tests/vbltest/vbltest.c
+++ b/tests/vbltest/vbltest.c
@@ -103,7 +103,7 @@ static void usage(char *name)
 int main(int argc, char **argv)
 {
int i, c, fd, ret;
-   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx" };
+   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos" };
drmVBlank vbl;
drmEventContext evctx;
struct vbl_info handler_info;
-- 
1.7.4.1

[Bug 47765] Corrupt rendering to a window between 57 and 63 pixels high

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47765

--- Comment #1 from Jerome Glisse  2012-03-23 
07:49:55 PDT ---
Does any of the mesa demo reproduce the bug ?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms/atom: force bpc to 8 for now

[alexdeuc...@gmail.com]

From: Alex Deucher 

Using the bpc (bits per color) specified by the monitor
can cause problems in some cases.  Until we get a better
handle on how to deal with those cases, just use a bpc of 8.

Reported-by: Lennert Buytenhek 
Signed-off-by: Alex Deucher 
Cc: stable at kernel.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c |8 +---
 drivers/gpu/drm/radeon/atombios_dp.c   |3 +++
 drivers/gpu/drm/radeon/atombios_encoders.c |4 ++--
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 083b3ea..b5ff1f7 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -588,8 +588,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder->crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
-   if (connector && connector->display_info.bpc)
-   bpc = connector->display_info.bpc;
+   /* if (connector && connector->display_info.bpc)
+   bpc = connector->display_info.bpc; */
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder, 
mode->clock);
if ((radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT 
| ATOM_DEVICE_DFP_SUPPORT)) ||
@@ -965,7 +965,9 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
struct radeon_connector_atom_dig *dig_connector =
radeon_connector->con_priv;
int dp_clock;
-   bpc = connector->display_info.bpc;
+
+   /* if (connector->display_info.bpc)
+   bpc = connector->display_info.bpc; */

switch (encoder_mode) {
case ATOM_ENCODER_MODE_DP_MST:
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 6c62be2..c57d856 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -405,10 +405,13 @@ static void dp_get_adjust_train(u8 
link_status[DP_LINK_STATUS_SIZE],
 /* get bpc from the EDID */
 static int convert_bpc_to_bpp(int bpc)
 {
+#if 0
if (bpc == 0)
return 24;
else
return bpc * 3;
+#endif
+   return 24;
 }

 /* get the max pix clock supported by the link rate and lane num */
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 468b874..e607c4d 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -541,7 +541,7 @@ atombios_dig_encoder_setup(struct drm_encoder *encoder, int 
action, int panel_mo
dp_clock = dig_connector->dp_clock;
dp_lane_count = dig_connector->dp_lane_count;
hpd_id = radeon_connector->hpd.hpd;
-   bpc = connector->display_info.bpc;
+   /* bpc = connector->display_info.bpc; */
}

/* no dig encoder assigned */
@@ -1159,7 +1159,7 @@ atombios_external_encoder_setup(struct drm_encoder 
*encoder,
dp_lane_count = dig_connector->dp_lane_count;
connector_object_id =
(radeon_connector->connector_object_id & 
OBJECT_ID_MASK) >> OBJECT_ID_SHIFT;
-   bpc = connector->display_info.bpc;
+   /* bpc = connector->display_info.bpc; */
}

memset(, 0, sizeof(args));
-- 
1.7.7.5

[PATCH] drm/i915: Add lock on drm_helper_resume_force_mode

[Chris Wilson]

On Fri, 23 Mar 2012 08:52:58 -0400, Sean Paul  wrote:
> i915_drm_thaw was not locking the mode_config lock when calling
> drm_helper_resume_force_mode. When there were multiple wake sources,
> this caused FDI training failure on SNB which in turn corrupted the
> display.
> 
> Signed-off-by: Sean Paul 
Reviewed-by: Chris Wilson 
Cc: stable at kernel.org
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[RFCv2 PATCH 5/9] v4l: vb2: add buffer exporting via dmabuf

[Tomasz Stanislawski]

Hi Laurent,
Thank you for you comments.

On 03/22/2012 12:24 PM, Laurent Pinchart wrote:
> Hi Tomasz,
> 
> Thanks for the patch.
> 
> On Tuesday 13 March 2012 11:17:03 Tomasz Stanislawski wrote:
>> This patch adds extension to videobuf2-core. It allow to export a mmap
>> buffer as a file descriptor.
>>
>> Signed-off-by: Tomasz Stanislawski 
>> Signed-off-by: Kyungmin Park 
>> ---
>>  drivers/media/video/videobuf2-core.c |   64
>> ++ include/media/videobuf2-core.h   |  
>>  2 +
>>  2 files changed, 66 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/video/videobuf2-core.c
>> b/drivers/media/video/videobuf2-core.c index e7df560..41c4bf8 100644
>> --- a/drivers/media/video/videobuf2-core.c
>> +++ b/drivers/media/video/videobuf2-core.c
>> @@ -1553,6 +1553,70 @@ int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer
>> *b, bool nonblocking) }
>>  EXPORT_SYMBOL_GPL(vb2_dqbuf);
>>
>> +static int __find_plane_by_offset(struct vb2_queue *q, unsigned long off,
>> +unsigned int *_buffer, unsigned int *_plane);
>> +
> 
> Could you please move __find_plane_by_offset() up or move vb2_expbuf() down 
> to 
> avoid the forward declaration ? The later might make more sense, you could 
> declare vb2_expbuf() right after vb2_mmap() (here and in videobuf2-core.h), 
> both functions perform similar tasks.
> 

Ok. I will move it.

I used the forward declaration to have only-plus patch while keeping all
vb2_*buf functions together.

Regards,
Tomasz Stanislawski

[Bug 47765] New: Corrupt rendering to a window between 57 and 63 pixels high

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47765

 Bug #: 47765
   Summary: Corrupt rendering to a window between 57 and 63 pixels
high
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: tvrtko.ursulin at onelan.co.uk


We are seeing render corruption when rendering a texture to a window between 57
and 63 pixels high. glViewport being set to window dimensions.

Texture vertices do not seem to matter. If I render to the full viewport, or to
a subset of a viewport, always the whole viewport gets corrupt (so including
the area outside texture vertices).

Texture size does not seem to matter.

Rendering is done with glDrawArray GL_TRIANGLE_FAN and the destination window
is RGBA.

Environment:

00:01.0 VGA compatible controller: ATI Technologies Inc AMD Radeon HD 6310
GraphicsATI

Kernel 3.3.0 + 0001-drm-radeon-add-support-for-evergreen-ni-tiling-infor.patch

It does not happen without this patch - so it is probably tiling related.

xorg-drivers-ati, mesa and libdrm from yesterday's git. Last one is in fact a
bit older, but I applied a single interesting patch
(9b3ad51ae5fd9654df8ef75de845a519015150bb) by hand to make it up to date.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf

[Tomasz Stanislawski]

Hi Laurent,
Please refer to the comments below.

On 03/22/2012 12:16 PM, Laurent Pinchart wrote:
> Hi Tomasz,
> 
> Thanks for the patch.
> 
> On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:
>> This patch adds extension to V4L2 api. It allow to export a mmap buffer as
>> file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
>> used by mmap and return a file descriptor on success.
> 
> I know code is more fun to write than documentation, but 
> Documentation/DocBook/media/v4l will be sad if this patch is merged as-is ;-)
> 

Ok. I will prepare the documentation just after there will be consensus
about shape of buffer exporting API :).

>> Signed-off-by: Tomasz Stanislawski 
>> Signed-off-by: Kyungmin Park 
>> ---
>>  drivers/media/video/v4l2-compat-ioctl32.c |1 +
>>  drivers/media/video/v4l2-ioctl.c  |   11 +++
>>  include/linux/videodev2.h |   20 
>>  include/media/v4l2-ioctl.h|2 ++
>>  4 files changed, 34 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
>> b/drivers/media/video/v4l2-compat-ioctl32.c index e6f67aa..fd157cb 100644
>> --- a/drivers/media/video/v4l2-compat-ioctl32.c
>> +++ b/drivers/media/video/v4l2-compat-ioctl32.c
>> @@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
>> cmd, unsigned long arg) case VIDIOC_S_FBUF32:
>>  case VIDIOC_OVERLAY32:
>>  case VIDIOC_QBUF32:
>> +case VIDIOC_EXPBUF:
>>  case VIDIOC_DQBUF32:
>>  case VIDIOC_STREAMON32:
>>  case VIDIOC_STREAMOFF32:
>> diff --git a/drivers/media/video/v4l2-ioctl.c
>> b/drivers/media/video/v4l2-ioctl.c index 74cab51..a125016 100644
>> --- a/drivers/media/video/v4l2-ioctl.c
>> +++ b/drivers/media/video/v4l2-ioctl.c
>> @@ -207,6 +207,7 @@ static const char *v4l2_ioctls[] = {
>>  [_IOC_NR(VIDIOC_S_FBUF)]   = "VIDIOC_S_FBUF",
>>  [_IOC_NR(VIDIOC_OVERLAY)]  = "VIDIOC_OVERLAY",
>>  [_IOC_NR(VIDIOC_QBUF)] = "VIDIOC_QBUF",
>> +[_IOC_NR(VIDIOC_EXPBUF)]   = "VIDIOC_EXPBUF",
>>  [_IOC_NR(VIDIOC_DQBUF)]= "VIDIOC_DQBUF",
>>  [_IOC_NR(VIDIOC_STREAMON)] = "VIDIOC_STREAMON",
>>  [_IOC_NR(VIDIOC_STREAMOFF)]= "VIDIOC_STREAMOFF",
>> @@ -938,6 +939,16 @@ static long __video_do_ioctl(struct file *file,
>>  dbgbuf(cmd, vfd, p);
>>  break;
>>  }
>> +case VIDIOC_EXPBUF:
>> +{
>> +struct v4l2_exportbuffer *p = arg;
>> +
>> +if (!ops->vidioc_expbuf)
>> +break;
>> +
>> +ret = ops->vidioc_expbuf(file, fh, p);
> 
> You can pass arg to ops->vidioc_expbuf() directly, there's no need to create 
> a 
> struct v4l2_exportbuffer *p variable.
> 

No problem. I tried to follow style of other ioctls.
Notice that adding this temporary variable provides some
form of type checking. I mean using a proper structure for
a proper callback.

>> +break;
>> +}
>>  case VIDIOC_DQBUF:
>>  {
>>  struct v4l2_buffer *p = arg;
>> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
>> index bb6844e..e71c787 100644
>> --- a/include/linux/videodev2.h
>> +++ b/include/linux/videodev2.h
>> @@ -680,6 +680,25 @@ struct v4l2_buffer {
>>  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE   0x0800
>>  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN0x1000
>>
>> +/**
>> + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
>> descriptor
>> + *
>> + * @fd: file descriptor associated with DMABUF (set by driver)
>> + * @mem_offset: for non-multiplanar buffers with memory ==
>> V4L2_MEMORY_MMAP;
> 
> I don't think we will ever support exporting anything else than 
> V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?
> 

Every plane is described by its separate mem-offset. So planes are
exported as separate DMABUF. I will update field description.

>> + *  offset from the start of the device memory for this plane,
>> + *  (or a "cookie" that should be passed to mmap() as offset)
>> + *
> 
> Shouldn't the mem_offset field always be set to the mmap cookie value ? I'm a 
> bit confused by the "or" part, it seems to have been copied from the 
> v4l2_buffer documentation directly. We should clarify that.
> 

Ok. I agree.

>> + * Contains data used for exporting a video buffer as DMABUF file
>> + * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
>> fields
>> + * must be set to zero.
>> + */
>> +struct v4l2_exportbuffer {
>> +__u32   fd;
>> +__u32   reserved0;
> 
> Why is there a reserved field here ?
> 

I expected that struct v4l2_requestbuffer might allow exporting buffers 
described
by something else than 'mmap cookie'. Union could be used for different schemes 
i.e.

struct v4l2_exportbuffer {
__u32   fd;
__u32   type;
union {

radeon + DVI->mDP converter + mDP display blank screen issue since 3.0

[Alex Deucher]

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?if (dig->coherent_mode)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?args.v3.sInput.ucDispPllConfig 
> |=
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> ?DISPPLL_CONFIG_COHERENT_MODE;
> @@ -753,7 +749,6 @@ static void atombios_crtc_program_pll(struct drm_crtc 
> *crtc,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u32 fb_div,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u32 frac_fb_div,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u32 post_div,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? int bpc,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bool ss_enabled,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct radeon_atom_ss *ss)
> ?{
> @@ -817,15 +812,6 @@ static void atombios_crtc_program_pll(struct drm_crtc 
> *crtc,
> ? ? ? ? ? ? ? ? ? ? ? ?args.v5.ucMiscInfo = 0; /* HDMI depth, etc. */
> ? ? ? ? ? ? ? ? ? ? ? ?if (ss_enabled && (ss->type & ATOM_EXTERNAL_SS_MASK))
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?args.v5.ucMiscInfo |= 
> PIXEL_CLOCK_V5_MISC_REF_DIV_SRC;
> - ? ? ? ? ? ? ? ? ? ? ? switch (bpc) {
> - ? ? ? ? ? ? ? ? ? ? ? case 8:
> - ? ? ? ? ? ? ? ? ? ? ? default:
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? args.v5.ucMiscInfo |= 
> PIXEL_CLOCK_V5_MISC_HDMI_24BPP;
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> - ? ? ? ? ? ? ? ? ? ? ? case 10:
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? args.v5.ucMiscInfo |= 
> PIXEL_CLOCK_V5_MISC_HDMI_30BPP;
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> - ? ? ? ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ? ? ? ? ?args.v5.ucTransmitterID = encoder_id;
> ? ? ? ? ? ? ? ? ? ? ? ?args.v5.ucEncoderMode = encoder_mode;
> ? ? ? ? ? ? ? ? ? ? ? ?args.v5.ucPpll = pll_id;
> @@ -839,21 +825,6 @@ static void atombios_crtc_program_pll(struct drm_crtc 
> *crtc,
> ? ? ? ? ? ? ? ? ? ? ? ?args.v6.ucMiscInfo = 0; /* HDMI depth, etc. */
> ? ? ? ? ? ? ? ? ? ? ? ?if (ss_enabled && (ss->type & ATOM_EXTERNAL_SS_MASK))
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?args.v6.ucMiscInfo |= 
> PIXEL_CLOCK_V6_MISC_REF_DIV_SRC;
> - ? ? ? ? ? ? ? ? ? ? ? switch (bpc) {
> - ? ? ? ? ? ? ? ? ? ? ? case 8:
> - ? ? ? ? ? ? ? ? ? ? ? default:
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? args.v6.ucMiscInfo |= 
> PIXEL_CLOCK_V6_MISC_HDMI_24BPP;
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> - ? ? ? ? ? ? ? ? ? ? ? case 10:
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? args.v6.ucMiscInfo |= 
> PIXEL_CLOCK_V6_MISC_HDMI_30BPP;
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> - ? ? ? ? ? ? ? ? ? ? ? case 12:
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? args.v6.ucMiscInfo |= 
> PIXEL_CLOCK_V6_MISC_HDMI_36BPP;
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> - ? ? ? ? ? ? ? ? ? ? ? case 16:
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? args.v6.ucMiscInfo |= 
> PIXEL_CLOCK_V6_MISC_HDMI_48BPP;
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> - ? ? ? ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ? ? ? ? ?args.v6.ucTransmitterID = encoder_id;
> ? ? ? ? ? ? ? ? ? ? ? ?args.v6.ucEncoderMode = encoder_mode;
> ? ? ? ? ? ? ? ? ? ? ? ?args.v6.ucPpll = pll_id;
> @@ -885,7 +856,6 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
> struct drm_display_mode
> ? ? ? ?int encoder_mode = 0;
> ? ? ? ?struct radeon_atom_ss ss;
> ? ? ? ?bool ss_enabled = false;
> - ? ? ? int bpc = 8;
>
> ? ? ? ?list_for_each_entry(encoder, >mode_config.encoder_list, head) {
> ? ? ? ? ? ? ? ?if (encoder->crtc == crtc) {
> @@ -922,7 +892,6 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
> struct drm_display_mode
> ? ? ? ? ? ? ? ?struct radeon_connector_atom_dig *dig_connector =
> ? ? ? ? ? ? ? ? ? ? ? ?radeon_connector->con_priv;
> ? ? ? ? ? ? ? ?int dp_clock;
> - ? ? ? ? ? ? ? bpc = connector->display_info.bpc;
>
> ? ? ? ? ? ? ? ?switch (encoder_mode) {
> ? ? ? ? ? ? ? ?case ATOM_ENCODER_MODE_DP_MST:
> @@ -995,7 +964,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
> struct drm_display_mode
>
> ? ? ? ?atombios_crtc_program_pll(crtc, radeon_crtc->crtc_id, 
> radeon_crtc->pll_id,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?encoder_mode, radeon_encoder->encoder_id, 
> mode->clock,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ref_div, fb_div, frac_fb_div, post_div, 
> bpc, ss_enabled, );
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ref_div, fb_div, frac_fb_div, post_div, 
> ss_enabled, );
>
> ? ? ? ?if (ss_enabled) {
> ? ? ? ? ? ? ? ?/* calculate ss amount and step size */
> @@ -1587,7 +1556,7 @@ static void atombios_crtc_disable(struct drm_crtc *crtc)
> ? ? ? ?case ATOM_PPLL2:
> ? ? ? ? ? ? ? ?/* disable the ppll */
> ? ? ? ? ? ? ? ?atombios_crtc_program_pll(crtc, radeon_crtc->crtc_id, 
> radeon_crtc->pll_id,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0, 0, ATOM_DISABLE, 0, 0, 0, 0, 0, 
> false, );
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0, 0, ATOM_DISABLE, 0, 0, 0, 0, 
> false, );
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?default:
> ? ? ? ? ? ? ? ?break;
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-kms-atom-force-bpc-to-8-for-now.patch
Type: text/x-patch
Size: 3447 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120323/b250b078/attachment.bin>

[PATCH v2] drm/i915: Run DDC buses at 50 kbps

[Jean Delvare]

On Thursday 22 March 2012 09:50:23 pm Daniel Vetter wrote:
> On Wed, Mar 21, 2012 at 02:29:47PM +0100, Jean Delvare wrote:
> > A udelay value of 20 leads to an I2C bus running at only 25 kbps.
> > I2C devices can typically operate faster than this, 50 kbps should
> > be fine for all devices (and compliant devices can always stretch
> > the clock if needed.)
> >
> > FWIW, the vast majority of framebuffer drivers set udelay to 10
> > already. So set it to 10 in DRM drivers too, this will make EDID
> > block reads faster. We might even lower the udelay value later if
> > no problem is reported.
> >
> > Signed-off-by: Jean Delvare 
> > Acked-by: Eugeni Dodonov 
> > Cc: Dave Airlie 
> > Cc: Keith Packard 
> 
> Fyi this already got merged int Dave's tree (the unsplit version) as:
> 
> commit 1849ecb22fb3b5d57b65e7369a3957adf9f26f39
> Author: Jean Delvare 
> Date:   Sat Jan 28 11:07:09 2012 +0100
> 
> drm/kms: Make i2c buses faster

Thanks Daniel, I just noticed this as it got merged into Linus tree last 
night. I had not received any ack from Dave and the git repository 
mentioned in MAINTAINERS is wrong so I couldn't check whether my patches 
were already applied or not.

Anyway, the important thing is that they are in Linus' tree now.

-- 
Jean Delvare
Suse L3

[PATCH] drm/i915: Add lock on drm_helper_resume_force_mode

[Sean Paul]

i915_drm_thaw was not locking the mode_config lock when calling
drm_helper_resume_force_mode. When there were multiple wake sources,
this caused FDI training failure on SNB which in turn corrupted the
display.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/i915_drv.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8e2c52e..1c554fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -535,7 +535,9 @@ static int i915_drm_thaw(struct drm_device *dev)
drm_irq_install(dev);

/* Resume the modeset for every activated CRTC */
+   mutex_lock(>mode_config.mutex);
drm_helper_resume_force_mode(dev);
+   mutex_unlock(>mode_config.mutex);

if (IS_IRONLAKE_M(dev))
ironlake_enable_rc6(dev);
-- 
1.7.7.3

[PATCH] drm: Add locking to resume_force_mode to prevent multiple

[Sean Paul]

On Thu, Mar 22, 2012 at 6:57 PM, Chris Wilson  
wrote:
> On Thu, 22 Mar 2012 18:25:55 -0400, Sean Paul  
> wrote:
>> Add a mutex to protect resume_force_mode from being called multiple
>> times. This fixes a bug observed on SNB where two wake sources call
>> resume_force_mode and the FDI training fails as a result. The user
>> facing result of this is complete screen corruption.
>
> Looks like a bug in i915_drv.c for calling that function without holding
> the mode_config.lock

Good catch, thanks for the feedback Chris.

I'll submit a new patch to intel-gfx, please drop this one.

Sean


> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre

[Bug 47519] Xorg hangs in ioCtl in path of RADEONDownloadFromScreenCS

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47519

Michel D?nzer  changed:

   What|Removed |Added

 AssignedTo|sandmann at cs.au.dk   |dri-devel at 
lists.freedesktop
   ||.org
Product|xorg|DRI
Version|7.6 (2010.12)   |unspecified
  Component|Driver/qxl  |DRM/Radeon

--- Comment #12 from Michel D?nzer  2012-03-23 01:18:55 
PDT ---
(In reply to comment #10)
> After running 3 days with radeon.msi=0 it seems the hang is gone. Did not
> suffer this problem until now.

Okay, so I'm reassigning this to the kernel driver for now, though this might
just be a duplicate of another MSI related report here or in the kernel
bugzilla.


> "EXAPixmaps" is "off" because i see many artifacts sometimes on the screen
> otherwise - maybe its the greedy option, did not test both exclusive.

Option "MigrationHeuristic" has no effect with KMS. Disabling EXAPixmaps
probably just avoids the problem because it prevents hardware acceleration in
most cases. The corruption looks like bug 47266, would be nice if somebody
could find a working driver snapshot and bisect.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/i2c/ch7006: Convert to dev_pm_ops

[Francisco Jerez]

Mark Brown  writes:

> The I2C specific suspend and resume functions have been deprecated and
> printing a warning on boot for over a year, dev_pm_ops should be used
> instead so convert to that.
>
> Also remove the suspend function since all it does is log.
>
> Signed-off-by: Mark Brown 
> ---
>  drivers/gpu/drm/i2c/ch7006_drv.c |   16 +++-
>  1 files changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c 
> b/drivers/gpu/drm/i2c/ch7006_drv.c
> index d3f2e87..ca4435d 100644
> --- a/drivers/gpu/drm/i2c/ch7006_drv.c
> +++ b/drivers/gpu/drm/i2c/ch7006_drv.c
> @@ -427,15 +427,10 @@ static int ch7006_remove(struct i2c_client *client)
>   return 0;
>  }
>  
> -static int ch7006_suspend(struct i2c_client *client, pm_message_t mesg)
> +static int ch7006_resume(struct device *dev)
>  {
> - ch7006_dbg(client, "\n");
> -
> - return 0;
> -}
> + struct i2c_client *client = to_i2c_device(dev);
>  
> -static int ch7006_resume(struct i2c_client *client)
> -{
>   ch7006_dbg(client, "\n");
>  
>   ch7006_write(client, 0x3d, 0x0);
> @@ -499,15 +494,18 @@ static struct i2c_device_id ch7006_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(i2c, ch7006_ids);
>  
> +static const struct dev_pm_ops ch7006_pm_ops = {
> + .resume = ch7006_resume,
> +};
> +
>  static struct drm_i2c_encoder_driver ch7006_driver = {
>   .i2c_driver = {
>   .probe = ch7006_probe,
>   .remove = ch7006_remove,
> - .suspend = ch7006_suspend,
> - .resume = ch7006_resume,
>  
>   .driver = {
>   .name = "ch7006",
> + .pm = ch7006_pm_ops,
>   },
>  
>   .id_table = ch7006_ids,

Thanks for fixing this,

Reviewed-by: Francisco Jerez 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120323/ea17e8a8/attachment.pgp>

[Bug 37696] [RADEON:KMS:PLL] frequent colored lines appear on screen

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37696

--- Comment #2 from Joshua Roys  2012-03-22 17:08:25 PDT 
---
They are still visible with 3.3.0.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/i915: no-lvds quirk on MSI DC500

[Anisse Astier]

Hi again,

Could anyone have a look at this ?

On Tue, Mar 13, 2012 at 3:16 PM, Anisse Astier  wrote:
>
> Any opinion on this quirk ?
>
> On Wed, ?7 Mar 2012 18:36:35 +0100, Anisse Astier  wrote
> :
>
> > This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
> > LVDS detection.
> >
> > Cc: stable at kernel.org
> > Signed-off-by: Anisse Astier 
> > ---
> > ?drivers/gpu/drm/i915/intel_lvds.c | ? ?8 
> > ?1 files changed, 8 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> > b/drivers/gpu/drm/i915/intel_lvds.c
> > index b103c3b..2dee11e 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -739,6 +739,14 @@ static const struct dmi_system_id intel_no_lvds[] =
> > {
> > ? ? ? ? ? ? ? ? ? ? ? DMI_MATCH(DMI_BOARD_NAME, "AT5NM10T-I"),
> > ? ? ? ? ? ? ? },
> > ? ? ? },
> > + ? ? {
> > + ? ? ? ? ? ? .callback = intel_no_lvds_dmi_callback,
> > + ? ? ? ? ? ? .ident = "MSI Wind Box DC500",
> > + ? ? ? ? ? ? .matches = {
> > + ? ? ? ? ? ? ? ? ? ? DMI_MATCH(DMI_BOARD_VENDOR, "MICRO-STAR
> > INTERNATIONAL CO., LTD"),
> > + ? ? ? ? ? ? ? ? ? ? DMI_MATCH(DMI_BOARD_NAME, "MS-7469"),
> > + ? ? ? ? ? ? },
> > + ? ? },
> >
> > ? ? ? { } ? ? /* terminating entry */
> > ?};

[PATCH] exynos: add module name.

[Inki Dae]

exynos drm driver have been added to mainline so this patch adds
module name for exynos to modetest and vbltest.

this patch is based on commit id below:
c50cc24690938db53cd91ae9ff2fa0958693f80d

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 tests/modetest/modetest.c |2 +-
 tests/vbltest/vbltest.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 229ab8a..884e6e4 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -721,7 +721,7 @@ int main(int argc, char **argv)
int c;
int encoders = 0, connectors = 0, crtcs = 0, framebuffers = 0;
int test_vsync = 0;
-   char *modules[] = { i915, radeon, nouveau, vmwgfx };
+   char *modules[] = { i915, radeon, nouveau, vmwgfx, exynos };
char *modeset = NULL;
int i, count = 0;
struct connector con_args[2];
diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
index 903ca0f..4fccd59 100644
--- a/tests/vbltest/vbltest.c
+++ b/tests/vbltest/vbltest.c
@@ -103,7 +103,7 @@ static void usage(char *name)
 int main(int argc, char **argv)
 {
int i, c, fd, ret;
-   char *modules[] = { i915, radeon, nouveau, vmwgfx };
+   char *modules[] = { i915, radeon, nouveau, vmwgfx, exynos };
drmVBlank vbl;
drmEventContext evctx;
struct vbl_info handler_info;
-- 
1.7.4.1

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

radeon + DVI-mDP converter + mDP display blank screen issue since 3.0

[Lennert Buytenhek]

Hi!

Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
to a 27 Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
to Mini DisplayPort converter has started to stop giving screen
output on switching from text mode to graphical framebuffer during
system startup.

I finally had some time to look at this, and it seems to have stopped
working after this commit:

commit df271bec805b42527d864777ed035fcbb42e76c0
Author: Alex Deucher alexdeuc...@gmail.com
Date:   Fri May 20 04:34:15 2011 -0400

drm/radeon/kms: properly handle bpc 8 in atom command tables

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com

...and with the patch below (i.e. reverting part of the commit above)
applied to 3.3 I get screen output again.

Even though the monitor seems to have an 8 bit panel, it reports 10
bits per channel in its EDID:

[...]
Manufacturer: APP Model 9226 Serial Number 41959462
Made week 38 of 2010
EDID version: 1.4
Digital display
10 bits per primary color channel
DisplayPort interface
Maximum image size: 60 cm x 34 cm
[...]

The (active, dual link) DVI-mDP converter spec sheet says it supports
24 bit color, and I'm guessing that it can't deal with 30.  Is the
converter at fault here for passing through the EDID unchanged?

Also, what would be the right way to handle this, a kernel command
line or module option to limit color depth or something like that?
(Buy a video card with DP output. is a valid answer, I suppose.)

I have no clue at all about graphics, and I have no idea whatsoever
what I'm doing here, but I just wanted to post this somewhere for
Google to find in case someone else runs into this!


thanks,
Lennert



diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 742f17f..77a6a04 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -513,11 +513,9 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
struct radeon_device *rdev = dev-dev_private;
struct drm_encoder *encoder = NULL;
struct radeon_encoder *radeon_encoder = NULL;
-   struct drm_connector *connector = NULL;
u32 adjusted_clock = mode-clock;
int encoder_mode = 0;
u32 dp_clock = mode-clock;
-   int bpc = 8;
bool is_duallink = false;
 
/* reset the pll flags */
@@ -549,13 +547,11 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
list_for_each_entry(encoder, dev-mode_config.encoder_list, head) {
if (encoder-crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
-   connector = radeon_get_connector_for_encoder(encoder);
-   if (connector  connector-display_info.bpc)
-   bpc = connector-display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder, 
mode-clock);
if ((radeon_encoder-devices  (ATOM_DEVICE_LCD_SUPPORT 
| ATOM_DEVICE_DFP_SUPPORT)) ||
(radeon_encoder_get_dp_bridge_encoder_id(encoder) 
!= ENCODER_OBJECT_ID_NONE)) {
+   struct drm_connector *connector = 
radeon_get_connector_for_encoder(encoder);
if (connector) {
struct radeon_connector 
*radeon_connector = to_radeon_connector(connector);
struct radeon_connector_atom_dig 
*dig_connector =
@@ -645,7 +641,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder_mode == 
ATOM_ENCODER_MODE_HDMI)
/* deep color support */
args.v3.sInput.usPixelClock =
-   
cpu_to_le16((mode-clock * bpc / 8) / 10);
+   cpu_to_le16(mode-clock 
/ 10);
if (dig-coherent_mode)
args.v3.sInput.ucDispPllConfig 
|=

DISPPLL_CONFIG_COHERENT_MODE;
@@ -753,7 +749,6 @@ static void atombios_crtc_program_pll(struct drm_crtc *crtc,
  u32 fb_div,
  u32 frac_fb_div,
  u32 post_div,
- int bpc,
  bool ss_enabled,
  struct radeon_atom_ss *ss)
 {
@@ -817,15 +812,6 @@ static void atombios_crtc_program_pll(struct drm_crtc 
*crtc,

Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9] v4l: vb2-dma-contig: update and code refactoring

[Subash Patel]

Hello Thomasz, Marek,

I found an issue with below patch. Please read below.

On 03/13/2012 03:47 PM, Tomasz Stanislawski wrote:

This patch combines updates and fixes to dma-contig allocator.
Moreover the allocator code was refactored.
The most important changes are:
- functions were reordered
- move compression of scatterlist to separete function
- add support for multichunk but contiguous scatterlists
- simplified implementation of vb2-dma-contig context structure
- let mmap method to use dma_mmap_writecombine
- add support for scatterlist in userptr mode

Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
[mmap method]
Signed-off-by: Andrzej Pietrasiewiczandrze...@samsung.com
[scatterlist in userptr mode]
Signed-off-by: Kamil Debskik.deb...@samsung.com
[bugfixing]
Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com
[core refactoring, helper functions]
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
  drivers/media/video/videobuf2-dma-contig.c |  495 +++-
  1 files changed, 414 insertions(+), 81 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index f17ad98..c1dc043 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -10,173 +10,506 @@
   * the Free Software Foundation.
   */

+#includelinux/dma-buf.h
+#includelinux/dma-mapping.h
  #includelinux/module.h
+#includelinux/scatterlist.h
+#includelinux/sched.h
  #includelinux/slab.h
-#includelinux/dma-mapping.h

  #includemedia/videobuf2-core.h
  #includemedia/videobuf2-memops.h

-struct vb2_dc_conf {
-   struct device   *dev;
-};
-
  struct vb2_dc_buf {
-   struct vb2_dc_conf  *conf;
+   struct device   *dev;
void*vaddr;
-   dma_addr_t  dma_addr;
unsigned long   size;
-   struct vm_area_struct   *vma;
-   atomic_trefcount;
+   dma_addr_t  dma_addr;
+   struct sg_table *dma_sgt;
+   enum dma_data_direction dma_dir;
+
+   /* MMAP related */
struct vb2_vmarea_handler   handler;
+   atomic_trefcount;
+   struct sg_table *sgt_base;
+
+   /* USERPTR related */
+   struct vm_area_struct   *vma;
  };

-static void vb2_dma_contig_put(void *buf_priv);
+/*/
+/*scatterlist table functions*/
+/*/

-static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size)
+static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
+   unsigned long n_pages, size_t offset, size_t offset2)
  {
-   struct vb2_dc_conf *conf = alloc_ctx;
-   struct vb2_dc_buf *buf;
+   struct sg_table *sgt;
+   int i, j; /* loop counters */
+   int cur_page, chunks;
+   int ret;
+   struct scatterlist *s;

-   buf = kzalloc(sizeof *buf, GFP_KERNEL);
-   if (!buf)
+   sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
+   if (!sgt)
return ERR_PTR(-ENOMEM);

-   buf-vaddr = dma_alloc_coherent(conf-dev, size,buf-dma_addr,
-   GFP_KERNEL);
-   if (!buf-vaddr) {
-   dev_err(conf-dev, dma_alloc_coherent of size %ld failed\n,
-   size);
-   kfree(buf);
+   /* compute number of chunks */
+   chunks = 1;
+   for (i = 1; i  n_pages; ++i)
+   if (pages[i] != pages[i - 1] + 1)
+   ++chunks;
+
+   ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
+   if (ret) {
+   kfree(sgt);
return ERR_PTR(-ENOMEM);
}

-   buf-conf = conf;
-   buf-size = size;
-
-   buf-handler.refcount =buf-refcount;
-   buf-handler.put = vb2_dma_contig_put;
-   buf-handler.arg = buf;
+   /* merging chunks and putting them into the scatterlist */
+   cur_page = 0;
+   for_each_sg(sgt-sgl, s, sgt-orig_nents, i) {
+   size_t size = PAGE_SIZE;
+
+   for (j = cur_page + 1; j  n_pages; ++j) {
+   if (pages[j] != pages[j - 1] + 1)
+   break;
+   size += PAGE_SIZE;
+   }
+
+   /* cut offset if chunk starts at the first page */
+   if (cur_page == 0)
+   size -= offset;
+   /* cut offset2 if chunk ends at the last page */
+   if (j == n_pages)
+   size -= offset2;
+
+   sg_set_page(s, pages[cur_page], size, offset);
+   offset = 0;
+   cur_page = j;
+   }

-   atomic_inc(buf-refcount);
+   return sgt;
+}

-   return buf;
+static void 

Re: [Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf

[Subash Patel]

Hi Thomasz,

On 03/22/2012 04:46 PM, Laurent Pinchart wrote:

Hi Tomasz,

Thanks for the patch.

On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:

This patch adds extension to V4L2 api. It allow to export a mmap buffer as
file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
used by mmap and return a file descriptor on success.


I know code is more fun to write than documentation, but
Documentation/DocBook/media/v4l will be sad if this patch is merged as-is ;-)


Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
  drivers/media/video/v4l2-compat-ioctl32.c |1 +
  drivers/media/video/v4l2-ioctl.c  |   11 +++
  include/linux/videodev2.h |   20 
  include/media/v4l2-ioctl.h|2 ++
  4 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c index e6f67aa..fd157cb 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg) case VIDIOC_S_FBUF32:
case VIDIOC_OVERLAY32:
case VIDIOC_QBUF32:
+   case VIDIOC_EXPBUF:
case VIDIOC_DQBUF32:
case VIDIOC_STREAMON32:
case VIDIOC_STREAMOFF32:
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c index 74cab51..a125016 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -207,6 +207,7 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_S_FBUF)]   = VIDIOC_S_FBUF,
[_IOC_NR(VIDIOC_OVERLAY)]  = VIDIOC_OVERLAY,
[_IOC_NR(VIDIOC_QBUF)] = VIDIOC_QBUF,
+   [_IOC_NR(VIDIOC_EXPBUF)]   = VIDIOC_EXPBUF,
[_IOC_NR(VIDIOC_DQBUF)]= VIDIOC_DQBUF,
[_IOC_NR(VIDIOC_STREAMON)] = VIDIOC_STREAMON,
[_IOC_NR(VIDIOC_STREAMOFF)]= VIDIOC_STREAMOFF,
@@ -938,6 +939,16 @@ static long __video_do_ioctl(struct file *file,
dbgbuf(cmd, vfd, p);
break;
}
+   case VIDIOC_EXPBUF:
+   {
+   struct v4l2_exportbuffer *p = arg;
+
+   if (!ops-vidioc_expbuf)
+   break;
+
+   ret = ops-vidioc_expbuf(file, fh, p);


You can pass arg to ops-vidioc_expbuf() directly, there's no need to create a
struct v4l2_exportbuffer *p variable.


+   break;
+   }
case VIDIOC_DQBUF:
{
struct v4l2_buffer *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index bb6844e..e71c787 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -680,6 +680,25 @@ struct v4l2_buffer {
  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN  0x1000

+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor
+ *
+ * @fd:file descriptor associated with DMABUF (set by driver)
+ * @mem_offset:for non-multiplanar buffers with memory ==
V4L2_MEMORY_MMAP;


I don't think we will ever support exporting anything else than
V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?


+ * offset from the start of the device memory for this plane,
+ * (or a cookie that should be passed to mmap() as offset)
+ *


Shouldn't the mem_offset field always be set to the mmap cookie value ? I'm a
bit confused by the or part, it seems to have been copied from the
v4l2_buffer documentation directly. We should clarify that.


+ * Contains data used for exporting a video buffer as DMABUF file
+ * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
fields
+ * must be set to zero.
+ */
+struct v4l2_exportbuffer {
+   __u32   fd;
+   __u32   reserved0;


Why is there a reserved field here ?
+1 to Laurent. Any particular need for reserved0 and reserved[13] below? 
I think one void user pointer is sufficient even for future need.



+   __u32   mem_offset;
+   __u32   reserved[13];
+};
+
Also, what is the reason for returning the fd through this structure? To 
keep it aligned with other v4l2 calls? I liked(or now hate making change 
in the app) how it was being returned through the ioctl in your last patch.



  /*
   *O V E R L A Y   P R E V I E W
   */
@@ -2303,6 +2322,7 @@ struct v4l2_create_buffers {
  #define VIDIOC_S_FBUF  _IOW('V', 11, struct v4l2_framebuffer)
  #define VIDIOC_OVERLAY _IOW('V', 14, int)
  #define VIDIOC_QBUF   _IOWR('V', 15, struct v4l2_buffer)
+#define VIDIOC_EXPBUF  _IOWR('V', 16, struct v4l2_exportbuffer)
  #define VIDIOC_DQBUF  _IOWR('V', 17, struct v4l2_buffer)
  #define VIDIOC_STREAMON  

Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring

[Subash Patel]

Hi Laurent,

On 03/22/2012 08:12 PM, Laurent Pinchart wrote:

Hi Tomasz,

On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote:

Hi Laurent,
Thank you very much for your comments and question.
They were very useful.


You're welcome.


Please refer to the comments below.

On 03/22/2012 11:50 AM, Laurent Pinchart wrote:

On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:

From: Tomasz Stanislawskit.stanisl...@samsung.com

This patch combines updates and fixes to dma-contig allocator.
Moreover the allocator code was refactored.
The most important changes are:
- functions were reordered
- move compression of scatterlist to separete function
- add support for multichunk but contiguous scatterlists
- simplified implementation of vb2-dma-contig context structure
- let mmap method to use dma_mmap_writecombine
- add support for scatterlist in userptr mode


[snip]


diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c index c898e6f..9965465
100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c


[snip]


  static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
  {

struct device *dev = alloc_ctx;
struct vb2_dc_buf *buf;

+   int ret;
+   int
n_pages;http://165.213.219.115/cgi-bin/gitweb.cgi?p=mirror/linux-3.0-mid
as;a=shortlog;h=refs/heads/exynos-3.0-dev + struct page **pages = NULL;

buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)

return ERR_PTR(-ENOMEM);

-   buf-vaddr = dma_alloc_coherent(dev, size,buf-dma_addr,

GFP_KERNEL);

+   buf-dev = dev;
+   buf-size = size;
+   buf-vaddr = dma_alloc_coherent(buf-dev, buf-size,buf-dma_addr,
+   GFP_KERNEL);
+
+   ret = -ENOMEM;

if (!buf-vaddr) {

-   dev_err(dev, dma_alloc_coherent of size %ld failed\n, size);
-   kfree(buf);
-   return ERR_PTR(-ENOMEM);
+   dev_err(dev, dma_alloc_coherent of size %ld failed\n,
+   size);
+   goto fail_buf;

}

-   buf-dev = dev;
-   buf-size = size;
+   WARN_ON((unsigned long)buf-vaddr  ~PAGE_MASK);
+   WARN_ON(buf-dma_addr  ~PAGE_MASK);
+
+   n_pages = PAGE_ALIGN(size)  PAGE_SHIFT;
+
+   pages = kmalloc(n_pages * sizeof pages[0], GFP_KERNEL);
+   if (!pages) {
+   printk(KERN_ERR failed to alloc page table\n);
+   goto fail_dma;
+   }
+
+   ret = dma_get_pages(dev, buf-vaddr, buf-dma_addr, pages, n_pages);


As the only purpose of this is to retrieve a list of pages that will be
used to create a single-entry sgt, wouldn't it be possible to shortcut
the code and get the physical address of the buffer directly ?


The physical address should not be used since they are meaningless in a
context of different devices. It seams that only the list of pages is
more-or-less portable between different drivers.


The pages are physically contiguous. The physical address of the first page is
thus all you need.

struct page and physical addresses can be used interchangeably in this case if
I'm not mistaken. If you want to go with pages, you could use the first page
only instead of the physical buffer address.


The physical address is already present in buf-dma_addr, but it is only
valid if the device has no MMU. Notice that vb2-dma-contig possess no
knowledge if MMU is present for a given device.


That's why buf-dma_addr can't be considered as a physical address. It's only
useful in the device context.


The sg list is not going to be single-entry if the device is provided with
its own MMU.


There's something I don't get then. vb2-dma-contig deals with physically
contiguous buffers. The buffer is backed by physically contiguous pages, so
the sg list should have a single entry.

I think at present, vb2-dma-contig is abused for any kind of memory 
allocation (continuous or not). Wouldnt it be good to have a proper 
working setup for videobuf2-dma-sg instead? Driver which chooses to use 
continuous, shall assign vb2_queue-mem_ops = vb2_dma_contig_memops. The 
devices which know they have a MMU backing can assign the same to 
vb2_dma_sg_memops. But as of now, we try to use vb2_dma_contig_memops 
for all kind of operation. I have also done this mistake, and wish I 
repaired it and posted it before :(



+   if (ret  0) {
+   printk(KERN_ERR failed to get buffer pages from DMA API\n);
+   goto fail_pages;
+   }
+   if (ret != n_pages) {
+   ret = -EFAULT;
+   printk(KERN_ERR failed to get all pages from DMA API\n);
+   goto fail_pages;
+   }
+
+   buf-sgt_base = vb2_dc_pages_to_sgt(pages, n_pages, 0, 0);
+   if (IS_ERR(buf-sgt_base)) {
+   ret = PTR_ERR(buf-sgt_base);
+   printk(KERN_ERR failed to prepare sg table\n);
+   goto fail_pages;
+   }

Re: [Linaro-mm-sig] [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf

[Subash Patel]

On 03/22/2012 07:37 PM, Laurent Pinchart wrote:

Hi Subash,

On Thursday 22 March 2012 19:27:01 Subash Patel wrote:

On 03/22/2012 04:46 PM, Laurent Pinchart wrote:

On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:


[snip]


diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index bb6844e..e71c787 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -680,6 +680,25 @@ struct v4l2_buffer {

   #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
   #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000

+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor
+ *
+ * @fd:file descriptor associated with DMABUF (set by driver)
+ * @mem_offset:for non-multiplanar buffers with memory ==
V4L2_MEMORY_MMAP;


I don't think we will ever support exporting anything else than
V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?


+ * offset from the start of the device memory for this plane,
+ * (or a cookie that should be passed to mmap() as offset)
+ *


Shouldn't the mem_offset field always be set to the mmap cookie value ?
I'm a bit confused by the or part, it seems to have been copied from
the v4l2_buffer documentation directly. We should clarify that.


+ * Contains data used for exporting a video buffer as DMABUF file
+ * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
fields
+ * must be set to zero.
+ */
+struct v4l2_exportbuffer {
+   __u32   fd;
+   __u32   reserved0;


Why is there a reserved field here ?


+1 to Laurent. Any particular need for reserved0 and reserved[13] below?
I think one void user pointer is sufficient even for future need.


I'd rather have more than one void user pointer, just in case. A couple of
bytes won't be expensive,
Just an off-topic note. When I learnt to hit keyboard for programming(in 
linux for embedded), I had strict guidelines not to declare variables as 
I like, as memory and computing was very precious then. A decade later, 
people no more think its expensive to keep 14*3 bytes*(who knows how 
many dma_buf objects) in the system.

Just a side note, thats all :)

and they will save lots of hassle in the future if

we need to add a couple of fields. I was just wondering why there was a
reserved field between fd and mem_offset.


+   __u32   mem_offset;
+   __u32   reserved[13];
+};
+


Also, what is the reason for returning the fd through this structure? To
keep it aligned with other v4l2 calls? I liked(or now hate making change
in the app) how it was being returned through the ioctl in your last patch.


Probably to be consistent with the V4L2 API, yes. It won't make a big
difference for applications, I would favor consistency in this case.


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

[PATCH] drm/i2c/ch7006: Convert to dev_pm_ops

[Mark Brown]

The I2C specific suspend and resume functions have been deprecated and
printing a warning on boot for over a year, dev_pm_ops should be used
instead so convert to that.

Also remove the suspend function since all it does is log.

Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
 drivers/gpu/drm/i2c/ch7006_drv.c |   16 +++-
 1 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index d3f2e87..ca4435d 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -427,15 +427,10 @@ static int ch7006_remove(struct i2c_client *client)
return 0;
 }
 
-static int ch7006_suspend(struct i2c_client *client, pm_message_t mesg)
+static int ch7006_resume(struct device *dev)
 {
-   ch7006_dbg(client, \n);
-
-   return 0;
-}
+   struct i2c_client *client = to_i2c_device(dev);
 
-static int ch7006_resume(struct i2c_client *client)
-{
ch7006_dbg(client, \n);
 
ch7006_write(client, 0x3d, 0x0);
@@ -499,15 +494,18 @@ static struct i2c_device_id ch7006_ids[] = {
 };
 MODULE_DEVICE_TABLE(i2c, ch7006_ids);
 
+static const struct dev_pm_ops ch7006_pm_ops = {
+   .resume = ch7006_resume,
+};
+
 static struct drm_i2c_encoder_driver ch7006_driver = {
.i2c_driver = {
.probe = ch7006_probe,
.remove = ch7006_remove,
-   .suspend = ch7006_suspend,
-   .resume = ch7006_resume,
 
.driver = {
.name = ch7006,
+   .pm = ch7006_pm_ops,
},
 
.id_table = ch7006_ids,
-- 
1.7.9.1

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

[Bug 47519] Xorg hangs in ioCtl in path of RADEONDownloadFromScreenCS

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=47519

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

 AssignedTo|sandm...@cs.au.dk   |dri-devel@lists.freedesktop
   ||.org
Product|xorg|DRI
Version|7.6 (2010.12)   |unspecified
  Component|Driver/qxl  |DRM/Radeon

--- Comment #12 from Michel Dänzer mic...@daenzer.net 2012-03-23 01:18:55 PDT 
---
(In reply to comment #10)
 After running 3 days with radeon.msi=0 it seems the hang is gone. Did not
 suffer this problem until now.

Okay, so I'm reassigning this to the kernel driver for now, though this might
just be a duplicate of another MSI related report here or in the kernel
bugzilla.


 EXAPixmaps is off because i see many artifacts sometimes on the screen
 otherwise - maybe its the greedy option, did not test both exclusive.

Option MigrationHeuristic has no effect with KMS. Disabling EXAPixmaps
probably just avoids the problem because it prevents hardware acceleration in
most cases. The corruption looks like bug 47266, would be nice if somebody
could find a working driver snapshot and bisect.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf

[Tomasz Stanislawski]

Hi Laurent,
Please refer to the comments below.

On 03/22/2012 12:16 PM, Laurent Pinchart wrote:
 Hi Tomasz,
 
 Thanks for the patch.
 
 On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote:
 This patch adds extension to V4L2 api. It allow to export a mmap buffer as
 file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
 used by mmap and return a file descriptor on success.
 
 I know code is more fun to write than documentation, but 
 Documentation/DocBook/media/v4l will be sad if this patch is merged as-is ;-)
 

Ok. I will prepare the documentation just after there will be consensus
about shape of buffer exporting API :).

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/video/v4l2-compat-ioctl32.c |1 +
  drivers/media/video/v4l2-ioctl.c  |   11 +++
  include/linux/videodev2.h |   20 
  include/media/v4l2-ioctl.h|2 ++
  4 files changed, 34 insertions(+), 0 deletions(-)

 diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
 b/drivers/media/video/v4l2-compat-ioctl32.c index e6f67aa..fd157cb 100644
 --- a/drivers/media/video/v4l2-compat-ioctl32.c
 +++ b/drivers/media/video/v4l2-compat-ioctl32.c
 @@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
 cmd, unsigned long arg) case VIDIOC_S_FBUF32:
  case VIDIOC_OVERLAY32:
  case VIDIOC_QBUF32:
 +case VIDIOC_EXPBUF:
  case VIDIOC_DQBUF32:
  case VIDIOC_STREAMON32:
  case VIDIOC_STREAMOFF32:
 diff --git a/drivers/media/video/v4l2-ioctl.c
 b/drivers/media/video/v4l2-ioctl.c index 74cab51..a125016 100644
 --- a/drivers/media/video/v4l2-ioctl.c
 +++ b/drivers/media/video/v4l2-ioctl.c
 @@ -207,6 +207,7 @@ static const char *v4l2_ioctls[] = {
  [_IOC_NR(VIDIOC_S_FBUF)]   = VIDIOC_S_FBUF,
  [_IOC_NR(VIDIOC_OVERLAY)]  = VIDIOC_OVERLAY,
  [_IOC_NR(VIDIOC_QBUF)] = VIDIOC_QBUF,
 +[_IOC_NR(VIDIOC_EXPBUF)]   = VIDIOC_EXPBUF,
  [_IOC_NR(VIDIOC_DQBUF)]= VIDIOC_DQBUF,
  [_IOC_NR(VIDIOC_STREAMON)] = VIDIOC_STREAMON,
  [_IOC_NR(VIDIOC_STREAMOFF)]= VIDIOC_STREAMOFF,
 @@ -938,6 +939,16 @@ static long __video_do_ioctl(struct file *file,
  dbgbuf(cmd, vfd, p);
  break;
  }
 +case VIDIOC_EXPBUF:
 +{
 +struct v4l2_exportbuffer *p = arg;
 +
 +if (!ops-vidioc_expbuf)
 +break;
 +
 +ret = ops-vidioc_expbuf(file, fh, p);
 
 You can pass arg to ops-vidioc_expbuf() directly, there's no need to create 
 a 
 struct v4l2_exportbuffer *p variable.
 

No problem. I tried to follow style of other ioctls.
Notice that adding this temporary variable provides some
form of type checking. I mean using a proper structure for
a proper callback.

 +break;
 +}
  case VIDIOC_DQBUF:
  {
  struct v4l2_buffer *p = arg;
 diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
 index bb6844e..e71c787 100644
 --- a/include/linux/videodev2.h
 +++ b/include/linux/videodev2.h
 @@ -680,6 +680,25 @@ struct v4l2_buffer {
  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE   0x0800
  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN0x1000

 +/**
 + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
 descriptor
 + *
 + * @fd: file descriptor associated with DMABUF (set by driver)
 + * @mem_offset: for non-multiplanar buffers with memory ==
 V4L2_MEMORY_MMAP;
 
 I don't think we will ever support exporting anything else than 
 V4L2_MEMORY_MMAP buffers. What will happen for multiplanar buffers ?
 

Every plane is described by its separate mem-offset. So planes are
exported as separate DMABUF. I will update field description.

 + *  offset from the start of the device memory for this plane,
 + *  (or a cookie that should be passed to mmap() as offset)
 + *
 
 Shouldn't the mem_offset field always be set to the mmap cookie value ? I'm a 
 bit confused by the or part, it seems to have been copied from the 
 v4l2_buffer documentation directly. We should clarify that.
 

Ok. I agree.

 + * Contains data used for exporting a video buffer as DMABUF file
 + * descriptor. Uses the same 'cookie' as mmap() syscall. All reserved
 fields
 + * must be set to zero.
 + */
 +struct v4l2_exportbuffer {
 +__u32   fd;
 +__u32   reserved0;
 
 Why is there a reserved field here ?
 

I expected that struct v4l2_requestbuffer might allow exporting buffers 
described
by something else than 'mmap cookie'. Union could be used for different schemes 
i.e.

struct v4l2_exportbuffer {
__u32   fd;
__u32   type;
union {
__u32   mem_offset;
__u32   reserved[14];
/* other descriptions */
} m;
};

Adding reserved0 field will 

Re: [RFCv2 PATCH 5/9] v4l: vb2: add buffer exporting via dmabuf

[Tomasz Stanislawski]

Hi Laurent,
Thank you for you comments.

On 03/22/2012 12:24 PM, Laurent Pinchart wrote:
 Hi Tomasz,
 
 Thanks for the patch.
 
 On Tuesday 13 March 2012 11:17:03 Tomasz Stanislawski wrote:
 This patch adds extension to videobuf2-core. It allow to export a mmap
 buffer as a file descriptor.

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/video/videobuf2-core.c |   64
 ++ include/media/videobuf2-core.h   |  
  2 +
  2 files changed, 66 insertions(+), 0 deletions(-)

 diff --git a/drivers/media/video/videobuf2-core.c
 b/drivers/media/video/videobuf2-core.c index e7df560..41c4bf8 100644
 --- a/drivers/media/video/videobuf2-core.c
 +++ b/drivers/media/video/videobuf2-core.c
 @@ -1553,6 +1553,70 @@ int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer
 *b, bool nonblocking) }
  EXPORT_SYMBOL_GPL(vb2_dqbuf);

 +static int __find_plane_by_offset(struct vb2_queue *q, unsigned long off,
 +unsigned int *_buffer, unsigned int *_plane);
 +
 
 Could you please move __find_plane_by_offset() up or move vb2_expbuf() down 
 to 
 avoid the forward declaration ? The later might make more sense, you could 
 declare vb2_expbuf() right after vb2_mmap() (here and in videobuf2-core.h), 
 both functions perform similar tasks.
 

Ok. I will move it.

I used the forward declaration to have only-plus patch while keeping all
vb2_*buf functions together.

Regards,
Tomasz Stanislawski

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

[Bug 47765] New: Corrupt rendering to a window between 57 and 63 pixels high

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=47765

 Bug #: 47765
   Summary: Corrupt rendering to a window between 57 and 63 pixels
high
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: tvrtko.ursu...@onelan.co.uk


We are seeing render corruption when rendering a texture to a window between 57
and 63 pixels high. glViewport being set to window dimensions.

Texture vertices do not seem to matter. If I render to the full viewport, or to
a subset of a viewport, always the whole viewport gets corrupt (so including
the area outside texture vertices).

Texture size does not seem to matter.

Rendering is done with glDrawArray GL_TRIANGLE_FAN and the destination window
is RGBA.

Environment:

00:01.0 VGA compatible controller: ATI Technologies Inc AMD Radeon HD 6310
GraphicsATI

Kernel 3.3.0 + 0001-drm-radeon-add-support-for-evergreen-ni-tiling-infor.patch

It does not happen without this patch - so it is probably tiling related.

xorg-drivers-ati, mesa and libdrm from yesterday's git. Last one is in fact a
bit older, but I applied a single interesting patch
(9b3ad51ae5fd9654df8ef75de845a519015150bb) by hand to make it up to date.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add locking to resume_force_mode to prevent multiple

[Sean Paul]

On Thu, Mar 22, 2012 at 6:57 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Thu, 22 Mar 2012 18:25:55 -0400, Sean Paul seanp...@chromium.org wrote:
 Add a mutex to protect resume_force_mode from being called multiple
 times. This fixes a bug observed on SNB where two wake sources call
 resume_force_mode and the FDI training fails as a result. The user
 facing result of this is complete screen corruption.

 Looks like a bug in i915_drv.c for calling that function without holding
 the mode_config.lock

Good catch, thanks for the feedback Chris.

I'll submit a new patch to intel-gfx, please drop this one.

Sean


 -Chris

 --
 Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Add lock on drm_helper_resume_force_mode

[Sean Paul]

i915_drm_thaw was not locking the mode_config lock when calling
drm_helper_resume_force_mode. When there were multiple wake sources,
this caused FDI training failure on SNB which in turn corrupted the
display.

Signed-off-by: Sean Paul seanp...@chromium.org
---
 drivers/gpu/drm/i915/i915_drv.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8e2c52e..1c554fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -535,7 +535,9 @@ static int i915_drm_thaw(struct drm_device *dev)
drm_irq_install(dev);
 
/* Resume the modeset for every activated CRTC */
+   mutex_lock(dev-mode_config.mutex);
drm_helper_resume_force_mode(dev);
+   mutex_unlock(dev-mode_config.mutex);
 
if (IS_IRONLAKE_M(dev))
ironlake_enable_rc6(dev);
-- 
1.7.7.3

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

Re: [PATCH] drm/i915: Add lock on drm_helper_resume_force_mode

[Chris Wilson]

On Fri, 23 Mar 2012 08:52:58 -0400, Sean Paul seanp...@chromium.org wrote:
 i915_drm_thaw was not locking the mode_config lock when calling
 drm_helper_resume_force_mode. When there were multiple wake sources,
 this caused FDI training failure on SNB which in turn corrupted the
 display.
 
 Signed-off-by: Sean Paul seanp...@chromium.org
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta...@kernel.org
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 47765] Corrupt rendering to a window between 57 and 63 pixels high

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=47765

--- Comment #1 from Jerome Glisse gli...@freedesktop.org 2012-03-23 07:49:55 
PDT ---
Does any of the mesa demo reproduce the bug ?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeon + DVI-mDP converter + mDP display blank screen issue since 3.0

[Alex Deucher]

On Thu, Mar 22, 2012 at 8:49 AM, Lennert Buytenhek
buyt...@wantstofly.org wrote:
 Hi!

 Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
 to a 27 Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
 to Mini DisplayPort converter has started to stop giving screen
 output on switching from text mode to graphical framebuffer during
 system startup.

 I finally had some time to look at this, and it seems to have stopped
 working after this commit:

        commit df271bec805b42527d864777ed035fcbb42e76c0
        Author: Alex Deucher alexdeuc...@gmail.com
        Date:   Fri May 20 04:34:15 2011 -0400

            drm/radeon/kms: properly handle bpc 8 in atom command tables

            Signed-off-by: Alex Deucher alexdeuc...@gmail.com
            Signed-off-by: Dave Airlie airl...@redhat.com

 ...and with the patch below (i.e. reverting part of the commit above)
 applied to 3.3 I get screen output again.

 Even though the monitor seems to have an 8 bit panel, it reports 10
 bits per channel in its EDID:

        [...]
        Manufacturer: APP Model 9226 Serial Number 41959462
        Made week 38 of 2010
        EDID version: 1.4
        Digital display
        10 bits per primary color channel
        DisplayPort interface
        Maximum image size: 60 cm x 34 cm
        [...]

 The (active, dual link) DVI-mDP converter spec sheet says it supports
 24 bit color, and I'm guessing that it can't deal with 30.  Is the
 converter at fault here for passing through the EDID unchanged?

 Also, what would be the right way to handle this, a kernel command
 line or module option to limit color depth or something like that?
 (Buy a video card with DP output. is a valid answer, I suppose.)

 I have no clue at all about graphics, and I have no idea whatsoever
 what I'm doing here, but I just wanted to post this somewhere for
 Google to find in case someone else runs into this!

I've inquired with out display team on how to best handle this.  In
the meantime, it's probably best to just default to 8 bpc.  Does the
attached patch fix your issue?

Alex



 thanks,
 Lennert



 diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
 b/drivers/gpu/drm/radeon/atombios_crtc.c
 index 742f17f..77a6a04 100644
 --- a/drivers/gpu/drm/radeon/atombios_crtc.c
 +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
 @@ -513,11 +513,9 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        struct radeon_device *rdev = dev-dev_private;
        struct drm_encoder *encoder = NULL;
        struct radeon_encoder *radeon_encoder = NULL;
 -       struct drm_connector *connector = NULL;
        u32 adjusted_clock = mode-clock;
        int encoder_mode = 0;
        u32 dp_clock = mode-clock;
 -       int bpc = 8;
        bool is_duallink = false;

        /* reset the pll flags */
 @@ -549,13 +547,11 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        list_for_each_entry(encoder, dev-mode_config.encoder_list, head) {
                if (encoder-crtc == crtc) {
                        radeon_encoder = to_radeon_encoder(encoder);
 -                       connector = radeon_get_connector_for_encoder(encoder);
 -                       if (connector  connector-display_info.bpc)
 -                               bpc = connector-display_info.bpc;
                        encoder_mode = atombios_get_encoder_mode(encoder);
                        is_duallink = radeon_dig_monitor_is_duallink(encoder, 
 mode-clock);
                        if ((radeon_encoder-devices  
 (ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) ||
                            (radeon_encoder_get_dp_bridge_encoder_id(encoder) 
 != ENCODER_OBJECT_ID_NONE)) {
 +                               struct drm_connector *connector = 
 radeon_get_connector_for_encoder(encoder);
                                if (connector) {
                                        struct radeon_connector 
 *radeon_connector = to_radeon_connector(connector);
                                        struct radeon_connector_atom_dig 
 *dig_connector =
 @@ -645,7 +641,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
                                        if (encoder_mode == 
 ATOM_ENCODER_MODE_HDMI)
                                                /* deep color support */
                                                args.v3.sInput.usPixelClock =
 -                                                       
 cpu_to_le16((mode-clock * bpc / 8) / 10);
 +                                                       
 cpu_to_le16(mode-clock / 10);
                                        if (dig-coherent_mode)
                                                args.v3.sInput.ucDispPllConfig 
 |=
                                                        
 DISPPLL_CONFIG_COHERENT_MODE;
 @@ -753,7 +749,6 @@ static void atombios_crtc_program_pll(struct drm_crtc 
 *crtc,
                                      u32 fb_div,
                                      u32 frac_fb_div,
                

[Bug 47765] Corrupt rendering to a window between 57 and 63 pixels high

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=47765

--- Comment #2 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-23 
08:22:20 PDT ---
(In reply to comment #1)
 Does any of the mesa demo reproduce the bug ?

/usr/lib64/mesa/tri shows it if you resize the window right.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 47765] Corrupt rendering to a window between 57 and 63 pixels high

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=47765

--- Comment #3 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-23 
08:28:01 PDT ---
Created attachment 58939
  -- https://bugs.freedesktop.org/attachment.cgi?id=58939
Screenshot showing corrupted mesa-demos/tri rendering

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dma-buf: Correct dummy function declarations.

[Sumit Semwal]

While testing, I found that we need to correct some of the dummy declarations. 
When I send my pull request to Linus, I wish to squash these changes into the 
original patches from Daniel. Could you please review?

Best regards,
~Sumit

=

Dummy functions for the newly added cpu access ops are needed for compilation
when dma-buf framework is not compiled-in.

Also, the introduction of flags in dma_buf_fd  needs to be added to dummy
functions as well.

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
 include/linux/dma-buf.h |   26 +-
 1 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index f08028e..779aaf9 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -189,7 +189,7 @@ static inline struct dma_buf *dma_buf_export(void *priv,
return ERR_PTR(-ENODEV);
 }
 
-static inline int dma_buf_fd(struct dma_buf *dmabuf)
+static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
 {
return -ENODEV;
 }
@@ -216,36 +216,36 @@ static inline void dma_buf_unmap_attachment(struct 
dma_buf_attachment *attach,
return;
 }
 
-static inline int dma_buf_begin_cpu_access(struct dma_buf *,
-  size_t, size_t,
-  enum dma_data_direction)
+static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
+  size_t start, size_t len,
+  enum dma_data_direction dir)
 {
return -ENODEV;
 }
 
-static inline void dma_buf_end_cpu_access(struct dma_buf *,
- size_t, size_t,
- enum dma_data_direction)
+static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
+ size_t start, size_t len,
+ enum dma_data_direction dir)
 {
 }
 
-static inline void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long)
+static inline void *dma_buf_kmap_atomic(struct dma_buf *db, unsigned long pnum)
 {
return NULL;
 }
 
-static inline void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long,
-void *)
+static inline void dma_buf_kunmap_atomic(struct dma_buf *db, unsigned long 
pnum,
+void *vaddr)
 {
 }
 
-static inline void *dma_buf_kmap(struct dma_buf *, unsigned long)
+static inline void *dma_buf_kmap(struct dma_buf *db, unsigned long pnum)
 {
return NULL;
 }
 
-static inline void dma_buf_kunmap(struct dma_buf *, unsigned long,
- void *)
+static inline void dma_buf_kunmap(struct dma_buf *db, unsigned long pnum,
+ void *vaddr)
 {
 }
 #endif /* CONFIG_DMA_SHARED_BUFFER */
-- 
1.7.5.4

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

Re: [PATCH v2] drm/i915: Run DDC buses at 50 kbps

[Jean Delvare]

On Thursday 22 March 2012 09:50:23 pm Daniel Vetter wrote:
 On Wed, Mar 21, 2012 at 02:29:47PM +0100, Jean Delvare wrote:
  A udelay value of 20 leads to an I2C bus running at only 25 kbps.
  I2C devices can typically operate faster than this, 50 kbps should
  be fine for all devices (and compliant devices can always stretch
  the clock if needed.)
 
  FWIW, the vast majority of framebuffer drivers set udelay to 10
  already. So set it to 10 in DRM drivers too, this will make EDID
  block reads faster. We might even lower the udelay value later if
  no problem is reported.
 
  Signed-off-by: Jean Delvare jdelv...@suse.de
  Acked-by: Eugeni Dodonov eugeni.dodo...@intel.com
  Cc: Dave Airlie airl...@gmail.com
  Cc: Keith Packard kei...@keithp.com
 
 Fyi this already got merged int Dave's tree (the unsplit version) as:
 
 commit 1849ecb22fb3b5d57b65e7369a3957adf9f26f39
 Author: Jean Delvare jdelv...@suse.de
 Date:   Sat Jan 28 11:07:09 2012 +0100
 
 drm/kms: Make i2c buses faster

Thanks Daniel, I just noticed this as it got merged into Linus tree last 
night. I had not received any ack from Dave and the git repository 
mentioned in MAINTAINERS is wrong so I couldn't check whether my patches 
were already applied or not.

Anyway, the important thing is that they are in Linus' tree now.

-- 
Jean Delvare
Suse L3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeon + DVI-mDP converter + mDP display blank screen issue since 3.0

[Lennert Buytenhek]

On Fri, Mar 23, 2012 at 10:59:27AM -0400, Alex Deucher wrote:

  Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
  to a 27 Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
  to Mini DisplayPort converter has started to stop giving screen
  output on switching from text mode to graphical framebuffer during
  system startup.
 
  I finally had some time to look at this, and it seems to have stopped
  working after this commit:
 
         commit df271bec805b42527d864777ed035fcbb42e76c0
         Author: Alex Deucher alexdeuc...@gmail.com
         Date:   Fri May 20 04:34:15 2011 -0400
 
             drm/radeon/kms: properly handle bpc 8 in atom command tables
 
             Signed-off-by: Alex Deucher alexdeuc...@gmail.com
             Signed-off-by: Dave Airlie airl...@redhat.com
 
  ...and with the patch below (i.e. reverting part of the commit above)
  applied to 3.3 I get screen output again.
 
  Even though the monitor seems to have an 8 bit panel, it reports 10
  bits per channel in its EDID:
 
         [...]
         Manufacturer: APP Model 9226 Serial Number 41959462
         Made week 38 of 2010
         EDID version: 1.4
         Digital display
         10 bits per primary color channel
         DisplayPort interface
         Maximum image size: 60 cm x 34 cm
         [...]
 
  The (active, dual link) DVI-mDP converter spec sheet says it supports
  24 bit color, and I'm guessing that it can't deal with 30.  Is the
  converter at fault here for passing through the EDID unchanged?
 
  Also, what would be the right way to handle this, a kernel command
  line or module option to limit color depth or something like that?
  (Buy a video card with DP output. is a valid answer, I suppose.)
 
  I have no clue at all about graphics, and I have no idea whatsoever
  what I'm doing here, but I just wanted to post this somewhere for
  Google to find in case someone else runs into this!
 
 I've inquired with out display team on how to best handle this.  In
 the meantime, it's probably best to just default to 8 bpc.  Does the
 attached patch fix your issue?

I've been using the patch below in a custom Fedora 17 kernel RPM, and
that seems to fix the issue.  Your patch seems to be a superset of
this patch, so logically, your patch should do the trick as well. :)


thanks,
Lennert


diff -up linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig 
linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
--- linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig   
2012-03-22 14:52:20.538854547 +0100
+++ linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
2012-03-22 14:55:39.740794113 +0100
@@ -550,8 +550,6 @@ static u32 atombios_adjust_pll(struct dr
if (encoder-crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
-   if (connector  connector-display_info.bpc)
-   bpc = connector-display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder, 
mode-clock);
if ((radeon_encoder-devices  (ATOM_DEVICE_LCD_SUPPORT 
| ATOM_DEVICE_DFP_SUPPORT)) ||
@@ -922,7 +920,6 @@ static void atombios_crtc_set_pll(struct
struct radeon_connector_atom_dig *dig_connector =
radeon_connector-con_priv;
int dp_clock;
-   bpc = connector-display_info.bpc;
 
switch (encoder_mode) {
case ATOM_ENCODER_MODE_DP_MST:



 From 22ca454eb749968f266d6788a5f4778acc08cc66 Mon Sep 17 00:00:00 2001
 From: Alex Deucher alexander.deuc...@amd.com
 Date: Fri, 23 Mar 2012 10:54:45 -0400
 Subject: [PATCH] drm/radeon/kms/atom: force bpc to 8 for now
 
 Using the bpc (bits per color) specified by the monitor
 can cause problems in some cases.  Until we get a better
 handle on how to deal with those cases, just use a bpc of 8.
 
 Reported-by: Lennert Buytenhek buyt...@wantstofly.org
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 Cc: sta...@kernel.org
 ---
  drivers/gpu/drm/radeon/atombios_crtc.c |8 +---
  drivers/gpu/drm/radeon/atombios_dp.c   |3 +++
  drivers/gpu/drm/radeon/atombios_encoders.c |4 ++--
  3 files changed, 10 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
 b/drivers/gpu/drm/radeon/atombios_crtc.c
 index 083b3ea..b5ff1f7 100644
 --- a/drivers/gpu/drm/radeon/atombios_crtc.c
 +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
 @@ -588,8 +588,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
   if (encoder-crtc == crtc) {
   radeon_encoder = to_radeon_encoder(encoder);
   connector = radeon_get_connector_for_encoder(encoder);
 -  

[Bug 36421] RV710: GPU lockup running portal2 in wine.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36421

--- Comment #8 from Vladimir Ysikov granti...@gmail.com 2012-03-23 10:15:54 
PDT ---
I have not tested it for a long time and I can't say when the error is gone.
mesa-8.0  mesa-git no error on ArchLinux x86, Radeon HD 4850. Tested Portal,
HL2 (Episode One/Two), Team Fortress 2, Left 4 Dead 2.

Can this be closed?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46713] HDMI audio played back at a wrong rate

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #20 from Vincenzov vincenzo...@hotmail.com 2012-03-23 10:36:52 
PDT ---
Hi, i have same problem hdmi audio slow. Radeon 5450.
But dual screen hdmi+crt 1920 x 1080 audio works fine.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: Correct dummy function declarations.

[Daniel Vetter]

On Fri, Mar 23, 2012 at 09:19:17PM +0530, Sumit Semwal wrote:
 While testing, I found that we need to correct some of the dummy 
 declarations. When I send my pull request to Linus, I wish to squash these 
 changes into the original patches from Daniel. Could you please review?
 
 Best regards,
 ~Sumit
 
 =
 
 Dummy functions for the newly added cpu access ops are needed for compilation
 when dma-buf framework is not compiled-in.
 
 Also, the introduction of flags in dma_buf_fd  needs to be added to dummy
 functions as well.
 
 Signed-off-by: Sumit Semwal sumit.sem...@linaro.org

Sorry for fumbling the compile-testing for the !DMA_BUF case here.

Acked-by: Daniel Vetter daniel.vet...@ffwll.ch

Cheers, Daniel

 ---
  include/linux/dma-buf.h |   26 +-
  1 files changed, 13 insertions(+), 13 deletions(-)
 
 diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
 index f08028e..779aaf9 100644
 --- a/include/linux/dma-buf.h
 +++ b/include/linux/dma-buf.h
 @@ -189,7 +189,7 @@ static inline struct dma_buf *dma_buf_export(void *priv,
   return ERR_PTR(-ENODEV);
  }
  
 -static inline int dma_buf_fd(struct dma_buf *dmabuf)
 +static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
  {
   return -ENODEV;
  }
 @@ -216,36 +216,36 @@ static inline void dma_buf_unmap_attachment(struct 
 dma_buf_attachment *attach,
   return;
  }
  
 -static inline int dma_buf_begin_cpu_access(struct dma_buf *,
 -size_t, size_t,
 -enum dma_data_direction)
 +static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
 +size_t start, size_t len,
 +enum dma_data_direction dir)
  {
   return -ENODEV;
  }
  
 -static inline void dma_buf_end_cpu_access(struct dma_buf *,
 -   size_t, size_t,
 -   enum dma_data_direction)
 +static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
 +   size_t start, size_t len,
 +   enum dma_data_direction dir)
  {
  }
  
 -static inline void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long)
 +static inline void *dma_buf_kmap_atomic(struct dma_buf *db, unsigned long 
 pnum)
  {
   return NULL;
  }
  
 -static inline void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long,
 -  void *)
 +static inline void dma_buf_kunmap_atomic(struct dma_buf *db, unsigned long 
 pnum,
 +  void *vaddr)
  {
  }
  
 -static inline void *dma_buf_kmap(struct dma_buf *, unsigned long)
 +static inline void *dma_buf_kmap(struct dma_buf *db, unsigned long pnum)
  {
   return NULL;
  }
  
 -static inline void dma_buf_kunmap(struct dma_buf *, unsigned long,
 -   void *)
 +static inline void dma_buf_kunmap(struct dma_buf *db, unsigned long pnum,
 +   void *vaddr)
  {
  }
  #endif /* CONFIG_DMA_SHARED_BUFFER */
 -- 
 1.7.5.4
 

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46713] HDMI audio played back at a wrong rate

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #21 from Vincenzov vincenzo...@hotmail.com 2012-03-23 11:00:19 
PDT ---
ok
1280x720 radeon 5450 works

avivotool regset 0x05b0 0x00138800

works good

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46713] HDMI audio played back at a wrong rate

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #22 from Vincenzov vincenzo...@hotmail.com 2012-03-23 11:24:09 
PDT ---
vincenzo@AthlonII-260:~$ sudo avivotool regset 0x05b0 0x00138800
OLD: 0x05b0 (05b0)  0x00075300 (48)
NEW: 0x05b0 (05b0)  0x00138800 (128)

work only 1280x720

slow with 1920 x 1080

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36421] RV710: GPU lockup running portal2 in wine.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36421

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Alex Deucher ag...@yahoo.com 2012-03-23 11:26:33 PDT ---
Please reopen if this is still an issue.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms/atom: force bpc to 8 for now

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Using the bpc (bits per color) specified by the monitor
can cause problems in some cases.  Until we get a better
handle on how to deal with those cases, just use a bpc of 8.

Reported-by: Lennert Buytenhek buyt...@wantstofly.org
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@kernel.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c |8 +---
 drivers/gpu/drm/radeon/atombios_dp.c   |3 +++
 drivers/gpu/drm/radeon/atombios_encoders.c |4 ++--
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 083b3ea..b5ff1f7 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -588,8 +588,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder-crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
-   if (connector  connector-display_info.bpc)
-   bpc = connector-display_info.bpc;
+   /* if (connector  connector-display_info.bpc)
+   bpc = connector-display_info.bpc; */
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder, 
mode-clock);
if ((radeon_encoder-devices  (ATOM_DEVICE_LCD_SUPPORT 
| ATOM_DEVICE_DFP_SUPPORT)) ||
@@ -965,7 +965,9 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
struct radeon_connector_atom_dig *dig_connector =
radeon_connector-con_priv;
int dp_clock;
-   bpc = connector-display_info.bpc;
+
+   /* if (connector-display_info.bpc)
+   bpc = connector-display_info.bpc; */
 
switch (encoder_mode) {
case ATOM_ENCODER_MODE_DP_MST:
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 6c62be2..c57d856 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -405,10 +405,13 @@ static void dp_get_adjust_train(u8 
link_status[DP_LINK_STATUS_SIZE],
 /* get bpc from the EDID */
 static int convert_bpc_to_bpp(int bpc)
 {
+#if 0
if (bpc == 0)
return 24;
else
return bpc * 3;
+#endif
+   return 24;
 }
 
 /* get the max pix clock supported by the link rate and lane num */
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 468b874..e607c4d 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -541,7 +541,7 @@ atombios_dig_encoder_setup(struct drm_encoder *encoder, int 
action, int panel_mo
dp_clock = dig_connector-dp_clock;
dp_lane_count = dig_connector-dp_lane_count;
hpd_id = radeon_connector-hpd.hpd;
-   bpc = connector-display_info.bpc;
+   /* bpc = connector-display_info.bpc; */
}
 
/* no dig encoder assigned */
@@ -1159,7 +1159,7 @@ atombios_external_encoder_setup(struct drm_encoder 
*encoder,
dp_lane_count = dig_connector-dp_lane_count;
connector_object_id =
(radeon_connector-connector_object_id  
OBJECT_ID_MASK)  OBJECT_ID_SHIFT;
-   bpc = connector-display_info.bpc;
+   /* bpc = connector-display_info.bpc; */
}
 
memset(args, 0, sizeof(args));
-- 
1.7.7.5

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

[Bug 46713] HDMI audio played back at a wrong rate

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #23 from Vincenzov vincenzo...@hotmail.com 2012-03-23 11:50:50 
PDT ---
sudo avivotool regset 0x05b0 0x00271000


works good whit 1920 x 1080

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeon + DVI-mDP converter + mDP display blank screen issue since 3.0

[Alex Deucher]

On Fri, Mar 23, 2012 at 11:44 AM, Lennert Buytenhek
buyt...@wantstofly.org wrote:
 On Fri, Mar 23, 2012 at 10:59:27AM -0400, Alex Deucher wrote:

  Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
  to a 27 Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
  to Mini DisplayPort converter has started to stop giving screen
  output on switching from text mode to graphical framebuffer during
  system startup.
 
  I finally had some time to look at this, and it seems to have stopped
  working after this commit:
 
         commit df271bec805b42527d864777ed035fcbb42e76c0
         Author: Alex Deucher alexdeuc...@gmail.com
         Date:   Fri May 20 04:34:15 2011 -0400
 
             drm/radeon/kms: properly handle bpc 8 in atom command tables
 
             Signed-off-by: Alex Deucher alexdeuc...@gmail.com
             Signed-off-by: Dave Airlie airl...@redhat.com
 
  ...and with the patch below (i.e. reverting part of the commit above)
  applied to 3.3 I get screen output again.
 
  Even though the monitor seems to have an 8 bit panel, it reports 10
  bits per channel in its EDID:
 
         [...]
         Manufacturer: APP Model 9226 Serial Number 41959462
         Made week 38 of 2010
         EDID version: 1.4
         Digital display
         10 bits per primary color channel
         DisplayPort interface
         Maximum image size: 60 cm x 34 cm
         [...]
 
  The (active, dual link) DVI-mDP converter spec sheet says it supports
  24 bit color, and I'm guessing that it can't deal with 30.  Is the
  converter at fault here for passing through the EDID unchanged?
 
  Also, what would be the right way to handle this, a kernel command
  line or module option to limit color depth or something like that?
  (Buy a video card with DP output. is a valid answer, I suppose.)
 
  I have no clue at all about graphics, and I have no idea whatsoever
  what I'm doing here, but I just wanted to post this somewhere for
  Google to find in case someone else runs into this!

 I've inquired with out display team on how to best handle this.  In
 the meantime, it's probably best to just default to 8 bpc.  Does the
 attached patch fix your issue?

 I've been using the patch below in a custom Fedora 17 kernel RPM, and
 that seems to fix the issue.  Your patch seems to be a superset of
 this patch, so logically, your patch should do the trick as well. :)

Can you try the attached patch on top of my previous one?

Alex



 thanks,
 Lennert


 diff -up 
 linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig 
 linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
 --- linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig     
   2012-03-22 14:52:20.538854547 +0100
 +++ linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c    
 2012-03-22 14:55:39.740794113 +0100
 @@ -550,8 +550,6 @@ static u32 atombios_adjust_pll(struct dr
                if (encoder-crtc == crtc) {
                        radeon_encoder = to_radeon_encoder(encoder);
                        connector = radeon_get_connector_for_encoder(encoder);
 -                       if (connector  connector-display_info.bpc)
 -                               bpc = connector-display_info.bpc;
                        encoder_mode = atombios_get_encoder_mode(encoder);
                        is_duallink = radeon_dig_monitor_is_duallink(encoder, 
 mode-clock);
                        if ((radeon_encoder-devices  
 (ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) ||
 @@ -922,7 +920,6 @@ static void atombios_crtc_set_pll(struct
                struct radeon_connector_atom_dig *dig_connector =
                        radeon_connector-con_priv;
                int dp_clock;
 -               bpc = connector-display_info.bpc;

                switch (encoder_mode) {
                case ATOM_ENCODER_MODE_DP_MST:



 From 22ca454eb749968f266d6788a5f4778acc08cc66 Mon Sep 17 00:00:00 2001
 From: Alex Deucher alexander.deuc...@amd.com
 Date: Fri, 23 Mar 2012 10:54:45 -0400
 Subject: [PATCH] drm/radeon/kms/atom: force bpc to 8 for now

 Using the bpc (bits per color) specified by the monitor
 can cause problems in some cases.  Until we get a better
 handle on how to deal with those cases, just use a bpc of 8.

 Reported-by: Lennert Buytenhek buyt...@wantstofly.org
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 Cc: sta...@kernel.org
 ---
  drivers/gpu/drm/radeon/atombios_crtc.c     |    8 +---
  drivers/gpu/drm/radeon/atombios_dp.c       |    3 +++
  drivers/gpu/drm/radeon/atombios_encoders.c |    4 ++--
  3 files changed, 10 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
 b/drivers/gpu/drm/radeon/atombios_crtc.c
 index 083b3ea..b5ff1f7 100644
 --- a/drivers/gpu/drm/radeon/atombios_crtc.c
 +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
 @@ -588,8 +588,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
               if (encoder-crtc == crtc) {
  

Re: radeon + DVI-mDP converter + mDP display blank screen issue since 3.0

[Alex Deucher]

On Fri, Mar 23, 2012 at 3:34 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Fri, Mar 23, 2012 at 11:44 AM, Lennert Buytenhek
 buyt...@wantstofly.org wrote:
 On Fri, Mar 23, 2012 at 10:59:27AM -0400, Alex Deucher wrote:

  Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
  to a 27 Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
  to Mini DisplayPort converter has started to stop giving screen
  output on switching from text mode to graphical framebuffer during
  system startup.
 
  I finally had some time to look at this, and it seems to have stopped
  working after this commit:
 
         commit df271bec805b42527d864777ed035fcbb42e76c0
         Author: Alex Deucher alexdeuc...@gmail.com
         Date:   Fri May 20 04:34:15 2011 -0400
 
             drm/radeon/kms: properly handle bpc 8 in atom command tables
 
             Signed-off-by: Alex Deucher alexdeuc...@gmail.com
             Signed-off-by: Dave Airlie airl...@redhat.com
 
  ...and with the patch below (i.e. reverting part of the commit above)
  applied to 3.3 I get screen output again.
 
  Even though the monitor seems to have an 8 bit panel, it reports 10
  bits per channel in its EDID:
 
         [...]
         Manufacturer: APP Model 9226 Serial Number 41959462
         Made week 38 of 2010
         EDID version: 1.4
         Digital display
         10 bits per primary color channel
         DisplayPort interface
         Maximum image size: 60 cm x 34 cm
         [...]
 
  The (active, dual link) DVI-mDP converter spec sheet says it supports
  24 bit color, and I'm guessing that it can't deal with 30.  Is the
  converter at fault here for passing through the EDID unchanged?
 
  Also, what would be the right way to handle this, a kernel command
  line or module option to limit color depth or something like that?
  (Buy a video card with DP output. is a valid answer, I suppose.)
 
  I have no clue at all about graphics, and I have no idea whatsoever
  what I'm doing here, but I just wanted to post this somewhere for
  Google to find in case someone else runs into this!

 I've inquired with out display team on how to best handle this.  In
 the meantime, it's probably best to just default to 8 bpc.  Does the
 attached patch fix your issue?

 I've been using the patch below in a custom Fedora 17 kernel RPM, and
 that seems to fix the issue.  Your patch seems to be a superset of
 this patch, so logically, your patch should do the trick as well. :)

 Can you try the attached patch on top of my previous one?

Scratch that.  Try this one instead.

Alex


 Alex



 thanks,
 Lennert


 diff -up 
 linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig 
 linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
 --- linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig    
    2012-03-22 14:52:20.538854547 +0100
 +++ linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c    
 2012-03-22 14:55:39.740794113 +0100
 @@ -550,8 +550,6 @@ static u32 atombios_adjust_pll(struct dr
                if (encoder-crtc == crtc) {
                        radeon_encoder = to_radeon_encoder(encoder);
                        connector = radeon_get_connector_for_encoder(encoder);
 -                       if (connector  connector-display_info.bpc)
 -                               bpc = connector-display_info.bpc;
                        encoder_mode = atombios_get_encoder_mode(encoder);
                        is_duallink = radeon_dig_monitor_is_duallink(encoder, 
 mode-clock);
                        if ((radeon_encoder-devices  
 (ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) ||
 @@ -922,7 +920,6 @@ static void atombios_crtc_set_pll(struct
                struct radeon_connector_atom_dig *dig_connector =
                        radeon_connector-con_priv;
                int dp_clock;
 -               bpc = connector-display_info.bpc;

                switch (encoder_mode) {
                case ATOM_ENCODER_MODE_DP_MST:



 From 22ca454eb749968f266d6788a5f4778acc08cc66 Mon Sep 17 00:00:00 2001
 From: Alex Deucher alexander.deuc...@amd.com
 Date: Fri, 23 Mar 2012 10:54:45 -0400
 Subject: [PATCH] drm/radeon/kms/atom: force bpc to 8 for now

 Using the bpc (bits per color) specified by the monitor
 can cause problems in some cases.  Until we get a better
 handle on how to deal with those cases, just use a bpc of 8.

 Reported-by: Lennert Buytenhek buyt...@wantstofly.org
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 Cc: sta...@kernel.org
 ---
  drivers/gpu/drm/radeon/atombios_crtc.c     |    8 +---
  drivers/gpu/drm/radeon/atombios_dp.c       |    3 +++
  drivers/gpu/drm/radeon/atombios_encoders.c |    4 ++--
  3 files changed, 10 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
 b/drivers/gpu/drm/radeon/atombios_crtc.c
 index 083b3ea..b5ff1f7 100644
 --- a/drivers/gpu/drm/radeon/atombios_crtc.c
 +++ 

[Bug 45760] World of warcraft 4.3 slow down after a hour of game

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45760

--- Comment #7 from Pablo silpa...@hotmail.com 2012-03-23 12:48:24 PDT ---
I have a hd 4670, I couldn't see something like that in WOW.
are you using WOTLK?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42983] New: Regression: black screen on VGA w/ nouveau in Linux 3.3

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42983

   Summary: Regression: black screen on VGA w/ nouveau in Linux
3.3
   Product: Drivers
   Version: 2.5
Kernel Version: 3.3
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: maciej.rute...@gmail.com
CC: flor...@mickler.org, r...@sisk.pl,
maciej.rute...@gmail.com
Regression: Yes


Subject: Regression: black screen on VGA w/ nouveau in Linux 3.3
Submitter  : Nick Bowler nbow...@elliptictech.com
Date   : 2012-03-19 14:35
Message-ID : 20120319143548.ga27...@elliptictech.com
References : http://marc.info/?l=linux-kernelm=133216782310186w=2

This entry is being used for tracking a regression from 3.2. Please don't
close it until the problem is fixed in the mainline.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42983] Regression: black screen on VGA w/ nouveau in Linux 3.3

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42983


Maciej Rutecki maciej.rute...@gmail.com changed:

   What|Removed |Added

 Blocks||42644




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45760] World of warcraft 4.3 slow down after a hour of game

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45760

--- Comment #8 from Pablo silpa...@hotmail.com 2012-03-23 12:50:31 PDT ---
Sorry, I forgot the specs in the title, FYI in WOW 3.3.5a this is not happening

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Regression: black screen on VGA w/ nouveau in Linux 3.3

[Maciej Rutecki]

On poniedziałek, 19 marca 2012 o 15:35:48 Nick Bowler wrote:
 Hi folks,
 
 Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output
 on my card w/ nouveau is totally black (both at the console and in X).
 Almost everything appears to work normally: DPMS works, modesetting
 works, DDC works... all messages indicate that things are working --
 just the image is completely black.
 
 The VGA is one of two outputs in use: the other (DVI) output works
 normally.  The card also has an unused TV-out port, FWIW.
 
 The card is an NV36 generation (Geforce FX5700 AGP).  This is a
 regression from Linux 3.2 -- unfortunately, bisection has proved
 extremely difficult because the intermediate kernels git is asking me
 to test panic immediately on boot (and compiling Linux takes a fairly
 long time on this box too).  The failed attempt went like this:
 
   git bisect start 'drivers/gpu'
   # bad: [c16fa4f2ad19908a47c63d8fa436a1178438c7e7] Linux 3.3
   git bisect bad c16fa4f2ad19908a47c63d8fa436a1178438c7e7
   # good: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
   git bisect good 805a6af8dba5dfdd35ec35dc52ec0122400b2610
   # skip: [5d56fe5fd794a98c4f446f8665fd06b82e93ff64] Merge branch
 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6
 into drm-core-next git bisect skip
 5d56fe5fd794a98c4f446f8665fd06b82e93ff64
   # good: [dffc9ceb55695f121adc57dd1fde7304c3afe81e] gma500: kill virtual
 mapping support git bisect good dffc9ceb55695f121adc57dd1fde7304c3afe81e
   # skip: [5c2a5ce689c99037771a6c110374461781a6f042] drm: add missing
 exports for i810 driver. git bisect skip
 5c2a5ce689c99037771a6c110374461781a6f042
   # skip: [44517c44496062180a6376cc704b33129441ce60] drm/radeon/kms: Add an
 MSI quirk for Dell RS690 git bisect skip
 44517c44496062180a6376cc704b33129441ce60
 
   (I stopped at this point)
 
 I'm running the latest git xf86-video-nouveau, but since the issue
 occurs at the console it's probably not too important...
 
 Let me know if you need any more info,

I created a Bugzilla entry at 
https://bugzilla.kernel.org/show_bug.cgi?id=42983
for your bug/regression report, please add your address to the CC list in 
there, thanks!

-- 
Maciej Rutecki
http://www.mrutecki.pl
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel