[git pull] drm fixes

[Dave Airlie]

Hi Linus

mostly radeon, more fixes for dynamic power management which is is off by 
default for this release anyways, but there are a large number of testers, 
so I'd like to keep merging the fixes,

otherwise, radeon UVD fixes affecting suspend/resume regressions, i915 
regression fixes, one for your mac mini, ast,mgag200,cirrus ttm fix and 
one regression fix in the core.

Dave.

The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:

  Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to e42f5814212079aecd5826dba10588a896ac0862:

  Merge tag 'drm-intel-fixes-2013-08-08' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-08-09 
09:09:37 +1000)



Aaron Lu (1):
  drm/i915: avoid brightness overflow when doing scale

Alex Deucher (11):
  drm/radeon: properly handle pm on gpu reset
  drm/radeon: select audio dto based on encoder id for DCE3
  drm/radeon/dpm: adjust thermal protection requirements
  drm/radeon/dpm: fix spread spectrum setup (v2)
  drm/radeon/dpm: adjust power state properly for UVD on SI
  drm/radeon/dpm: disable sclk ss on rv6xx
  drm/radeon: fix audio dto calculation on DCE3+ (v3)
  drm/radeon: always program the MC on startup
  drm/radeon/cik: use a mutex to properly lock srbm instanced registers
  drm/radeon/dpm: require rlc for dpm
  drm/radeon: make missing smc ucode non-fatal

Christian König (5):
  drm/radeon: fix halting UVD
  drm/radeon: only save UVD bo when we have open handles
  drm/radeon: stop sending invalid UVD destroy msg
  drm/radeon: add more UVD CS checking
  drm/radeon: remove unnecessary unpin

Daniel Vetter (1):
  drm/i915: fix gen4 digital port hotplug definitions

Dave Airlie (3):
  drm/ast: invalidate page tables when pinning a BO
  Merge branch 'drm-fixes-3.11' of git://people.freedesktop.org/~agd5f/linux
  Merge tag 'drm-intel-fixes-2013-08-08' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

Egbert Eich (1):
  drm/mgag200: Invalidate page tables when pinning a BO

Jani Nikula (1):
  drm/i915: do not disable backlight on vgaswitcheroo switch off

Michal Srb (1):
  drm/cirrus: Invalidate page tables when pinning a BO

Michel Dänzer (1):
  drm: Don't pass negative delta to ktime_sub_ns()

Paulo Zanoni (1):
  drm/i915: update last_vblank when disabling the power well

Ville Syrjälä (1):
  drm/i915: Don't call encoder's get_config unless encoder is active

 drivers/gpu/drm/ast/ast_ttm.c   |  1 +
 drivers/gpu/drm/cirrus/cirrus_ttm.c |  1 +
 drivers/gpu/drm/drm_irq.c   |  5 +-
 drivers/gpu/drm/i915/i915_reg.h | 12 +++--
 drivers/gpu/drm/i915/intel_display.c|  4 +-
 drivers/gpu/drm/i915/intel_panel.c  | 18 ++-
 drivers/gpu/drm/i915/intel_pm.c | 18 +++
 drivers/gpu/drm/mgag200/mgag200_ttm.c   |  1 +
 drivers/gpu/drm/radeon/btc_dpm.c| 17 +-
 drivers/gpu/drm/radeon/cik.c| 18 +--
 drivers/gpu/drm/radeon/cypress_dpm.c| 17 +-
 drivers/gpu/drm/radeon/evergreen.c  |  6 ++-
 drivers/gpu/drm/radeon/evergreen_hdmi.c | 26 -
 drivers/gpu/drm/radeon/evergreend.h |  3 ++
 drivers/gpu/drm/radeon/ni.c | 16 --
 drivers/gpu/drm/radeon/ni_dpm.c | 17 +-
 drivers/gpu/drm/radeon/r600.c   | 41 +++
 drivers/gpu/drm/radeon/r600_hdmi.c  | 37 +++--
 drivers/gpu/drm/radeon/r600d.h  |  3 ++
 drivers/gpu/drm/radeon/radeon.h |  4 +-
 drivers/gpu/drm/radeon/radeon_asic.h|  2 +-
 drivers/gpu/drm/radeon/radeon_device.c  |  3 ++
 drivers/gpu/drm/radeon/radeon_fence.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_gart.c|  1 -
 drivers/gpu/drm/radeon/radeon_pm.c  |  9 +++-
 drivers/gpu/drm/radeon/radeon_uvd.c | 93 +
 drivers/gpu/drm/radeon/rv6xx_dpm.c  | 22 
 drivers/gpu/drm/radeon/rv770.c  |  7 ++-
 drivers/gpu/drm/radeon/rv770_dpm.c  | 33 ++--
 drivers/gpu/drm/radeon/rv770_dpm.h  |  1 +
 drivers/gpu/drm/radeon/si.c | 19 ---
 drivers/gpu/drm/radeon/si_dpm.c | 61 +++--
 32 files changed, 353 insertions(+), 165 deletions(-)___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 22/25] drm: no-op out GET_STATS ioctl

[Daniel Vetter]

On Thu, Aug 08, 2013 at 05:55:45PM +0200, Eric Anholt wrote:
> Daniel Vetter  writes:
> 
> > Again only used by a tests in libdrm and by dristat. Nowadays we have
> > much better tracing tools to get detailed insights into what a drm
> > driver is doing. And for a simple "does it work" kind of question that
> > these stats could answer we have plenty of dmesg debug log spew.
> >
> > So I don't see any use for this stat gathering complexity at all.
> >
> > To be able to gradually drop things start with ripping out the
> > interfaces to it, here the ioctl.
> >
> > To prevent dristat from eating its own stack garbage we can't use the
> > drm_noop ioctl though, since we need to clear the return data with a
> > memset.
> 
> I'm happy to see these two die.  Even back in the day we didn't use
> them.
> 
> This has been quite a trip down memory lane.
> 
> Patch 9 typo: s/functinal/functional/
> Patch 25 typo: s/loose/lose/

Fixed.

> Patches 2, 6-11, 19, 21, 22, 24, 25 are:
> 
> Reviewed-by: Eric Anholt 

Thanks for the review. I've pushed a fixed branch with r-b tags to

http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-cleanups

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm fixes for 3.11: Tag more patches for stable? (was: [git pull] drm fixes)

[Paul Menzel]

Dear Dave,


Am Freitag, den 09.08.2013, 05:53 +0100 schrieb Dave Airlie:

[…]

> The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:
> 
>   Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~airlied/linux drm-fixes
> 
> for you to fetch changes up to e42f5814212079aecd5826dba10588a896ac0862:
> 
>   Merge tag 'drm-intel-fixes-2013-08-08' of 
> git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-08-09 
> 09:09:37 +1000)
> 
> 
> 
> Aaron Lu (1):
>   drm/i915: avoid brightness overflow when doing scale
> 
> Alex Deucher (11):
>   drm/radeon: properly handle pm on gpu reset
>   drm/radeon: select audio dto based on encoder id for DCE3
>   drm/radeon/dpm: adjust thermal protection requirements
>   drm/radeon/dpm: fix spread spectrum setup (v2)
>   drm/radeon/dpm: adjust power state properly for UVD on SI
>   drm/radeon/dpm: disable sclk ss on rv6xx
>   drm/radeon: fix audio dto calculation on DCE3+ (v3)
>   drm/radeon: always program the MC on startup
>   drm/radeon/cik: use a mutex to properly lock srbm instanced registers
>   drm/radeon/dpm: require rlc for dpm
>   drm/radeon: make missing smc ucode non-fatal
> 
> Christian König (5):
>   drm/radeon: fix halting UVD
>   drm/radeon: only save UVD bo when we have open handles
>   drm/radeon: stop sending invalid UVD destroy msg
>   drm/radeon: add more UVD CS checking
>   drm/radeon: remove unnecessary unpin

as UVD is also in 3.10 should more of these be tagged
`sta...@vger.kernel.org` too? I only checked

drm/radeon: add more UVD CS checking

and it did not have that tag.

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67800] Computer freezes after idle for several hours (trinity)

[bugzilla-daemon]

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

--- Comment #6 from Kertesz Laszlo  ---
I recompiled the kernel (from linus' git) with these patches applied:

http://lists.freedesktop.org/archives/dri-devel/2013-August/043145.html
I also disabled C6 state from BIOS.

I had no freezes since then. I still have to test some longer idle times (i had
~3 hours maximum so far), but it seems promising.

-- 
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/i915: precedence bug in hsw_compute_wm_results()

[Dan Carpenter]

The '!' operation has higher precedence than the compare so probably
this test is never true.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a5a9959..0b9d9a7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2562,7 +2562,7 @@ static void hsw_compute_wm_results(struct drm_device *dev,
 * a WM level. */
results->enable_fbc_wm = true;
for (level = 1; level <= max_level; level++) {
-   if (!lp_results[level - 1].fbc_val > lp_maximums->fbc) {
+   if (lp_results[level - 1].fbc_val <= lp_maximums->fbc) {
results->enable_fbc_wm = false;
lp_results[level - 1].fbc_val = 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch] drm/i915: unbreak i915_gem_object_ggtt_unbind()

[Dan Carpenter]

There is an extra semi-colon here so we just leak and never unbind
anything.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 735f43f..a582540 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2656,7 +2656,7 @@ i915_gem_object_ggtt_unbind(struct drm_i915_gem_object 
*obj)
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
struct i915_address_space *ggtt = &dev_priv->gtt.base;
 
-   if (!i915_gem_obj_ggtt_bound(obj));
+   if (!i915_gem_obj_ggtt_bound(obj))
return 0;
 
if (obj->pin_count)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch] drm/i915: precedence bug in hsw_compute_wm_results()

[Chris Wilson]

On Fri, Aug 09, 2013 at 12:43:02PM +0300, Dan Carpenter wrote:
> The '!' operation has higher precedence than the compare so probably
> this test is never true.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a5a9959..0b9d9a7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2562,7 +2562,7 @@ static void hsw_compute_wm_results(struct drm_device 
> *dev,
>* a WM level. */
>   results->enable_fbc_wm = true;
>   for (level = 1; level <= max_level; level++) {
> - if (!lp_results[level - 1].fbc_val > lp_maximums->fbc) {
> + if (lp_results[level - 1].fbc_val <= lp_maximums->fbc) {

I didn't spot that '!' at all. It's a stray and should be just removed.
-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

Re: [patch] drm/i915: precedence bug in hsw_compute_wm_results()

[Ville Syrjälä]

On Fri, Aug 09, 2013 at 12:43:02PM +0300, Dan Carpenter wrote:
> The '!' operation has higher precedence than the compare so probably
> this test is never true.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a5a9959..0b9d9a7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2562,7 +2562,7 @@ static void hsw_compute_wm_results(struct drm_device 
> *dev,
>* a WM level. */
>   results->enable_fbc_wm = true;
>   for (level = 1; level <= max_level; level++) {
> - if (!lp_results[level - 1].fbc_val > lp_maximums->fbc) {
> + if (lp_results[level - 1].fbc_val <= lp_maximums->fbc) {

Whoops. My bad.

It should still be > but ! should just be dropped.

>   results->enable_fbc_wm = false;
>   lp_results[level - 1].fbc_val = 0;
>   }
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch] drm/i915: unbreak i915_gem_object_ggtt_unbind()

[Daniel Vetter]

On Fri, Aug 09, 2013 at 12:44:11PM +0300, Dan Carpenter wrote:
> There is an extra semi-colon here so we just leak and never unbind
> anything.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 735f43f..a582540 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2656,7 +2656,7 @@ i915_gem_object_ggtt_unbind(struct drm_i915_gem_object 
> *obj)
>   struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
>   struct i915_address_space *ggtt = &dev_priv->gtt.base;
>  
> - if (!i915_gem_obj_ggtt_bound(obj));
> + if (!i915_gem_obj_ggtt_bound(obj))

Oops, thanks for spotting this. Applied to dinq.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch v2] drm/i915: fix a limit check in hsw_compute_wm_results()

[Dan Carpenter]

The '!' here was not intended.  Since '!' has higher precedence than
compare, it means the check is never true.

Signed-off-by: Dan Carpenter 
---
v2: My first patch was wrong.

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 96234c6..0f5eb21 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2685,7 +2685,7 @@ static void hsw_compute_wm_results(struct drm_device *dev,
 * a WM level. */
results->enable_fbc_wm = true;
for (level = 1; level <= max_level; level++) {
-   if (!lp_results[level - 1].fbc_val > lp_maximums->fbc) {
+   if (lp_results[level - 1].fbc_val > lp_maximums->fbc) {
results->enable_fbc_wm = false;
lp_results[level - 1].fbc_val = 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [patch v2] drm/i915: fix a limit check in hsw_compute_wm_results()

[Ville Syrjälä]

On Fri, Aug 09, 2013 at 01:07:31PM +0300, Dan Carpenter wrote:
> The '!' here was not intended.  Since '!' has higher precedence than
> compare, it means the check is never true.
> 
> Signed-off-by: Dan Carpenter 

Reviewed-by: Ville Syrjälä 

The culprit for Daniel:

commit 71fff20ff1bb790f4defe0c880e028581ffab420
Author: Ville Syrjälä 
Date:   Tue Aug 6 22:24:03 2013 +0300

drm/i915: Kill fbc_enable from hsw_lp_wm_results

> ---
> v2: My first patch was wrong.
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 96234c6..0f5eb21 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2685,7 +2685,7 @@ static void hsw_compute_wm_results(struct drm_device 
> *dev,
>* a WM level. */
>   results->enable_fbc_wm = true;
>   for (level = 1; level <= max_level; level++) {
> - if (!lp_results[level - 1].fbc_val > lp_maximums->fbc) {
> + if (lp_results[level - 1].fbc_val > lp_maximums->fbc) {
>   results->enable_fbc_wm = false;
>   lp_results[level - 1].fbc_val = 0;
>   }
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm fixes for 3.11: Tag more patches for stable? (was: [git pull] drm fixes)

[Dave Airlie]

On Fri, Aug 9, 2013 at 7:25 PM, Paul Menzel
 wrote:
> Dear Dave,
>
>
> Am Freitag, den 09.08.2013, 05:53 +0100 schrieb Dave Airlie:
>
> […]
>
>> The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:
>>
>>   Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)
>>
>> are available in the git repository at:
>>
>>   git://people.freedesktop.org/~airlied/linux drm-fixes
>>
>> for you to fetch changes up to e42f5814212079aecd5826dba10588a896ac0862:
>>
>>   Merge tag 'drm-intel-fixes-2013-08-08' of 
>> git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-08-09 
>> 09:09:37 +1000)
>>
>> 
>>
>> Aaron Lu (1):
>>   drm/i915: avoid brightness overflow when doing scale
>>
>> Alex Deucher (11):
>>   drm/radeon: properly handle pm on gpu reset
>>   drm/radeon: select audio dto based on encoder id for DCE3
>>   drm/radeon/dpm: adjust thermal protection requirements
>>   drm/radeon/dpm: fix spread spectrum setup (v2)
>>   drm/radeon/dpm: adjust power state properly for UVD on SI
>>   drm/radeon/dpm: disable sclk ss on rv6xx
>>   drm/radeon: fix audio dto calculation on DCE3+ (v3)
>>   drm/radeon: always program the MC on startup
>>   drm/radeon/cik: use a mutex to properly lock srbm instanced registers
>>   drm/radeon/dpm: require rlc for dpm
>>   drm/radeon: make missing smc ucode non-fatal
>>
>> Christian König (5):
>>   drm/radeon: fix halting UVD
>>   drm/radeon: only save UVD bo when we have open handles
>>   drm/radeon: stop sending invalid UVD destroy msg
>>   drm/radeon: add more UVD CS checking
>>   drm/radeon: remove unnecessary unpin
>
> as UVD is also in 3.10 should more of these be tagged
> `sta...@vger.kernel.org` too? I only checked
>
> drm/radeon: add more UVD CS checking
>
> and it did not have that tag.

I think if they are required they might be best done via separate
backports, not sure how much the code has changed but dpm moved a lot
of stuff around.

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

Re: drm fixes for 3.11: Tag more patches for stable?

[Christian König]

Am 09.08.2013 11:25, schrieb Paul Menzel:

Dear Dave,


Am Freitag, den 09.08.2013, 05:53 +0100 schrieb Dave Airlie:

[…]


The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:

   Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)

are available in the git repository at:

   git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to e42f5814212079aecd5826dba10588a896ac0862:

   Merge tag 'drm-intel-fixes-2013-08-08' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-08-09 
09:09:37 +1000)



Aaron Lu (1):
   drm/i915: avoid brightness overflow when doing scale

Alex Deucher (11):
   drm/radeon: properly handle pm on gpu reset
   drm/radeon: select audio dto based on encoder id for DCE3
   drm/radeon/dpm: adjust thermal protection requirements
   drm/radeon/dpm: fix spread spectrum setup (v2)
   drm/radeon/dpm: adjust power state properly for UVD on SI
   drm/radeon/dpm: disable sclk ss on rv6xx
   drm/radeon: fix audio dto calculation on DCE3+ (v3)
   drm/radeon: always program the MC on startup
   drm/radeon/cik: use a mutex to properly lock srbm instanced registers
   drm/radeon/dpm: require rlc for dpm
   drm/radeon: make missing smc ucode non-fatal

Christian König (5):
   drm/radeon: fix halting UVD
   drm/radeon: only save UVD bo when we have open handles
   drm/radeon: stop sending invalid UVD destroy msg
   drm/radeon: add more UVD CS checking
   drm/radeon: remove unnecessary unpin

as UVD is also in 3.10 should more of these be tagged
`sta...@vger.kernel.org` too? I only checked

 drm/radeon: add more UVD CS checking

and it did not have that tag.


That patch doesn't have the tag because it is a (minor) new feature to 
check the incoming parameters for incorrect values and not a bugfix.


The other three UVD patches are bugfixes and indeed does have the 
necessary tag.


Regards,
Christian.



[…]


Thanks,

Paul


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

[Bug 67946] New: Switching to Integrated card to vgaswitcheroo with radeon.audio=1 makes kernel to hang

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 67946
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Switching to Integrated card to vgaswitcheroo with
radeon.audio=1 makes kernel to hang
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: m...@3v1n0.net
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

I've a Mobility Radeon HD 5650 muxed with an intel card. If I boot with
radeon.audio=1 and I switch the radeon card off when pulseaudio is running,
then the kernel hangs as soon as I close X:

[ 489.177732] hda-intel :01:00.1: Disabling via VGA-switcheroo
[ 489.297129] hda-intel :01:00.1: Cannot lock devices!
[ 489.297139] radeon: switched off
[ 489.300356] [drm] Disabling audio support
[ 489.319552] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x0015e418 and cpu addr 0xc90009df0418
[ 489.973886] ACPI: \_SB_.PCI0: ACPI_NOTIFY_BUS_CHECK event: unsupported
[ 489.973903] _handle_hotplug_event_root: Bus check notify on \_SB_.PCI0
[ 678.992375] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 678.992453] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28
[ 683.996303] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 683.996377] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28
[ 683.996453] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
C3DC (len 871, WS 0, PS 0) @ 0xC439
[ 689.000275] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 689.000349] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28
[ 694.004285] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 694.004363] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28
[ 699.008330] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 699.008414] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28
[ 699.514458] init: tty1 main process (2460) killed by QUIT signal
[ 699.514489] init: tty1 main process ended, respawning
[ 704.012405] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 704.012492] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28
[ 709.016515] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 709.016596] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28

These errors doesn't happen instead if I close X and kill pulseaudio before
switching cards.

Not sure if this is a pulseaudio issue or a kernel one (that should notify
pulseaudio about the unplugged HDMI audio card).

-- 
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 67946] Switching to Integrated card to vgaswitcheroo with radeon.audio=1 makes kernel to hang

[bugzilla-daemon]

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

Marco Trevisan (Treviño)  changed:

   What|Removed |Added

URL||https://bugs.launchpad.net/
   ||ubuntu/+source/pulseaudio/+
   ||bug/1210470

-- 
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 67276] kernel-3.11 [drm:r600_uvd_ring_test] *ERROR* radeon: ring 5 test failed (0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #25 from Joshua Cov.  ---
Ping on this.

-- 
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 67927] R600_DEBUG=sb: Celestia show 2 earths, one wrongly rendered

[bugzilla-daemon]

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

--- Comment #1 from Vadim Girlin  ---
So far I can't reproduce this issue. Please test with the latest mesa from git
if you are using older version. If llvm backend is active in your
configuration, you might want to update llvm as well or test the application
with R600_DEBUG=sb,nollvm.

Also please attach the output with R600_DEBUG=sb,ps,vs

-- 
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 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor

[bugzilla-daemon]

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

Damian Nowak  changed:

   What|Removed |Added

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

--- Comment #3 from Damian Nowak  ---
My 7870 burned a month ago. Now I have a new one so I can continue
investigating.

In the meantime there was a kernel update - I now have 3.10.5-1-ARCH instead of
3.9.6-1-ARCH. There were some updates along the way as well, marked as
[updated]. I currently have:

linux 3.10.5-1 [updated]
mesa 9.1.6-1 [updated]
libdrm 2.4.46-2 [updated]
ati-dri 9.1.6-1 [updated]
llvm-amdgpu-lib-snapshot 20130403-3 [the same]
xf86-video-ati-glamor-git 1:20120730-1 [the same]


> I am able to reproduce the bug using Linphone (it doesn't mean it hangs just 
> in 
> Linphone). I call my mobile. Screen goes blank right after connection is 
> established (connection = when you hear beeping and you wait for the guy to 
> answer the phone). Therefore, I can test if the changes you provide resolve 
> the 
> issue.

Fortunately, it works now. No hangs in Linphone after connection is
established.

-- 
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: [PATCHv2 1/5] drm/exynos: add device tree support for rotator

[Tomasz Figa]

Hi Chanho,

On Friday 09 of August 2013 16:40:49 Chanho Park wrote:
> The exynos4 platform is only dt-based since 3.10, we should convert
> driver data and ids to dt-based parsing methods. The rotator driver has
> a limit table to get size limit of input picture. Each SoCs has slightly
> different limit value compared with any others.
> For example, exynos4210's max_size of RGB888 is 16k x 16k. But, others
> have 8k x 8k. Another example the exynos5250 should have multiple of 2
> pixel size for its X/Y axis. Thus, we should keep different tables for
> each of them.
> 
> Signed-off-by: Chanho Park 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |  109
> --- 1 file changed, 81 insertions(+), 28
> deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c index 427640a..39b09e0
> 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -632,6 +632,73 @@ static int rotator_ippdrv_start(struct device *dev,
> enum drm_exynos_ipp_cmd cmd) return 0;
>  }
> 
> +static struct rot_limit_table rot_limit_tbl_4210 = {
> + .ycbcr420_2p = {
> + .min_w = 32,
> + .min_h = 32,
> + .max_w = SZ_64K,
> + .max_h = SZ_64K,
> + .align = 3,
> + },
> + .rgb888 = {
> + .min_w = 8,
> + .min_h = 8,
> + .max_w = SZ_16K,
> + .max_h = SZ_16K,
> + .align = 2,
> + },
> +};
> +
> +static struct rot_limit_table rot_limit_tbl_4x12 = {
> + .ycbcr420_2p = {
> + .min_w = 32,
> + .min_h = 32,
> + .max_w = SZ_32K,
> + .max_h = SZ_32K,
> + .align = 3,
> + },
> + .rgb888 = {
> + .min_w = 8,
> + .min_h = 8,
> + .max_w = SZ_8K,
> + .max_h = SZ_8K,
> + .align = 2,
> + },
> +};
> +
> +static struct rot_limit_table rot_limit_tbl_5250 = {
> + .ycbcr420_2p = {
> + .min_w = 32,
> + .min_h = 32,
> + .max_w = SZ_32K,
> + .max_h = SZ_32K,
> + .align = 3,
> + },
> + .rgb888 = {
> + .min_w = 8,
> + .min_h = 8,
> + .max_w = SZ_8K,
> + .max_h = SZ_8K,
> + .align = 1,
> + },
> +};
> +
> +static const struct of_device_id exynos_rotator_match[] = {
> + {
> + .compatible = "samsung,exynos4210-rotator",
> + .data = &rot_limit_tbl_4210,
> + },
> + {
> + .compatible = "samsung,exynos4212-rotator",
> + .data = &rot_limit_tbl_4x12,
> + },
> + {
> + .compatible = "samsung,exynos5250-rotator",
> + .data = &rot_limit_tbl_5250,
> + },
> + {},
> +};
> +
>  static int rotator_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
> @@ -645,8 +712,19 @@ static int rotator_probe(struct platform_device
> *pdev) return -ENOMEM;
>   }
> 
> - rot->limit_tbl = (struct rot_limit_table *)
> - platform_get_device_id(pdev)->driver_data;
> + if (dev->of_node) {
> + const struct of_device_id *match;
> + match = of_match_node(of_match_ptr(exynos_rotator_match),
> + dev->of_node);
> + if (match == NULL) {
> + dev_err(dev, "failed to match node\n");
> + return -ENODEV;
> + }
> + rot->limit_tbl = (struct rot_limit_table *)match->data;
> + } else {
> + dev_err(dev, "cannot find binding\n");

What about having a check for !dev->of_node at the beginning of probe, to 
not complicate further code?

Also the error message is confusing. It should be something closer to 
"device does not have of_node".

> + return -ENODEV;
> + }
> 
>   rot->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   rot->regs = devm_ioremap_resource(dev, rot->regs_res);
> @@ -718,31 +796,6 @@ static int rotator_remove(struct platform_device
> *pdev) return 0;
>  }
> 
> -static struct rot_limit_table rot_limit_tbl = {
> - .ycbcr420_2p = {
> - .min_w = 32,
> - .min_h = 32,
> - .max_w = SZ_32K,
> - .max_h = SZ_32K,
> - .align = 3,
> - },
> - .rgb888 = {
> - .min_w = 8,
> - .min_h = 8,
> - .max_w = SZ_8K,
> - .max_h = SZ_8K,
> - .align = 2,
> - },
> -};
> -
> -static struct platform_device_id rotator_driver_ids[] = {
> - {
> - .name   = "exynos-rot",
> - .driver_data= (unsigned long)&rot_limit_tbl,
> - },
> - {},
> -};
> -
>  static int rotator_clk_crtl(struct rot_context *rot, bool enable)
>  {
>   if (enable) {
> @@ -

Re: [PATCHv2 2/5] ARM: dts: Add rotator node for exynos4210

[Tomasz Figa]

On Friday 09 of August 2013 16:40:50 Chanho Park wrote:
> This patch adds a rotator node for exynos4210. The exynos4210 has
> different limitation of image size compared with later chips.
> 
> Signed-off-by: Chanho Park 
> Cc: Thomas Abraham 
> Cc: Kukjin Kim 
> Cc: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  arch/arm/boot/dts/exynos4.dtsi |9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4.dtsi
> b/arch/arm/boot/dts/exynos4.dtsi index 597cfcf..002b2b8 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -243,6 +243,15 @@
>   status = "disabled";
>   };
> 
> + rotator: rotator@1281 {
> + compatible = "samsung,exynos4210-rotator";
> + reg = <0x1281 0x1000>;
> + interrupts = <0 83 0>;
> + clocks = <&clock 278>;
> + clock-names = "rotator";
> + status = "disabled";

Does the rotator need any board-specific information to work? If no, it 
should not be disabled by default. Same comment goes to patch 4/5.

Best regards,
Tomasz

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

Re: [PATCHv2 5/5] ARM: dts: Add dt binding documentation for exynos rotator

[Tomasz Figa]

Hi Chanho,

On Friday 09 of August 2013 16:40:53 Chanho Park wrote:
> This patch describes each nodes of rotator and specifies a example how to
> bind it.
> 
> Signed-off-by: Chanho Park 
> Cc: Thomas Abraham 
> Cc: Kukjin Kim 
> Cc: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  .../devicetree/bindings/gpu/samsung-rotator.txt|   26
>  1 file changed, 26 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt new file
> mode 100644
> index 000..31ee7b5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> @@ -0,0 +1,26 @@
> +* Samsung Image Rotator
> +
> +Required properties:
> +  - compatible : value should be following:
> + (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210
> + (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412
> + (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250
> +
> +  - reg : Physical base address of the IP registers and length of memory
> +   mapped region.
> +
> +  - interrupts : Interrupt number of Rotator

What about: interrupt specifier for rotator interrupt, according to format 
specific to interrupt parent.

> +
> +  - clocks : Clock number described in
> Documentations/devicetree/binding/clock. +

Perhaps: clock specifier for rotator clock, according to generic clock 
bindings.

> +  - clock-names : Clock name.

Names of clocks specified in "clocks" property. For exynos rotator this 
property should contain only one name: "rotator".

> +Example:
> + rotator: rotator@1280 {

I wonder if we shouldn't use a more generic name here, according to ePAPR 
node naming recommendation.

> + compatible = "samsung,exynos4210-rotator";
> + reg = <0x1281 0x1000>;

Typo. Node has 1280 in unit-address suffix, but this property has 
1281 instead.

> + interrupts = <0 83 0>;
> + clocks = <&clock 278>;
> + clock-names = "rotator";
> + status = "disabled";

Status property should be omitted from this example, as it's not a part of 
this binding.

Best regards,
Tomasz

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

Re: [PATCH] drm: Add drm_bridge

[Sean Paul]

On Thu, Aug 8, 2013 at 8:36 PM, Daniel Vetter  wrote:
> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul  wrote:
>> This patch adds the notion of a drm_bridge. A bridge is a chained
>> device which hangs off an encoder. The drm driver using the bridge
>> should provide the association between encoder and bridge. Once a
>> bridge is associated with an encoder, it will participate in mode
>> set, dpms, and optionally connection detection.
>>
>> Since a connector may not be able to determine the connection state
>> downstream of the bridge, bridges may implement detect() which will take
>> precedence over connector detect() if the bridge is already attached
>> to an encoder and that encoder is already attached to the connector.
>> In practical terms, this requires the drm driver to make these
>> associations at init time, which is fine for SoC applications where
>> this link is static.
>>
>> Signed-off-by: Sean Paul 
>
> A few comments below. I think overall any such infrastructure simply
> needs to demonstrate viability on a few drivers, that makes it much
> simpler to check whether the interfaces make sense.

Thanks for your feedback, Daniel.

As mentioned by Stephane and Rob, there are a few drivers already
using this. In the ChromeOS tree, we have 2 simple DP->LVDS bridges
which quite frankly aren't terribly interesting atm, and we'll be
converting an HDMI->myDP bridge in a couple of weeks (time permitting,
of course).


> Generally I'd make
> more sense for me if the bridge is just an implementation detail of a
> given encoder and if the bridge would not be exposed to the crtc
> helpers.

After we discussed this on IRC, I converted our exynos driver to do
this. You can check out the patch here
(https://gerrit.chromium.org/gerrit/#/c/64680).

It felt like a lot of boilerplate code that would be duplicated in
every drm driver. Given the number of hooks we have, it's a pretty
fine granularity such that there aren't *that* many creative ways to
order things (famous last words). If a driver finds the need to differ
from the helper order, they probably aren't going to be using the
helper anyways.


> With that abstraction chaining would be more natural imo and
> we'd also have a much higher chance that bridge drivers work accross
> different drm drivers: Atm you can run some encoder stuff in the crtc
> callbacks and the other way round (and pretty much every driver for a
> bit more complicated hw does that), and every driver can differ in
> those tricks a bit. If we bake the bridge callbacks into the crtc
> helpers I expect that for bridges with tricky ordering constraints
> this will become a giant mess. So I'd prefer much if this would work
> like drm i2c slave encoders.
>

In the three bridge chips I've dealt with, they all try their best to
be transparent to the encoder. They all fail at this. However their
quirks are usually not dependent on the encoder implementation, but
rather the general order of operations (ie: when to assert hotplug,
video signal on, etc.).

Furthermore, drm_bridge will allow us to use bridges across drm
drivers. For example, the HDMI->myDP driver I mentioned earlier is
used on a number of platforms, not just exynos. It would be a waste to
bind it to exynos when a more general implementation can be achieved.



> Cheers, Daniel
>
>> ---
>>  drivers/gpu/drm/drm_crtc.c|  50 +
>>  drivers/gpu/drm/drm_crtc_helper.c | 112 
>> ++
>>  drivers/gpu/drm/drm_sysfs.c   |   8 ++-
>>  include/drm/drm_crtc.h|  48 
>>  include/drm/drm_crtc_helper.h |  34 
>>  5 files changed, 241 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index fc83bb9..0311e2b 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -781,6 +781,41 @@ void drm_connector_unplug_all(struct drm_device *dev)
>>  }
>>  EXPORT_SYMBOL(drm_connector_unplug_all);
>>
>> +int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
>> +   const struct drm_bridge_funcs *funcs)
>> +{
>> +   int ret;
>> +
>> +   drm_modeset_lock_all(dev);
>> +
>> +   ret = drm_mode_object_get(dev, &bridge->base, 
>> DRM_MODE_OBJECT_BRIDGE);
>> +   if (ret)
>> +   goto out;
>> +
>> +   bridge->dev = dev;
>> +   bridge->funcs = funcs;
>> +
>> +   list_add_tail(&bridge->head, &dev->mode_config.bridge_list);
>> +   dev->mode_config.num_bridge++;
>> +
>> + out:
>> +   drm_modeset_unlock_all(dev);
>> +   return ret;
>> +}
>> +EXPORT_SYMBOL(drm_bridge_init);
>> +
>> +void drm_bridge_cleanup(struct drm_bridge *bridge)
>> +{
>> +   struct drm_device *dev = bridge->dev;
>> +
>> +   drm_modeset_lock_all(dev);
>> +   drm_mode_object_put(dev, &bridge->base);
>> +   list_del(&bridge->head);
>> +   dev->mode_config.num_bridge--;
>> +   drm_modeset_unlock_all(dev);
>> +}
>> +EXPORT_SYMBOL(

[Bug 67276] kernel-3.11 [drm:r600_uvd_ring_test] *ERROR* radeon: ring 5 test failed (0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #26 from Alex Deucher  ---
Is this still an issue with Dave's latest drm-fixes branch:
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes

-- 
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

[GIT PULL] gma500-next

[Patrik Jakobsson]

Hi Dave

Here's some gma500 unifying and cleanups for drm-next. There is more stuff in
the pipe for 3.12 but I'd like to get these out of the way first.

Thanks
Patrik

The following changes since commit 85d9cb41db3bf0f36c999c2e547b37cb9f32367b:

  drm: remove drm_order (2013-07-23 20:14:29 +1000)

are available in the git repository at:

  git://github.com/patjak/drm-gma500 gma500-next

for you to fetch changes up to 367e44080e20f77fa7b0f2db83fd6367da59b6c3:

  drm/gma500: Rename psb_intel_encoder to gma_encoder (2013-07-24
01:49:43 +0200)


Patrik Jakobsson (33):
  drm/gma500: Add generic code for clock calculation
  drm/gma500/cdv: Make use of the generic clock code
  drm/gma500: Make use of gma_pipe_has_type()
  drm/gma500/psb: Make use of generic clock code
  drm/gma500: Remove the unused psb_intel_display.h
  drm/gma500: Add generic pipe/crtc functions
  drm/gma500/cdv: Use identical generic crtc funcs
  drm/gma500: Make all chips use gma_wait_for_vblank
  drm/gma500/psb: Use identical generic crtc funcs
  drm/gma500/cdv: Convert to gma_pipe_set_base()
  drm/gma500: Add IS_CDV() macro
  drm/gma500/cdv: Convert to gma_crtc_dpms()
  drm/gma500/cdv: Convert to generic gamma funcs
  drm/gma500/psb: Convert to gma_pipe_set_base()
  drm/gma500: Convert to generic gamma funcs
  drm/gma500/psb: Convert to gma_crtc_dpms()
  drm/gma500/oak: Use identical generic crtc funcs
  drm/gma500/mdfld: Use identical generic crtc funcs
  drm/gma500/psb: Convert to generic crtc->destroy
  drm/gma500: Add generic cursor functions
  drm/gma500/cdv: Convert to generic cursor funcs
  drm/gma500/psb: Convert to generic cursor funcs
  drm/gma500: Add generic encoder functions
  drm/gma500: Convert to generic encoder funcs
  drm/gma500: Add generic crtc save/restore funcs
  drm/gma500/psb: Convert to generic save/restore
  drm/gma500/cdv: Convert to generic save/restore
  drm/gma500: Add generic set_config() function
  drm/gma500/psb: Convert to generic set_config()
  drm/gma500/cdv: Convert to generic set_config()
  drm/gma500: Rename psb_intel_crtc to gma_crtc
  drm/gma500: Rename psb_intel_connector to gma_connector
  drm/gma500: Rename psb_intel_encoder to gma_encoder

 drivers/gpu/drm/gma500/Makefile|   1 +
 drivers/gpu/drm/gma500/cdv_device.c|   1 +
 drivers/gpu/drm/gma500/cdv_device.h|  10 +-
 drivers/gpu/drm/gma500/cdv_intel_crt.c |  57 +-
 drivers/gpu/drm/gma500/cdv_intel_display.c | 916 ++--
 drivers/gpu/drm/gma500/cdv_intel_dp.c  | 154 ++--
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c|  89 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c|  71 +-
 drivers/gpu/drm/gma500/framebuffer.c   |  25 +-
 drivers/gpu/drm/gma500/framebuffer.h   |   2 +-
 drivers/gpu/drm/gma500/gma_display.c   | 776 +
 drivers/gpu/drm/gma500/gma_display.h   | 108 +++
 drivers/gpu/drm/gma500/mdfld_dsi_output.c  |  15 +-
 drivers/gpu/drm/gma500/mdfld_dsi_output.h  |  16 +-
 drivers/gpu/drm/gma500/mdfld_intel_display.c   |  65 +-
 drivers/gpu/drm/gma500/oaktrail_crtc.c |  63 +-
 drivers/gpu/drm/gma500/oaktrail_hdmi.c |  43 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c |  48 +-
 drivers/gpu/drm/gma500/psb_device.c|   3 +-
 .../gma500/{psb_intel_display.h => psb_device.h}   |  13 +-
 drivers/gpu/drm/gma500/psb_drv.c   |  14 +-
 drivers/gpu/drm/gma500/psb_drv.h   |   3 +
 drivers/gpu/drm/gma500/psb_intel_display.c | 944 ++---
 drivers/gpu/drm/gma500/psb_intel_drv.h |  44 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c|  75 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c|  53 +-
 26 files changed, 1443 insertions(+), 2166 deletions(-)
 create mode 100644 drivers/gpu/drm/gma500/gma_display.c
 create mode 100644 drivers/gpu/drm/gma500/gma_display.h
 rename drivers/gpu/drm/gma500/{psb_intel_display.h => psb_device.h} (76%)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

[Tom Cooksey]

Hi Daniel, Rob.

Thank you both for your reviews - greatly appreciated!

> > > Known issues:
> > >  * It still includes code to use KDS, which is not going upstream.
> >
> > review's on  > July/042462.html> can't hurt
> >
> > although you might consider submitting a reduced functionality driver
> > w/ KDS bits removed in the mean time.. then when the fence stuff is
> > merged it is just an incremental patch rather than a whole driver ;-)
> 
> Yeah, I think the KDS bits and comments need to go first before
> merginge.

Right, as I expected really. Though as I said we'll probably wait for
fences to land and switch over to that before asking for it to be
merged. A pl111 KMS driver with neither KDS nor implicit fences is 
useless to us. Having said that, if someone else would have a use for
a fence/KDS-less pl111 KMS driver, please let me know!



> > > +/*
> > > + * Number of flips allowed in flight at any one time. Any more
> > > + * flips requested beyond this value will cause the caller to 
> > > + * block until earlier flips have completed.
> > > + *
> > > + * For performance reasons, this must be greater than the number
> > > + * of buffers used in the rendering pipeline. Note that the 
> > > + * rendering pipeline can contain different types of buffer, e.g.:
> > > + * - 2 final framebuffers
> > > + * - >2 geometry buffers for GPU use-cases
> > > + * - >2 vertex buffers for GPU use-cases
> > > + *
> > > + * For example, a system using 5 geometry buffers could have 5
> > > + * flips in flight, and so NR_FLIPS_IN_FLIGHT_THRESHOLD must be 
> > > + * 5 or greater.
> > > + *
> > > + * Whilst there may be more intermediate buffers (such as
> > > + * vertex/geometry) than final framebuffers, KDS is used to 
> > > + * ensure that GPU rendering waits for the next off-screen 
> > > + * buffer, so it doesn't overwrite an on-screen buffer and 
> > > + * produce tearing.
> > > + */
> > > +
> >
> > fwiw, this is at least different from how other drivers do triple
> > (or > double) buffering.  In other drivers (intel, omap, and
> > msm/freedreno, that I know of, maybe others too) the xorg driver
> > dri2 bits implement the double buffering (ie. send flip event back
> > to client immediately and queue up the flip and call page-flip
> > after the pageflip event back from kernel.
> >
> > I'm not saying not to do it this way, I guess I'd like to hear
> > what other folks think.  I kinda prefer doing this in userspace 
> > as it keeps the kernel bits simpler (plus it would then work 
> > properly on exynosdrm or other kms drivers).
> 
> Yeah, if this is just a sw queue then I don't think it makes sense
> to have it in the kernel. Afaik the current pageflip interface drm
> exposes allows one oustanding flip only, and you _must_ wait for
> the flip complete event before you can submit the second one.

Right, I'll have a think about this. I think our idea was to issue
enough page-flips into the kernel to make sure that any process
scheduling latencies on a heavily loaded system don't cause us to
miss a v_sync deadline. At the moment we issue the page flip from DRI2
schedule_swap. If we were to move that to the page flip event handler
of the previous page-flip, we're potentially adding in extra latency.

I.e. Currently we have:

DRI2SwapBuffers
 - drm_mode_page_flip to buffer B
DRI2SwapBuffers
 - drm_mode_page_flip to buffer A (gets queued in kernel)
...
v_sync! (at this point buffer B is scanned out)
 - release buffer A's KDS resource/signal buffer A's fence
- queued GPU job to render next frame to buffer A scheduled on HW
...
GPU interrupt! (at this point buffer A is ready to be scanned out)
 - release buffer A's KDS resource/signal buffer A's fence
- second page flip executed, buffer A's address written to scanout
  register, takes effect on next v_sync.


So in the above, after X receives the second DRI2SwapBuffers, it
doesn't need to get scheduled again for the next frame to be both
rendered by the GPU and issued to the display for scanout.


If we were to move to a user-space queue, I think we have something
like this:

DRI2SwapBuffers
 - drm_mode_page_flip to buffer B
DRI2SwapBuffers
 - queue page flip to buffer A in DDX
...
v_sync! (at this point buffer B is scanned out)
 - release buffer A's KDS resource/signal buffer A's fence
- queued GPU job to render next frame to buffer A scheduled on HW
 - Send page flip event to X
...
GPU interrupt! (at this point buffer A is ready to be scanned out)
 - Release buffer A's KDS resource/signal buffer A's fence - but nothing
   is waiting on it
...
X gets scheduled, runs page flip handler
 - drm_mode_page_flip to buffer A
   - buffer A's address written to scanout register, takes effect on
 next v_sync.


So here, X must get scheduled again after processing the second
DRI2SwapBuffers in order to have the next frame displayed. This
increases the likely-hood that we're not able to write the address of
buf

RE: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

[Tom Cooksey]

> > Turning to DRM/KMS, it seems the supported formats of a plane can be
> > queried using drm_mode_get_plane. However, there doesn't seem to be a
> > way to query the supported formats of a crtc? If display HW only
> > supports scanning out from a single buffer (like pl111 does), I think
> > it won't have any planes and a fb can only be set on the crtc. In
> > which case, how should user-space query which pixel formats that crtc
> > supports?
> 
> it is exposed for drm plane's.  What is missing is to expose the
> primary-plane associated with the crtc.

Cool - so a patch which adds a way to query the what formats a crtc
supports would be welcome?

What about a way to query the stride alignment constraints?

Presumably using the drm_mode_get_property mechanism would be the
right way to implement that?


> > As with v4l2, DRM doesn't appear to have a way to query the stride
> > constraints? Assuming there is a way to query the stride constraints,
> > there also isn't a way to specify them when creating a buffer with
> > DRM, though perhaps the existing pitch parameter of
> > drm_mode_create_dumb could be used to allow user-space to pass in a
> > minimum stride as well as receive the allocated stride?
> >
> 
> well, you really shouldn't be using create_dumb..  you should have a
> userspace piece that is specific to the drm driver, and knows how to
> use that driver's gem allocate ioctl.

Sorry, why does this need a driver-specific allocation function? It's
just a display controller driver and I just want to allocate a scan-
out buffer - all I'm asking is for the display controller driver to
use a minimum stride alignment so I can export the buffer and use
another device to fill it with data.

The whole point is to be able to allocate the buffer in such a way
that another device can access it. So the driver _can't_ use a
special, device specific format, nor can it allocate it from a
private memory pool because doing so would preclude it from being
shared with another device.

That other device doesn't need to be a GPU wither, it could just as
easily be a camera/ISP or video decoder.



> >> > So presumably you're talking about a GPU driver being the exporter
> >> > here? If so, how could the GPU driver do these kind of tricks on
> >> > memory shared with another device?
> >>
> >> Yes, that is gpu-as-exporter.  If someone else is allocating
> >> buffers, it is up to them to do these tricks or not.  Probably 
> >> there is a pretty good chance that if you aren't a GPU you don't 
> >> need those sort of tricks for fast allocation of transient upload 
> >> buffers, staging textures, temporary pixmaps, etc.  Ie. I don't 
> >> really think a v4l camera or video decoder would benefit from that 
> >> sort of optimization.
> >
> > Right - but none of those are really buffers you'd want to export
> 
> > with dma_buf to share with another device are they? In which case, 
> > why not just have dma_buf figure out the constraints and allocate 
> > the memory?
>
> maybe not.. but (a) you don't necessarily know at creation time if it
> is going to be exported (maybe you know if it is definitely not going
> to be exported, but the converse is not true),

I can't actually think of an example where you would not know if a
buffer was going to be exported or not at allocation time? Do you have
a case in mind?

Regardless, you'd certainly have to know if a buffer will be exported
pretty quickly, before it's used so that you can import it into
whatever devices are going to access it. Otherwise if it gets
allocated before you export it, the allocation won't satisfy the
constraints of the other devices which will need to access it and
importing will fail. Assuming of course deferred allocation of the
backing pages as discussed earlier in the thread.



> and (b) there isn't
> really any reason to special case the allocation in the driver because
> it is going to be exported.

Not sure I follow you here? Surely you absolutely have to special-case
the allocation if the buffer is to be exported because you have to
take the other devices' constraints into account when you allocate? Or
do you mean you don't need to special-case the GEM buffer object
creation, only the allocation of the backing pages? Though I'm not
sure how that distinction is useful - at the end of the day, you need
to special-case allocation of the backing pages.


> helpers that can be used by simple drivers, yes.  Forcing the way the
> buffer is allocated, for sure not.  Currently, for example, there is
> no issue to export a buffer allocated from stolen-mem.

Where stolen-mem is the PC-world's version of a carveout? I.e. A chunk
of memory reserved at boot for the GPU which the OS can't touch? I
guess I view such memory as accessible to all media devices on the 
system and as such, needs to be managed by a central allocator which
dma_buf can use to allocate from.

I guess if that stolen-mem is managed by a single device then in
essence that device becomes the central

Re: [PATCH] drm: Add drm_bridge

[Alex Deucher]

On Fri, Aug 9, 2013 at 9:19 AM, Sean Paul  wrote:
> On Thu, Aug 8, 2013 at 8:36 PM, Daniel Vetter  wrote:
>> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul  wrote:
>>> This patch adds the notion of a drm_bridge. A bridge is a chained
>>> device which hangs off an encoder. The drm driver using the bridge
>>> should provide the association between encoder and bridge. Once a
>>> bridge is associated with an encoder, it will participate in mode
>>> set, dpms, and optionally connection detection.
>>>
>>> Since a connector may not be able to determine the connection state
>>> downstream of the bridge, bridges may implement detect() which will take
>>> precedence over connector detect() if the bridge is already attached
>>> to an encoder and that encoder is already attached to the connector.
>>> In practical terms, this requires the drm driver to make these
>>> associations at init time, which is fine for SoC applications where
>>> this link is static.
>>>
>>> Signed-off-by: Sean Paul 
>>
>> A few comments below. I think overall any such infrastructure simply
>> needs to demonstrate viability on a few drivers, that makes it much
>> simpler to check whether the interfaces make sense.
>
> Thanks for your feedback, Daniel.
>
> As mentioned by Stephane and Rob, there are a few drivers already
> using this. In the ChromeOS tree, we have 2 simple DP->LVDS bridges
> which quite frankly aren't terribly interesting atm, and we'll be
> converting an HDMI->myDP bridge in a couple of weeks (time permitting,
> of course).

radeon also uses DP->LVDS and DP->VGA bridges on a number of systems.
It currently uses a driver specific hack, but it could probably be
converted to use the bridge infrastructure.

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

Re: [Intel-gfx] [patch v2] drm/i915: fix a limit check in hsw_compute_wm_results()

[Daniel Vetter]

On Fri, Aug 09, 2013 at 01:29:33PM +0300, Ville Syrjälä wrote:
> On Fri, Aug 09, 2013 at 01:07:31PM +0300, Dan Carpenter wrote:
> > The '!' here was not intended.  Since '!' has higher precedence than
> > compare, it means the check is never true.
> > 
> > Signed-off-by: Dan Carpenter 
> 
> Reviewed-by: Ville Syrjälä 
> 
> The culprit for Daniel:
> 
> commit 71fff20ff1bb790f4defe0c880e028581ffab420
> Author: Ville Syrjälä 
> Date:   Tue Aug 6 22:24:03 2013 +0300
> 
> drm/i915: Kill fbc_enable from hsw_lp_wm_results

Queued for -next, thanks for the patch.
-Daniel
> 
> > ---
> > v2: My first patch was wrong.
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 96234c6..0f5eb21 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -2685,7 +2685,7 @@ static void hsw_compute_wm_results(struct drm_device 
> > *dev,
> >  * a WM level. */
> > results->enable_fbc_wm = true;
> > for (level = 1; level <= max_level; level++) {
> > -   if (!lp_results[level - 1].fbc_val > lp_maximums->fbc) {
> > +   if (lp_results[level - 1].fbc_val > lp_maximums->fbc) {
> > results->enable_fbc_wm = false;
> > lp_results[level - 1].fbc_val = 0;
> > }
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

[Rob Clark]

On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey  wrote:
> Hi Daniel, Rob.
>
> Thank you both for your reviews - greatly appreciated!
>
>> > > Known issues:
>> > >  * It still includes code to use KDS, which is not going upstream.
>> >
>> > review's on > > July/042462.html> can't hurt
>> >
>> > although you might consider submitting a reduced functionality driver
>> > w/ KDS bits removed in the mean time.. then when the fence stuff is
>> > merged it is just an incremental patch rather than a whole driver ;-)
>>
>> Yeah, I think the KDS bits and comments need to go first before
>> merginge.
>
> Right, as I expected really. Though as I said we'll probably wait for
> fences to land and switch over to that before asking for it to be
> merged. A pl111 KMS driver with neither KDS nor implicit fences is
> useless to us. Having said that, if someone else would have a use for
> a fence/KDS-less pl111 KMS driver, please let me know!
>

well, it would make it easier to review the patches adding fence
support if it was on top of basic KMS support.  So there still is some
benefit to a fence-less pl111, even if it is just for purposes of git
history and patch review ;-)

>
>> > > +/*
>> > > + * Number of flips allowed in flight at any one time. Any more
>> > > + * flips requested beyond this value will cause the caller to
>> > > + * block until earlier flips have completed.
>> > > + *
>> > > + * For performance reasons, this must be greater than the number
>> > > + * of buffers used in the rendering pipeline. Note that the
>> > > + * rendering pipeline can contain different types of buffer, e.g.:
>> > > + * - 2 final framebuffers
>> > > + * - >2 geometry buffers for GPU use-cases
>> > > + * - >2 vertex buffers for GPU use-cases
>> > > + *
>> > > + * For example, a system using 5 geometry buffers could have 5
>> > > + * flips in flight, and so NR_FLIPS_IN_FLIGHT_THRESHOLD must be
>> > > + * 5 or greater.
>> > > + *
>> > > + * Whilst there may be more intermediate buffers (such as
>> > > + * vertex/geometry) than final framebuffers, KDS is used to
>> > > + * ensure that GPU rendering waits for the next off-screen
>> > > + * buffer, so it doesn't overwrite an on-screen buffer and
>> > > + * produce tearing.
>> > > + */
>> > > +
>> >
>> > fwiw, this is at least different from how other drivers do triple
>> > (or > double) buffering.  In other drivers (intel, omap, and
>> > msm/freedreno, that I know of, maybe others too) the xorg driver
>> > dri2 bits implement the double buffering (ie. send flip event back
>> > to client immediately and queue up the flip and call page-flip
>> > after the pageflip event back from kernel.
>> >
>> > I'm not saying not to do it this way, I guess I'd like to hear
>> > what other folks think.  I kinda prefer doing this in userspace
>> > as it keeps the kernel bits simpler (plus it would then work
>> > properly on exynosdrm or other kms drivers).
>>
>> Yeah, if this is just a sw queue then I don't think it makes sense
>> to have it in the kernel. Afaik the current pageflip interface drm
>> exposes allows one oustanding flip only, and you _must_ wait for
>> the flip complete event before you can submit the second one.
>
> Right, I'll have a think about this. I think our idea was to issue
> enough page-flips into the kernel to make sure that any process
> scheduling latencies on a heavily loaded system don't cause us to
> miss a v_sync deadline. At the moment we issue the page flip from DRI2
> schedule_swap. If we were to move that to the page flip event handler
> of the previous page-flip, we're potentially adding in extra latency.
>
> I.e. Currently we have:
>
> DRI2SwapBuffers
>  - drm_mode_page_flip to buffer B
> DRI2SwapBuffers
>  - drm_mode_page_flip to buffer A (gets queued in kernel)
> ...
> v_sync! (at this point buffer B is scanned out)
>  - release buffer A's KDS resource/signal buffer A's fence
> - queued GPU job to render next frame to buffer A scheduled on HW
> ...
> GPU interrupt! (at this point buffer A is ready to be scanned out)
>  - release buffer A's KDS resource/signal buffer A's fence
> - second page flip executed, buffer A's address written to scanout
>   register, takes effect on next v_sync.
>
>
> So in the above, after X receives the second DRI2SwapBuffers, it
> doesn't need to get scheduled again for the next frame to be both
> rendered by the GPU and issued to the display for scanout.

well, this is really only an issue if you are so loaded that you don't
get a chance to schedule for ~16ms.. which is pretty long time.  If
you are triple buffering, it should not end up in the critical path
(since the gpu already has the 3rd buffer to start on the next frame).
 And, well, if you do it all in the kernel you probably need to toss
things over to a workqueue anyways.

>
>
> If we were to move to a user-space queue, I think we have something
> like this:
>
> DRI2SwapBuffers
>  - drm_mode_page_flip to buffer B
> DRI

Re: [PATCHv2 5/5] ARM: dts: Add dt binding documentation for exynos rotator

[Stephen Warren]

On 08/09/2013 07:15 AM, Tomasz Figa wrote:
> Hi Chanho,
> 
> On Friday 09 of August 2013 16:40:53 Chanho Park wrote:
>> This patch describes each nodes of rotator and specifies a example how to
>> bind it.

>> diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt

>> +* Samsung Image Rotator
>> +
>> +Required properties:
>> +  - compatible : value should be following:
>> +(a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210
>> +(b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412
>> +(c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250

Is "rotator" the name that the HW documentation uses to refer to this
block? If so, those compatible values seem fine. If not, they seem
slightly too generic for me; perhaps better to use the raw HW block name?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add drm_bridge

[Daniel Vetter]

On Fri, Aug 09, 2013 at 09:19:22AM -0400, Sean Paul wrote:
> On Thu, Aug 8, 2013 at 8:36 PM, Daniel Vetter  wrote:
> > On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul  wrote:
> >> This patch adds the notion of a drm_bridge. A bridge is a chained
> >> device which hangs off an encoder. The drm driver using the bridge
> >> should provide the association between encoder and bridge. Once a
> >> bridge is associated with an encoder, it will participate in mode
> >> set, dpms, and optionally connection detection.
> >>
> >> Since a connector may not be able to determine the connection state
> >> downstream of the bridge, bridges may implement detect() which will take
> >> precedence over connector detect() if the bridge is already attached
> >> to an encoder and that encoder is already attached to the connector.
> >> In practical terms, this requires the drm driver to make these
> >> associations at init time, which is fine for SoC applications where
> >> this link is static.
> >>
> >> Signed-off-by: Sean Paul 
> >
> > A few comments below. I think overall any such infrastructure simply
> > needs to demonstrate viability on a few drivers, that makes it much
> > simpler to check whether the interfaces make sense.
> 
> Thanks for your feedback, Daniel.
> 
> As mentioned by Stephane and Rob, there are a few drivers already
> using this. In the ChromeOS tree, we have 2 simple DP->LVDS bridges
> which quite frankly aren't terribly interesting atm, and we'll be
> converting an HDMI->myDP bridge in a couple of weeks (time permitting,
> of course).
> 
> 
> > Generally I'd make
> > more sense for me if the bridge is just an implementation detail of a
> > given encoder and if the bridge would not be exposed to the crtc
> > helpers.
> 
> After we discussed this on IRC, I converted our exynos driver to do
> this. You can check out the patch here
> (https://gerrit.chromium.org/gerrit/#/c/64680).

Hm, looking at this (I didn't read the full thing) it smells a bit like
exynos registers the connector first eg as hdmi. And then it sets up the
hdmi->whatever bridge later on. Imo (and presuming my 5 minutes strolling
around guess is right) that's the wrong approach since the connector is
the userspace interface object and should represent the actual output
port. So if you have a pile of conversion bridges that's irrelevant and
the user doesn't really care that the first step is a hmdi connetion if it
eventually ends up on a lvds panel (or something like that). Instead the
connector should be registered by the last bridge, with the correct type.

> It felt like a lot of boilerplate code that would be duplicated in
> every drm driver. Given the number of hooks we have, it's a pretty
> fine granularity such that there aren't *that* many creative ways to
> order things (famous last words). If a driver finds the need to differ
> from the helper order, they probably aren't going to be using the
> helper anyways.

I think you haven't seen some of the fun stuff we've done in i915 before
we've given up and scrapped it all ;-) But the current interface look
sensible enough that we can fix things by moving it back into drivers
again (and just leaving the the generic encoder->bridge pointer NULL).

> > With that abstraction chaining would be more natural imo and
> > we'd also have a much higher chance that bridge drivers work accross
> > different drm drivers: Atm you can run some encoder stuff in the crtc
> > callbacks and the other way round (and pretty much every driver for a
> > bit more complicated hw does that), and every driver can differ in
> > those tricks a bit. If we bake the bridge callbacks into the crtc
> > helpers I expect that for bridges with tricky ordering constraints
> > this will become a giant mess. So I'd prefer much if this would work
> > like drm i2c slave encoders.
> >
> 
> In the three bridge chips I've dealt with, they all try their best to
> be transparent to the encoder. They all fail at this. However their
> quirks are usually not dependent on the encoder implementation, but
> rather the general order of operations (ie: when to assert hotplug,
> video signal on, etc.).
> 
> Furthermore, drm_bridge will allow us to use bridges across drm
> drivers. For example, the HDMI->myDP driver I mentioned earlier is
> used on a number of platforms, not just exynos. It would be a waste to
> bind it to exynos when a more general implementation can be achieved.

I guess it's best to just look a bit at actual implementations, without
them my comments are likely rather useless.


> >> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> >> b/drivers/gpu/drm/drm_crtc_helper.c
> >> index 6a64749..30139fe 100644
> >> --- a/drivers/gpu/drm/drm_crtc_helper.c
> >> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> >> @@ -71,6 +71,23 @@ EXPORT_SYMBOL(drm_helper_move_panel_connectors_to_head);
> >>  static bool drm_kms_helper_poll = true;
> >>  module_param_named(poll, drm_kms_helper_poll, bool, 0600);
> >>
> >> +static enum drm_connector_status detect_c

Re: [RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

[Daniel Vetter]

On Fri, Aug 09, 2013 at 12:34:55PM -0400, Rob Clark wrote:
> On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey  wrote:
> >> > fwiw, this is at least different from how other drivers do triple
> >> > (or > double) buffering.  In other drivers (intel, omap, and
> >> > msm/freedreno, that I know of, maybe others too) the xorg driver
> >> > dri2 bits implement the double buffering (ie. send flip event back
> >> > to client immediately and queue up the flip and call page-flip
> >> > after the pageflip event back from kernel.
> >> >
> >> > I'm not saying not to do it this way, I guess I'd like to hear
> >> > what other folks think.  I kinda prefer doing this in userspace
> >> > as it keeps the kernel bits simpler (plus it would then work
> >> > properly on exynosdrm or other kms drivers).
> >>
> >> Yeah, if this is just a sw queue then I don't think it makes sense
> >> to have it in the kernel. Afaik the current pageflip interface drm
> >> exposes allows one oustanding flip only, and you _must_ wait for
> >> the flip complete event before you can submit the second one.
> >
> > Right, I'll have a think about this. I think our idea was to issue
> > enough page-flips into the kernel to make sure that any process
> > scheduling latencies on a heavily loaded system don't cause us to
> > miss a v_sync deadline. At the moment we issue the page flip from DRI2
> > schedule_swap. If we were to move that to the page flip event handler
> > of the previous page-flip, we're potentially adding in extra latency.
> >
> > I.e. Currently we have:
> >
> > DRI2SwapBuffers
> >  - drm_mode_page_flip to buffer B
> > DRI2SwapBuffers
> >  - drm_mode_page_flip to buffer A (gets queued in kernel)
> > ...
> > v_sync! (at this point buffer B is scanned out)
> >  - release buffer A's KDS resource/signal buffer A's fence
> > - queued GPU job to render next frame to buffer A scheduled on HW
> > ...
> > GPU interrupt! (at this point buffer A is ready to be scanned out)
> >  - release buffer A's KDS resource/signal buffer A's fence
> > - second page flip executed, buffer A's address written to scanout
> >   register, takes effect on next v_sync.
> >
> >
> > So in the above, after X receives the second DRI2SwapBuffers, it
> > doesn't need to get scheduled again for the next frame to be both
> > rendered by the GPU and issued to the display for scanout.
> 
> well, this is really only an issue if you are so loaded that you don't
> get a chance to schedule for ~16ms.. which is pretty long time.  If
> you are triple buffering, it should not end up in the critical path
> (since the gpu already has the 3rd buffer to start on the next frame).
>  And, well, if you do it all in the kernel you probably need to toss
> things over to a workqueue anyways.

Just a quick comment on the kernel flip queue issue.

16 ms scheduling latency sounds awful but totally doable with a less than
stellar ddx driver going into limbo land and so preventing your single
threaded X from doing more useful stuff. Is this really the linux
scheduler being stupid?

At least my impression was that the hw/kernel flip queue is to save power
so that you can queue up a few frames and everything goes to sleep for
half a second or so (at 24fps or whatever movie your showing). Needing to
schedule 5 frames ahead with pageflips under load is just guaranteed to
result in really horrible interactivity and so awful user experience ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 5/5] ARM: dts: Add dt binding documentation for exynos rotator

[Tomasz Figa]

On Friday 09 of August 2013 10:38:30 Stephen Warren wrote:
> On 08/09/2013 07:15 AM, Tomasz Figa wrote:
> > Hi Chanho,
> > 
> > On Friday 09 of August 2013 16:40:53 Chanho Park wrote:
> >> This patch describes each nodes of rotator and specifies a example how
> >> to bind it.
> >> 
> >> diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> >> 
> >> +* Samsung Image Rotator
> >> +
> >> +Required properties:
> >> +  - compatible : value should be following:
> >> +  (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210
> >> +  (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412
> >> +  (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250
> 
> Is "rotator" the name that the HW documentation uses to refer to this
> block?

Yes, it is. More specifically it is referred to as "Image Rotator".

Best regards,
Tomasz

> If so, those compatible values seem fine. If not, they seem
> slightly too generic for me; perhaps better to use the raw HW block name?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

[Rob Clark]

On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey  wrote:
>
>> > Turning to DRM/KMS, it seems the supported formats of a plane can be
>> > queried using drm_mode_get_plane. However, there doesn't seem to be a
>> > way to query the supported formats of a crtc? If display HW only
>> > supports scanning out from a single buffer (like pl111 does), I think
>> > it won't have any planes and a fb can only be set on the crtc. In
>> > which case, how should user-space query which pixel formats that crtc
>> > supports?
>>
>> it is exposed for drm plane's.  What is missing is to expose the
>> primary-plane associated with the crtc.
>
> Cool - so a patch which adds a way to query the what formats a crtc
> supports would be welcome?

well, I kinda think we want something that exposes the "primary plane"
of the crtc.. I'm thinking something roughly like:

-
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 53db7ce..c7ffca8 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -157,6 +157,12 @@ struct drm_mode_get_plane {
 struct drm_mode_get_plane_res {
__u64 plane_id_ptr;
__u32 count_planes;
+   /* The primary planes are in matching order to crtc_id_ptr in
+* drm_mode_card_res (and same length).  For crtc_id[n], it's
+* primary plane is given by primary_plane_id[n].
+*/
+   __u32 count_primary_planes;
+   __u64 primary_plane_id_ptr;
 };

 #define DRM_MODE_ENCODER_NONE  0
-

then use the existing GETPLANE ioctl to query the capabilities

> What about a way to query the stride alignment constraints?
>
> Presumably using the drm_mode_get_property mechanism would be the
> right way to implement that?
>

I suppose you could try that.. typically that is in userspace,
however.  It seems like get_property would get messy quickly (ie. is
it a pitch alignment constraint, or stride alignment?  What if this is
different for different formats (in particular tiled)? etc)

>
>> > As with v4l2, DRM doesn't appear to have a way to query the stride
>> > constraints? Assuming there is a way to query the stride constraints,
>> > there also isn't a way to specify them when creating a buffer with
>> > DRM, though perhaps the existing pitch parameter of
>> > drm_mode_create_dumb could be used to allow user-space to pass in a
>> > minimum stride as well as receive the allocated stride?
>> >
>>
>> well, you really shouldn't be using create_dumb..  you should have a
>> userspace piece that is specific to the drm driver, and knows how to
>> use that driver's gem allocate ioctl.
>
> Sorry, why does this need a driver-specific allocation function? It's
> just a display controller driver and I just want to allocate a scan-
> out buffer - all I'm asking is for the display controller driver to
> use a minimum stride alignment so I can export the buffer and use
> another device to fill it with data.

Sure.. but userspace has more information readily available to make a
better choice.  For example, for omapdrm I'd do things differently
depending on whether I wanted to scan out that buffer (or a portion of
it) rotated.  This is something I know in the DDX driver, but not in
the kernel.  And it is quite likely something that is driver specific.
 Sure, we could add that to a generic "allocate me a buffer" ioctl.
But that doesn't really seem better, and it becomes a problem as soon
as we come across some hw that needs to know something different.  In
userspace, you have a lot more flexibility, since you don't really
need to commit to an API for life.

And to bring back the GStreamer argument (since that seems a fitting
example when you start talking about sharing buffers between many
devices, for example camera+codec+display), it would already be
negotiating format between v4l2src + fooencoder + displaysink.. the
pitch/stride is part of that format information.  If the display isn't
the one with the strictest requirements, we don't want the display
driver deciding what pitch to use.

> The whole point is to be able to allocate the buffer in such a way
> that another device can access it. So the driver _can't_ use a
> special, device specific format, nor can it allocate it from a
> private memory pool because doing so would preclude it from being
> shared with another device.
>
> That other device doesn't need to be a GPU wither, it could just as
> easily be a camera/ISP or video decoder.
>
>
>
>> >> > So presumably you're talking about a GPU driver being the exporter
>> >> > here? If so, how could the GPU driver do these kind of tricks on
>> >> > memory shared with another device?
>> >>
>> >> Yes, that is gpu-as-exporter.  If someone else is allocating
>> >> buffers, it is up to them to do these tricks or not.  Probably
>> >> there is a pretty good chance that if you aren't a GPU you don't
>> >> need those sort of tricks for fast allocation of transient upload
>> >> buffers, staging textures, temporary pixmaps, etc.  Ie. I don't
>> >> really th

RE: [RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

[Tom Cooksey]

> > > So in the above, after X receives the second DRI2SwapBuffers, it
> > > doesn't need to get scheduled again for the next frame to be both
> > > rendered by the GPU and issued to the display for scanout.
> >
> > well, this is really only an issue if you are so loaded that you
> > don't get a chance to schedule for ~16ms.. which is pretty long time.

Yes - it really is 16ms (minus interrupt/workqueue latency) isn't it?
Hmmm, that does sound very long. Will try out some experiments and see.


> > If you are triple buffering, it should not end up in the critical 
> > path (since the gpu already has the 3rd buffer to start on the next
> > frame). And, well, if you do it all in the kernel you probably need
> > to toss things over to a workqueue anyways.
> 
> Just a quick comment on the kernel flip queue issue.
> 
> 16 ms scheduling latency sounds awful but totally doable with a less
> than stellar ddx driver going into limbo land and so preventing your
> single threaded X from doing more useful stuff. Is this really the 
> linux scheduler being stupid?

Ahahhaaa!! Yes!!! Really good point. We generally don't have 2D HW and
so rely on pixman to perform all 2D operations which does indeed tie
up that thread for fairly long periods of time.

We've had internal discussions about introducing a thread (gulp) in
the DDX to off-load drawing operations to. I think we were all a bit
scared by that idea though.


BTW: I wasn't suggesting it was the linux scheduler being stupid, just
that there is sometimes lots of contention over the CPU cores and X
is just one thread among many wanting to run.


> At least my impression was that the hw/kernel flip queue is to save
> power so that you can queue up a few frames and everything goes to
> sleep for half a second or so (at 24fps or whatever movie your
> showing). Needing to schedule 5 frames ahead with pageflips under
> load is just guaranteed to result in really horrible interactivity
> and so awful user experience

Agreed. There's always a tradeoff between tolerance to variable frame
rendering time/system latency (lot of buffers) and UI latency (few
buffers). 

As a side note, video playback is one use-case for explicit sync
objects which implicit/buffer-based sync doesn't handle: Queue up lots
of video frames for display, but mark those "display buffer" 
operations as depending on explicit sync objects which get signalled 
by the audio clock. Not sure Android actually does that yet though. 
Anyway, off topic.


Cheers,

Tom





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

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state

[bugzilla-daemon]

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

Alexandre Demers  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #32 from Alexandre Demers  ---
Closing this bug since fixed since a few of releases.

-- 
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 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

[bugzilla-daemon]

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

--- Comment #16 from Harald Judt  ---
Just as I wanted to write that everything works ok with uvd enabled and this
bug can be closed, after the 19th suspend/hibernate attempt the machine failed
to resume, with the screen simply going black and reporting no signal :-(

I've tried to resume from the same image 5 times but to no avail, so I'm back
now with radeon.no_uvd=1 for a while to give it a test with real-world usage
pattern. Just to be sure that this works in all cases too.

-- 
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 17/25] drm: rip out drm_core_has_MTRR checks

[Daniel Vetter]

On Fri, Aug 9, 2013 at 8:12 PM, Andy Lutomirski  wrote:
> On Thu, Aug 8, 2013 at 6:41 AM, Daniel Vetter  wrote:
>> The new arch_phys_wc_add/del functions do the right thing both with
>> and without MTRR support in the kernel. So we can drop these
>> additional checks.
>
> If any of the new arch_phys_wc_add calls are reachable and if the
> driver calls arch_phys_wc_add itself, then the lack of refcounting on
> non-PAT systems may cause a problem.  (I don't understand the drm
> stuff well enough to know whether that can actually happen.)

This is only about compile-time options really. Somehow drm had the
idea to use these check functions instead of #ifdef plus dummy static
inline noop functions. David Herrmann just did the same patch for the
agp stuff. So refcounting is of no concern here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 17/25] drm: rip out drm_core_has_MTRR checks

[Daniel Vetter]

On Fri, Aug 9, 2013 at 8:39 PM, Andy Lutomirski  wrote:
> On Fri, Aug 9, 2013 at 11:36 AM, Daniel Vetter  wrote:
>> On Fri, Aug 9, 2013 at 8:12 PM, Andy Lutomirski  wrote:
>>> On Thu, Aug 8, 2013 at 6:41 AM, Daniel Vetter  
>>> wrote:
 The new arch_phys_wc_add/del functions do the right thing both with
 and without MTRR support in the kernel. So we can drop these
 additional checks.
>>>
>>> If any of the new arch_phys_wc_add calls are reachable and if the
>>> driver calls arch_phys_wc_add itself, then the lack of refcounting on
>>> non-PAT systems may cause a problem.  (I don't understand the drm
>>> stuff well enough to know whether that can actually happen.)
>>
>> This is only about compile-time options really. Somehow drm had the
>> idea to use these check functions instead of #ifdef plus dummy static
>> inline noop functions. David Herrmann just did the same patch for the
>> agp stuff. So refcounting is of no concern here.
>
> I feel like I'm missing something obvious here.  On nouveau, prior to
> this patch, the drm maps code would not touch mtrrs.  Now it will.
> Nouveau already calls arch_phys_wc_add, so if that maps code is
> reached on the same resource, then there could be refcounting issues.

Oh that kind of confusion. The maps code here is for old userspace
drivers, I have some patches in the queue that will disable it
properly for kms drivers. So it should never happen that both the kms
driver and the maps code in the drm core set up a mtrr mapping. And if
it happens someone is doing something really nasty, and that hole will
soon be plugged.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54143] Error when running GLSL_deferred

[bugzilla-daemon]

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

Alexandre Demers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #2 from Alexandre Demers  ---
Closing since it is probably a problem with the demo application itself.

-- 
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: [GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC

[Dave Airlie]

On Thu, Aug 8, 2013 at 11:39 AM, Simon Horman  wrote:
> On Thu, Aug 08, 2013 at 03:34:17AM +0200, Laurent Pinchart wrote:
>> Hi Dave,
>>
>> (CC'ing Simon Horman, the shmobile tree maintainer)
>>
>> On Thursday 08 August 2013 10:57:33 Dave Airlie wrote:
>> > On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote:
>> > > Hi Dave,
>> > >
>> > > I've got a couple of arch/arm/ patches that depend on this series and 
>> > > that
>> > > I would like to get merged in v3.12. They should go upstream through the
>> > > arm-soc tree. Would you be able to provide a stable branch with this
>> > > patch set based on one of the 3.11-rcX tags ? Ideally that branch should
>> > > have as little patches as possible other than this set.
>> >
>> > Yeah that shouldn't be a problem, though is there any interface changes or
>> > things with this wrt drm-next?
>> >
>> > i.e. will this tree build on v3.11-rcX and drm-next?
>>
>> They depend on a fix that went in between -rc1 and -rc2. You can base the
>> branch on any -rc >= 2.
>
> An rc2 or rc3 base would be ideal for me, but any rc would be fine.

So the problem with making a stable branch is we have conflicts in
other places that have already been solved in drm-next,

is there any problem with using Laurent's tree directly as the stable point?

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

[Bug 67927] R600_DEBUG=sb: Celestia show 2 earths, one wrongly rendered

[bugzilla-daemon]

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

--- Comment #2 from Dieter Nützel  ---
Created attachment 83906
  --> https://bugs.freedesktop.org/attachment.cgi?id=83906&action=edit
celestia started with R600_DEBUG=sb,ps,vs

-- 
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 67927] R600_DEBUG=sb: Celestia show 2 earths, one wrongly rendered

[bugzilla-daemon]

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

--- Comment #3 from Dieter Nützel  ---
(In reply to comment #1)
> So far I can't reproduce this issue. Please test with the latest mesa from
> git if you are using older version.

I normally use git only...
...fixed an error in git last night ;-)

> If llvm backend is active in your
> configuration, you might want to update llvm as well

/home/dieter> llvm-config --version
3.3svn
openSUSE 12.3 distro version

I wouldn't use git LLVM on my working machinery if it is doable.

> or test the application
> with R600_DEBUG=sb,nollvm.

Good point!
Without LLVM it works, OK.

> Also please attach the output with R600_DEBUG=sb,ps,vs

See Comment 2.

Thanks,
  Dieter

-- 
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: [GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC

[Laurent Pinchart]

Hi Dave,

On Saturday 10 August 2013 06:45:05 Dave Airlie wrote:
> On Thu, Aug 8, 2013 at 11:39 AM, Simon Horman  wrote:
> > On Thu, Aug 08, 2013 at 03:34:17AM +0200, Laurent Pinchart wrote:
> >> Hi Dave,
> >> 
> >> (CC'ing Simon Horman, the shmobile tree maintainer)
> >> 
> >> On Thursday 08 August 2013 10:57:33 Dave Airlie wrote:
> >> > On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote:
> >> > > Hi Dave,
> >> > > 
> >> > > I've got a couple of arch/arm/ patches that depend on this series and
> >> > > that I would like to get merged in v3.12. They should go upstream
> >> > > through the arm-soc tree. Would you be able to provide a stable
> >> > > branch with this patch set based on one of the 3.11-rcX tags ?
> >> > > Ideally that branch should have as little patches as possible other
> >> > > than this set.
> >> > 
> >> > Yeah that shouldn't be a problem, though is there any interface changes
> >> > or things with this wrt drm-next?
> >> > 
> >> > i.e. will this tree build on v3.11-rcX and drm-next?
> >> 
> >> They depend on a fix that went in between -rc1 and -rc2. You can base the
> >> branch on any -rc >= 2.
> > 
> > An rc2 or rc3 base would be ideal for me, but any rc would be fine.
> 
> So the problem with making a stable branch is we have conflicts in other
> places that have already been solved in drm-next,
> 
> is there any problem with using Laurent's tree directly as the stable point?

As agreed on IRC, I've rebased the patches on top of v3.11-rc3 and pushed the 
result to

git://linuxtv.org/pinchartl/fbdev.git drm/next/du

 b/drivers/gpu/drm/rcar-du/Kconfig   |7 

   
 b/drivers/gpu/drm/rcar-du/Makefile  |   10 -   

   
 b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  255 +-
 b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h|   13 -
 b/drivers/gpu/drm/rcar-du/rcar_du_drv.c |  173 +++---
 b/drivers/gpu/drm/rcar-du/rcar_du_drv.h |   63 +-
 b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  202 ++
 b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h |   49 +
 b/drivers/gpu/drm/rcar-du/rcar_du_group.c   |  187 
 b/drivers/gpu/drm/rcar-du/rcar_du_group.h   |   50 +
 b/drivers/gpu/drm/rcar-du/rcar_du_kms.c |  165 ++
 b/drivers/gpu/drm/rcar-du/rcar_du_kms.h |   29 ---
 b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  131 ++
 b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |   25 ++
 b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |  196 +
 b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |   46 +
 b/drivers/gpu/drm/rcar-du/rcar_du_plane.c   |  170 +-
 b/drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   26 ++
 b/drivers/gpu/drm/rcar-du/rcar_du_regs.h|   94 --
 b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |   96 ++
 b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.h  |   23 ++
 b/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h  |   69 +++
 b/include/linux/platform_data/rcar-du.h |   34 ++-
 drivers/gpu/drm/rcar-du/rcar_du_lvds.c  |  216 ---
 drivers/gpu/drm/rcar-du/rcar_du_lvds.h  |   24 --
 drivers/gpu/drm/rcar-du/rcar_du_vga.c   |  149 
 drivers/gpu/drm/rcar-du/rcar_du_vga.h   |   24 --
 27 files changed, 1665 insertions(+), 861 deletions(-)

Can you merge that into drm-next ? Simon, you can base the r8a7790 arch/ 
patches on top of this drm/next/du branch.

-- 
Regards,

Laurent Pinchart

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

[PATCH] drm/nouveau/fb: fix null derefs in nv49 and nv4e init

[Ilia Mirkin]

Commit dceef5d87 (drm/nouveau/fb: initialise vram controller as pfb
sub-object) moved some code around and introduced these null derefs.
pfb->ram is set to the new ram object outside of this ctor.

Reported-by: Ronald Uitermark 
Tested-by: Ronald Uitermark 
Signed-off-by: Ilia Mirkin 
---
 drivers/gpu/drm/nouveau/core/subdev/fb/ramnv49.c | 12 ++--
 drivers/gpu/drm/nouveau/core/subdev/fb/ramnv4e.c |  4 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramnv49.c 
b/drivers/gpu/drm/nouveau/core/subdev/fb/ramnv49.c
index 19e3a9a..ab7ef0a 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/fb/ramnv49.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/fb/ramnv49.c
@@ -40,15 +40,15 @@ nv49_ram_create(struct nouveau_object *parent, struct 
nouveau_object *engine,
return ret;
 
switch (pfb914 & 0x0003) {
-   case 0x: pfb->ram->type = NV_MEM_TYPE_DDR1; break;
-   case 0x0001: pfb->ram->type = NV_MEM_TYPE_DDR2; break;
-   case 0x0002: pfb->ram->type = NV_MEM_TYPE_GDDR3; break;
+   case 0x: ram->type = NV_MEM_TYPE_DDR1; break;
+   case 0x0001: ram->type = NV_MEM_TYPE_DDR2; break;
+   case 0x0002: ram->type = NV_MEM_TYPE_GDDR3; break;
case 0x0003: break;
}
 
-   pfb->ram->size  =  nv_rd32(pfb, 0x10020c) & 0xff00;
-   pfb->ram->parts = (nv_rd32(pfb, 0x100200) & 0x0003) + 1;
-   pfb->ram->tags  =  nv_rd32(pfb, 0x100320);
+   ram->size  =  nv_rd32(pfb, 0x10020c) & 0xff00;
+   ram->parts = (nv_rd32(pfb, 0x100200) & 0x0003) + 1;
+   ram->tags  =  nv_rd32(pfb, 0x100320);
return 0;
 }
 
diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramnv4e.c 
b/drivers/gpu/drm/nouveau/core/subdev/fb/ramnv4e.c
index 7192aa6..63a6aab 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/fb/ramnv4e.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/fb/ramnv4e.c
@@ -38,8 +38,8 @@ nv4e_ram_create(struct nouveau_object *parent, struct 
nouveau_object *engine,
if (ret)
return ret;
 
-   pfb->ram->size = nv_rd32(pfb, 0x10020c) & 0xff00;
-   pfb->ram->type = NV_MEM_TYPE_STOLEN;
+   ram->size = nv_rd32(pfb, 0x10020c) & 0xff00;
+   ram->type = NV_MEM_TYPE_STOLEN;
return 0;
 }
 
-- 
1.8.1.5

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

Re: [GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC

[Dave Airlie]

On Sat, Aug 10, 2013 at 7:25 AM, Laurent Pinchart
 wrote:
> Hi Dave,
>
> On Saturday 10 August 2013 06:45:05 Dave Airlie wrote:
>> On Thu, Aug 8, 2013 at 11:39 AM, Simon Horman  wrote:
>> > On Thu, Aug 08, 2013 at 03:34:17AM +0200, Laurent Pinchart wrote:
>> >> Hi Dave,
>> >>
>> >> (CC'ing Simon Horman, the shmobile tree maintainer)
>> >>
>> >> On Thursday 08 August 2013 10:57:33 Dave Airlie wrote:
>> >> > On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote:
>> >> > > Hi Dave,
>> >> > >
>> >> > > I've got a couple of arch/arm/ patches that depend on this series and
>> >> > > that I would like to get merged in v3.12. They should go upstream
>> >> > > through the arm-soc tree. Would you be able to provide a stable
>> >> > > branch with this patch set based on one of the 3.11-rcX tags ?
>> >> > > Ideally that branch should have as little patches as possible other
>> >> > > than this set.
>> >> >
>> >> > Yeah that shouldn't be a problem, though is there any interface changes
>> >> > or things with this wrt drm-next?
>> >> >
>> >> > i.e. will this tree build on v3.11-rcX and drm-next?
>> >>
>> >> They depend on a fix that went in between -rc1 and -rc2. You can base the
>> >> branch on any -rc >= 2.
>> >
>> > An rc2 or rc3 base would be ideal for me, but any rc would be fine.
>>
>> So the problem with making a stable branch is we have conflicts in other
>> places that have already been solved in drm-next,
>>
>> is there any problem with using Laurent's tree directly as the stable point?
>
> As agreed on IRC, I've rebased the patches on top of v3.11-rc3 and pushed the
> result to
>
> git://linuxtv.org/pinchartl/fbdev.git drm/next/du
>
>  b/drivers/gpu/drm/rcar-du/Kconfig   |7
>  b/drivers/gpu/drm/rcar-du/Makefile  |   10 -
>  b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  255 +-
>  b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h|   13 -
>  b/drivers/gpu/drm/rcar-du/rcar_du_drv.c |  173 +++---
>  b/drivers/gpu/drm/rcar-du/rcar_du_drv.h |   63 +-
>  b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  202 ++
>  b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h |   49 +
>  b/drivers/gpu/drm/rcar-du/rcar_du_group.c   |  187 
>  b/drivers/gpu/drm/rcar-du/rcar_du_group.h   |   50 +
>  b/drivers/gpu/drm/rcar-du/rcar_du_kms.c |  165 ++
>  b/drivers/gpu/drm/rcar-du/rcar_du_kms.h |   29 ---
>  b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  131 ++
>  b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |   25 ++
>  b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |  196 +
>  b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |   46 +
>  b/drivers/gpu/drm/rcar-du/rcar_du_plane.c   |  170 +-
>  b/drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   26 ++
>  b/drivers/gpu/drm/rcar-du/rcar_du_regs.h|   94 --
>  b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |   96 ++
>  b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.h  |   23 ++
>  b/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h  |   69 +++
>  b/include/linux/platform_data/rcar-du.h |   34 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_lvds.c  |  216 ---
>  drivers/gpu/drm/rcar-du/rcar_du_lvds.h  |   24 --
>  drivers/gpu/drm/rcar-du/rcar_du_vga.c   |  149 
>  drivers/gpu/drm/rcar-du/rcar_du_vga.h   |   24 --
>  27 files changed, 1665 insertions(+), 861 deletions(-)
>
> Can you merge that into drm-next ? Simon, you can base the r8a7790 arch/
> patches on top of this drm/next/du branch.

Actually small change

Simon can you use

git://git.freedesktop.org/~airlied/linux drm-rcar-for-v3.12

as I've merged this tree with an S-o-b on the merge commit, so other
people will know it has gone via me.

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

[Bug 67927] R600_DEBUG=sb: Celestia show 2 earths, one wrongly rendered

[bugzilla-daemon]

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

--- Comment #4 from Vadim Girlin  ---
Created attachment 83907
  --> https://bugs.freedesktop.org/attachment.cgi?id=83907&action=edit
[PATCH] r600g/sb: use MULADD workaround on 7xx for MULADD_IEEE

Does this patch help?

-- 
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/RFC v3 00/19] Common Display Framework

[Laurent Pinchart]

Hi everybody,

Here's the third RFC of the Common Display Framework. This is a resent, the
series I've sent earlier seems not to have made it to the vger mailing lists,
possibly due to a too long list of CCs (the other explanation being that CDF
has been delayed for so long that vger considers it as spam, which I really
hope isn't the case :-)). I've thus dropped the CCs, sorry about that.

I won't repeat all the background information from the versions one and two
here, you can read it at http://lwn.net/Articles/512363/ and
http://lwn.net/Articles/526965/.

This RFC isn't final. Given the high interest in CDF and the urgent tasks that
kept delaying the next version of the patch set, I've decided to release v3
before completing all parts of the implementation. Known missing items are

- documentation: kerneldoc and this cover letter should provide basic
  information, more extensive documentation will likely make it to v4.

- pipeline configuration and control: generic code to configure and control
  display pipelines (in a nutshell, translating high-level mode setting and
  DPMS calls to low-level entity operations) is missing. Video and stream
  control operations have been carried over from v2, but will need to be
  revised for v4.

- DSI support: I still have no DSI hardware I can easily test the code on.

Special thanks go to

- Renesas for inviting me to LinuxCon Japan 2013 where I had the opportunity
  to validate the CDF v3 concepts with Alexandre Courbot (NVidia) and Tomasz
  Figa (Samsung).

- Tomi Valkeinen (TI) for taking the time to deeply brainstorm v3 with me.

- Linaro for inviting me to Linaro Connect Europe 2013, the discussions we had
  there greatly helped moving CDF forward.

- And of course all the developers who showed interest in CDF and spent time
  sharing ideas, reviewing patches and testing code.

I have to confess I was a bit lost and discouraged after all the CDF-related
meetings during which we have discussed how to move from v2 to v3. With every
meeting I was hoping to run the implementation through use cases of various
interesting parties and narrow down the scope of the huge fuzzy beast that CDF
was. With every meeting the scope actually broadened, with no clear path at
sight anywhere.

Earlier this year I was about to drop one of the requirements on which I had
based CDF v2: sharing drivers between DRM/KMS and V4L2. With only two HDMI
transmitters as use cases for that feature (with only out-of-tree drivers so
far), I just thought the involved completely wasn't worth it and that I should
implement CDF v3 as a DRM/KMS-only helper framework. However, a seemingly
unrelated discussion with Xilinx developers showed me that hybrid SoC-FPGA
platforms such as the Xilinx Zynq 7000 have a larger library of IP cores that
can be used in camera capture pipelines and in display pipelines. The two use
cases suddenly became tens or even hundreds of use cases that I couldn't
ignore anymore.

CDF v3 is thus userspace API agnostic. It isn't tied to DRM/KMS or V4L2 and
can be used by any kernel subsystem, potentially including FBDEV (although I
won't personally wrote FBDEV support code, as I've already advocated for FBDEV
to be deprecated).

The code you are about to read is based on the concept of display entities
introduced in v2. Diagrams related to the explanations below are available at
http://ideasonboard.org/media/cdf/20130709-lce-cdf.pdf.


Display Entities


A display entity abstracts any hardware block that sources, processes or sinks
display-related video streams. It offers an abstract API, implemented by display
entity drivers, that is used by master drivers (such as the main display driver)
to query, configure and control display pipelines.

Display entities are connected to at least one video data bus, and optionally
to a control bus. The video data busses carry display-related video data out
of sources (such as a CRTC in a display controller) to sinks (such as a panel
or a monitor), optionally going through transmitters, encoders, decoders,
bridges or other similar devices. A CRTC or a panel will usually be connected
to a single data bus, while an encoder or a transmitter will be connected to
two data busses.

The simple linear display pipelines we find in most embedded platforms at the
moment are expected to grow more complex with time. CDF needs to accomodate
those needs from the start to be, if not future-proof, at least present-proof
at the time it will get merged in to mainline. For this reason display
entities have data ports through which video streams flow in or out, with link
objects representing the connections between those ports. A typical entity in
a linear display pipeline will have one (for video source and video sink
entities such as CRTCs or panels) or two ports (for video processing entities
such as encoders), but more ports are allowed, and entities can be linked in
complex non-linear pipelines.

Readers might think that this model if extreme

[PATCH/RFC v3 01/19] OMAPDSS: panels: Rename Kconfig options to OMAP2_DISPLAY_*

[Laurent Pinchart]

The DISPLAY_ prefix will clash with the Common Display Framework, rename
it.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/omap2/displays-new/Kconfig  | 24 
 drivers/video/omap2/displays-new/Makefile | 24 
 2 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/video/omap2/displays-new/Kconfig 
b/drivers/video/omap2/displays-new/Kconfig
index 6c90885..2a44b41 100644
--- a/drivers/video/omap2/displays-new/Kconfig
+++ b/drivers/video/omap2/displays-new/Kconfig
@@ -1,68 +1,68 @@
 menu "OMAP Display Device Drivers (new device model)"
 depends on OMAP2_DSS
 
-config DISPLAY_ENCODER_TFP410
+config OMAP2_DISPLAY_ENCODER_TFP410
 tristate "TFP410 DPI to DVI Encoder"
help
  Driver for TFP410 DPI to DVI encoder.
 
-config DISPLAY_ENCODER_TPD12S015
+config OMAP2_DISPLAY_ENCODER_TPD12S015
 tristate "TPD12S015 HDMI ESD protection and level shifter"
help
  Driver for TPD12S015, which offers HDMI ESD protection and level
  shifting.
 
-config DISPLAY_CONNECTOR_DVI
+config OMAP2_DISPLAY_CONNECTOR_DVI
 tristate "DVI Connector"
depends on I2C
help
  Driver for a generic DVI connector.
 
-config DISPLAY_CONNECTOR_HDMI
+config OMAP2_DISPLAY_CONNECTOR_HDMI
 tristate "HDMI Connector"
help
  Driver for a generic HDMI connector.
 
-config DISPLAY_CONNECTOR_ANALOG_TV
+config OMAP2_DISPLAY_CONNECTOR_ANALOG_TV
 tristate "Analog TV Connector"
help
  Driver for a generic analog TV connector.
 
-config DISPLAY_PANEL_DPI
+config OMAP2_DISPLAY_PANEL_DPI
tristate "Generic DPI panel"
help
  Driver for generic DPI panels.
 
-config DISPLAY_PANEL_DSI_CM
+config OMAP2_DISPLAY_PANEL_DSI_CM
tristate "Generic DSI Command Mode Panel"
help
  Driver for generic DSI command mode panels.
 
-config DISPLAY_PANEL_SONY_ACX565AKM
+config OMAP2_DISPLAY_PANEL_SONY_ACX565AKM
tristate "ACX565AKM Panel"
depends on SPI && BACKLIGHT_CLASS_DEVICE
help
  This is the LCD panel used on Nokia N900
 
-config DISPLAY_PANEL_LGPHILIPS_LB035Q02
+config OMAP2_DISPLAY_PANEL_LGPHILIPS_LB035Q02
tristate "LG.Philips LB035Q02 LCD Panel"
depends on SPI
help
  LCD Panel used on the Gumstix Overo Palo35
 
-config DISPLAY_PANEL_SHARP_LS037V7DW01
+config OMAP2_DISPLAY_PANEL_SHARP_LS037V7DW01
 tristate "Sharp LS037V7DW01 LCD Panel"
 depends on BACKLIGHT_CLASS_DEVICE
 help
   LCD Panel used in TI's SDP3430 and EVM boards
 
-config DISPLAY_PANEL_TPO_TD043MTEA1
+config OMAP2_DISPLAY_PANEL_TPO_TD043MTEA1
 tristate "TPO TD043MTEA1 LCD Panel"
 depends on SPI
 help
   LCD Panel used in OMAP3 Pandora
 
-config DISPLAY_PANEL_NEC_NL8048HL11
+config OMAP2_DISPLAY_PANEL_NEC_NL8048HL11
tristate "NEC NL8048HL11 Panel"
depends on SPI
depends on BACKLIGHT_CLASS_DEVICE
diff --git a/drivers/video/omap2/displays-new/Makefile 
b/drivers/video/omap2/displays-new/Makefile
index 5aeb11b..768ad94 100644
--- a/drivers/video/omap2/displays-new/Makefile
+++ b/drivers/video/omap2/displays-new/Makefile
@@ -1,12 +1,12 @@
-obj-$(CONFIG_DISPLAY_ENCODER_TFP410) += encoder-tfp410.o
-obj-$(CONFIG_DISPLAY_ENCODER_TPD12S015) += encoder-tpd12s015.o
-obj-$(CONFIG_DISPLAY_CONNECTOR_DVI) += connector-dvi.o
-obj-$(CONFIG_DISPLAY_CONNECTOR_HDMI) += connector-hdmi.o
-obj-$(CONFIG_DISPLAY_CONNECTOR_ANALOG_TV) += connector-analog-tv.o
-obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
-obj-$(CONFIG_DISPLAY_PANEL_DSI_CM) += panel-dsi-cm.o
-obj-$(CONFIG_DISPLAY_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
-obj-$(CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
-obj-$(CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
-obj-$(CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
-obj-$(CONFIG_DISPLAY_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
+obj-$(CONFIG_OMAP2_DISPLAY_ENCODER_TFP410) += encoder-tfp410.o
+obj-$(CONFIG_OMAP2_DISPLAY_ENCODER_TPD12S015) += encoder-tpd12s015.o
+obj-$(CONFIG_OMAP2_DISPLAY_CONNECTOR_DVI) += connector-dvi.o
+obj-$(CONFIG_OMAP2_DISPLAY_CONNECTOR_HDMI) += connector-hdmi.o
+obj-$(CONFIG_OMAP2_DISPLAY_CONNECTOR_ANALOG_TV) += connector-analog-tv.o
+obj-$(CONFIG_OMAP2_DISPLAY_PANEL_DPI) += panel-dpi.o
+obj-$(CONFIG_OMAP2_DISPLAY_PANEL_DSI_CM) += panel-dsi-cm.o
+obj-$(CONFIG_OMAP2_DISPLAY_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_OMAP2_DISPLAY_PANEL_LGPHILIPS_LB035Q02) += 
panel-lgphilips-lb035q02.o
+obj-$(CONFIG_OMAP2_DISPLAY_PANEL_SHARP_LS037V7DW01) += 
panel-sharp-ls037v7dw01.o
+obj-$(CONFIG_OMAP2_DISPLAY_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
+obj-$(CONFIG_OMAP2_DISPLAY_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.fr

[PATCH/RFC v3 02/19] video: Add Common Display Framework core

[Laurent Pinchart]

The Common Display Framework (CDF) splits display devices in entities
that interact through an abstract API. Each entity is managed by its own
driver independently of the other entities, with the framework
orchestrating interactions.

This commit introduces the CDF core with entity (un)registration and
core control operations support.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/Kconfig|   1 +
 drivers/video/Makefile   |   1 +
 drivers/video/display/Kconfig|   4 +
 drivers/video/display/Makefile   |   2 +
 drivers/video/display/display-core.c | 236 +++
 include/video/display.h  |  94 ++
 6 files changed, 338 insertions(+)
 create mode 100644 drivers/video/display/Kconfig
 create mode 100644 drivers/video/display/Makefile
 create mode 100644 drivers/video/display/display-core.c
 create mode 100644 include/video/display.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4cf1e1d..c9ca1d5 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2477,6 +2477,7 @@ source "drivers/video/omap2/Kconfig"
 source "drivers/video/exynos/Kconfig"
 source "drivers/video/mmp/Kconfig"
 source "drivers/video/backlight/Kconfig"
+source "drivers/video/display/Kconfig"
 
 if VT
source "drivers/video/console/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index e8bae8d..d7fd4a2 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -15,6 +15,7 @@ fb-objs   := $(fb-y)
 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
 obj-y+= backlight/
+obj-y+= display/
 
 obj-$(CONFIG_EXYNOS_VIDEO) += exynos/
 
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
new file mode 100644
index 000..1d533e7
--- /dev/null
+++ b/drivers/video/display/Kconfig
@@ -0,0 +1,4 @@
+menuconfig DISPLAY_CORE
+   tristate "Display Core"
+   ---help---
+ Support common display framework for graphics devices.
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
new file mode 100644
index 000..3054adc
--- /dev/null
+++ b/drivers/video/display/Makefile
@@ -0,0 +1,2 @@
+display-y  := display-core.o
+obj-$(CONFIG_DISPLAY_CORE) += display.o
diff --git a/drivers/video/display/display-core.c 
b/drivers/video/display/display-core.c
new file mode 100644
index 000..82fc58b
--- /dev/null
+++ b/drivers/video/display/display-core.c
@@ -0,0 +1,236 @@
+/*
+ * Display Core
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+/* 
-
+ * Control operations
+ */
+
+/**
+ * display_entity_get_modes - Get video modes supported by the display entity
+ * @entity: The display entity
+ * @port: The display entity port
+ * @modes: Pointer to an array of modes
+ *
+ * Fill the modes argument with a pointer to an array of video modes. The array
+ * is owned by the display entity.
+ *
+ * Return the number of supported modes on success (including 0 if no mode is
+ * supported) or a negative error code otherwise.
+ */
+int display_entity_get_modes(struct display_entity *entity, unsigned int port,
+const struct videomode **modes)
+{
+   if (port >= entity->entity.num_pads)
+   return -EINVAL;
+
+   if (!entity->ops->ctrl || !entity->ops->ctrl->get_modes)
+   return 0;
+
+   return entity->ops->ctrl->get_modes(entity, port, modes);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_modes);
+
+/**
+ * display_entity_get_size - Get display entity physical size
+ * @entity: The display entity
+ * @width: Physical width in millimeters
+ * @height: Physical height in millimeters
+ *
+ * When applicable, for instance for display panels, retrieve the display
+ * physical size in millimeters.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_get_size(struct display_entity *entity,
+   unsigned int *width, unsigned int *height)
+{
+   if (!entity->ops->ctrl || !entity->ops->ctrl->get_size)
+   return -EOPNOTSUPP;
+
+   return entity->ops->ctrl->get_size(entity, width, height);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_size);
+
+/**
+ * display_entity_get_params - Get display entity interface parameters
+ * @entity: The display entity
+ * @port: The display entity port
+ * @params: Pointer to interface parameters
+ *
+ * Fill the parameters structure pointed to by t

[PATCH/RFC v3 03/19] video: display: Add video and stream control operations

[Laurent Pinchart]

The video and stream control operations handle video stream management,
both from the control point of view (called in response to userspace
requests) and the video stream point of view (called by entities to
control the video stream they receive on their input(s)).

Signed-off-by: Laurent Pinchart 
---
 drivers/video/display/display-core.c | 82 
 include/video/display.h  | 49 +
 2 files changed, 131 insertions(+)

diff --git a/drivers/video/display/display-core.c 
b/drivers/video/display/display-core.c
index 82fc58b..bb18723 100644
--- a/drivers/video/display/display-core.c
+++ b/drivers/video/display/display-core.c
@@ -25,6 +25,57 @@
  */
 
 /**
+ * display_entity_set_state - Set the display entity operation state
+ * @entity: The display entity
+ * @state: Display entity operation state
+ *
+ * See &enum display_entity_state for information regarding the entity states.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_set_state(struct display_entity *entity,
+enum display_entity_state state)
+{
+   int ret;
+
+   if (entity->state == state)
+   return 0;
+
+   if (!entity->ops->ctrl || !entity->ops->ctrl->set_state)
+   return 0;
+
+   ret = entity->ops->ctrl->set_state(entity, state);
+   if (ret < 0)
+   return ret;
+
+   entity->state = state;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(display_entity_set_state);
+
+/**
+ * display_entity_update - Update the display
+ * @entity: The display entity
+ *
+ * Make the display entity ready to receive pixel data and start frame 
transfer.
+ * This operation can only be called if the display entity is in STANDBY or ON
+ * state.
+ *
+ * The display entity will call the upstream entity in the video chain to start
+ * the video stream.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_update(struct display_entity *entity)
+{
+   if (!entity->ops->ctrl || !entity->ops->ctrl->update)
+   return 0;
+
+   return entity->ops->ctrl->update(entity);
+}
+EXPORT_SYMBOL_GPL(display_entity_update);
+
+/**
  * display_entity_get_modes - Get video modes supported by the display entity
  * @entity: The display entity
  * @port: The display entity port
@@ -95,6 +146,36 @@ int display_entity_get_params(struct display_entity 
*entity, unsigned int port,
 EXPORT_SYMBOL_GPL(display_entity_get_params);
 
 /* 
-
+ * Video operations
+ */
+
+/**
+ * display_entity_set_stream - Control the video stream state
+ * @entity: The display entity
+ * @port: The display entity port
+ * @state: Display video stream state
+ *
+ * Control the video stream state at the entity video output.
+ *
+ * See &enum display_entity_stream_state for information regarding the stream
+ * states.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_set_stream(struct display_entity *entity, unsigned int port,
+ enum display_entity_stream_state state)
+{
+   if (port >= entity->entity.num_pads)
+   return -EINVAL;
+
+   if (!entity->ops->video || !entity->ops->video->set_stream)
+   return 0;
+
+   return entity->ops->video->set_stream(entity, port, state);
+}
+EXPORT_SYMBOL_GPL(display_entity_set_stream);
+
+/* 
-
  * Connections
  */
 
@@ -177,6 +258,7 @@ int display_entity_init(struct display_entity *entity, 
unsigned int num_sinks,
int ret;
 
kref_init(&entity->ref);
+   entity->state = DISPLAY_ENTITY_STATE_OFF;
 
num_pads = num_sinks + num_sources;
pads = kzalloc(sizeof(*pads) * num_pads, GFP_KERNEL);
diff --git a/include/video/display.h b/include/video/display.h
index 74b227d..fef05a68 100644
--- a/include/video/display.h
+++ b/include/video/display.h
@@ -25,6 +25,38 @@
 struct display_entity;
 struct videomode;
 
+/**
+ * enum display_entity_state - State of a display entity
+ * @DISPLAY_ENTITY_STATE_OFF: The entity is turned off completely, possibly
+ * including its power supplies. Communication with a display entity in
+ * that state is not possible.
+ * @DISPLAY_ENTITY_STATE_STANDBY: The entity is in a low-power state. Full
+ * communication with the display entity is supported, including pixel data
+ * transfer, but the output is kept blanked.
+ * @DISPLAY_ENTITY_STATE_ON: The entity is fully operational.
+ */
+enum display_entity_state {
+   DISPLAY_ENTITY_STATE_OFF,
+   DISPLAY_ENTITY_STATE_STANDBY,
+   DISPLAY_ENTITY_STATE_ON,
+};
+
+/**
+ * enum display_entity_stream_state - State of a video stream
+ * @DISPLAY_ENTITY_STREAM_STOPPED: The video stream is stopped, no frames are
+ * transferred.
+ * @DISPLAY_ENTITY_STREAM_SINGLE_SHOT: Th

[PATCH/RFC v3 04/19] video: display: Add display entity notifier

[Laurent Pinchart]

Display entities are initialized by they respective drivers
asynchronously with the master display driver. The notifier
infrastructure allows display drivers to create a list of entities they
need (based on platform data) and be notified when those entities are
added to or removed from the system.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/display/Makefile   |   3 +-
 drivers/video/display/display-notifier.c | 304 +++
 include/video/display.h  |  66 +++
 3 files changed, 372 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/display/display-notifier.c

diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index 3054adc..b907aad 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1,2 +1,3 @@
-display-y  := display-core.o
+display-y  := display-core.o \
+  display-notifier.o
 obj-$(CONFIG_DISPLAY_CORE) += display.o
diff --git a/drivers/video/display/display-notifier.c 
b/drivers/video/display/display-notifier.c
new file mode 100644
index 000..c9210ec
--- /dev/null
+++ b/drivers/video/display/display-notifier.c
@@ -0,0 +1,304 @@
+/*
+ * Display Notifier
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static LIST_HEAD(display_entity_list);
+static LIST_HEAD(display_entity_notifiers);
+static DEFINE_MUTEX(display_entity_mutex);
+
+/* 
-
+ * Notifiers
+ */
+
+static bool match_platform(struct device *dev,
+  struct display_entity_match *match)
+{
+   pr_debug("%s: matching device '%s' with name '%s'\n", __func__,
+dev_name(dev), match->match.platform.name);
+
+   return !strcmp(match->match.platform.name, dev_name(dev));
+}
+
+static struct display_entity_match *
+display_entity_notifier_match(struct display_entity_notifier *notifier,
+ struct display_entity *entity)
+{
+   bool (*match_func)(struct device *, struct display_entity_match *);
+   struct display_entity_match *match;
+
+   pr_debug("%s: matching entity '%s' (ptr 0x%p dev '%s')\n", __func__,
+entity->name, entity, dev_name(entity->dev));
+
+   list_for_each_entry(match, ¬ifier->waiting, list) {
+   switch (match->type) {
+   default:
+   case DISPLAY_ENTITY_BUS_PLATFORM:
+   match_func = match_platform;
+   break;
+   }
+
+   if (match_func(entity->dev, match))
+   return match;
+   }
+
+   return NULL;
+}
+
+static void display_entity_notifier_cleanup(struct display_entity *entity)
+{
+   entity->match = NULL;
+   entity->notifier = NULL;
+}
+
+static int
+display_entity_notifier_notify(struct display_entity_notifier *notifier,
+  struct display_entity *entity,
+  struct display_entity_match *match)
+{
+   int ret;
+
+   pr_debug("%s: notifying device '%s' for entity '%s' (ptr 0x%p dev 
'%s')\n",
+__func__, dev_name(notifier->dev), entity->name, entity,
+dev_name(entity->dev));
+
+   /* Remove the match from waiting list. */
+   list_del(&match->list);
+   entity->match = match;
+   entity->notifier = notifier;
+
+   if (notifier->bound) {
+   ret = notifier->bound(notifier, entity, match);
+   if (ret < 0)
+   goto error_bound;
+   }
+
+   /* Move the entity from the global list to the notifier's done list. */
+   list_move(&entity->list, ¬ifier->done);
+
+   if (list_empty(¬ifier->waiting) && notifier->complete) {
+   pr_debug("%s: notifying device '%s' of completion\n", __func__,
+dev_name(notifier->dev));
+   ret = notifier->complete(notifier);
+   if (ret < 0)
+   goto error_complete;
+   }
+
+   return 0;
+
+error_complete:
+   /* Move the entity back to the global list. */
+   list_move(&entity->list, &display_entity_list);
+   if (notifier->unbind)
+   notifier->unbind(notifier, entity, match);
+error_bound:
+   /* Put the match back to the waiting list. */
+   list_add_tail(&match->list, ¬ifier->waiting);
+   display_entity_notifier_cleanup(entity);
+
+   return ret;
+}
+
+/**
+ * display_entity_register_notifier - register a display entity

[PATCH/RFC v3 05/19] video: display: Graph helpers

[Laurent Pinchart]

Add two graph helper functions. display_entity_build_notifier() builds
an entity notifier from an entities graph represented as a flat array,
typically passed from platform data. display_entity_link_graph() can
then be used to create media controller links between all entities in
the graph.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/display/display-core.c | 107 +++
 drivers/video/display/display-notifier.c |  51 +++
 include/video/display.h  |  20 ++
 3 files changed, 178 insertions(+)

diff --git a/drivers/video/display/display-core.c 
b/drivers/video/display/display-core.c
index bb18723..c3b47d3 100644
--- a/drivers/video/display/display-core.c
+++ b/drivers/video/display/display-core.c
@@ -10,6 +10,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -313,6 +314,112 @@ void display_entity_unregister(struct display_entity 
*entity)
 }
 EXPORT_SYMBOL_GPL(display_entity_unregister);
 
+/* 
-
+ * Graph Helpers
+ */
+
+static int display_entity_link_entity(struct device *dev,
+ struct display_entity *entity,
+ struct list_head *entities)
+{
+   const struct display_entity_graph_data *graph = entity->match->data;
+   u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
+   struct media_entity *local = &entity->entity;
+   unsigned int i;
+   int ret = 0;
+
+   dev_dbg(dev, "creating links for entity %s\n", local->name);
+
+   for (i = 0; i < entity->entity.num_pads; ++i) {
+   const struct display_entity_source_data *source;
+   struct media_pad *local_pad = &local->pads[i];
+   struct media_entity *remote = NULL;
+   struct media_pad *remote_pad;
+   struct display_entity *ent;
+
+   dev_dbg(dev, "processing pad %u\n", i);
+
+   /* Skip source pads, they will be processed from the other end
+* of the link.
+*/
+   if (local_pad->flags & MEDIA_PAD_FL_SOURCE) {
+   dev_dbg(dev, "skipping source pad %s:%u\n",
+   local->name, i);
+   continue;
+   }
+
+   /* Find the remote entity. If not found, just skip the link as
+* it goes out of scope of the entities handled by the notifier.
+*/
+   source = &graph->sources[i];
+   list_for_each_entry(ent, entities, list) {
+   if (strcmp(source->name, dev_name(ent->dev)) == 0) {
+   remote = &ent->entity;
+   break;
+   }
+   }
+
+   if (remote == NULL) {
+   dev_dbg(dev, "no entity found for %s\n", source->name);
+   continue;
+   }
+
+   if (source->port >= remote->num_pads) {
+   dev_err(dev, "invalid port number %u on %s\n",
+   source->port, source->name);
+   ret = -EINVAL;
+   break;
+   }
+
+   remote_pad = &remote->pads[source->port];
+
+   /* Create the media link. */
+   dev_dbg(dev, "creating %s:%u -> %s:%u link\n",
+   remote->name, remote_pad->index,
+   local->name, local_pad->index);
+
+   ret = media_entity_create_link(remote, remote_pad->index,
+  local, local_pad->index,
+  link_flags);
+   if (ret < 0) {
+   dev_err(dev, "failed to create %s:%u -> %s:%u link\n",
+   remote->name, remote_pad->index,
+   local->name, local_pad->index);
+   break;
+   }
+   }
+
+   return ret;
+}
+
+/**
+ * display_entity_link_graph - Link all entities in a graph
+ * @dev: device used to print debugging and error messages
+ * @entities: list of display entities in the graph
+ *
+ * This function creates media controller links for all entities in a graph
+ * based on graph link data. It relies on the entities match data pointers
+ * having been initialized by the display_entity_build_notifier() function when
+ * building the notifier and thus can't be used when the notifier is built in a
+ * different way.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_link_graph(struct device *dev, struct list_head *entities)
+{
+   struct display_entity *entity;
+   int ret;
+
+   list_for_each_entry(entity, entities, list) {
+   ret = display_entity_link_entity(dev,

[PATCH/RFC v3 07/19] video: display: Add pixel coding definitions

[Laurent Pinchart]

Pixel codings describe how pixels are transmitted on a physical bus. The
information can be communicated between drivers to configure devices.

Signed-off-by: Laurent Pinchart 
---
 include/video/display.h | 120 
 1 file changed, 120 insertions(+)

diff --git a/include/video/display.h b/include/video/display.h
index 36ff637..ba319d6 100644
--- a/include/video/display.h
+++ b/include/video/display.h
@@ -18,6 +18,126 @@
 #include 
 #include 
 
+#define DISPLAY_PIXEL_CODING(option, type, from, to, variant) \
+   (((option) << 17) | ((type) << 13) | ((variant) << 10) | \
+((to) << 5) | (from))
+
+#define DISPLAY_PIXEL_CODING_FROM(coding)  ((coding) & 0x1f)
+#define DISPLAY_PIXEL_CODING_TO(coding)(((coding) >> 5) & 0x1f)
+#define DISPLAY_PIXEL_CODING_VARIANT(coding)   (((coding) >> 10) & 7)
+#define DISPLAY_PIXEL_CODING_TYPE(coding)  (((coding) >> 13) & 0xf)
+
+#define DISPLAY_PIXEL_CODING_TYPE_DBI  0
+#define DISPLAY_PIXEL_CODING_TYPE_DPI  1
+
+/* DBI pixel codings. */
+#define DISPLAY_PIXEL_CODING_DBI(from, to, variant) \
+   DISPLAY_PIXEL_CODING_TYPE(DISPLAY_PIXEL_CODING_TYPE_DBI, \
+ from, to, variant, 0)
+
+/* Standard DBI codings, defined in the DBI specification. */
+/*   17   16   15   14   13   12   11   109876543  
  210 */
+/*---------- R0,2 R0,1 R0,0 G0,2 G0,1 
G0,0 B0,1 B0,0 */
+#define DISPLAY_PIXEL_CODING_DBI_8TO8  DISPLAY_PIXEL_CODING_DBI(8, 8, 
0)
+/*---------- R0,3 R0,2 R0,1 R0,0 G0,3 
G0,2 G0,1 G0,0 */
+/*---------- B0,3 B0,2 B0,1 B0,0 R1,3 
R1,2 R1,1 R1,0 */
+/*---------- G1,3 G1,2 G1,1 G1,0 B1,3 
B1,2 B1,1 b1,0 */
+#define DISPLAY_PIXEL_CODING_DBI_12TO8 DISPLAY_PIXEL_CODING_DBI(12, 8, 
0)
+/*---------- R0,4 R0,3 R0,2 R0,1 R0,0 
G0,5 G0,4 G0,3 */
+/*---------- G0,2 G0,1 G0,0 B0,4 B0,3 
B0,2 B0,1 B0,0 */
+#define DISPLAY_PIXEL_CODING_DBI_16TO8 DISPLAY_PIXEL_CODING_DBI(16, 8, 
0)
+/*---------- R0,5 R0,4 R0,3 R0,2 R0,1 
R0,0-- */
+/*---------- G0,5 G0,4 G0,3 G0,2 G0,1 
G0,0-- */
+/*---------- B0,5 B0,4 B0,3 B0,2 B0,1 
B0,0-- */
+#define DISPLAY_PIXEL_CODING_DBI_18TO8 DISPLAY_PIXEL_CODING_DBI(18, 8, 
0)
+/*---------- R0,7 R0,6 R0,5 R0,4 R0,3 
R0,2 R0,1 R0,0 */
+/*---------- G0,7 G0,6 G0,5 G0,4 G0,3 
G0,2 G0,1 G0,0 */
+/*---------- B0,7 B0,6 B0,5 B0,4 B0,3 
B0,2 B0,1 B0,0 */
+#define DISPLAY_PIXEL_CODING_DBI_24TO8 DISPLAY_PIXEL_CODING_DBI(24, 8, 
0)
+/*--------- R0,5 R0,4 R0,3 R0,2 R0,1 R0,0 
G0,5 G0,4 G0,4 */
+/*--------- G0,2 G0,1 G0,0 B0,5 B0,4 B0,3 
B0,2 B0,1 B0,0 */
+#define DISPLAY_PIXEL_CODING_DBI_18TO9 DISPLAY_PIXEL_CODING_DBI(18, 9, 
0)
+/*-- R1,2 R1,1 R1,0 G1,2 G1,1 G1,0 B1,1 B1,0 R0,2 R0,1 R0,0 G0,2 G0,1 
G0,0 B0,1 B0,0 */
+#define DISPLAY_PIXEL_CODING_DBI_8TO16 DISPLAY_PIXEL_CODING_DBI(8, 16, 
0)
+/*------ R0,3 R0,2 R0,1 R0,0 G0,3 G0,2 G0,1 G0,0 B0,3 
B0,2 B0,1 B0,0 */
+#define DISPLAY_PIXEL_CODING_DBI_12TO16
DISPLAY_PIXEL_CODING_DBI(12, 16, 0)
+/*-- R0,4 R0,3 R0,2 R0,1 R0,0 G0,5 G0,4 G0,3 G0,2 G0,1 G0,0 B0,4 B0,3 
B0,2 B0,1 B0,0 */
+#define DISPLAY_PIXEL_CODING_DBI_16TO16
DISPLAY_PIXEL_CODING_DBI(16, 16, 0)
+/*-- R0,5 R0,4 R0,3 R0,2 R0,1 R0,0-- G0,5 G0,4 G0,3 G0,2 G0,1 
G0,0-- */
+/*-- B0,5 B0,4 B0,3 B0,2 B0,1 B0,0-- R1,5 R1,4 R1,3 R1,2 R1,1 
R1,0-- */
+/*-- G1,5 G1,4 G1,3 G1,2 G1,1 G1,0-- B1,5 B1,4 B1,3 B1,2 B1,1 
B1,0-- */
+#define DISPLAY_PIXEL_CODING_DBI_18TO16_A  DISPLAY_PIXEL_CODING_DBI(18, 
16, 0)
+/*---------- R0,5 R0,4 R0,3 R0,2 R0,1 
R0,0-- */
+/*-- G0,5 G0,4 G0,3 G0,2 G0,1 G0,0-- B0,5 B0,4 B0,3 B0,2 B0,1 
B0,0-- */
+#define DISPLAY_PIXEL_CODING_DBI_18TO16_B  DISPLAY_PIXEL_CODING_DBI(18, 
16, 1)
+/*-- R0,7 R0,6 R0,5 R0,4 R0,3 R0,2 R0,1 R0,0 G0,7 G0,6 G0,5 G0,4 G0,3 
G0,2 G0,1 G0,0 */
+/*-- B0,7 B0,6 B0,5 B0,4 B0,3 B0,2 B0,1 B0,0 R1,7 R1,6 R1,5 R1,4 R1,3 
R1,2 R1,1 R1,0 */
+/*-- G1,7 G1,6 G1,5 G1,4 G1,3 G1,2 G1,1 G1,0 B1,7 B1,6 B1,5 B1,4 B1,3 
B1,2 B1,1 B1,0 */
+#define DISPLAY_PIXEL_CODING_DBI_24TO16_A  DISPLAY_PIXEL_CODING_DBI(24, 
16, 0)
+/*---------- R0,7 R0,6 R0,5 R0,4 R0,3 
R0,2 R0,1 R0,0 */
+/*-- G0,7

[PATCH/RFC v3 06/19] video: display: OF support

[Laurent Pinchart]

Extend the notifier with DT node matching support, and add helper functions to
build the notifier and link entities based on a graph representation in
DT.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/display/display-core.c | 334 +++
 drivers/video/display/display-notifier.c | 187 +
 include/video/display.h  |  45 +
 3 files changed, 566 insertions(+)

diff --git a/drivers/video/display/display-core.c 
b/drivers/video/display/display-core.c
index c3b47d3..328ead7 100644
--- a/drivers/video/display/display-core.c
+++ b/drivers/video/display/display-core.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -315,6 +316,184 @@ void display_entity_unregister(struct display_entity 
*entity)
 EXPORT_SYMBOL_GPL(display_entity_unregister);
 
 /* 
-
+ * OF Helpers
+ */
+
+#ifdef CONFIG_OF
+
+/**
+ * display_of_get_next_endpoint() - get next endpoint node
+ * @parent: pointer to the parent device node
+ * @prev: previous endpoint node, or NULL to get first
+ *
+ * Return: An 'endpoint' node pointer with refcount incremented. Refcount
+ * of the passed @prev node is not decremented, the caller have to use
+ * of_node_put() on it when done.
+ */
+struct device_node *
+display_of_get_next_endpoint(const struct device_node *parent,
+struct device_node *prev)
+{
+   struct device_node *endpoint;
+   struct device_node *port = NULL;
+
+   if (!parent)
+   return NULL;
+
+   if (!prev) {
+   struct device_node *node;
+   /*
+* It's the first call, we have to find a port subnode
+* within this node or within an optional 'ports' node.
+*/
+   node = of_get_child_by_name(parent, "ports");
+   if (node)
+   parent = node;
+
+   port = of_get_child_by_name(parent, "port");
+
+   if (port) {
+   /* Found a port, get an endpoint. */
+   endpoint = of_get_next_child(port, NULL);
+   of_node_put(port);
+   } else {
+   endpoint = NULL;
+   }
+
+   if (!endpoint)
+   pr_err("%s(): no endpoint nodes specified for %s\n",
+  __func__, parent->full_name);
+   of_node_put(node);
+   } else {
+   port = of_get_parent(prev);
+   if (!port)
+   /* Hm, has someone given us the root node ?... */
+   return NULL;
+
+   /* Avoid dropping prev node refcount to 0. */
+   of_node_get(prev);
+   endpoint = of_get_next_child(port, prev);
+   if (endpoint) {
+   of_node_put(port);
+   return endpoint;
+   }
+
+   /* No more endpoints under this port, try the next one. */
+   do {
+   port = of_get_next_child(parent, port);
+   if (!port)
+   return NULL;
+   } while (of_node_cmp(port->name, "port"));
+
+   /* Pick up the first endpoint in this port. */
+   endpoint = of_get_next_child(port, NULL);
+   of_node_put(port);
+   }
+
+   return endpoint;
+}
+
+/**
+ * display_of_get_remote_port_parent() - get remote port's parent node
+ * @node: pointer to a local endpoint device_node
+ *
+ * Return: Remote device node associated with remote endpoint node linked
+ *to @node. Use of_node_put() on it when done.
+ */
+struct device_node *
+display_of_get_remote_port_parent(const struct device_node *node)
+{
+   struct device_node *np;
+   unsigned int depth;
+
+   /* Get remote endpoint node. */
+   np = of_parse_phandle(node, "remote-endpoint", 0);
+
+   /* Walk 3 levels up only if there is 'ports' node. */
+   for (depth = 3; depth && np; depth--) {
+   np = of_get_next_parent(np);
+   if (depth == 2 && of_node_cmp(np->name, "ports"))
+   break;
+   }
+   return np;
+}
+
+/**
+ * struct display_of_link - a link between two endpoints
+ * @local_node: pointer to device_node of this endpoint
+ * @local_port: identifier of the port this endpoint belongs to
+ * @remote_node: pointer to device_node of the remote endpoint
+ * @remote_port: identifier of the port the remote endpoint belongs to
+ */
+struct display_of_link {
+   struct device_node *local_node;
+   unsigned int local_port;
+   struct device_node *remote_node;
+   unsigned int remote_port;
+};
+
+/**
+ * display_of_parse_link() - parse a link between two endpoints
+ * @node: pointer to the endpoint at the local end of the link
+ * @link: pointe

[PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support

[Laurent Pinchart]

MIPI DBI is a configurable-width parallel display bus that transmits
commands and data.

Add a new DBI Linux bus type that implements the usual bus
infrastructure (including devices and drivers (un)registration and
matching, and bus configuration and access functions).

Signed-off-by: Laurent Pinchart 
---
 drivers/video/display/Kconfig|   8 ++
 drivers/video/display/Makefile   |   1 +
 drivers/video/display/mipi-dbi-bus.c | 234 +++
 include/video/display.h  |   4 +
 include/video/mipi-dbi-bus.h | 125 +++
 5 files changed, 372 insertions(+)
 create mode 100644 drivers/video/display/mipi-dbi-bus.c
 create mode 100644 include/video/mipi-dbi-bus.h

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 1d533e7..f7532c1 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -2,3 +2,11 @@ menuconfig DISPLAY_CORE
tristate "Display Core"
---help---
  Support common display framework for graphics devices.
+
+if DISPLAY_CORE
+
+config DISPLAY_MIPI_DBI
+   tristate
+   default n
+
+endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index b907aad..59022d2 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1,3 +1,4 @@
 display-y  := display-core.o \
   display-notifier.o
 obj-$(CONFIG_DISPLAY_CORE) += display.o
+obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
diff --git a/drivers/video/display/mipi-dbi-bus.c 
b/drivers/video/display/mipi-dbi-bus.c
new file mode 100644
index 000..791fb4d
--- /dev/null
+++ b/drivers/video/display/mipi-dbi-bus.c
@@ -0,0 +1,234 @@
+/*
+ * MIPI DBI Bus
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* 
-
+ * Bus operations
+ */
+
+int mipi_dbi_set_data_width(struct mipi_dbi_device *dev, unsigned int width)
+{
+   if (width != 8 && width != 16)
+   return -EINVAL;
+
+   dev->data_width = width;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_set_data_width);
+
+int mipi_dbi_write_command(struct mipi_dbi_device *dev, u16 cmd)
+{
+   return dev->bus->ops->write_command(dev->bus, dev, cmd);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_write_command);
+
+int mipi_dbi_write_data(struct mipi_dbi_device *dev, const u8 *data,
+   size_t len)
+{
+   return dev->bus->ops->write_data(dev->bus, dev, data, len);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_write_data);
+
+int mipi_dbi_read_data(struct mipi_dbi_device *dev, u8 *data, size_t len)
+{
+   return dev->bus->ops->read_data(dev->bus, dev, data, len);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_read_data);
+
+/* 
-
+ * Bus type
+ */
+
+static const struct mipi_dbi_device_id *
+mipi_dbi_match_id(const struct mipi_dbi_device_id *id,
+ struct mipi_dbi_device *dev)
+{
+   while (id->name[0]) {
+   if (strcmp(dev->name, id->name) == 0) {
+   dev->id_entry = id;
+   return id;
+   }
+   id++;
+   }
+   return NULL;
+}
+
+static int mipi_dbi_match(struct device *_dev, struct device_driver *_drv)
+{
+   struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+   struct mipi_dbi_driver *drv = to_mipi_dbi_driver(_drv);
+
+   if (drv->id_table)
+   return mipi_dbi_match_id(drv->id_table, dev) != NULL;
+
+   return (strcmp(dev->name, _drv->name) == 0);
+}
+
+static ssize_t modalias_show(struct device *_dev, struct device_attribute *a,
+char *buf)
+{
+   struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+   int len = snprintf(buf, PAGE_SIZE, MIPI_DBI_MODULE_PREFIX "%s\n",
+  dev->name);
+
+   return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
+}
+
+static struct device_attribute mipi_dbi_dev_attrs[] = {
+   __ATTR_RO(modalias),
+   __ATTR_NULL,
+};
+
+static int mipi_dbi_uevent(struct device *_dev, struct kobj_uevent_env *env)
+{
+   struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+
+   add_uevent_var(env, "MODALIAS=%s%s", MIPI_DBI_MODULE_PREFIX,
+  dev->name);
+   return 0;
+}
+
+static const struct dev_pm_ops mipi_dbi_dev_pm_ops = {
+   .runtime_suspend = pm_generic_runtime_suspend,
+   .runtime_resume = pm_generic_runtime_resume,
+   .

[PATCH/RFC v3 10/19] video: panel: Add R61505 panel support

[Laurent Pinchart]

The R61505 is a SYS-80 bus panel controller from Renesas.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/display/Kconfig|  10 +
 drivers/video/display/Makefile   |   1 +
 drivers/video/display/panel-r61505.c | 567 +++
 include/video/panel-r61505.h |  27 ++
 4 files changed, 605 insertions(+)
 create mode 100644 drivers/video/display/panel-r61505.c
 create mode 100644 include/video/panel-r61505.h

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index bce09d6..76729ef 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -19,4 +19,14 @@ config DISPLAY_PANEL_DPI
  If you are in doubt, say N. To compile this driver as a module, choose
  M here; the module will be called panel-dpi.
 
+config DISPLAY_PANEL_R61505
+   tristate "Renesas R61505-based Display Panel"
+   select DISPLAY_MIPI_DBI
+   ---help---
+ Support panels based on the Renesas R61505 panel controller.
+ Those panels are controlled through a MIPI DBI interface.
+
+ If you are in doubt, say N. To compile this driver as a module, choose
+ M here; the module will be called panel-r61505.
+
 endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index 31c017b..db8a4c3 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -3,3 +3,4 @@ display-y   := 
display-core.o \
 obj-$(CONFIG_DISPLAY_CORE) += display.o
 obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
 obj-$(CONFIG_DISPLAY_PANEL_DPI)+= panel-dpi.o
+obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
diff --git a/drivers/video/display/panel-r61505.c 
b/drivers/video/display/panel-r61505.c
new file mode 100644
index 000..c86177e
--- /dev/null
+++ b/drivers/video/display/panel-r61505.c
@@ -0,0 +1,567 @@
+/*
+ * Renesas R61505-based Display Panels
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Based on SuperH MigoR Quarter VGA LCD Panel
+ * Copyright (C) 2008 Magnus Damm
+ * Based on lcd_powertip.c from Kenati Technologies Pvt Ltd.
+ * Copyright (c) 2007 Ujjwal Pande
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define R61505_DEVICE_CODE 0x
+#define R61505_DEVICE_CODE_VALUE   0x1505
+#define R61505_DRIVER_OUTPUT_CONTROL   0x0001
+#define R61505_DRIVER_OUTPUT_CONTROL_SM(1 << 10)
+#define R61505_DRIVER_OUTPUT_CONTROL_SS(1 << 8)
+#define R61505_LCD_WAVEFORM0x0002
+#define R61505_LCD_WAVEFORM_BC0(1 << 9)
+#define R61505_LCD_WAVEFORM_EOR(1 << 8)
+#define R61505_ENTRY_MODE  0x0003
+#define R61505_ENTRY_MODE_TRIREG   (1 << 15)
+#define R61505_ENTRY_MODE_DFM  (1 << 14)
+#define R61505_ENTRY_MODE_BGR  (1 << 12)
+#define R61505_ENTRY_MODE_HWM  (1 << 9)
+#define R61505_ENTRY_MODE_ORG  (1 << 7)
+#define R61505_ENTRY_MODE_ID1  (1 << 5)
+#define R61505_ENTRY_MODE_ID0  (1 << 4)
+#define R61505_ENTRY_MODE_AM   (1 << 3)
+#define R61505_RESIZE_CONTROL  0x0004
+#define R61505_RESIZE_CONTROL_RCV(n)   (((n) & 3) << 8)
+#define R61505_RESIZE_CONTROL_RCH(n)   (((n) & 3) << 4)
+#define R61505_RESIZE_CONTROL_RSZ_4(3 << 0)
+#define R61505_RESIZE_CONTROL_RSZ_2(1 << 0)
+#define R61505_RESIZE_CONTROL_RSZ_1(0 << 0)
+#define R61505_DISPLAY_CONTROL10x0007
+#define R61505_DISPLAY_CONTROL1_PTDE1  (1 << 13)
+#define R61505_DISPLAY_CONTROL1_PTDE0  (1 << 12)
+#define R61505_DISPLAY_CONTROL1_BASEE  (1 << 8)
+#define R61505_DISPLAY_CONTROL1_VON(1 << 6)
+#define R61505_DISPLAY_CONTROL1_GON(1 << 5)
+#define R61505_DISPLAY_CONTROL1_DTE(1 << 4)
+#define R61505_DISPLAY_CONTROL1_COL(1 << 3)
+#define R61505_DISPLAY_CONTROL1_D1 (1 << 1)
+#define R61505_DISPLAY_CONTROL1_D0 (1 << 0)
+#define R61505_DISPLAY_CONTROL20x0008
+#define R61505_DISPLAY_CONTROL2_FP(n)  (((n) & 0xf) << 8)
+#define R61505_DISPLAY_CONTROL2_BP(n)  (((n) & 0xf) << 0)
+#define R61505_DISPLAY_CONTROL30x0009
+#define R61505_DISPLAY_CONTROL3_PTS(n) (((n) & 7) << 8)
+#define R61505_DISPLAY_CONTROL3_PTG(n) (((n) & 3) << 3)
+#define R61505_DISPLAY_CONTROL3_ICS(n) 

[PATCH/RFC v3 09/19] video: panel: Add DPI panel support

[Laurent Pinchart]

The Display Pixel Interface is a configurable-width video-only
unidirectional parallel bus standard that defines video formats and
signaling for panel devices.

This driver implements support for simple DPI panels with no runtime
configuration capabilities (GPIOs- and/or regulators-based control can
be implemented later when needed) and exposes it as a display entity.
The panel native video mode is passed to the driver through platform
data or device tree properties.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/display/Kconfig |  10 ++
 drivers/video/display/Makefile|   1 +
 drivers/video/display/panel-dpi.c | 207 ++
 include/video/panel-dpi.h |  24 +
 4 files changed, 242 insertions(+)
 create mode 100644 drivers/video/display/panel-dpi.c
 create mode 100644 include/video/panel-dpi.h

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index f7532c1..bce09d6 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -9,4 +9,14 @@ config DISPLAY_MIPI_DBI
tristate
default n
 
+config DISPLAY_PANEL_DPI
+   tristate "DPI (Parallel) Display Panels"
+   ---help---
+ Support for simple digital (parallel) pixel interface panels. Those
+ panels receive pixel data through a parallel bus and have no control
+ bus.
+
+ If you are in doubt, say N. To compile this driver as a module, choose
+ M here; the module will be called panel-dpi.
+
 endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index 59022d2..31c017b 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -2,3 +2,4 @@ display-y   := 
display-core.o \
   display-notifier.o
 obj-$(CONFIG_DISPLAY_CORE) += display.o
 obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
+obj-$(CONFIG_DISPLAY_PANEL_DPI)+= panel-dpi.o
diff --git a/drivers/video/display/panel-dpi.c 
b/drivers/video/display/panel-dpi.c
new file mode 100644
index 000..b1ecf6d
--- /dev/null
+++ b/drivers/video/display/panel-dpi.c
@@ -0,0 +1,207 @@
+/*
+ * DPI Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct panel_dpi {
+   struct display_entity entity;
+
+   unsigned int width;
+   unsigned int height;
+   struct videomode mode;
+};
+
+static inline struct panel_dpi *to_panel_dpi(struct display_entity *e)
+{
+   return container_of(e, struct panel_dpi, entity);
+}
+
+static const struct display_entity_interface_params panel_dpi_params = {
+   .type = DISPLAY_ENTITY_INTERFACE_DPI,
+};
+
+static int panel_dpi_set_state(struct display_entity *entity,
+  enum display_entity_state state)
+{
+   struct media_pad *source;
+
+   source = media_entity_remote_pad(&entity->entity.pads[0]);
+   if (source == NULL)
+   return -EPIPE;
+
+   switch (state) {
+   case DISPLAY_ENTITY_STATE_OFF:
+   case DISPLAY_ENTITY_STATE_STANDBY:
+   display_entity_set_stream(to_display_entity(source->entity),
+ source->index,
+ DISPLAY_ENTITY_STREAM_STOPPED);
+   break;
+
+   case DISPLAY_ENTITY_STATE_ON:
+   display_entity_set_stream(to_display_entity(source->entity),
+ source->index,
+ DISPLAY_ENTITY_STREAM_CONTINUOUS);
+   break;
+   }
+
+   return 0;
+}
+
+static int panel_dpi_get_modes(struct display_entity *entity, unsigned int 
port,
+  const struct videomode **modes)
+{
+   struct panel_dpi *panel = to_panel_dpi(entity);
+
+   *modes = &panel->mode;
+   return 1;
+}
+
+static int panel_dpi_get_size(struct display_entity *entity,
+ unsigned int *width, unsigned int *height)
+{
+   struct panel_dpi *panel = to_panel_dpi(entity);
+
+   *width = panel->width;
+   *height = panel->height;
+   return 0;
+}
+
+static int panel_dpi_get_params(struct display_entity *entity,
+   unsigned int port,
+   struct display_entity_interface_params *params)
+{
+   *params = panel_dpi_params;
+   return 0;
+}
+
+static const struct display_entity_control_ops panel_dpi_control_ops = {
+   .set_state = panel_dpi_set_state,
+   .get_mode

[PATCH/RFC v3 11/19] video: panel: Add R61517 panel support

[Laurent Pinchart]

The R61517 is a MIPI DBI panel controller from Renesas.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/display/Kconfig|  10 +
 drivers/video/display/Makefile   |   1 +
 drivers/video/display/panel-r61517.c | 460 +++
 include/video/panel-r61517.h |  28 +++
 4 files changed, 499 insertions(+)
 create mode 100644 drivers/video/display/panel-r61517.c
 create mode 100644 include/video/panel-r61517.h

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 76729ef..9b44b5f 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -29,4 +29,14 @@ config DISPLAY_PANEL_R61505
  If you are in doubt, say N. To compile this driver as a module, choose
  M here; the module will be called panel-r61505.
 
+config DISPLAY_PANEL_R61517
+   tristate "Renesas R61517-based Display Panel"
+   select DISPLAY_MIPI_DBI
+   ---help---
+ Support panels based on the Renesas R61517 panel controller.
+ Those panels are controlled through a MIPI DBI interface.
+
+ If you are in doubt, say N. To compile this driver as a module, choose
+ M here; the module will be called panel-r61517.
+
 endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index db8a4c3..1cdc8d4 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DISPLAY_CORE)  += display.o
 obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
 obj-$(CONFIG_DISPLAY_PANEL_DPI)+= panel-dpi.o
 obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
+obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o
diff --git a/drivers/video/display/panel-r61517.c 
b/drivers/video/display/panel-r61517.c
new file mode 100644
index 000..ccfec33
--- /dev/null
+++ b/drivers/video/display/panel-r61517.c
@@ -0,0 +1,460 @@
+/*
+ * Renesas R61517-based Display Panels
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Based on KFR2R09 LCD panel support
+ * Copyright (C) 2009 Magnus Damm
+ * Register settings based on the out-of-tree t33fb.c driver
+ * Copyright (C) 2008 Lineo Solutions, Inc.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct r61517 {
+   struct display_entity entity;
+   struct mipi_dbi_device *dbi;
+   const struct panel_r61517_platform_data *pdata;
+};
+
+static inline struct r61517 *to_panel(struct display_entity *e)
+{
+   return container_of(e, struct r61517, entity);
+}
+
+/* 
-
+ * Read, write and reset
+ */
+
+static void r61517_write_command(struct r61517 *panel, u16 cmd)
+{
+   mipi_dbi_write_command(panel->dbi, cmd);
+}
+
+static void r61517_write_data(struct r61517 *panel, u8 data)
+{
+   mipi_dbi_write_data(panel->dbi, &data, 1);
+}
+
+static int r61517_read_data(struct r61517 *panel)
+{
+   u8 data;
+   int ret;
+
+   ret = mipi_dbi_read_data(panel->dbi, &data, 1);
+   if (ret < 0)
+   return ret;
+
+   return data;
+}
+
+static void r61517_write(struct r61517 *panel, u8 reg, const u8 *data,
+size_t len)
+{
+   mipi_dbi_write_command(panel->dbi, reg);
+   mipi_dbi_write_data(panel->dbi, data, len);
+}
+
+static void r61517_write8(struct r61517 *panel, u8 reg, u8 data)
+{
+   r61517_write(panel, reg, &data, 1);
+}
+
+static void r61517_write16(struct r61517 *panel, u8 reg, u16 data)
+{
+   u8 buffer[2] = { (data >> 8) & 0xff, (data >> 0) & 0xff };
+
+   r61517_write(panel, reg, buffer, 2);
+}
+
+static void r61517_write32(struct r61517 *panel, u8 reg, u32 data)
+{
+   u8 buffer[4] = { (data >> 24) & 0xff, (data >> 16) & 0xff,
+(data >>  8) & 0xff, (data >>  0) & 0xff };
+
+   r61517_write(panel, reg, buffer, 4);
+}
+
+#define r61517_write_array(p, c, a) \
+   r61517_write((p), (c), (a), ARRAY_SIZE(a))
+
+static void r61517_reset(struct r61517 *panel)
+{
+   gpio_set_value(panel->pdata->protect, 0);   /* PROTECT/ -> L */
+   gpio_set_value(panel->pdata->reset, 0); /* LCD_RST/ -> L */
+   gpio_set_value(panel->pdata->protect, 1);   /* PROTECT/ -> H */
+   usleep_range(1100, 1200);
+   gpio_set_value(panel->pdata->reset, 1); /* LCD_RST/ -> H */
+   usleep_range(10, 100);
+   gpio_set_value(panel->pdata->protect, 0);   /* PROTECT/ -> L */
+   msleep(20);
+}
+
+/* 
-
+ * Confi

[PATCH/RFC v3 12/19] video: display: Add VGA Digital to Analog Converter support

[Laurent Pinchart]

This driver implements support for VGA Digital to Analog Converters
(DACs) that receive pixel data through a DPI interface and have no
control interface (GPIOs- and/or regulators-based control can be
implemented later when needed). It exposes the devices a display
entities.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/display/Kconfig   |   9 +++
 drivers/video/display/Makefile  |   1 +
 drivers/video/display/vga-dac.c | 152 
 3 files changed, 162 insertions(+)
 create mode 100644 drivers/video/display/vga-dac.c

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 9b44b5f..32ce08d 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -39,4 +39,13 @@ config DISPLAY_PANEL_R61517
  If you are in doubt, say N. To compile this driver as a module, choose
  M here; the module will be called panel-r61517.
 
+config DISPLAY_VGA_DAC
+   tristate "VGA Digital to Analog Converters"
+   ---help---
+ Support for simple VGA digital to analog converters. Those converters
+ receive pixel data through a parallel bus and have no control bus.
+
+ If you are in doubt, say N. To compile this driver as a module, choose
+ M here: the module will be called vga-dac.
+
 endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index 1cdc8d4..43cd78d 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_DISPLAY_MIPI_DBI)  += 
mipi-dbi-bus.o
 obj-$(CONFIG_DISPLAY_PANEL_DPI)+= panel-dpi.o
 obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
 obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o
+obj-$(CONFIG_DISPLAY_VGA_DAC)  += vga-dac.o
diff --git a/drivers/video/display/vga-dac.c b/drivers/video/display/vga-dac.c
new file mode 100644
index 000..d0256e6
--- /dev/null
+++ b/drivers/video/display/vga-dac.c
@@ -0,0 +1,152 @@
+/*
+ * VGA Digital to Analog Converter
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define VGA_DAC_PORT_SINK  0
+#define VGA_DAC_PORT_SOURCE1
+
+struct vga_dac {
+   struct display_entity entity;
+};
+
+static inline struct vga_dac *to_vga_dac(struct display_entity *e)
+{
+   return container_of(e, struct vga_dac, entity);
+}
+
+static int vga_dac_set_state(struct display_entity *entity,
+enum display_entity_state state)
+{
+   struct media_pad *source;
+
+   source = media_entity_remote_pad(&entity->entity.pads[0]);
+   if (source == NULL)
+   return -EPIPE;
+
+   switch (state) {
+   case DISPLAY_ENTITY_STATE_OFF:
+   case DISPLAY_ENTITY_STATE_STANDBY:
+   display_entity_set_stream(to_display_entity(source->entity),
+ source->index,
+ DISPLAY_ENTITY_STREAM_STOPPED);
+   break;
+
+   case DISPLAY_ENTITY_STATE_ON:
+   display_entity_set_stream(to_display_entity(source->entity),
+ source->index,
+ DISPLAY_ENTITY_STREAM_CONTINUOUS);
+   break;
+   }
+
+   return 0;
+}
+
+static int vga_dac_get_params(struct display_entity *entity, unsigned int port,
+ struct display_entity_interface_params *params)
+{
+   memset(params, 0, sizeof(*params));
+
+   if (port == VGA_DAC_PORT_SINK)
+   params->type = DISPLAY_ENTITY_INTERFACE_DPI;
+   else
+   params->type = DISPLAY_ENTITY_INTERFACE_VGA;
+
+   return 0;
+}
+
+static const struct display_entity_control_ops vga_dac_control_ops = {
+   .set_state = vga_dac_set_state,
+   .get_params = vga_dac_get_params,
+};
+
+static const struct display_entity_ops vga_dac_ops = {
+   .ctrl = &vga_dac_control_ops,
+};
+
+static int vga_dac_remove(struct platform_device *pdev)
+{
+   struct vga_dac *dac = platform_get_drvdata(pdev);
+
+   display_entity_remove(&dac->entity);
+   display_entity_cleanup(&dac->entity);
+
+   return 0;
+}
+
+static int vga_dac_probe(struct platform_device *pdev)
+{
+   struct vga_dac *dac;
+   int ret;
+
+   dac = devm_kzalloc(&pdev->dev, sizeof(*dac), GFP_KERNEL);
+   if (dac == NULL)
+   return -ENOMEM;
+
+   dac->entity.dev = &pdev->dev;
+   dac->entity.ops = &vga_dac_ops;
+   strlcpy(dac->entity.name, dev_name(&pdev->dev),
+   sizeof(dac->entity.name));
+
+ 

[PATCH/RFC v3 13/19] video: display: Add VGA connector support

[Laurent Pinchart]

This driver exposes VGA connectors as display entity devices. The
connectors are passive devices that pass analog VGA signals though. They
optionally cary DDC signals for bidirectional control communications
with the devices connected to the connectors.

EDID retrieval isn't supported yet.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/display/Kconfig   |  11 +++
 drivers/video/display/Makefile  |   1 +
 drivers/video/display/con-vga.c | 148 
 3 files changed, 160 insertions(+)
 create mode 100644 drivers/video/display/con-vga.c

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 32ce08d..9b482a8 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -5,6 +5,17 @@ menuconfig DISPLAY_CORE
 
 if DISPLAY_CORE
 
+
+config DISPLAY_CONNECTOR_VGA
+   tristate "VGA Connector"
+   ---help---
+ Support for simple digital (parallel) pixel interface panels. Those
+ panels receive pixel data through a parallel bus and have no control
+ bus.
+
+ If you are in doubt, say N. To compile this driver as a module, choose
+ M here; the module will be called con-vga.
+
 config DISPLAY_MIPI_DBI
tristate
default n
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index 43cd78d..d03c64a 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1,6 +1,7 @@
 display-y  := display-core.o \
   display-notifier.o
 obj-$(CONFIG_DISPLAY_CORE) += display.o
+obj-$(CONFIG_DISPLAY_CONNECTOR_VGA)+= con-vga.o
 obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
 obj-$(CONFIG_DISPLAY_PANEL_DPI)+= panel-dpi.o
 obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
diff --git a/drivers/video/display/con-vga.c b/drivers/video/display/con-vga.c
new file mode 100644
index 000..798ac9e
--- /dev/null
+++ b/drivers/video/display/con-vga.c
@@ -0,0 +1,148 @@
+/*
+ * VGA Connector
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct con_vga {
+   struct display_entity entity;
+};
+
+static int con_vga_set_state(struct display_entity *entity,
+enum display_entity_state state)
+{
+   struct media_pad *source;
+
+   source = media_entity_remote_pad(&entity->entity.pads[0]);
+   if (source == NULL)
+   return -EPIPE;
+
+   switch (state) {
+   case DISPLAY_ENTITY_STATE_OFF:
+   case DISPLAY_ENTITY_STATE_STANDBY:
+   display_entity_set_stream(to_display_entity(source->entity),
+ source->index,
+ DISPLAY_ENTITY_STREAM_STOPPED);
+   break;
+
+   case DISPLAY_ENTITY_STATE_ON:
+   display_entity_set_stream(to_display_entity(source->entity),
+ source->index,
+ DISPLAY_ENTITY_STREAM_CONTINUOUS);
+   break;
+   }
+
+   return 0;
+}
+
+static int con_vga_get_modes(struct display_entity *entity, unsigned int port,
+const struct videomode **modes)
+{
+   /* TODO: Add EDID retrieval support. */
+   return 0;
+}
+
+static int con_vga_get_params(struct display_entity *entity, unsigned int port,
+ struct display_entity_interface_params *params)
+{
+   memset(params, 0, sizeof(*params));
+
+   params->type = DISPLAY_ENTITY_INTERFACE_VGA;
+
+   return 0;
+}
+
+static const struct display_entity_control_ops con_vga_control_ops = {
+   .set_state = con_vga_set_state,
+   .get_modes = con_vga_get_modes,
+   .get_params = con_vga_get_params,
+};
+
+static const struct display_entity_ops con_vga_ops = {
+   .ctrl = &con_vga_control_ops,
+};
+
+static int con_vga_remove(struct platform_device *pdev)
+{
+   struct con_vga *con = platform_get_drvdata(pdev);
+
+   display_entity_remove(&con->entity);
+   display_entity_cleanup(&con->entity);
+
+   return 0;
+}
+
+static int con_vga_probe(struct platform_device *pdev)
+{
+   struct con_vga *con;
+   int ret;
+
+   con = devm_kzalloc(&pdev->dev, sizeof(*con), GFP_KERNEL);
+   if (con == NULL)
+   return -ENOMEM;
+
+   con->entity.dev = &pdev->dev;
+   con->entity.ops = &con_vga_ops;
+   strlcpy(con->entity.name, "vga-con", sizeof(con->entity.name));
+
+   ret = display_entity_init(&con->entity, 1, 0);
+   if (ret 

[PATCH/RFC v3 14/19] ARM: shmobile: r8a7790: Add DU clocks for DT

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 arch/arm/mach-shmobile/clock-r8a7790.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c 
b/arch/arm/mach-shmobile/clock-r8a7790.c
index d99b87b..7229f96 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -257,10 +257,15 @@ static struct clk_lookup lookups[] = {
 
/* MSTP */
CLKDEV_ICK_ID("lvds.0", "rcar-du-r8a7790", &mstp_clks[MSTP726]),
+   CLKDEV_ICK_ID("lvds.0", "feb0.display", &mstp_clks[MSTP726]),
CLKDEV_ICK_ID("lvds.1", "rcar-du-r8a7790", &mstp_clks[MSTP725]),
+   CLKDEV_ICK_ID("lvds.1", "feb0.display", &mstp_clks[MSTP725]),
CLKDEV_ICK_ID("du.0", "rcar-du-r8a7790", &mstp_clks[MSTP724]),
+   CLKDEV_ICK_ID("du.0", "feb0.display", &mstp_clks[MSTP724]),
CLKDEV_ICK_ID("du.1", "rcar-du-r8a7790", &mstp_clks[MSTP723]),
+   CLKDEV_ICK_ID("du.1", "feb0.display", &mstp_clks[MSTP723]),
CLKDEV_ICK_ID("du.2", "rcar-du-r8a7790", &mstp_clks[MSTP722]),
+   CLKDEV_ICK_ID("du.2", "feb0.display", &mstp_clks[MSTP722]),
CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP204]),
CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP203]),
CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP206]),
-- 
1.8.1.5

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

[PATCH/RFC v3 15/19] ARM: shmobile: r8a7790: Add DU device node to device tree

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7790.dtsi | 33 +
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index ab0582c..b63f1a6 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -186,4 +186,37 @@
reg = <0 0xe606 0 0x250>;
#gpio-range-cells = <3>;
};
+
+   du: display@feb0 {
+   compatible = "renesas,du-r8a7790";
+   reg = <0 0xfeb0 0 0x7>,
+ <0 0xfeb9 0 0x1c>,
+ <0 0xfeb94000 0 0x1c>;
+   reg-names = "core", "lvds.0", "lvds.1";
+   interrupt-parent = <&gic>;
+   interrupts = <0 256 4
+ 0 268 4
+ 0 269 4>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   du_out_rgb: endpoint {
+   };
+   };
+   port@1 {
+   reg = <1>;
+   du_out_lvds0: endpoint {
+   };
+   };
+   port@2 {
+   reg = <2>;
+   du_out_lvds1: endpoint {
+   };
+   };
+   };
+   };
 };
-- 
1.8.1.5

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

[PATCH/RFC v3 16/19] ARM: shmobile: marzen: Port DU platform data to CDF

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 arch/arm/mach-shmobile/board-marzen.c | 77 ---
 1 file changed, 53 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-marzen.c 
b/arch/arm/mach-shmobile/board-marzen.c
index 6499f1a..be1b7cb 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
@@ -39,6 +39,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -174,35 +176,56 @@ static struct platform_device hspi_device = {
  * The panel only specifies the [hv]display and [hv]total values. The position
  * and width of the sync pulses don't matter, they're copied from VESA timings.
  */
-static struct rcar_du_encoder_data du_encoders[] = {
+static const struct videomode marzen_panel_mode = {
+   .pixelclock = 6500,
+   .hactive = 1024,
+   .hfront_porch = 24,
+   .hback_porch = 160,
+   .hsync_len = 136,
+   .vactive = 768,
+   .vfront_porch = 3,
+   .vback_porch = 29,
+   .vsync_len = 6,
+   .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_dpi_platform_data marzen_panel_data = {
+   .width = 210,
+   .height = 158,
+   .mode = &marzen_panel_mode,
+};
+
+static const struct display_entity_graph_data marzen_du_entities[] = {
{
-   .type = RCAR_DU_ENCODER_VGA,
-   .output = RCAR_DU_OUTPUT_DPAD0,
+   .name = "adv7123",
+   .sources = (const struct display_entity_source_data[]) {
+   {
+   .name = "rcar-du",
+   .port = 0,
+   },
+   },
}, {
-   .type = RCAR_DU_ENCODER_LVDS,
-   .output = RCAR_DU_OUTPUT_DPAD1,
-   .connector.lvds.panel = {
-   .width_mm = 210,
-   .height_mm = 158,
-   .mode = {
-   .clock = 65000,
-   .hdisplay = 1024,
-   .hsync_start = 1048,
-   .hsync_end = 1184,
-   .htotal = 1344,
-   .vdisplay = 768,
-   .vsync_start = 771,
-   .vsync_end = 777,
-   .vtotal = 806,
-   .flags = 0,
+   .name = "con-vga",
+   .sources = (const struct display_entity_source_data[]) {
+   {
+   .name = "adv7123",
+   .port = 1,
},
},
+   }, {
+   .name = "panel-dpi",
+   .sources = (const struct display_entity_source_data[]) {
+   {
+   .name = "rcar-du",
+   .port = 1,
+   },
+   },
+   }, {
},
 };
 
-static const struct rcar_du_platform_data du_pdata __initconst = {
-   .encoders = du_encoders,
-   .num_encoders = ARRAY_SIZE(du_encoders),
+static const struct rcar_du_platform_data marzen_du_pdata __initconst = {
+   .graph = marzen_du_entities,
 };
 
 static const struct resource du_resources[] __initconst = {
@@ -217,8 +240,8 @@ static void __init marzen_add_du_device(void)
.id = -1,
.res = du_resources,
.num_res = ARRAY_SIZE(du_resources),
-   .data = &du_pdata,
-   .size_data = sizeof(du_pdata),
+   .data = &marzen_du_pdata,
+   .size_data = sizeof(marzen_du_pdata),
.dma_mask = DMA_BIT_MASK(32),
};
 
@@ -327,6 +350,12 @@ static void __init marzen_init(void)
r8a7779_add_standard_devices();
platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
marzen_add_du_device();
+
+   platform_device_register_simple("adv7123", -1, NULL, 0);
+   platform_device_register_simple("con-vga", -1, NULL, 0);
+   platform_device_register_data(&platform_bus, "panel-dpi", -1,
+ &marzen_panel_data,
+ sizeof(marzen_panel_data));
 }
 
 static const char *marzen_boards_compat_dt[] __initdata = {
-- 
1.8.1.5

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

[PATCH/RFC v3 17/19] ARM: shmobile: lager: Port DU platform data to CDF

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 arch/arm/mach-shmobile/board-lager.c | 76 +---
 1 file changed, 53 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-lager.c 
b/arch/arm/mach-shmobile/board-lager.c
index 75a01bc..d61b892 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -40,35 +42,56 @@
 #include 
 
 /* DU */
-static struct rcar_du_encoder_data lager_du_encoders[] = {
+static const struct videomode lager_panel_mode = {
+   .pixelclock = 6500,
+   .hactive = 1024,
+   .hfront_porch = 24,
+   .hback_porch = 160,
+   .hsync_len = 136,
+   .vactive = 768,
+   .vfront_porch = 3,
+   .vback_porch = 29,
+   .vsync_len = 6,
+   .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_dpi_platform_data lager_panel_data = {
+   .width = 210,
+   .height = 158,
+   .mode = &lager_panel_mode,
+};
+
+static const struct display_entity_graph_data lager_du_entities[] = {
{
-   .type = RCAR_DU_ENCODER_VGA,
-   .output = RCAR_DU_OUTPUT_DPAD0,
+   .name = "adv7123",
+   .sources = (const struct display_entity_source_data[]) {
+   {
+   .name = "rcar-du",
+   .port = 0,
+   },
+   },
}, {
-   .type = RCAR_DU_ENCODER_NONE,
-   .output = RCAR_DU_OUTPUT_LVDS1,
-   .connector.lvds.panel = {
-   .width_mm = 210,
-   .height_mm = 158,
-   .mode = {
-   .clock = 65000,
-   .hdisplay = 1024,
-   .hsync_start = 1048,
-   .hsync_end = 1184,
-   .htotal = 1344,
-   .vdisplay = 768,
-   .vsync_start = 771,
-   .vsync_end = 777,
-   .vtotal = 806,
-   .flags = 0,
+   .name = "con-vga",
+   .sources = (const struct display_entity_source_data[]) {
+   {
+   .name = "adv7123",
+   .port = 1,
},
},
+   }, {
+   .name = "panel-dpi",
+   .sources = (const struct display_entity_source_data[]) {
+   {
+   .name = "rcar-du",
+   .port = 2,
+   },
+   },
+   }, {
},
 };
 
 static const struct rcar_du_platform_data lager_du_pdata __initconst = {
-   .encoders = lager_du_encoders,
-   .num_encoders = ARRAY_SIZE(lager_du_encoders),
+   .graph = lager_du_entities,
 };
 
 static const struct resource du_resources[] __initconst = {
@@ -87,8 +110,8 @@ static void __init lager_add_du_device(void)
.id = -1,
.res = du_resources,
.num_res = ARRAY_SIZE(du_resources),
-   .data = &du_resources,
-   .size_data = sizeof(du_resources),
+   .data = &lager_du_pdata,
+   .size_data = sizeof(lager_du_pdata),
.dma_mask = DMA_BIT_MASK(32),
};
 
@@ -202,6 +225,7 @@ static void __init lager_add_standard_devices(void)
r8a7790_pinmux_init();
 
r8a7790_add_standard_devices();
+
platform_device_register_data(&platform_bus, "leds-gpio", -1,
  &lager_leds_pdata,
  sizeof(lager_leds_pdata));
@@ -220,6 +244,12 @@ static void __init lager_add_standard_devices(void)
  ðer_pdata, sizeof(ether_pdata));
 
lager_add_du_device();
+
+   platform_device_register_simple("adv7123", -1, NULL, 0);
+   platform_device_register_simple("con-vga", -1, NULL, 0);
+   platform_device_register_data(&platform_bus, "panel-dpi", -1,
+ &lager_panel_data,
+ sizeof(lager_panel_data));
 }
 
 static const char * const lager_boards_compat_dt[] __initconst = {
-- 
1.8.1.5

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

[PATCH/RFC v3 18/19] ARM: shmobile: lager-reference: Add display device nodes to device tree

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7790-lager-reference.dts | 92 +++
 1 file changed, 92 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager-reference.dts 
b/arch/arm/boot/dts/r8a7790-lager-reference.dts
index d9a25d5..ba2469b 100644
--- a/arch/arm/boot/dts/r8a7790-lager-reference.dts
+++ b/arch/arm/boot/dts/r8a7790-lager-reference.dts
@@ -42,6 +42,98 @@
gpios = <&gpio5 17 GPIO_ACTIVE_HIGH>;
};
};
+
+   adv7123 {
+   compatible = "adi,adv7123";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   adv7123_in: endpoint {
+   remote-endpoint = <&du_out_rgb>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   adv7123_out: endpoint {
+   remote-endpoint = <&con_vga_in>;
+   };
+   };
+   };
+   };
+
+   con-vga {
+   compatible = "con-vga";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   con_vga_in: endpoint {
+   remote-endpoint = <&adv7123_out>;
+   };
+   };
+   };
+   };
+
+   panel-dpi {
+   compatible = "panel-dpi";
+
+   width-mm = <210>;
+   height-mm = <158>;
+
+   display-timings {
+   timing {
+   /* 1024x768 @65Hz */
+   clock-frequency = <6500>;
+   hactive = <1024>;
+   vactive = <768>;
+   hsync-len = <136>;
+   hfront-porch = <20>;
+   hback-porch = <160>;
+   vfront-porch = <3>;
+   vback-porch = <29>;
+   vsync-len = <6>;
+   };
+   };
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   panel_in: endpoint {
+   remote-endpoint = <&du_out_lvds1>;
+   };
+   };
+   };
+   };
+};
+
+&du {
+   pinctrl-0 = <&du_pins>;
+   pinctrl-names = "default";
+};
+
+&du_out_rgb {
+   remote-endpoint = <&adv7123_in>;
+};
+
+&du_out_lvds1 {
+   remote-endpoint = <&panel_in>;
+};
+
+&pfc {
+   du_pins: du {
+   renesas,groups = "du_rgb666", "du_sync_1", "du_clk_out_0";
+   renesas,function = "du";
+   };
 };
 
 &pfc {
-- 
1.8.1.5

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

[PATCH/RFC v3 19/19] drm/rcar-du: Port to the Common Display Framework

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/Kconfig |   3 +-
 drivers/gpu/drm/rcar-du/Makefile|   7 +-
 drivers/gpu/drm/rcar-du/rcar_du_connector.c | 164 
 drivers/gpu/drm/rcar-du/rcar_du_connector.h |  36 
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 279 
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  28 ++-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c   |  87 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h   |  22 +--
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 116 ++--
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c   | 131 -
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h   |  25 ---
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c|  96 --
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h|  23 ---
 include/linux/platform_data/rcar-du.h   |  55 +-
 15 files changed, 611 insertions(+), 463 deletions(-)
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_connector.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_connector.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index c590cd9..a54eeba 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -1,9 +1,10 @@
 config DRM_RCAR_DU
tristate "DRM Support for R-Car Display Unit"
-   depends on DRM && ARM
+   depends on DRM && ARM && OF
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
+   select VIDEOMODE_HELPERS
help
  Choose this option if you have an R-Car chipset.
  If M is selected the module will be called rcar-du-drm.
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 12b8d44..3ac8566 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -1,11 +1,10 @@
-rcar-du-drm-y := rcar_du_crtc.o \
+rcar-du-drm-y := rcar_du_connector.o \
+rcar_du_crtc.o \
 rcar_du_drv.o \
 rcar_du_encoder.o \
 rcar_du_group.o \
 rcar_du_kms.o \
-rcar_du_lvdscon.o \
-rcar_du_plane.o \
-rcar_du_vgacon.o
+rcar_du_plane.o
 
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_connector.c 
b/drivers/gpu/drm/rcar-du/rcar_du_connector.c
new file mode 100644
index 000..a09aada
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_connector.c
@@ -0,0 +1,164 @@
+/*
+ * rcar_du_connector.c  --  R-Car Display Unit Connector
+ *
+ * Copyright (C) 2013 Renesas Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "rcar_du_drv.h"
+#include "rcar_du_connector.h"
+#include "rcar_du_encoder.h"
+#include "rcar_du_kms.h"
+
+static int rcar_du_connector_get_modes(struct drm_connector *connector)
+{
+   struct rcar_du_connector *rcon = to_rcar_connector(connector);
+   struct display_entity *entity = to_display_entity(rcon->pad->entity);
+   const struct videomode *modes;
+   int ret;
+   int i;
+
+   ret = display_entity_get_modes(entity, rcon->pad->index, &modes);
+   if (ret <= 0)
+   return drm_add_modes_noedid(connector, 1280, 768);
+
+   for (i = 0; i < ret; ++i) {
+   struct drm_display_mode *mode;
+
+   mode = drm_mode_create(connector->dev);
+   if (mode == NULL)
+   break;
+
+   mode->type = DRM_MODE_TYPE_PREFERRED | DRM_MODE_TYPE_DRIVER;
+   drm_display_mode_from_videomode(&modes[i], mode);
+   drm_mode_probed_add(connector, mode);
+   }
+
+   return i;
+}
+
+static int rcar_du_connector_mode_valid(struct drm_connector *connector,
+   struct drm_display_mode *mode)
+{
+   return MODE_OK;
+}
+
+static struct drm_encoder *
+rcar_du_connector_best_encoder(struct drm_connector *connector)
+{
+   struct rcar_du_connector *rcon = to_rcar_connector(connector);
+
+   return &rcon->encoder->encoder;
+}
+
+static const struct drm_connector_helper_funcs connector_helper_funcs = {
+   .get_modes = rcar_du_connector_get_modes,
+   .mode_valid = rcar_du_connector_mode_valid,
+   .best_encoder = rcar_du_connector_be

[Bug 67800] Computer freezes after idle for several hours (trinity)

[bugzilla-daemon]

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

--- Comment #7 from Kertesz Laszlo  ---
Last night i rebooted and re-activated C6 in the BIOS. Reactivated dpms (turn
off display completely after 4 minutes).

It the morning (~7 hours of idle time) the computer works as expected. So it
seems that those patches  solved this issue. I will test it further for anothey
day.

As a sideline, sleep state C6 enabled in the BIOS (versus disabled) lowers the
idle temperature of the APU by 2-4 C.

-- 
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 67970] New: Kernel bugs related to the powersaving features of mobility radeon x1400

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 67970
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Kernel bugs related to the powersaving features of
mobility radeon x1400
  Severity: blocker
Classification: Unclassified
OS: Linux (All)
  Reporter: shayanmans...@yahoo.com
  Hardware: All
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

I have a Mobility Radeon X1400 (RV500 Family) on my dell inspiron 6400 (or it's
called inspiron 1501 or 1505 elsewhere). I use Open-source drivers and they
work for me and I have no problem with anything except the powermanagement at
kernel level.

When I want to activate powersaving feature I use these commands:

1. when I use this command:
echo dynpm > /sys/class/drm/card0/device/power_method

nothing happens. I mean GPU frequency remain high. I even do not use a GUI. I'm
in the shell.

2. when I use these commands
echo profile > /sys/class/drm/card0/device/power_method
echo low > /sys/class/drm/card0/device/power_profile

I receive these error: 
 kernel:[  192.253008] NMI: PCI system error (SERR) for reason b1 on CPU 0.
 kernel:[  192.253016] Dazed and confused, but trying to continue

I have noticed that the kernel do not changes the GPU and Vram frequencies
correctly in the profile mode. 

This is what I get when I set it to mid:
# echo mid > /sys/class/drm/card0/device/power_profile
# cat /sys/kernel/debug/dri/0/radeon_pm_info

default engine clock: 432000 kHz
current engine clock: 209250 kHz
default memory clock: 396000 kHz
current memory clock: 135000 kHz
PCIE lanes: 1

This is what I get when I set it to low:
# echo low > /sys/class/drm/card0/device/power_profile
# cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 432000 kHz
current engine clock: 324000 kHz
default memory clock: 396000 kHz
current memory clock: 135000 kHz
PCIE lanes: 1

This is what I get when I set it to high:
# echo high > /sys/class/drm/card0/device/power_profile
# cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 432000 kHz
current engine clock: 432000 kHz
default memory clock: 396000 kHz
current memory clock: 396000 kHz
PCIE lanes: 0

If you look at the above values, it is obvious that the current clock of mid
and low profiles should be replaced with each other.

I've tested this in different distribution of GNU/Linux with different kernel
versions: Including Ubuntu, LMDE, Archlinux and Chakra. with these kernel
versions: 2.6.38, 2.6.39, 3.0.0 RC5, 3.0.0-1-amd64 in LMDE, and lately with
3.4.55 LTS in ubuntu 12.04.2.

-- 
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: [RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

[Inki Dae]

2013/8/8 Daniel Vetter 

> Just comment a bit on Rob's review with my own opinion.
>
> On Wed, Aug 07, 2013 at 12:17:21PM -0400, Rob Clark wrote:
> > On Thu, Jul 25, 2013 at 1:17 PM,   wrote:
> > > From: Tom Cooksey 
> > >
> > > This is a mode-setting driver for the pl111 CLCD display controller
> > > found on various ARM reference platforms such as the Versatile
> > > Express. The driver supports setting of a single mode (640x480) and
> > > has only been tested on Versatile Express with a Cortex-A9 core tile.
> > >
> > > Known issues:
> > >  * It still includes code to use KDS, which is not going upstream.
> >
> > review's on
> http://lists.freedesktop.org/archives/dri-devel/2013-July/042462.html
> > can't hurt
> >
> > although you might consider submitting a reduced functionality driver
> > w/ KDS bits removed in the mean time.. then when the fence stuff is
> > merged it is just an incremental patch rather than a whole driver ;-)
>
> Yeah, I think the KDS bits and comments need to go first before merginge.
>
>
> > > +/*
> > > + * Number of flips allowed in flight at any one time. Any more flips
> requested
> > > + * beyond this value will cause the caller to block until earlier
> flips have
> > > + * completed.
> > > + *
> > > + * For performance reasons, this must be greater than the number of
> buffers
> > > + * used in the rendering pipeline. Note that the rendering pipeline
> can contain
> > > + * different types of buffer, e.g.:
> > > + * - 2 final framebuffers
> > > + * - >2 geometry buffers for GPU use-cases
> > > + * - >2 vertex buffers for GPU use-cases
> > > + *
> > > + * For example, a system using 5 geometry buffers could have 5 flips
> in flight,
> > > + * and so NR_FLIPS_IN_FLIGHT_THRESHOLD must be 5 or greater.
> > > + *
> > > + * Whilst there may be more intermediate buffers (such as
> vertex/geometry) than
> > > + * final framebuffers, KDS is used to ensure that GPU rendering waits
> for the
> > > + * next off-screen buffer, so it doesn't overwrite an on-screen
> buffer and
> > > + * produce tearing.
> > > + */
> > > +
> >
> > fwiw, this is at least different from how other drivers do triple (or
> > > double) buffering.  In other drivers (intel, omap, and
> > msm/freedreno, that I know of, maybe others too) the xorg driver dri2
> > bits implement the double buffering (ie. send flip event back to
> > client immediately and queue up the flip and call page-flip after the
> > pageflip event back from kernel.
> >
> > I'm not saying not to do it this way, I guess I'd like to hear what
> > other folks think.  I kinda prefer doing this in userspace as it keeps
> > the kernel bits simpler (plus it would then work properly on exynosdrm
> > or other kms drivers).
>
> Yeah, if this is just a sw queue then I don't think it makes sense to have
> it in the kernel. Afaik the current pageflip interface drm exposes allows
> one oustanding flip only, and you _must_ wait for the flip complete event
> before you can submit the second one.
>

Agree. Tizen platform using exynos drm driver also does in same way. And
there is another issue we are facing with. Please, assume CPU and GPU are
sharing a same buffer. The issue is that in case of using glFlush GL API,
3d app cannot be aware of when GPU access to the buffer is
completed: the completion event is sent only to GPU specific API; in our
case, MALI specific DDK, so the buffer could be broken if CPU accesses the
buffer at once after glFlush. Of course we can use glFinish instead of
glFlush but glFinish makes GPU more idle: CPU should wait for the
completion of GPU access to the buffer so CPU cannot do anything until that
time. So I'd like to know how other folks take care of this issue.

In our case, we are using dmabuf sync framework I posted before because
I thought we may need buffer access control between CPU and DMA: the user
land interfaces are fcntl and select system calls so no having any new
additional api. with this feature, 3d app, only using standard GL API, can
be aware of the completion event from GPU driver without DRM or other
driver API. For this, I will introduce the more stable patch set soon with
more features.

For this, I'd happy to give me other opinions and advices if there is my
missing point.

Thanks,
Inki Dae


>
> Ofc if your hardware as a hw-based flip queue (maybe even with frame
> targets) that's a different matter, but currently we don't have a drm
> interface to expose this. I'd say for merging the basic driver first we
> should go with the existing simple pageflip semantics.
>
> And tbh I don't understand why the amount of buffers you keep in the
> render pipeline side of things matters here at all. But I also haven't
> read the details of your driver code.
>
> >
> > > +/*
> > > + * Here, we choose a conservative value. A lower value is most likely
> > > + * suitable for GPU use-cases.
> > > + */
> > > +#define NR_FLIPS_IN_FLIGHT_THRESHOLD 16
> > > +
> > > +#define CLCD_IRQ_NEXTBASE_UPDATE (1u<<2)
> > > +
> > > +struct pl111_

[PATCH] drm: Add drm_bridge

[Daniel Vetter]

On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul  wrote:
> This patch adds the notion of a drm_bridge. A bridge is a chained
> device which hangs off an encoder. The drm driver using the bridge
> should provide the association between encoder and bridge. Once a
> bridge is associated with an encoder, it will participate in mode
> set, dpms, and optionally connection detection.
>
> Since a connector may not be able to determine the connection state
> downstream of the bridge, bridges may implement detect() which will take
> precedence over connector detect() if the bridge is already attached
> to an encoder and that encoder is already attached to the connector.
> In practical terms, this requires the drm driver to make these
> associations at init time, which is fine for SoC applications where
> this link is static.
>
> Signed-off-by: Sean Paul 

A few comments below. I think overall any such infrastructure simply
needs to demonstrate viability on a few drivers, that makes it much
simpler to check whether the interfaces make sense. Generally I'd make
more sense for me if the bridge is just an implementation detail of a
given encoder and if the bridge would not be exposed to the crtc
helpers. With that abstraction chaining would be more natural imo and
we'd also have a much higher chance that bridge drivers work accross
different drm drivers: Atm you can run some encoder stuff in the crtc
callbacks and the other way round (and pretty much every driver for a
bit more complicated hw does that), and every driver can differ in
those tricks a bit. If we bake the bridge callbacks into the crtc
helpers I expect that for bridges with tricky ordering constraints
this will become a giant mess. So I'd prefer much if this would work
like drm i2c slave encoders.

Cheers, Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c|  50 +
>  drivers/gpu/drm/drm_crtc_helper.c | 112 
> ++
>  drivers/gpu/drm/drm_sysfs.c   |   8 ++-
>  include/drm/drm_crtc.h|  48 
>  include/drm/drm_crtc_helper.h |  34 
>  5 files changed, 241 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index fc83bb9..0311e2b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -781,6 +781,41 @@ void drm_connector_unplug_all(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_connector_unplug_all);
>
> +int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
> +   const struct drm_bridge_funcs *funcs)
> +{
> +   int ret;
> +
> +   drm_modeset_lock_all(dev);
> +
> +   ret = drm_mode_object_get(dev, &bridge->base, DRM_MODE_OBJECT_BRIDGE);
> +   if (ret)
> +   goto out;
> +
> +   bridge->dev = dev;
> +   bridge->funcs = funcs;
> +
> +   list_add_tail(&bridge->head, &dev->mode_config.bridge_list);
> +   dev->mode_config.num_bridge++;
> +
> + out:
> +   drm_modeset_unlock_all(dev);
> +   return ret;
> +}
> +EXPORT_SYMBOL(drm_bridge_init);
> +
> +void drm_bridge_cleanup(struct drm_bridge *bridge)
> +{
> +   struct drm_device *dev = bridge->dev;
> +
> +   drm_modeset_lock_all(dev);
> +   drm_mode_object_put(dev, &bridge->base);
> +   list_del(&bridge->head);
> +   dev->mode_config.num_bridge--;
> +   drm_modeset_unlock_all(dev);
> +}
> +EXPORT_SYMBOL(drm_bridge_cleanup);
> +
>  int drm_encoder_init(struct drm_device *dev,
>   struct drm_encoder *encoder,
>   const struct drm_encoder_funcs *funcs,
> @@ -1190,6 +1225,7 @@ static int drm_mode_group_init(struct drm_device *dev, 
> struct drm_mode_group *gr
> total_objects += dev->mode_config.num_crtc;
> total_objects += dev->mode_config.num_connector;
> total_objects += dev->mode_config.num_encoder;
> +   total_objects += dev->mode_config.num_bridge;
>
> group->id_list = kzalloc(total_objects * sizeof(uint32_t), 
> GFP_KERNEL);
> if (!group->id_list)
> @@ -1198,6 +1234,7 @@ static int drm_mode_group_init(struct drm_device *dev, 
> struct drm_mode_group *gr
> group->num_crtcs = 0;
> group->num_connectors = 0;
> group->num_encoders = 0;
> +   group->num_bridges = 0;
> return 0;
>  }
>
> @@ -1207,6 +1244,7 @@ int drm_mode_group_init_legacy_group(struct drm_device 
> *dev,
> struct drm_crtc *crtc;
> struct drm_encoder *encoder;
> struct drm_connector *connector;
> +   struct drm_bridge *bridge;
> int ret;
>
> if ((ret = drm_mode_group_init(dev, group)))
> @@ -1223,6 +1261,11 @@ int drm_mode_group_init_legacy_group(struct drm_device 
> *dev,
> group->id_list[group->num_crtcs + group->num_encoders +
>group->num_connectors++] = connector->base.id;
>
> +   list_for_each_entry(bridge, &dev->mode_config.bridge_list, head)
> +   group-

[Bug 60709] With 3.10.3 / 3.10.5 screen output is "green" - looks like a green overlay

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

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

--- Comment #17 from Torsten Krah  ---
Done with bisect - did take some time but got it:

d3418eacad403033e95e49dc14afa37c2112c134 is the first bad commit
commit d3418eacad403033e95e49dc14afa37c2112c134
Author: Rafa? Mi?ecki 
Date:   Thu Apr 18 09:23:12 2013 -0400

drm/radeon/evergreen: setup HDMI before enabling it

Closed source driver fglrx seems to enable infoframes and audio packets
at the end, which makes sense, do the same.

Signed-off-by: Rafa? Mi?ecki 
Signed-off-by: Alex Deucher 

:04 04 67e10b90afeefe688d0c291e603c80dd7a9e810a
1105ef4336989eee87c971b035fedcc092c42417 Mdrivers

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 66738] System freeze randomly with latest kernel 3.10 (also 3.11-rc4)

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

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

--- Comment #12 from lh  ---
(In reply to comment #11)
> Are you running the same userspace stack with both kernel 3.9 and kernel
> 3.10/3.11?  If so, it sounds like this is UVD related.

Yes, I have two kernels: arch official kernel 3.9.9 and kernel
3.11-rc4(https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git) which
compiled myself.

3.9.9 was quiet stable here.

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

[git pull] drm fixes

[Dave Airlie]

Hi Linus

mostly radeon, more fixes for dynamic power management which is is off by 
default for this release anyways, but there are a large number of testers, 
so I'd like to keep merging the fixes,

otherwise, radeon UVD fixes affecting suspend/resume regressions, i915 
regression fixes, one for your mac mini, ast,mgag200,cirrus ttm fix and 
one regression fix in the core.

Dave.

The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:

  Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to e42f5814212079aecd5826dba10588a896ac0862:

  Merge tag 'drm-intel-fixes-2013-08-08' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-08-09 
09:09:37 +1000)



Aaron Lu (1):
  drm/i915: avoid brightness overflow when doing scale

Alex Deucher (11):
  drm/radeon: properly handle pm on gpu reset
  drm/radeon: select audio dto based on encoder id for DCE3
  drm/radeon/dpm: adjust thermal protection requirements
  drm/radeon/dpm: fix spread spectrum setup (v2)
  drm/radeon/dpm: adjust power state properly for UVD on SI
  drm/radeon/dpm: disable sclk ss on rv6xx
  drm/radeon: fix audio dto calculation on DCE3+ (v3)
  drm/radeon: always program the MC on startup
  drm/radeon/cik: use a mutex to properly lock srbm instanced registers
  drm/radeon/dpm: require rlc for dpm
  drm/radeon: make missing smc ucode non-fatal

Christian K?nig (5):
  drm/radeon: fix halting UVD
  drm/radeon: only save UVD bo when we have open handles
  drm/radeon: stop sending invalid UVD destroy msg
  drm/radeon: add more UVD CS checking
  drm/radeon: remove unnecessary unpin

Daniel Vetter (1):
  drm/i915: fix gen4 digital port hotplug definitions

Dave Airlie (3):
  drm/ast: invalidate page tables when pinning a BO
  Merge branch 'drm-fixes-3.11' of git://people.freedesktop.org/~agd5f/linux
  Merge tag 'drm-intel-fixes-2013-08-08' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

Egbert Eich (1):
  drm/mgag200: Invalidate page tables when pinning a BO

Jani Nikula (1):
  drm/i915: do not disable backlight on vgaswitcheroo switch off

Michal Srb (1):
  drm/cirrus: Invalidate page tables when pinning a BO

Michel D?nzer (1):
  drm: Don't pass negative delta to ktime_sub_ns()

Paulo Zanoni (1):
  drm/i915: update last_vblank when disabling the power well

Ville Syrj?l? (1):
  drm/i915: Don't call encoder's get_config unless encoder is active

 drivers/gpu/drm/ast/ast_ttm.c   |  1 +
 drivers/gpu/drm/cirrus/cirrus_ttm.c |  1 +
 drivers/gpu/drm/drm_irq.c   |  5 +-
 drivers/gpu/drm/i915/i915_reg.h | 12 +++--
 drivers/gpu/drm/i915/intel_display.c|  4 +-
 drivers/gpu/drm/i915/intel_panel.c  | 18 ++-
 drivers/gpu/drm/i915/intel_pm.c | 18 +++
 drivers/gpu/drm/mgag200/mgag200_ttm.c   |  1 +
 drivers/gpu/drm/radeon/btc_dpm.c| 17 +-
 drivers/gpu/drm/radeon/cik.c| 18 +--
 drivers/gpu/drm/radeon/cypress_dpm.c| 17 +-
 drivers/gpu/drm/radeon/evergreen.c  |  6 ++-
 drivers/gpu/drm/radeon/evergreen_hdmi.c | 26 -
 drivers/gpu/drm/radeon/evergreend.h |  3 ++
 drivers/gpu/drm/radeon/ni.c | 16 --
 drivers/gpu/drm/radeon/ni_dpm.c | 17 +-
 drivers/gpu/drm/radeon/r600.c   | 41 +++
 drivers/gpu/drm/radeon/r600_hdmi.c  | 37 +++--
 drivers/gpu/drm/radeon/r600d.h  |  3 ++
 drivers/gpu/drm/radeon/radeon.h |  4 +-
 drivers/gpu/drm/radeon/radeon_asic.h|  2 +-
 drivers/gpu/drm/radeon/radeon_device.c  |  3 ++
 drivers/gpu/drm/radeon/radeon_fence.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_gart.c|  1 -
 drivers/gpu/drm/radeon/radeon_pm.c  |  9 +++-
 drivers/gpu/drm/radeon/radeon_uvd.c | 93 +
 drivers/gpu/drm/radeon/rv6xx_dpm.c  | 22 
 drivers/gpu/drm/radeon/rv770.c  |  7 ++-
 drivers/gpu/drm/radeon/rv770_dpm.c  | 33 ++--
 drivers/gpu/drm/radeon/rv770_dpm.h  |  1 +
 drivers/gpu/drm/radeon/si.c | 19 ---
 drivers/gpu/drm/radeon/si_dpm.c | 61 +++--
 32 files changed, 353 insertions(+), 165 deletions(-)

[PATCH 22/25] drm: no-op out GET_STATS ioctl

[Daniel Vetter]

On Thu, Aug 08, 2013 at 05:55:45PM +0200, Eric Anholt wrote:
> Daniel Vetter  writes:
> 
> > Again only used by a tests in libdrm and by dristat. Nowadays we have
> > much better tracing tools to get detailed insights into what a drm
> > driver is doing. And for a simple "does it work" kind of question that
> > these stats could answer we have plenty of dmesg debug log spew.
> >
> > So I don't see any use for this stat gathering complexity at all.
> >
> > To be able to gradually drop things start with ripping out the
> > interfaces to it, here the ioctl.
> >
> > To prevent dristat from eating its own stack garbage we can't use the
> > drm_noop ioctl though, since we need to clear the return data with a
> > memset.
> 
> I'm happy to see these two die.  Even back in the day we didn't use
> them.
> 
> This has been quite a trip down memory lane.
> 
> Patch 9 typo: s/functinal/functional/
> Patch 25 typo: s/loose/lose/

Fixed.

> Patches 2, 6-11, 19, 21, 22, 24, 25 are:
> 
> Reviewed-by: Eric Anholt 

Thanks for the review. I've pushed a fixed branch with r-b tags to

http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-cleanups

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

drm fixes for 3.11: Tag more patches for stable? (was: [git pull] drm fixes)

[Paul Menzel]

Dear Dave,


Am Freitag, den 09.08.2013, 05:53 +0100 schrieb Dave Airlie:

[?]

> The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:
> 
>   Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~airlied/linux drm-fixes
> 
> for you to fetch changes up to e42f5814212079aecd5826dba10588a896ac0862:
> 
>   Merge tag 'drm-intel-fixes-2013-08-08' of 
> git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-08-09 
> 09:09:37 +1000)
> 
> 
> 
> Aaron Lu (1):
>   drm/i915: avoid brightness overflow when doing scale
> 
> Alex Deucher (11):
>   drm/radeon: properly handle pm on gpu reset
>   drm/radeon: select audio dto based on encoder id for DCE3
>   drm/radeon/dpm: adjust thermal protection requirements
>   drm/radeon/dpm: fix spread spectrum setup (v2)
>   drm/radeon/dpm: adjust power state properly for UVD on SI
>   drm/radeon/dpm: disable sclk ss on rv6xx
>   drm/radeon: fix audio dto calculation on DCE3+ (v3)
>   drm/radeon: always program the MC on startup
>   drm/radeon/cik: use a mutex to properly lock srbm instanced registers
>   drm/radeon/dpm: require rlc for dpm
>   drm/radeon: make missing smc ucode non-fatal
> 
> Christian K?nig (5):
>   drm/radeon: fix halting UVD
>   drm/radeon: only save UVD bo when we have open handles
>   drm/radeon: stop sending invalid UVD destroy msg
>   drm/radeon: add more UVD CS checking
>   drm/radeon: remove unnecessary unpin

as UVD is also in 3.10 should more of these be tagged
`stable at vger.kernel.org` too? I only checked

drm/radeon: add more UVD CS checking

and it did not have that tag.

[?]


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130809/b610d5b9/attachment.pgp>

[Bug 67800] Computer freezes after idle for several hours (trinity)

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

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

--- Comment #6 from Kertesz Laszlo  ---
I recompiled the kernel (from linus' git) with these patches applied:

http://lists.freedesktop.org/archives/dri-devel/2013-August/043145.html
I also disabled C6 state from BIOS.

I had no freezes since then. I still have to test some longer idle times (i had
~3 hours maximum so far), but it seems promising.

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

[patch] drm/i915: precedence bug in hsw_compute_wm_results()

[Dan Carpenter]

The '!' operation has higher precedence than the compare so probably
this test is never true.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a5a9959..0b9d9a7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2562,7 +2562,7 @@ static void hsw_compute_wm_results(struct drm_device *dev,
 * a WM level. */
results->enable_fbc_wm = true;
for (level = 1; level <= max_level; level++) {
-   if (!lp_results[level - 1].fbc_val > lp_maximums->fbc) {
+   if (lp_results[level - 1].fbc_val <= lp_maximums->fbc) {
results->enable_fbc_wm = false;
lp_results[level - 1].fbc_val = 0;
}

[patch] drm/i915: unbreak i915_gem_object_ggtt_unbind()

[Dan Carpenter]

There is an extra semi-colon here so we just leak and never unbind
anything.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 735f43f..a582540 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2656,7 +2656,7 @@ i915_gem_object_ggtt_unbind(struct drm_i915_gem_object 
*obj)
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
struct i915_address_space *ggtt = &dev_priv->gtt.base;

-   if (!i915_gem_obj_ggtt_bound(obj));
+   if (!i915_gem_obj_ggtt_bound(obj))
return 0;

if (obj->pin_count)

[patch] drm/i915: precedence bug in hsw_compute_wm_results()

[Chris Wilson]

On Fri, Aug 09, 2013 at 12:43:02PM +0300, Dan Carpenter wrote:
> The '!' operation has higher precedence than the compare so probably
> this test is never true.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a5a9959..0b9d9a7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2562,7 +2562,7 @@ static void hsw_compute_wm_results(struct drm_device 
> *dev,
>* a WM level. */
>   results->enable_fbc_wm = true;
>   for (level = 1; level <= max_level; level++) {
> - if (!lp_results[level - 1].fbc_val > lp_maximums->fbc) {
> + if (lp_results[level - 1].fbc_val <= lp_maximums->fbc) {

I didn't spot that '!' at all. It's a stray and should be just removed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[patch] drm/i915: precedence bug in hsw_compute_wm_results()

[Ville Syrjälä]

On Fri, Aug 09, 2013 at 12:43:02PM +0300, Dan Carpenter wrote:
> The '!' operation has higher precedence than the compare so probably
> this test is never true.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a5a9959..0b9d9a7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2562,7 +2562,7 @@ static void hsw_compute_wm_results(struct drm_device 
> *dev,
>* a WM level. */
>   results->enable_fbc_wm = true;
>   for (level = 1; level <= max_level; level++) {
> - if (!lp_results[level - 1].fbc_val > lp_maximums->fbc) {
> + if (lp_results[level - 1].fbc_val <= lp_maximums->fbc) {

Whoops. My bad.

It should still be > but ! should just be dropped.

>   results->enable_fbc_wm = false;
>   lp_results[level - 1].fbc_val = 0;
>   }
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[patch] drm/i915: unbreak i915_gem_object_ggtt_unbind()

[Daniel Vetter]

On Fri, Aug 09, 2013 at 12:44:11PM +0300, Dan Carpenter wrote:
> There is an extra semi-colon here so we just leak and never unbind
> anything.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 735f43f..a582540 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2656,7 +2656,7 @@ i915_gem_object_ggtt_unbind(struct drm_i915_gem_object 
> *obj)
>   struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
>   struct i915_address_space *ggtt = &dev_priv->gtt.base;
>  
> - if (!i915_gem_obj_ggtt_bound(obj));
> + if (!i915_gem_obj_ggtt_bound(obj))

Oops, thanks for spotting this. Applied to dinq.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[patch v2] drm/i915: fix a limit check in hsw_compute_wm_results()

[Dan Carpenter]

The '!' here was not intended.  Since '!' has higher precedence than
compare, it means the check is never true.

Signed-off-by: Dan Carpenter 
---
v2: My first patch was wrong.

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 96234c6..0f5eb21 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2685,7 +2685,7 @@ static void hsw_compute_wm_results(struct drm_device *dev,
 * a WM level. */
results->enable_fbc_wm = true;
for (level = 1; level <= max_level; level++) {
-   if (!lp_results[level - 1].fbc_val > lp_maximums->fbc) {
+   if (lp_results[level - 1].fbc_val > lp_maximums->fbc) {
results->enable_fbc_wm = false;
lp_results[level - 1].fbc_val = 0;
}

[Intel-gfx] [patch v2] drm/i915: fix a limit check in hsw_compute_wm_results()

[Ville Syrjälä]

On Fri, Aug 09, 2013 at 01:07:31PM +0300, Dan Carpenter wrote:
> The '!' here was not intended.  Since '!' has higher precedence than
> compare, it means the check is never true.
> 
> Signed-off-by: Dan Carpenter 

Reviewed-by: Ville Syrj?l? 

The culprit for Daniel:

commit 71fff20ff1bb790f4defe0c880e028581ffab420
Author: Ville Syrj?l? 
Date:   Tue Aug 6 22:24:03 2013 +0300

drm/i915: Kill fbc_enable from hsw_lp_wm_results

> ---
> v2: My first patch was wrong.
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 96234c6..0f5eb21 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2685,7 +2685,7 @@ static void hsw_compute_wm_results(struct drm_device 
> *dev,
>* a WM level. */
>   results->enable_fbc_wm = true;
>   for (level = 1; level <= max_level; level++) {
> - if (!lp_results[level - 1].fbc_val > lp_maximums->fbc) {
> + if (lp_results[level - 1].fbc_val > lp_maximums->fbc) {
>   results->enable_fbc_wm = false;
>   lp_results[level - 1].fbc_val = 0;
>   }
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrj?l?
Intel OTC

drm fixes for 3.11: Tag more patches for stable? (was: [git pull] drm fixes)

[Dave Airlie]

On Fri, Aug 9, 2013 at 7:25 PM, Paul Menzel
 wrote:
> Dear Dave,
>
>
> Am Freitag, den 09.08.2013, 05:53 +0100 schrieb Dave Airlie:
>
> [?]
>
>> The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:
>>
>>   Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)
>>
>> are available in the git repository at:
>>
>>   git://people.freedesktop.org/~airlied/linux drm-fixes
>>
>> for you to fetch changes up to e42f5814212079aecd5826dba10588a896ac0862:
>>
>>   Merge tag 'drm-intel-fixes-2013-08-08' of 
>> git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-08-09 
>> 09:09:37 +1000)
>>
>> 
>>
>> Aaron Lu (1):
>>   drm/i915: avoid brightness overflow when doing scale
>>
>> Alex Deucher (11):
>>   drm/radeon: properly handle pm on gpu reset
>>   drm/radeon: select audio dto based on encoder id for DCE3
>>   drm/radeon/dpm: adjust thermal protection requirements
>>   drm/radeon/dpm: fix spread spectrum setup (v2)
>>   drm/radeon/dpm: adjust power state properly for UVD on SI
>>   drm/radeon/dpm: disable sclk ss on rv6xx
>>   drm/radeon: fix audio dto calculation on DCE3+ (v3)
>>   drm/radeon: always program the MC on startup
>>   drm/radeon/cik: use a mutex to properly lock srbm instanced registers
>>   drm/radeon/dpm: require rlc for dpm
>>   drm/radeon: make missing smc ucode non-fatal
>>
>> Christian K?nig (5):
>>   drm/radeon: fix halting UVD
>>   drm/radeon: only save UVD bo when we have open handles
>>   drm/radeon: stop sending invalid UVD destroy msg
>>   drm/radeon: add more UVD CS checking
>>   drm/radeon: remove unnecessary unpin
>
> as UVD is also in 3.10 should more of these be tagged
> `stable at vger.kernel.org` too? I only checked
>
> drm/radeon: add more UVD CS checking
>
> and it did not have that tag.

I think if they are required they might be best done via separate
backports, not sure how much the code has changed but dpm moved a lot
of stuff around.

Dave.

drm fixes for 3.11: Tag more patches for stable?

[Christian König]

Am 09.08.2013 11:25, schrieb Paul Menzel:
> Dear Dave,
>
>
> Am Freitag, den 09.08.2013, 05:53 +0100 schrieb Dave Airlie:
>
> [?]
>
>> The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:
>>
>>Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)
>>
>> are available in the git repository at:
>>
>>git://people.freedesktop.org/~airlied/linux drm-fixes
>>
>> for you to fetch changes up to e42f5814212079aecd5826dba10588a896ac0862:
>>
>>Merge tag 'drm-intel-fixes-2013-08-08' of 
>> git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-08-09 
>> 09:09:37 +1000)
>>
>> 
>>
>> Aaron Lu (1):
>>drm/i915: avoid brightness overflow when doing scale
>>
>> Alex Deucher (11):
>>drm/radeon: properly handle pm on gpu reset
>>drm/radeon: select audio dto based on encoder id for DCE3
>>drm/radeon/dpm: adjust thermal protection requirements
>>drm/radeon/dpm: fix spread spectrum setup (v2)
>>drm/radeon/dpm: adjust power state properly for UVD on SI
>>drm/radeon/dpm: disable sclk ss on rv6xx
>>drm/radeon: fix audio dto calculation on DCE3+ (v3)
>>drm/radeon: always program the MC on startup
>>drm/radeon/cik: use a mutex to properly lock srbm instanced registers
>>drm/radeon/dpm: require rlc for dpm
>>drm/radeon: make missing smc ucode non-fatal
>>
>> Christian K?nig (5):
>>drm/radeon: fix halting UVD
>>drm/radeon: only save UVD bo when we have open handles
>>drm/radeon: stop sending invalid UVD destroy msg
>>drm/radeon: add more UVD CS checking
>>drm/radeon: remove unnecessary unpin
> as UVD is also in 3.10 should more of these be tagged
> `stable at vger.kernel.org` too? I only checked
>
>  drm/radeon: add more UVD CS checking
>
> and it did not have that tag.

That patch doesn't have the tag because it is a (minor) new feature to 
check the incoming parameters for incorrect values and not a bugfix.

The other three UVD patches are bugfixes and indeed does have the 
necessary tag.

Regards,
Christian.

>
> [?]
>
>
> Thanks,
>
> Paul

[Bug 67946] New: Switching to Integrated card to vgaswitcheroo with radeon.audio=1 makes kernel to hang

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

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

  Priority: medium
Bug ID: 67946
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Switching to Integrated card to vgaswitcheroo with
radeon.audio=1 makes kernel to hang
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: mail at 3v1n0.net
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

I've a Mobility Radeon HD 5650 muxed with an intel card. If I boot with
radeon.audio=1 and I switch the radeon card off when pulseaudio is running,
then the kernel hangs as soon as I close X:

[ 489.177732] hda-intel :01:00.1: Disabling via VGA-switcheroo
[ 489.297129] hda-intel :01:00.1: Cannot lock devices!
[ 489.297139] radeon: switched off
[ 489.300356] [drm] Disabling audio support
[ 489.319552] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x0015e418 and cpu addr 0xc90009df0418
[ 489.973886] ACPI: \_SB_.PCI0: ACPI_NOTIFY_BUS_CHECK event: unsupported
[ 489.973903] _handle_hotplug_event_root: Bus check notify on \_SB_.PCI0
[ 678.992375] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 678.992453] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28
[ 683.996303] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 683.996377] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28
[ 683.996453] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
C3DC (len 871, WS 0, PS 0) @ 0xC439
[ 689.000275] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 689.000349] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28
[ 694.004285] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 694.004363] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28
[ 699.008330] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 699.008414] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28
[ 699.514458] init: tty1 main process (2460) killed by QUIT signal
[ 699.514489] init: tty1 main process ended, respawning
[ 704.012405] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 704.012492] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28
[ 709.016515] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 709.016596] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
CD0C (len 62, WS 0, PS 0) @ 0xCD28

These errors doesn't happen instead if I close X and kill pulseaudio before
switching cards.

Not sure if this is a pulseaudio issue or a kernel one (that should notify
pulseaudio about the unplugged HDMI audio card).

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

[Bug 67946] Switching to Integrated card to vgaswitcheroo with radeon.audio=1 makes kernel to hang

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

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

Marco Trevisan (Trevi?o)  changed:

   What|Removed |Added

URL||https://bugs.launchpad.net/
   ||ubuntu/+source/pulseaudio/+
   ||bug/1210470

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

[Bug 67276] kernel-3.11 [drm:r600_uvd_ring_test] *ERROR* radeon: ring 5 test failed (0xCAFEDEAD)

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

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

--- Comment #25 from Joshua Cov.  ---
Ping on this.

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

[Bug 67927] R600_DEBUG=sb: Celestia show 2 earths, one wrongly rendered

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

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

--- Comment #1 from Vadim Girlin  ---
So far I can't reproduce this issue. Please test with the latest mesa from git
if you are using older version. If llvm backend is active in your
configuration, you might want to update llvm as well or test the application
with R600_DEBUG=sb,nollvm.

Also please attach the output with R600_DEBUG=sb,ps,vs

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

[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor

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

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

Damian Nowak  changed:

   What|Removed |Added

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

--- Comment #3 from Damian Nowak  ---
My 7870 burned a month ago. Now I have a new one so I can continue
investigating.

In the meantime there was a kernel update - I now have 3.10.5-1-ARCH instead of
3.9.6-1-ARCH. There were some updates along the way as well, marked as
[updated]. I currently have:

linux 3.10.5-1 [updated]
mesa 9.1.6-1 [updated]
libdrm 2.4.46-2 [updated]
ati-dri 9.1.6-1 [updated]
llvm-amdgpu-lib-snapshot 20130403-3 [the same]
xf86-video-ati-glamor-git 1:20120730-1 [the same]


> I am able to reproduce the bug using Linphone (it doesn't mean it hangs just 
> in 
> Linphone). I call my mobile. Screen goes blank right after connection is 
> established (connection = when you hear beeping and you wait for the guy to 
> answer the phone). Therefore, I can test if the changes you provide resolve 
> the 
> issue.

Fortunately, it works now. No hangs in Linphone after connection is
established.

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

[PATCHv2 1/5] drm/exynos: add device tree support for rotator

[Tomasz Figa]

Hi Chanho,

On Friday 09 of August 2013 16:40:49 Chanho Park wrote:
> The exynos4 platform is only dt-based since 3.10, we should convert
> driver data and ids to dt-based parsing methods. The rotator driver has
> a limit table to get size limit of input picture. Each SoCs has slightly
> different limit value compared with any others.
> For example, exynos4210's max_size of RGB888 is 16k x 16k. But, others
> have 8k x 8k. Another example the exynos5250 should have multiple of 2
> pixel size for its X/Y axis. Thus, we should keep different tables for
> each of them.
> 
> Signed-off-by: Chanho Park 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |  109
> --- 1 file changed, 81 insertions(+), 28
> deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c index 427640a..39b09e0
> 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -632,6 +632,73 @@ static int rotator_ippdrv_start(struct device *dev,
> enum drm_exynos_ipp_cmd cmd) return 0;
>  }
> 
> +static struct rot_limit_table rot_limit_tbl_4210 = {
> + .ycbcr420_2p = {
> + .min_w = 32,
> + .min_h = 32,
> + .max_w = SZ_64K,
> + .max_h = SZ_64K,
> + .align = 3,
> + },
> + .rgb888 = {
> + .min_w = 8,
> + .min_h = 8,
> + .max_w = SZ_16K,
> + .max_h = SZ_16K,
> + .align = 2,
> + },
> +};
> +
> +static struct rot_limit_table rot_limit_tbl_4x12 = {
> + .ycbcr420_2p = {
> + .min_w = 32,
> + .min_h = 32,
> + .max_w = SZ_32K,
> + .max_h = SZ_32K,
> + .align = 3,
> + },
> + .rgb888 = {
> + .min_w = 8,
> + .min_h = 8,
> + .max_w = SZ_8K,
> + .max_h = SZ_8K,
> + .align = 2,
> + },
> +};
> +
> +static struct rot_limit_table rot_limit_tbl_5250 = {
> + .ycbcr420_2p = {
> + .min_w = 32,
> + .min_h = 32,
> + .max_w = SZ_32K,
> + .max_h = SZ_32K,
> + .align = 3,
> + },
> + .rgb888 = {
> + .min_w = 8,
> + .min_h = 8,
> + .max_w = SZ_8K,
> + .max_h = SZ_8K,
> + .align = 1,
> + },
> +};
> +
> +static const struct of_device_id exynos_rotator_match[] = {
> + {
> + .compatible = "samsung,exynos4210-rotator",
> + .data = &rot_limit_tbl_4210,
> + },
> + {
> + .compatible = "samsung,exynos4212-rotator",
> + .data = &rot_limit_tbl_4x12,
> + },
> + {
> + .compatible = "samsung,exynos5250-rotator",
> + .data = &rot_limit_tbl_5250,
> + },
> + {},
> +};
> +
>  static int rotator_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
> @@ -645,8 +712,19 @@ static int rotator_probe(struct platform_device
> *pdev) return -ENOMEM;
>   }
> 
> - rot->limit_tbl = (struct rot_limit_table *)
> - platform_get_device_id(pdev)->driver_data;
> + if (dev->of_node) {
> + const struct of_device_id *match;
> + match = of_match_node(of_match_ptr(exynos_rotator_match),
> + dev->of_node);
> + if (match == NULL) {
> + dev_err(dev, "failed to match node\n");
> + return -ENODEV;
> + }
> + rot->limit_tbl = (struct rot_limit_table *)match->data;
> + } else {
> + dev_err(dev, "cannot find binding\n");

What about having a check for !dev->of_node at the beginning of probe, to 
not complicate further code?

Also the error message is confusing. It should be something closer to 
"device does not have of_node".

> + return -ENODEV;
> + }
> 
>   rot->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   rot->regs = devm_ioremap_resource(dev, rot->regs_res);
> @@ -718,31 +796,6 @@ static int rotator_remove(struct platform_device
> *pdev) return 0;
>  }
> 
> -static struct rot_limit_table rot_limit_tbl = {
> - .ycbcr420_2p = {
> - .min_w = 32,
> - .min_h = 32,
> - .max_w = SZ_32K,
> - .max_h = SZ_32K,
> - .align = 3,
> - },
> - .rgb888 = {
> - .min_w = 8,
> - .min_h = 8,
> - .max_w = SZ_8K,
> - .max_h = SZ_8K,
> - .align = 2,
> - },
> -};
> -
> -static struct platform_device_id rotator_driver_ids[] = {
> - {
> - .name   = "exynos-rot",
> - .driver_data= (unsigned long)&rot_limit_tbl,
> - },
> - {},
> -};
> -
>  static int rotator_clk_crtl(struct rot_context *rot, bool enable)
>  {
>   if (enable) {
> @@ -

[PATCHv2 2/5] ARM: dts: Add rotator node for exynos4210

[Tomasz Figa]

On Friday 09 of August 2013 16:40:50 Chanho Park wrote:
> This patch adds a rotator node for exynos4210. The exynos4210 has
> different limitation of image size compared with later chips.
> 
> Signed-off-by: Chanho Park 
> Cc: Thomas Abraham 
> Cc: Kukjin Kim 
> Cc: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  arch/arm/boot/dts/exynos4.dtsi |9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4.dtsi
> b/arch/arm/boot/dts/exynos4.dtsi index 597cfcf..002b2b8 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -243,6 +243,15 @@
>   status = "disabled";
>   };
> 
> + rotator: rotator at 1281 {
> + compatible = "samsung,exynos4210-rotator";
> + reg = <0x1281 0x1000>;
> + interrupts = <0 83 0>;
> + clocks = <&clock 278>;
> + clock-names = "rotator";
> + status = "disabled";

Does the rotator need any board-specific information to work? If no, it 
should not be disabled by default. Same comment goes to patch 4/5.

Best regards,
Tomasz

[PATCHv2 5/5] ARM: dts: Add dt binding documentation for exynos rotator

[Tomasz Figa]

Hi Chanho,

On Friday 09 of August 2013 16:40:53 Chanho Park wrote:
> This patch describes each nodes of rotator and specifies a example how to
> bind it.
> 
> Signed-off-by: Chanho Park 
> Cc: Thomas Abraham 
> Cc: Kukjin Kim 
> Cc: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  .../devicetree/bindings/gpu/samsung-rotator.txt|   26
>  1 file changed, 26 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt new file
> mode 100644
> index 000..31ee7b5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> @@ -0,0 +1,26 @@
> +* Samsung Image Rotator
> +
> +Required properties:
> +  - compatible : value should be following:
> + (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210
> + (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412
> + (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250
> +
> +  - reg : Physical base address of the IP registers and length of memory
> +   mapped region.
> +
> +  - interrupts : Interrupt number of Rotator

What about: interrupt specifier for rotator interrupt, according to format 
specific to interrupt parent.

> +
> +  - clocks : Clock number described in
> Documentations/devicetree/binding/clock. +

Perhaps: clock specifier for rotator clock, according to generic clock 
bindings.

> +  - clock-names : Clock name.

Names of clocks specified in "clocks" property. For exynos rotator this 
property should contain only one name: "rotator".

> +Example:
> + rotator: rotator at 1280 {

I wonder if we shouldn't use a more generic name here, according to ePAPR 
node naming recommendation.

> + compatible = "samsung,exynos4210-rotator";
> + reg = <0x1281 0x1000>;

Typo. Node has 1280 in unit-address suffix, but this property has 
1281 instead.

> + interrupts = <0 83 0>;
> + clocks = <&clock 278>;
> + clock-names = "rotator";
> + status = "disabled";

Status property should be omitted from this example, as it's not a part of 
this binding.

Best regards,
Tomasz

[PATCH] drm: Add drm_bridge

[Sean Paul]

On Thu, Aug 8, 2013 at 8:36 PM, Daniel Vetter  wrote:
> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul  wrote:
>> This patch adds the notion of a drm_bridge. A bridge is a chained
>> device which hangs off an encoder. The drm driver using the bridge
>> should provide the association between encoder and bridge. Once a
>> bridge is associated with an encoder, it will participate in mode
>> set, dpms, and optionally connection detection.
>>
>> Since a connector may not be able to determine the connection state
>> downstream of the bridge, bridges may implement detect() which will take
>> precedence over connector detect() if the bridge is already attached
>> to an encoder and that encoder is already attached to the connector.
>> In practical terms, this requires the drm driver to make these
>> associations at init time, which is fine for SoC applications where
>> this link is static.
>>
>> Signed-off-by: Sean Paul 
>
> A few comments below. I think overall any such infrastructure simply
> needs to demonstrate viability on a few drivers, that makes it much
> simpler to check whether the interfaces make sense.

Thanks for your feedback, Daniel.

As mentioned by Stephane and Rob, there are a few drivers already
using this. In the ChromeOS tree, we have 2 simple DP->LVDS bridges
which quite frankly aren't terribly interesting atm, and we'll be
converting an HDMI->myDP bridge in a couple of weeks (time permitting,
of course).


> Generally I'd make
> more sense for me if the bridge is just an implementation detail of a
> given encoder and if the bridge would not be exposed to the crtc
> helpers.

After we discussed this on IRC, I converted our exynos driver to do
this. You can check out the patch here
(https://gerrit.chromium.org/gerrit/#/c/64680).

It felt like a lot of boilerplate code that would be duplicated in
every drm driver. Given the number of hooks we have, it's a pretty
fine granularity such that there aren't *that* many creative ways to
order things (famous last words). If a driver finds the need to differ
from the helper order, they probably aren't going to be using the
helper anyways.


> With that abstraction chaining would be more natural imo and
> we'd also have a much higher chance that bridge drivers work accross
> different drm drivers: Atm you can run some encoder stuff in the crtc
> callbacks and the other way round (and pretty much every driver for a
> bit more complicated hw does that), and every driver can differ in
> those tricks a bit. If we bake the bridge callbacks into the crtc
> helpers I expect that for bridges with tricky ordering constraints
> this will become a giant mess. So I'd prefer much if this would work
> like drm i2c slave encoders.
>

In the three bridge chips I've dealt with, they all try their best to
be transparent to the encoder. They all fail at this. However their
quirks are usually not dependent on the encoder implementation, but
rather the general order of operations (ie: when to assert hotplug,
video signal on, etc.).

Furthermore, drm_bridge will allow us to use bridges across drm
drivers. For example, the HDMI->myDP driver I mentioned earlier is
used on a number of platforms, not just exynos. It would be a waste to
bind it to exynos when a more general implementation can be achieved.



> Cheers, Daniel
>
>> ---
>>  drivers/gpu/drm/drm_crtc.c|  50 +
>>  drivers/gpu/drm/drm_crtc_helper.c | 112 
>> ++
>>  drivers/gpu/drm/drm_sysfs.c   |   8 ++-
>>  include/drm/drm_crtc.h|  48 
>>  include/drm/drm_crtc_helper.h |  34 
>>  5 files changed, 241 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index fc83bb9..0311e2b 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -781,6 +781,41 @@ void drm_connector_unplug_all(struct drm_device *dev)
>>  }
>>  EXPORT_SYMBOL(drm_connector_unplug_all);
>>
>> +int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
>> +   const struct drm_bridge_funcs *funcs)
>> +{
>> +   int ret;
>> +
>> +   drm_modeset_lock_all(dev);
>> +
>> +   ret = drm_mode_object_get(dev, &bridge->base, 
>> DRM_MODE_OBJECT_BRIDGE);
>> +   if (ret)
>> +   goto out;
>> +
>> +   bridge->dev = dev;
>> +   bridge->funcs = funcs;
>> +
>> +   list_add_tail(&bridge->head, &dev->mode_config.bridge_list);
>> +   dev->mode_config.num_bridge++;
>> +
>> + out:
>> +   drm_modeset_unlock_all(dev);
>> +   return ret;
>> +}
>> +EXPORT_SYMBOL(drm_bridge_init);
>> +
>> +void drm_bridge_cleanup(struct drm_bridge *bridge)
>> +{
>> +   struct drm_device *dev = bridge->dev;
>> +
>> +   drm_modeset_lock_all(dev);
>> +   drm_mode_object_put(dev, &bridge->base);
>> +   list_del(&bridge->head);
>> +   dev->mode_config.num_bridge--;
>> +   drm_modeset_unlock_all(dev);
>> +}
>> +EXPORT_SYMBOL(

[Bug 67276] kernel-3.11 [drm:r600_uvd_ring_test] *ERROR* radeon: ring 5 test failed (0xCAFEDEAD)

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

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

--- Comment #26 from Alex Deucher  ---
Is this still an issue with Dave's latest drm-fixes branch:
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes

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

[GIT PULL] gma500-next

[Patrik Jakobsson]

Hi Dave

Here's some gma500 unifying and cleanups for drm-next. There is more stuff in
the pipe for 3.12 but I'd like to get these out of the way first.

Thanks
Patrik

The following changes since commit 85d9cb41db3bf0f36c999c2e547b37cb9f32367b:

  drm: remove drm_order (2013-07-23 20:14:29 +1000)

are available in the git repository at:

  git://github.com/patjak/drm-gma500 gma500-next

for you to fetch changes up to 367e44080e20f77fa7b0f2db83fd6367da59b6c3:

  drm/gma500: Rename psb_intel_encoder to gma_encoder (2013-07-24
01:49:43 +0200)


Patrik Jakobsson (33):
  drm/gma500: Add generic code for clock calculation
  drm/gma500/cdv: Make use of the generic clock code
  drm/gma500: Make use of gma_pipe_has_type()
  drm/gma500/psb: Make use of generic clock code
  drm/gma500: Remove the unused psb_intel_display.h
  drm/gma500: Add generic pipe/crtc functions
  drm/gma500/cdv: Use identical generic crtc funcs
  drm/gma500: Make all chips use gma_wait_for_vblank
  drm/gma500/psb: Use identical generic crtc funcs
  drm/gma500/cdv: Convert to gma_pipe_set_base()
  drm/gma500: Add IS_CDV() macro
  drm/gma500/cdv: Convert to gma_crtc_dpms()
  drm/gma500/cdv: Convert to generic gamma funcs
  drm/gma500/psb: Convert to gma_pipe_set_base()
  drm/gma500: Convert to generic gamma funcs
  drm/gma500/psb: Convert to gma_crtc_dpms()
  drm/gma500/oak: Use identical generic crtc funcs
  drm/gma500/mdfld: Use identical generic crtc funcs
  drm/gma500/psb: Convert to generic crtc->destroy
  drm/gma500: Add generic cursor functions
  drm/gma500/cdv: Convert to generic cursor funcs
  drm/gma500/psb: Convert to generic cursor funcs
  drm/gma500: Add generic encoder functions
  drm/gma500: Convert to generic encoder funcs
  drm/gma500: Add generic crtc save/restore funcs
  drm/gma500/psb: Convert to generic save/restore
  drm/gma500/cdv: Convert to generic save/restore
  drm/gma500: Add generic set_config() function
  drm/gma500/psb: Convert to generic set_config()
  drm/gma500/cdv: Convert to generic set_config()
  drm/gma500: Rename psb_intel_crtc to gma_crtc
  drm/gma500: Rename psb_intel_connector to gma_connector
  drm/gma500: Rename psb_intel_encoder to gma_encoder

 drivers/gpu/drm/gma500/Makefile|   1 +
 drivers/gpu/drm/gma500/cdv_device.c|   1 +
 drivers/gpu/drm/gma500/cdv_device.h|  10 +-
 drivers/gpu/drm/gma500/cdv_intel_crt.c |  57 +-
 drivers/gpu/drm/gma500/cdv_intel_display.c | 916 ++--
 drivers/gpu/drm/gma500/cdv_intel_dp.c  | 154 ++--
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c|  89 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c|  71 +-
 drivers/gpu/drm/gma500/framebuffer.c   |  25 +-
 drivers/gpu/drm/gma500/framebuffer.h   |   2 +-
 drivers/gpu/drm/gma500/gma_display.c   | 776 +
 drivers/gpu/drm/gma500/gma_display.h   | 108 +++
 drivers/gpu/drm/gma500/mdfld_dsi_output.c  |  15 +-
 drivers/gpu/drm/gma500/mdfld_dsi_output.h  |  16 +-
 drivers/gpu/drm/gma500/mdfld_intel_display.c   |  65 +-
 drivers/gpu/drm/gma500/oaktrail_crtc.c |  63 +-
 drivers/gpu/drm/gma500/oaktrail_hdmi.c |  43 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c |  48 +-
 drivers/gpu/drm/gma500/psb_device.c|   3 +-
 .../gma500/{psb_intel_display.h => psb_device.h}   |  13 +-
 drivers/gpu/drm/gma500/psb_drv.c   |  14 +-
 drivers/gpu/drm/gma500/psb_drv.h   |   3 +
 drivers/gpu/drm/gma500/psb_intel_display.c | 944 ++---
 drivers/gpu/drm/gma500/psb_intel_drv.h |  44 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c|  75 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c|  53 +-
 26 files changed, 1443 insertions(+), 2166 deletions(-)
 create mode 100644 drivers/gpu/drm/gma500/gma_display.c
 create mode 100644 drivers/gpu/drm/gma500/gma_display.h
 rename drivers/gpu/drm/gma500/{psb_intel_display.h => psb_device.h} (76%)

[RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

[Tom Cooksey]

Hi Daniel, Rob.

Thank you both for your reviews - greatly appreciated!

> > > Known issues:
> > >  * It still includes code to use KDS, which is not going upstream.
> >
> > review's on  > July/042462.html> can't hurt
> >
> > although you might consider submitting a reduced functionality driver
> > w/ KDS bits removed in the mean time.. then when the fence stuff is
> > merged it is just an incremental patch rather than a whole driver ;-)
> 
> Yeah, I think the KDS bits and comments need to go first before
> merginge.

Right, as I expected really. Though as I said we'll probably wait for
fences to land and switch over to that before asking for it to be
merged. A pl111 KMS driver with neither KDS nor implicit fences is 
useless to us. Having said that, if someone else would have a use for
a fence/KDS-less pl111 KMS driver, please let me know!



> > > +/*
> > > + * Number of flips allowed in flight at any one time. Any more
> > > + * flips requested beyond this value will cause the caller to 
> > > + * block until earlier flips have completed.
> > > + *
> > > + * For performance reasons, this must be greater than the number
> > > + * of buffers used in the rendering pipeline. Note that the 
> > > + * rendering pipeline can contain different types of buffer, e.g.:
> > > + * - 2 final framebuffers
> > > + * - >2 geometry buffers for GPU use-cases
> > > + * - >2 vertex buffers for GPU use-cases
> > > + *
> > > + * For example, a system using 5 geometry buffers could have 5
> > > + * flips in flight, and so NR_FLIPS_IN_FLIGHT_THRESHOLD must be 
> > > + * 5 or greater.
> > > + *
> > > + * Whilst there may be more intermediate buffers (such as
> > > + * vertex/geometry) than final framebuffers, KDS is used to 
> > > + * ensure that GPU rendering waits for the next off-screen 
> > > + * buffer, so it doesn't overwrite an on-screen buffer and 
> > > + * produce tearing.
> > > + */
> > > +
> >
> > fwiw, this is at least different from how other drivers do triple
> > (or > double) buffering.  In other drivers (intel, omap, and
> > msm/freedreno, that I know of, maybe others too) the xorg driver
> > dri2 bits implement the double buffering (ie. send flip event back
> > to client immediately and queue up the flip and call page-flip
> > after the pageflip event back from kernel.
> >
> > I'm not saying not to do it this way, I guess I'd like to hear
> > what other folks think.  I kinda prefer doing this in userspace 
> > as it keeps the kernel bits simpler (plus it would then work 
> > properly on exynosdrm or other kms drivers).
> 
> Yeah, if this is just a sw queue then I don't think it makes sense
> to have it in the kernel. Afaik the current pageflip interface drm
> exposes allows one oustanding flip only, and you _must_ wait for
> the flip complete event before you can submit the second one.

Right, I'll have a think about this. I think our idea was to issue
enough page-flips into the kernel to make sure that any process
scheduling latencies on a heavily loaded system don't cause us to
miss a v_sync deadline. At the moment we issue the page flip from DRI2
schedule_swap. If we were to move that to the page flip event handler
of the previous page-flip, we're potentially adding in extra latency.

I.e. Currently we have:

DRI2SwapBuffers
 - drm_mode_page_flip to buffer B
DRI2SwapBuffers
 - drm_mode_page_flip to buffer A (gets queued in kernel)
...
v_sync! (at this point buffer B is scanned out)
 - release buffer A's KDS resource/signal buffer A's fence
- queued GPU job to render next frame to buffer A scheduled on HW
...
GPU interrupt! (at this point buffer A is ready to be scanned out)
 - release buffer A's KDS resource/signal buffer A's fence
- second page flip executed, buffer A's address written to scanout
  register, takes effect on next v_sync.


So in the above, after X receives the second DRI2SwapBuffers, it
doesn't need to get scheduled again for the next frame to be both
rendered by the GPU and issued to the display for scanout.


If we were to move to a user-space queue, I think we have something
like this:

DRI2SwapBuffers
 - drm_mode_page_flip to buffer B
DRI2SwapBuffers
 - queue page flip to buffer A in DDX
...
v_sync! (at this point buffer B is scanned out)
 - release buffer A's KDS resource/signal buffer A's fence
- queued GPU job to render next frame to buffer A scheduled on HW
 - Send page flip event to X
...
GPU interrupt! (at this point buffer A is ready to be scanned out)
 - Release buffer A's KDS resource/signal buffer A's fence - but nothing
   is waiting on it
...
X gets scheduled, runs page flip handler
 - drm_mode_page_flip to buffer A
   - buffer A's address written to scanout register, takes effect on
 next v_sync.


So here, X must get scheduled again after processing the second
DRI2SwapBuffers in order to have the next frame displayed. This
increases the likely-hood that we're not able to write the address of
buf

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

[Tom Cooksey]

> > Turning to DRM/KMS, it seems the supported formats of a plane can be
> > queried using drm_mode_get_plane. However, there doesn't seem to be a
> > way to query the supported formats of a crtc? If display HW only
> > supports scanning out from a single buffer (like pl111 does), I think
> > it won't have any planes and a fb can only be set on the crtc. In
> > which case, how should user-space query which pixel formats that crtc
> > supports?
> 
> it is exposed for drm plane's.  What is missing is to expose the
> primary-plane associated with the crtc.

Cool - so a patch which adds a way to query the what formats a crtc
supports would be welcome?

What about a way to query the stride alignment constraints?

Presumably using the drm_mode_get_property mechanism would be the
right way to implement that?


> > As with v4l2, DRM doesn't appear to have a way to query the stride
> > constraints? Assuming there is a way to query the stride constraints,
> > there also isn't a way to specify them when creating a buffer with
> > DRM, though perhaps the existing pitch parameter of
> > drm_mode_create_dumb could be used to allow user-space to pass in a
> > minimum stride as well as receive the allocated stride?
> >
> 
> well, you really shouldn't be using create_dumb..  you should have a
> userspace piece that is specific to the drm driver, and knows how to
> use that driver's gem allocate ioctl.

Sorry, why does this need a driver-specific allocation function? It's
just a display controller driver and I just want to allocate a scan-
out buffer - all I'm asking is for the display controller driver to
use a minimum stride alignment so I can export the buffer and use
another device to fill it with data.

The whole point is to be able to allocate the buffer in such a way
that another device can access it. So the driver _can't_ use a
special, device specific format, nor can it allocate it from a
private memory pool because doing so would preclude it from being
shared with another device.

That other device doesn't need to be a GPU wither, it could just as
easily be a camera/ISP or video decoder.



> >> > So presumably you're talking about a GPU driver being the exporter
> >> > here? If so, how could the GPU driver do these kind of tricks on
> >> > memory shared with another device?
> >>
> >> Yes, that is gpu-as-exporter.  If someone else is allocating
> >> buffers, it is up to them to do these tricks or not.  Probably 
> >> there is a pretty good chance that if you aren't a GPU you don't 
> >> need those sort of tricks for fast allocation of transient upload 
> >> buffers, staging textures, temporary pixmaps, etc.  Ie. I don't 
> >> really think a v4l camera or video decoder would benefit from that 
> >> sort of optimization.
> >
> > Right - but none of those are really buffers you'd want to export
> 
> > with dma_buf to share with another device are they? In which case, 
> > why not just have dma_buf figure out the constraints and allocate 
> > the memory?
>
> maybe not.. but (a) you don't necessarily know at creation time if it
> is going to be exported (maybe you know if it is definitely not going
> to be exported, but the converse is not true),

I can't actually think of an example where you would not know if a
buffer was going to be exported or not at allocation time? Do you have
a case in mind?

Regardless, you'd certainly have to know if a buffer will be exported
pretty quickly, before it's used so that you can import it into
whatever devices are going to access it. Otherwise if it gets
allocated before you export it, the allocation won't satisfy the
constraints of the other devices which will need to access it and
importing will fail. Assuming of course deferred allocation of the
backing pages as discussed earlier in the thread.



> and (b) there isn't
> really any reason to special case the allocation in the driver because
> it is going to be exported.

Not sure I follow you here? Surely you absolutely have to special-case
the allocation if the buffer is to be exported because you have to
take the other devices' constraints into account when you allocate? Or
do you mean you don't need to special-case the GEM buffer object
creation, only the allocation of the backing pages? Though I'm not
sure how that distinction is useful - at the end of the day, you need
to special-case allocation of the backing pages.


> helpers that can be used by simple drivers, yes.  Forcing the way the
> buffer is allocated, for sure not.  Currently, for example, there is
> no issue to export a buffer allocated from stolen-mem.

Where stolen-mem is the PC-world's version of a carveout? I.e. A chunk
of memory reserved at boot for the GPU which the OS can't touch? I
guess I view such memory as accessible to all media devices on the 
system and as such, needs to be managed by a central allocator which
dma_buf can use to allocate from.

I guess if that stolen-mem is managed by a single device then in
essence that device becomes the central

[PATCH] drm: Add drm_bridge

[Alex Deucher]

On Fri, Aug 9, 2013 at 9:19 AM, Sean Paul  wrote:
> On Thu, Aug 8, 2013 at 8:36 PM, Daniel Vetter  wrote:
>> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul  wrote:
>>> This patch adds the notion of a drm_bridge. A bridge is a chained
>>> device which hangs off an encoder. The drm driver using the bridge
>>> should provide the association between encoder and bridge. Once a
>>> bridge is associated with an encoder, it will participate in mode
>>> set, dpms, and optionally connection detection.
>>>
>>> Since a connector may not be able to determine the connection state
>>> downstream of the bridge, bridges may implement detect() which will take
>>> precedence over connector detect() if the bridge is already attached
>>> to an encoder and that encoder is already attached to the connector.
>>> In practical terms, this requires the drm driver to make these
>>> associations at init time, which is fine for SoC applications where
>>> this link is static.
>>>
>>> Signed-off-by: Sean Paul 
>>
>> A few comments below. I think overall any such infrastructure simply
>> needs to demonstrate viability on a few drivers, that makes it much
>> simpler to check whether the interfaces make sense.
>
> Thanks for your feedback, Daniel.
>
> As mentioned by Stephane and Rob, there are a few drivers already
> using this. In the ChromeOS tree, we have 2 simple DP->LVDS bridges
> which quite frankly aren't terribly interesting atm, and we'll be
> converting an HDMI->myDP bridge in a couple of weeks (time permitting,
> of course).

radeon also uses DP->LVDS and DP->VGA bridges on a number of systems.
It currently uses a driver specific hack, but it could probably be
converted to use the bridge infrastructure.

Alex