[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

[Russell King - ARM Linux]

On Wed, Jun 17, 2015 at 04:14:07PM -0700, Doug Anderson wrote:
> If you plug in a DVI monitor to your HDMI port, you need to filter out
> clocks > 165MHz.  That's because 165MHz is the maximum clock rate that
> we can run single-link DVI at.
> 
> If you want to run high resolutions to DVI, you'd need some type of an
> active adapter that pretended that it was HDMI, interpreted the
> signal, and produced a new dual link DVI signal at a lower clock rate.
> 
> Signed-off-by: Doug Anderson 
> ---
> Note: this patch was tested against a 3.14 kernel with backports.  It
> was only compile tested against linuxnext, but the code is
> sufficiently similar that I'm convinced it will work there.

Really?  I have to wonder what your testing was...

hdmi->vic = drm_match_cea_mode(mode);

if (!hdmi->vic) {
dev_dbg(hdmi->dev, "Non-CEA mode used in HDMI\n");
hdmi->hdmi_data.video_mode.mdvi = true;
} else {
dev_dbg(hdmi->dev, "CEA mode used vic=%d\n", hdmi->vic);
hdmi->hdmi_data.video_mode.mdvi = false;
}

mdvi indicates whether the _currently set mode_ is a CEA mode or not (imho,
it's mis-named).  It doesn't indicate whether we have a HDMI display device
or a DVI display device connected, which seems to be what you want to use
it for below.

To sort that, what you need to do is detect a HDMI display device using
drm_detect_hdmi_monitor() on the EDID received from the device before
parsing the modes, and save that value in a dw_hdmi struct member, and
I'd suggest that it's a top-level struct member, not buried in 'hdmi_data'
or 'video_mode'.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] drm/radeon: don't probe MST on hw we don't support it on

[Dave Airlie]

From: Dave Airlie 

If you do radeon.mst=1 on a gpu without mst hw, and then
plug some mst hw it will oops instead of falling back.

So check we have DCE5 at least before proceeding.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/radeon_dp_mst.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c 
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index 2b98ed3..257b10be 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -663,12 +663,17 @@ int
 radeon_dp_mst_probe(struct radeon_connector *radeon_connector)
 {
struct radeon_connector_atom_dig *dig_connector = 
radeon_connector->con_priv;
+   struct drm_device *dev = radeon_connector->base.dev;
+   struct radeon_device *rdev = dev->dev_private;
int ret;
u8 msg[1];

if (!radeon_mst)
return 0;

+   if (!ASIC_IS_DCE5(rdev))
+   return 0;
+
if (dig_connector->dpcd[DP_DPCD_REV] < 0x12)
return 0;

-- 
2.4.2

[PATCH v10 00/17] drm/exynos: atomic modesetting support

[Inki Dae]

On 2015년 06월 17일 23:33, Gustavo Padovan wrote:
> Hi Inki,
> 
> 2015-06-17 Inki Dae :
> 
>> Hi Gustavo,
>>
>> On 2015년 06월 17일 05:35, Gustavo Padovan wrote:
>>> HI Inki,
>>>
>>> 2015-06-15 Inki Dae :
>>>
 Hi Gustavo,

 On 2015년 06월 02일 00:04, Gustavo Padovan wrote:
> From: Gustavo Padovan 
>
> Hi,
>
> Here goes the full support for atomic modesetting on exynos. I've
> split the patches in the various phases of atomic support.
>
> v2: fixes comments by Joonyoung
> - remove unused var in patch 09
> - use ->disable instead of outdated ->dpms in hdmi code
> - remove WARN_ON from crtc enable/disable
>
> v3: fixes comment by Joonyoung
> - move the removal of drm_helper_disable_unused_functions() to
> separated patch
>
> v4: add patches that remove unnecessary calls to disable_plane()
>
> v5: fixes NULL CRTC crash on planes updates (reported by Inki and Tobias)
>
> v6: rebase on latest exynos_drm_next
>
> v7: fix comments by Joonyoung
> - fix two checkpatch errors
> - remove extra crtc->commit() call
> - check for null fb on exynos_check_plane()
>
> v8: fix comments by Joonyoung
> - fix merge error
> - move drm_crtc_vblank_get to the commit that introduces atomic 
> pageflip
> - remove .prepare() in the apropiated patch
> - add a new patch to move exynos_drm_crtc_disable()
>
> v9:  * fix comments by Joonyoung
> - also remove encoder .prepare()
> - do not shift exynos_update_plane() parameters
> - remove unused .mode_set() and .mode_set_base()
>  * add specific exynos .atomic_commit()
>  * add split of exynos_crtc->ops->dpms() into enable() and disable()
>  * add other atomic clean ups
>
> v10: * fix comments by Joonyoung
>   - add more comments on exynos_atomic_commit()
>   - make exynos_crtc's .enable and .disable void

 I found out one issue that refresh rate gets low with display extension
 mode test.

 I tested it with two crtc drivers - vidi and fimd on Trats2 board. Here
 is how to test it,

 #echo 1 > /sys/devices/platform/exynos-drm-vidi/connection
 # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480
 setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29
 setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21
 freq: 20.00Hz
 freq: 20.00Hz

 As you can see, refresh rate is 20.

 Below is the result without atomic patch series,
 # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480
 setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29
 setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21
 freq: 60.18Hz
 freq: 49.09Hz

 I can see 60Hz for FIMD and 49Hz for vidi.
>>>
>>> I gave this a try and figured out that this might be a vidi specific
>>> problem. If I try VIDI and FIMD I get the same results as you but with
>>> Mixer and FIMD(the setup I actually use to test) everything works fine.
>>
>> Hm... Did Mixer and FIMD combination really work correctly with
>> extension mode?
> 
> Yes.
> 
> collabora at singularity:~$ modetest -M exynos -s 31:1920x1080 -v -s
> 25:1366x768
> setting mode 1920x1080-60Hz at XR24 on connectors 31, crtc 29
> setting mode 1366x768-60Hz at XR24 on connectors 25, crtc 23
> freq: 55.82Hz
> freq: 55.38Hz
> freq: 55.30Hz
> freq: 55.38Hz
> freq: 55.30Hz
> freq: 55.38Hz
> freq: 55.30Hz
> freq: 55.38Hz
> freq: 55.30Hz
> freq: 55.38Hz
> 
>>
>>> So somehow my patches caused a regression on vidi that I'm still
>>> ivestigating.
>>
>> I think this issue is because page flip operations are performed in
>> atomic: if I see correctly, when page flip is requested by modetest, the
>> call flow is as follows,
>>
>> drm_atomic_helper_page_flip
>>  drm_atomic_async_commit
>>  exynos_atomic_commit
>>  ...
>>  drm_atomic_helper_wait_for_vblanks
>>  ...
>>
>> However, the function, drm_atomic_helper_wait_for_vblanks called by
>> exynos_atomic_commit, waits for the vblank completion of each crtc
>> driver . See wait_event_timeout function call in
>> drm_atomic_helper_wait_for_vblanks function.
>>
>> This means that a page flip request of a crtc driver cannot be performed
>> until the vblank completion of another crtc driver. I think you should
>> have implemented exynos_atomic_commit function asynchronously, not
>> synchronously like you did. So it seems that this function should be
>> re-implemented.
> 
> I have a patch for it already. I'll resend a v2 of my last series. 

Can you post it now?

Thanks,
Inki Dae

> 
>>
>> If my analysis is correct and you cannot post the change set within this
>> week, I'm not sure whether the atomic patch series should 

[PATCH] Fixes: 9697dffb098d ("drm: Turn off Legacy Context Functions")

[Daniel Vetter]

On Wed, Jun 17, 2015 at 02:03:47PM -0600, Eddie Kovsky wrote:
> Commit 9697dffb098d ("drm: Turn off Legacy Context Functions")
> added checks for legacy features to several functions in the 
> drm driver. It is now possible for the void functions changed by 
> this commit to return an int error code. This patch updates
> the function definitions to return int. This fixes the build warnings:
> 
> warning: ‘return’ with a value, in function returning void
>return -EINVAL
> 
> Signed-off-by: Eddie Kovsky 

Oops sorry, I spotted this while applying but somehow screwed up and still
pushed out the patch. Dropped it now for real.

Thanks, Daniel

> ---
>  drivers/gpu/drm/drm_context.c | 12 +---
>  drivers/gpu/drm/drm_legacy.h  |  6 +++---
>  2 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
> index f3ea657f6574..3c2f4a76f934 100644
> --- a/drivers/gpu/drm/drm_context.c
> +++ b/drivers/gpu/drm/drm_context.c
> @@ -51,7 +51,7 @@ struct drm_ctx_list {
>   * in drm_device::ctx_idr, while holding the drm_device::struct_mutex
>   * lock.
>   */
> -void drm_legacy_ctxbitmap_free(struct drm_device * dev, int ctx_handle)
> +int drm_legacy_ctxbitmap_free(struct drm_device * dev, int ctx_handle)
>  {
>   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
>   drm_core_check_feature(dev, DRIVER_MODESET))
> @@ -60,6 +60,8 @@ void drm_legacy_ctxbitmap_free(struct drm_device * dev, int 
> ctx_handle)
>   mutex_lock(&dev->struct_mutex);
>   idr_remove(&dev->ctx_idr, ctx_handle);
>   mutex_unlock(&dev->struct_mutex);
> +
> + return 0;
>  }
>  
>  /**
> @@ -107,7 +109,7 @@ int drm_legacy_ctxbitmap_init(struct drm_device * dev)
>   * Free all idr members using drm_ctx_sarea_free helper function
>   * while holding the drm_device::struct_mutex lock.
>   */
> -void drm_legacy_ctxbitmap_cleanup(struct drm_device * dev)
> +int drm_legacy_ctxbitmap_cleanup(struct drm_device * dev)
>  {
>   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
>   drm_core_check_feature(dev, DRIVER_MODESET))
> @@ -116,6 +118,8 @@ void drm_legacy_ctxbitmap_cleanup(struct drm_device * dev)
>   mutex_lock(&dev->struct_mutex);
>   idr_destroy(&dev->ctx_idr);
>   mutex_unlock(&dev->struct_mutex);
> +
> + return 0;
>  }
>  
>  /**
> @@ -127,7 +131,7 @@ void drm_legacy_ctxbitmap_cleanup(struct drm_device * dev)
>   * @file. Note that after this call returns, new contexts might be added if
>   * the file is still alive.
>   */
> -void drm_legacy_ctxbitmap_flush(struct drm_device *dev, struct drm_file 
> *file)
> +int drm_legacy_ctxbitmap_flush(struct drm_device *dev, struct drm_file *file)
>  {
>   struct drm_ctx_list *pos, *tmp;
>  
> @@ -150,6 +154,8 @@ void drm_legacy_ctxbitmap_flush(struct drm_device *dev, 
> struct drm_file *file)
>   }
>  
>   mutex_unlock(&dev->ctxlist_mutex);
> +
> + return 0;
>  }
>  
>  /*@}*/
> diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
> index c1dc61473db5..26c16220e475 100644
> --- a/drivers/gpu/drm/drm_legacy.h
> +++ b/drivers/gpu/drm/drm_legacy.h
> @@ -43,9 +43,9 @@ struct drm_file;
>  #define DRM_RESERVED_CONTEXTS1
>  
>  int drm_legacy_ctxbitmap_init(struct drm_device *dev);
> -void drm_legacy_ctxbitmap_cleanup(struct drm_device *dev);
> -void drm_legacy_ctxbitmap_free(struct drm_device *dev, int ctx_handle);
> -void drm_legacy_ctxbitmap_flush(struct drm_device *dev, struct drm_file 
> *file);
> +int drm_legacy_ctxbitmap_cleanup(struct drm_device *dev);
> +int drm_legacy_ctxbitmap_free(struct drm_device *dev, int ctx_handle);
> +int drm_legacy_ctxbitmap_flush(struct drm_device *dev, struct drm_file 
> *file);
>  
>  int drm_legacy_resctx(struct drm_device *d, void *v, struct drm_file *f);
>  int drm_legacy_addctx(struct drm_device *d, void *v, struct drm_file *f);
> -- 
> 2.4.3
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, final i915 fixes for v4.1.

BR,
Jani.


The following changes since commit 0f57d86787d8b1076ea8f9cba2a46d534a27:

  Linux 4.1-rc8 (2015-06-14 15:51:10 -1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-06-18

for you to fetch changes up to 245ec9d85696c3e539b23e210f248698b478379c:

  Revert "drm/i915: Don't skip request retirement if the active list is empty" 
(2015-06-15 14:32:54 +0300)


Chris Wilson (1):
  drm/i915: Always reset vma->ggtt_view.pages cache on unbinding

Jani Nikula (1):
  Revert "drm/i915: Don't skip request retirement if the active list is 
empty"

 drivers/gpu/drm/i915/i915_gem.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PULL] drm-intel-next-fixes

[Jani Nikula]

Hi Dave, i915 fixes for drm-next/v4.2.

BR,
Jani.


The following changes since commit bf546f8158e2df2656494a475e6235634121c87c:

  drm/i915/skl: Fix DMC API version in firmware file name (2015-06-05 12:08:01 
+0300)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2015-06-18

for you to fetch changes up to 4ed9fb371ccdfe465bd3bbb69e4cad5243e6c4e2:

  drm/i915: Don't set enabled value of all CRTCs when restoring the mode 
(2015-06-17 14:21:01 +0300)


Ander Conselvan de Oliveira (3):
  drm/i915: Don't check modeset state in the hw state force restore path
  drm/i915: Don't update staged config during force restore modesets
  drm/i915: Don't set enabled value of all CRTCs when restoring the mode

Francisco Jerez (3):
  drm/i915: Fix command parser to validate multiple register access with 
the same command.
  drm/i915: Extend the parser to check register writes against a mask/value 
pair.
  drm/i915: Add SCRATCH1 and ROW_CHICKEN3 to the register whitelist.

Ville Syrjälä (1):
  drm/i915: Don't skip request retirement if the active list is empty

 drivers/gpu/drm/i915/i915_cmd_parser.c  | 197 +---
 drivers/gpu/drm/i915/i915_drv.h |   5 +
 drivers/gpu/drm/i915/i915_gem.c |   3 -
 drivers/gpu/drm/i915/intel_display.c|  54 -
 drivers/gpu/drm/i915/intel_ringbuffer.h |   5 +-
 5 files changed, 164 insertions(+), 100 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

inverted brightness for HP notebook

[Jani Nikula]

On Wed, 17 Jun 2015, Max Manheimer  wrote:
> Hi,
>
> Jani Nikula  linux.intel.com> writes:
>
>> On Thu, 13 Nov 2014, olivier.fambon  free.fr wrote:
>
>>> $ lspci | grep VGA
>>> 00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 
>>> 0e)
>
>>> $ sudo lspci -v -s 00:02
>>> 00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev
> 0e) (prog-if 00 [VGA controller])
>>> Subsystem: Hewlett-Packard Company Device 2213
>>> Flags: bus master, fast devsel, latency 0, IRQ 107
>>> Memory at 9000 (32-bit, non-prefetchable) [size=4M]
>>> Memory at 8000 (32-bit, prefetchable) [size=256M]
>>> I/O ports at 3050 [size=8]
>>> Expansion ROM at  [disabled]
>>> Capabilities: [d0] Power Management version 2
>>> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>>> Capabilities: [b0] Vendor Specific Information: Len=07 
>>> Kernel driver in use: i915
>
>>> => requires the following to make brightness control keys work as expected
>
>>> $ cat /etc/modprobe.d/i915.conf 
>>> options i915 invert_brightness=1
>
> As there's a specific broadwell i915 module, you have to adapt as follows:
>
> options i915_bdw invert_brightness=1
>  
>> I highly doubt this. This might be true for some gen4 models, but not
>> Valleyview.
>
> The above mentioned i915_bdw option fixes the backlight inversion on my HP
> 250 G3 (same lspci output as in original post)

i915_bdw is an Ubuntu thing, upstream has nothing to do with it. But I'm
surprised they'd use i915_bdw for a Baytrail/Valleyview.

If you can reproduce with the upstream driver, please file a bug at [1].

BR,
Jani.


[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel


-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 91014] Piglit regression: spec/!OpenGL 1.2/texture-packed-formats

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

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

Kenneth Graunke  changed:

   What|Removed |Added

  Component|Mesa core   |Drivers/Gallium/i915g
   Assignee|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org
 QA Contact|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org

-- 
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/20150618/be3f9412/attachment.html>

[Bug 91015] Piglit regression: spec/ARB_occlusion_query2/api

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

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

Kenneth Graunke  changed:

   What|Removed |Added

  Component|Mesa core   |Drivers/Gallium/i915g
   Assignee|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org
 QA Contact|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org

-- 
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/20150618/74354d6b/attachment.html>

[Bug 91016] Piglit regression: shaders/glsl-floating-constant-120

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

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

Kenneth Graunke  changed:

   What|Removed |Added

  Component|Mesa core   |Drivers/Gallium/i915g
   Assignee|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org
 QA Contact|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org

-- 
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/20150618/39620184/attachment.html>

[PATCH] drm/radeon: don't probe MST on hw we don't support it on

[Christian König]

On 18.06.2015 06:29, Dave Airlie wrote:
> From: Dave Airlie 
>
> If you do radeon.mst=1 on a gpu without mst hw, and then
> plug some mst hw it will oops instead of falling back.
>
> So check we have DCE5 at least before proceeding.
>
> Signed-off-by: Dave Airlie 

Reviewed-by: Christian König 

BTW: Since Alex is on vacation I'm managing drm-fixes for Radeon/Amdgpu 
for a while.

Should I add that patch to my pull request on Friday or do you wan to 
add it directly?

Regards,
Christian.

> ---
>   drivers/gpu/drm/radeon/radeon_dp_mst.c | 5 +
>   1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c 
> b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> index 2b98ed3..257b10be 100644
> --- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
> +++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> @@ -663,12 +663,17 @@ int
>   radeon_dp_mst_probe(struct radeon_connector *radeon_connector)
>   {
>   struct radeon_connector_atom_dig *dig_connector = 
> radeon_connector->con_priv;
> + struct drm_device *dev = radeon_connector->base.dev;
> + struct radeon_device *rdev = dev->dev_private;
>   int ret;
>   u8 msg[1];
>   
>   if (!radeon_mst)
>   return 0;
>   
> + if (!ASIC_IS_DCE5(rdev))
> + return 0;
> +
>   if (dig_connector->dpcd[DP_DPCD_REV] < 0x12)
>   return 0;
>   

[PATCH 2/6] drm/rockchip: vop: optimize virtual stride calculate

[Mark Yao]

vir_stride need number words of the virtual width, and fb->pitches
save bytes_per_pixel, so just div 4 switch to stride.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 6188221..3c9f4f3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -644,7 +644,7 @@ static int vop_update_plane_event(struct drm_plane *plane,
offset += (src.y1 >> 16) * fb->pitches[0];
yrgb_mst = rk_obj->dma_addr + offset;

-   y_vir_stride = fb->pitches[0] / (fb->bits_per_pixel >> 3);
+   y_vir_stride = fb->pitches[0] >> 2;

/*
 * If this plane update changes the plane's framebuffer, (or more
-- 
1.7.9.5

[PATCH 1/6] drm/rockchip: import dma_buf to gem

[Mark Yao]

We want to display a buffer allocated by other driver, need import
the buffer to gem.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |1 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c |   45 +--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |5 ++-
 3 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 3962176..9001a90 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -287,6 +287,7 @@ static struct drm_driver rockchip_drm_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import   = drm_gem_prime_import,
+   .gem_prime_import_sg_table = rockchip_gem_prime_import_sg_table,
.gem_prime_export   = drm_gem_prime_export,
.gem_prime_get_sg_table = rockchip_gem_prime_get_sg_table,
.gem_prime_vmap = rockchip_gem_prime_vmap,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index eb2282c..2e30e23 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -18,6 +18,7 @@
 #include 

 #include 
+#include 

 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_gem.h"
@@ -105,6 +106,38 @@ int rockchip_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
return ret;
 }

+struct drm_gem_object *
+rockchip_gem_prime_import_sg_table(struct drm_device *drm,
+  struct dma_buf_attachment *attach,
+  struct sg_table *sgt)
+{
+   struct rockchip_gem_object *rk_obj;
+   struct drm_gem_object *obj;
+   int ret;
+
+   rk_obj = kzalloc(sizeof(*rk_obj), GFP_KERNEL);
+   if (!rk_obj)
+   return ERR_PTR(-ENOMEM);
+
+   obj = &rk_obj->base;
+
+   drm_gem_private_object_init(drm, obj, attach->dmabuf->size);
+
+   if (!dma_map_sg(drm->dev, sgt->sgl, sgt->nents, DMA_TO_DEVICE)) {
+   ret = -ENOMEM;
+   goto err_free_obj;
+   }
+   rk_obj->dma_addr = sg_dma_address(sgt->sgl);
+   rk_obj->sgt = sgt;
+   obj->size = sg_dma_len(sgt->sgl);
+
+   return obj;
+
+err_free_obj:
+   kfree(rk_obj);
+   return ERR_PTR(ret);
+}
+
 struct rockchip_gem_object *
rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
   bool alloc_kmap)
@@ -140,13 +173,19 @@ err_free_rk_obj:
  */
 void rockchip_gem_free_object(struct drm_gem_object *obj)
 {
+   struct drm_device *drm = obj->dev;
struct rockchip_gem_object *rk_obj;

-   drm_gem_free_mmap_offset(obj);
-
rk_obj = to_rockchip_obj(obj);

-   rockchip_gem_free_buf(rk_obj);
+   if (obj->import_attach) {
+   dma_unmap_sg(drm->dev, rk_obj->sgt->sgl,
+rk_obj->sgt->nents, DMA_TO_DEVICE);
+   drm_prime_gem_destroy(obj, rk_obj->sgt);
+   } else {
+   drm_gem_free_mmap_offset(obj);
+   rockchip_gem_free_buf(rk_obj);
+   }

kfree(rk_obj);
 }
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
index ad22618..9fd58e3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
@@ -21,6 +21,7 @@ struct rockchip_gem_object {
struct drm_gem_object base;
unsigned int flags;

+   struct sg_table *sgt;
void *kvaddr;
dma_addr_t dma_addr;
struct dma_attrs dma_attrs;
@@ -28,8 +29,10 @@ struct rockchip_gem_object {

 struct sg_table *rockchip_gem_prime_get_sg_table(struct drm_gem_object *obj);
 struct drm_gem_object *
-rockchip_gem_prime_import_sg_table(struct drm_device *dev, size_t size,
+rockchip_gem_prime_import_sg_table(struct drm_device *drm,
+  struct dma_buf_attachment *attach,
   struct sg_table *sgt);
+
 void *rockchip_gem_prime_vmap(struct drm_gem_object *obj);
 void rockchip_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);

-- 
1.7.9.5

[PATCH 3/6] drm/rockchip: vop: fix yuv plane support

[Mark Yao]

vop support yuv with NV12, NV16 and NV24, only 2 plane yuv.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   42 ++-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 3c9f4f3..7d84549 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -373,6 +373,18 @@ static enum vop_data_format vop_convert_format(uint32_t 
format)
}
 }

+static bool is_yuv_support(uint32_t format)
+{
+   switch (format) {
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV16:
+   case DRM_FORMAT_NV24:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static bool is_alpha_support(uint32_t format)
 {
switch (format) {
@@ -577,16 +589,21 @@ static int vop_update_plane_event(struct drm_plane *plane,
struct vop *vop = to_vop(crtc);
struct drm_gem_object *obj;
struct rockchip_gem_object *rk_obj;
+   struct drm_gem_object *uv_obj;
+   struct rockchip_gem_object *rk_uv_obj;
unsigned long offset;
unsigned int actual_w;
unsigned int actual_h;
unsigned int dsp_stx;
unsigned int dsp_sty;
unsigned int y_vir_stride;
+   unsigned int uv_vir_stride;
dma_addr_t yrgb_mst;
+   dma_addr_t uv_mst;
enum vop_data_format format;
uint32_t val;
bool is_alpha;
+   bool is_yuv;
bool visible;
int ret;
struct drm_rect dest = {
@@ -608,6 +625,12 @@ static int vop_update_plane_event(struct drm_plane *plane,
};
bool can_position = plane->type != DRM_PLANE_TYPE_PRIMARY;

+   if (drm_format_num_planes(fb->pixel_format) > 2) {
+   DRM_ERROR("unsupport more than 2 plane format[%08x]\n",
+ fb->pixel_format);
+   return -EINVAL;
+   }
+
ret = drm_plane_helper_check_update(plane, crtc, fb,
&src, &dest, &clip,
DRM_PLANE_HELPER_NO_SCALING,
@@ -624,6 +647,8 @@ static int vop_update_plane_event(struct drm_plane *plane,
if (format < 0)
return format;

+   is_yuv = is_yuv_support(fb->pixel_format);
+
obj = rockchip_fb_get_gem_obj(fb, 0);
if (!obj) {
DRM_ERROR("fail to get rockchip gem object from framebuffer\n");
@@ -642,10 +667,21 @@ static int vop_update_plane_event(struct drm_plane *plane,

offset = (src.x1 >> 16) * (fb->bits_per_pixel >> 3);
offset += (src.y1 >> 16) * fb->pitches[0];
-   yrgb_mst = rk_obj->dma_addr + offset;

+   yrgb_mst = rk_obj->dma_addr + offset + fb->offsets[0];
y_vir_stride = fb->pitches[0] >> 2;

+   if (is_yuv) {
+   uv_obj = rockchip_fb_get_gem_obj(fb, 1);
+   if (!uv_obj) {
+   DRM_ERROR("fail to get uv object from framebuffer\n");
+   return -EINVAL;
+   }
+   rk_uv_obj = to_rockchip_obj(uv_obj);
+   uv_vir_stride = (fb->pitches[1] >> 2);
+   uv_mst = rk_uv_obj->dma_addr + fb->offsets[1];
+   }
+
/*
 * If this plane update changes the plane's framebuffer, (or more
 * precisely, if this update has a different framebuffer than the last
@@ -681,6 +717,10 @@ static int vop_update_plane_event(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, y_vir_stride);
VOP_WIN_SET(vop, win, yrgb_mst, yrgb_mst);
+   if (is_yuv) {
+   VOP_WIN_SET(vop, win, uv_vir, uv_vir_stride);
+   VOP_WIN_SET(vop, win, uv_mst, uv_mst);
+   }
val = (actual_h - 1) << 16;
val |= (actual_w - 1) & 0x;
VOP_WIN_SET(vop, win, act_info, val);
-- 
1.7.9.5

[PATCH 0/6] drm/rockchip: support yuv overlay and plane scale

[Mark Yao]

This series patches are used for yuv image overlay display.

Rockchip vop support NV11, NV16, NV24 yuv format,
and can scale the image scale 1/8 to 8.

Mark Yao (6):
  drm/rockchip: import dma_buf to gem
  drm/rockchip: vop: optimize virtual stride calculate
  drm/rockchip: vop: fix yuv plane support
  drm/rockchip: vop: support plane scale
  drm/rockchip: vop: switch cursor plane to window 3
  drm/rockchip: vop: default enable win2/3 area0 bit

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |1 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c |   45 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |5 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  445 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   96 ++
 5 files changed, 581 insertions(+), 11 deletions(-)

-- 
1.7.9.5

[PATCH 4/6] drm/rockchip: vop: support plane scale

[Mark Yao]

Win_full support 1/8 to 8 scale down/up engine, support
all format scale.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  390 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   96 +++
 2 files changed, 483 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 7d84549..f573459 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -49,6 +49,8 @@

 #define VOP_WIN_SET(x, win, name, v) \
REG_SET(x, win->base, win->phy->name, v, RELAXED)
+#define VOP_SCL_SET(x, win, name, v) \
+   REG_SET(x, win->base, win->phy->scl->name, v, RELAXED)
 #define VOP_CTRL_SET(x, name, v) \
REG_SET(x, 0, (x)->data->ctrl->name, v, NORMAL)

@@ -163,7 +165,37 @@ struct vop_ctrl {
struct vop_reg vpost_st_end;
 };

+struct vop_scl_regs {
+   struct vop_reg cbr_vsd_mode;
+   struct vop_reg cbr_vsu_mode;
+   struct vop_reg cbr_hsd_mode;
+   struct vop_reg cbr_ver_scl_mode;
+   struct vop_reg cbr_hor_scl_mode;
+   struct vop_reg yrgb_vsd_mode;
+   struct vop_reg yrgb_vsu_mode;
+   struct vop_reg yrgb_hsd_mode;
+   struct vop_reg yrgb_ver_scl_mode;
+   struct vop_reg yrgb_hor_scl_mode;
+   struct vop_reg line_load_mode;
+   struct vop_reg cbr_axi_gather_num;
+   struct vop_reg yrgb_axi_gather_num;
+   struct vop_reg vsd_cbr_gt2;
+   struct vop_reg vsd_cbr_gt4;
+   struct vop_reg vsd_yrgb_gt2;
+   struct vop_reg vsd_yrgb_gt4;
+   struct vop_reg bic_coe_sel;
+   struct vop_reg cbr_axi_gather_en;
+   struct vop_reg yrgb_axi_gather_en;
+
+   struct vop_reg lb_mode;
+   struct vop_reg scale_yrgb_x;
+   struct vop_reg scale_yrgb_y;
+   struct vop_reg scale_cbcr_x;
+   struct vop_reg scale_cbcr_y;
+};
+
 struct vop_win_phy {
+   const struct vop_scl_regs *scl;
const uint32_t *data_formats;
uint32_t nformats;

@@ -212,7 +244,36 @@ static const uint32_t formats_234[] = {
DRM_FORMAT_RGB565,
 };

+static const struct vop_scl_regs win_full_scl = {
+   .cbr_vsd_mode = VOP_REG(WIN0_CTRL1, 0x1, 31),
+   .cbr_vsu_mode = VOP_REG(WIN0_CTRL1, 0x1, 30),
+   .cbr_hsd_mode = VOP_REG(WIN0_CTRL1, 0x3, 28),
+   .cbr_ver_scl_mode = VOP_REG(WIN0_CTRL1, 0x3, 26),
+   .cbr_hor_scl_mode = VOP_REG(WIN0_CTRL1, 0x3, 24),
+   .yrgb_vsd_mode = VOP_REG(WIN0_CTRL1, 0x1, 23),
+   .yrgb_vsu_mode = VOP_REG(WIN0_CTRL1, 0x1, 22),
+   .yrgb_hsd_mode = VOP_REG(WIN0_CTRL1, 0x3, 20),
+   .yrgb_ver_scl_mode = VOP_REG(WIN0_CTRL1, 0x3, 18),
+   .yrgb_hor_scl_mode = VOP_REG(WIN0_CTRL1, 0x3, 16),
+   .line_load_mode = VOP_REG(WIN0_CTRL1, 0x1, 15),
+   .cbr_axi_gather_num = VOP_REG(WIN0_CTRL1, 0x7, 12),
+   .yrgb_axi_gather_num = VOP_REG(WIN0_CTRL1, 0xf, 8),
+   .vsd_cbr_gt2 = VOP_REG(WIN0_CTRL1, 0x1, 7),
+   .vsd_cbr_gt4 = VOP_REG(WIN0_CTRL1, 0x1, 6),
+   .vsd_yrgb_gt2 = VOP_REG(WIN0_CTRL1, 0x1, 5),
+   .vsd_yrgb_gt4 = VOP_REG(WIN0_CTRL1, 0x1, 4),
+   .bic_coe_sel = VOP_REG(WIN0_CTRL1, 0x3, 2),
+   .cbr_axi_gather_en = VOP_REG(WIN0_CTRL1, 0x1, 1),
+   .yrgb_axi_gather_en = VOP_REG(WIN0_CTRL1, 0x1, 0),
+   .lb_mode = VOP_REG(WIN0_CTRL0, 0x7, 5),
+   .scale_yrgb_x = VOP_REG(WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
+   .scale_yrgb_y = VOP_REG(WIN0_SCL_FACTOR_YRGB, 0x, 16),
+   .scale_cbcr_x = VOP_REG(WIN0_SCL_FACTOR_CBR, 0x, 0x0),
+   .scale_cbcr_y = VOP_REG(WIN0_SCL_FACTOR_CBR, 0x, 16),
+};
+
 static const struct vop_win_phy win01_data = {
+   .scl = &win_full_scl,
.data_formats = formats_01,
.nformats = ARRAY_SIZE(formats_01),
.enable = VOP_REG(WIN0_CTRL0, 0x1, 0),
@@ -351,6 +412,15 @@ static inline void vop_mask_write_relaxed(struct vop *vop, 
uint32_t offset,
}
 }

+static inline int _get_vskiplines(uint32_t srch, uint32_t dsth)
+{
+   if (srch >= (uint32_t)(4 * dsth * MIN_SCL_FT_AFTER_VSKIP))
+   return 4;
+   else if (srch >= (uint32_t)(2 * dsth * MIN_SCL_FT_AFTER_VSKIP))
+   return 2;
+   return 1;
+}
+
 static enum vop_data_format vop_convert_format(uint32_t format)
 {
switch (format) {
@@ -538,6 +608,310 @@ static void vop_disable(struct drm_crtc *crtc)
pm_runtime_put(vop->dev);
 }

+static int _vop_cal_yrgb_lb_mode(int width)
+{
+   int lb_mode = LB_RGB_1920X5;
+
+   if (width > 2560)
+   lb_mode = LB_RGB_3840X2;
+   else if (width > 1920)
+   lb_mode = LB_RGB_2560X4;
+
+   return lb_mode;
+}
+
+static int _vop_cal_cbcr_lb_mode(int width)
+{
+   int lb_mode = LB_YUV_2560X8;
+
+   if (width > 2560)
+   lb_mode = LB_RGB_3840X2;
+   else if (width > 1920)
+   lb_mode = LB_RGB_2560X4;
+   else if (width > 1280)
+   lb_mode = LB_YU

[PATCH 5/6] drm/rockchip: vop: switch cursor plane to window 3

[Mark Yao]

Window 1 support scale and yuv format, it's waste use it for a
cursor, use window 3 is enough.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index f573459..ceac71f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -342,13 +342,14 @@ static const struct vop_reg_data vop_init_reg_table[] = {
 /*
  * Note: rk3288 has a dedicated 'cursor' window, however, that window requires
  * special support to get alpha blending working.  For now, just use overlay
- * window 1 for the drm cursor.
+ * window 3 for the drm cursor.
+ *
  */
 static const struct vop_win_data rk3288_vop_win_data[] = {
{ .base = 0x00, .phy = &win01_data, .type = DRM_PLANE_TYPE_PRIMARY },
-   { .base = 0x40, .phy = &win01_data, .type = DRM_PLANE_TYPE_CURSOR },
+   { .base = 0x40, .phy = &win01_data, .type = DRM_PLANE_TYPE_OVERLAY },
{ .base = 0x00, .phy = &win23_data, .type = DRM_PLANE_TYPE_OVERLAY },
-   { .base = 0x50, .phy = &win23_data, .type = DRM_PLANE_TYPE_OVERLAY },
+   { .base = 0x50, .phy = &win23_data, .type = DRM_PLANE_TYPE_CURSOR },
{ .base = 0x00, .phy = &cursor_data, .type = DRM_PLANE_TYPE_OVERLAY },
 };

-- 
1.7.9.5

[PATCH 6/6] drm/rockchip: vop: default enable win2/3 area0 bit

[Mark Yao]

Win2/3 support 4 area display, but now havn't found a suitable
way to use it, and it enable by win gate and area gate,
so default enable area0 gate, so that its behaviour just like a
win.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ceac71f..1b70783 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -337,6 +337,12 @@ static const struct vop_reg_data vop_init_reg_table[] = {
{DSP_CTRL0, 0x},
{WIN0_CTRL0, 0x0080},
{WIN1_CTRL0, 0x0080},
+   /*
+* Todo: win2/3 support area func, but now havn't found a suitable
+* way to use it, so default enable area0 as a win display.
+*/
+   {WIN2_CTRL0, 0x0010},
+   {WIN3_CTRL0, 0x0010},
 };

 /*
-- 
1.7.9.5

[PATCH] drm/radeon: don't probe MST on hw we don't support it on

[Dave Airlie]

On 18 June 2015 at 17:39, Christian König  wrote:
> On 18.06.2015 06:29, Dave Airlie wrote:
>>
>> From: Dave Airlie 
>>
>> If you do radeon.mst=1 on a gpu without mst hw, and then
>> plug some mst hw it will oops instead of falling back.
>>
>> So check we have DCE5 at least before proceeding.
>>
>> Signed-off-by: Dave Airlie 
>
>
> Reviewed-by: Christian König 
>
> BTW: Since Alex is on vacation I'm managing drm-fixes for Radeon/Amdgpu for
> a while.
>
> Should I add that patch to my pull request on Friday or do you wan to add it
> directly?
>

Can you add it, and maybe send the fixes pull a bit earlier :-),

since Friday for you is my Saturday, and I don't always make it to the
laptop before Sunday.

Dave.

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

[Russell King - ARM Linux]

On Wed, Jun 17, 2015 at 07:52:14PM -0700, Doug Anderson wrote:
> Russell,
> 
> On Wed, Jun 17, 2015 at 4:30 PM, Russell King - ARM Linux
>  wrote:
> > On Wed, Jun 17, 2015 at 04:14:07PM -0700, Doug Anderson wrote:
> >> If you plug in a DVI monitor to your HDMI port, you need to filter out
> >> clocks > 165MHz.  That's because 165MHz is the maximum clock rate that
> >> we can run single-link DVI at.
> >>
> >> If you want to run high resolutions to DVI, you'd need some type of an
> >> active adapter that pretended that it was HDMI, interpreted the
> >> signal, and produced a new dual link DVI signal at a lower clock rate.
> >>
> >> Signed-off-by: Doug Anderson 
> >> ---
> >> Note: this patch was tested against a 3.14 kernel with backports.  It
> >> was only compile tested against linuxnext, but the code is
> >> sufficiently similar that I'm convinced it will work there.
> >
> > Really?  I have to wonder what your testing was...
> >
> > hdmi->vic = drm_match_cea_mode(mode);
> >
> > if (!hdmi->vic) {
> > dev_dbg(hdmi->dev, "Non-CEA mode used in HDMI\n");
> > hdmi->hdmi_data.video_mode.mdvi = true;
> > } else {
> > dev_dbg(hdmi->dev, "CEA mode used vic=%d\n", hdmi->vic);
> > hdmi->hdmi_data.video_mode.mdvi = false;
> > }
> >
> > mdvi indicates whether the _currently set mode_ is a CEA mode or not (imho,
> > it's mis-named).  It doesn't indicate whether we have a HDMI display device
> > or a DVI display device connected, which seems to be what you want to use
> > it for below.
> >
> > To sort that, what you need to do is detect a HDMI display device using
> > drm_detect_hdmi_monitor() on the EDID received from the device before
> > parsing the modes, and save that value in a dw_hdmi struct member, and
> > I'd suggest that it's a top-level struct member, not buried in 'hdmi_data'
> > or 'video_mode'.
> 
> OK, so clearly my patch won't work against mainline.  I guess it's a
> good thing that I pointed out that it was only tested locally (would
> have been better to test against mainline, but I don't think that's so
> easy since there are several unlanded patches in mainline for
> Rockchip).

As far as I'm aware, Freescale's original BSP version was the same, as is
their later BSPs, and Jon's maintained 3.14-stable kernel.

> As pointed out by others at , locally
> our kernel has a slightly older version of
> , which would change mdvi to be
> as needed.

Please don't post unreliable lkml.org URLs, please use some other archive
site.  I can't access this URL at the moment.

> ...so I guess my change is blocked on someone reviewing/landing that
> series.  If that series is rejected (or is changed sufficiently so
> that mdvi no longer is set via drm_detect_hdmi_monitor() then my patch
> will need to be re-spun.

That's not what I said.  I said mdvi is set according to whether the mode
being set is a CEA mode or not.  We need something set according to
the return value of drm_detect_hdmi_monitor(), which will tell us if the
connected sink is a HDMI device or a DVI device (based upon the EDID.)

A thought occurs to me this morning though: what happens if you connect
a DVI monitor to an AV receiver which is then connected to this device.
Does the resulting EDID contain the HDMI vendor ID?  If it does, it
means that drm_detect_hdmi_monitor() will return true, indicating that
the connected device is HDMI, and we will still allow modes greater than
165MHz.

That's probably a scenario that should be checked at some point... and
it would throw a question mark over whether this is the correct approach
to limit the video modes.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] drm/atomic: Extract needs_modeset function

[Daniel Vetter]

We use the same check already in the atomic core, so might as well
make this official. And it's also reused in e.g. i915.

Motivated by Maarten's idea to extract a connector_changed state out
of mode_changed.

Cc: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c|  3 +--
 drivers/gpu/drm/drm_atomic_helper.c | 16 +---
 include/drm/drm_atomic.h|  6 ++
 3 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c7e59b074e62..f6f2fb58eb37 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1216,8 +1216,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state)

if (!state->allow_modeset) {
for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   if (crtc_state->mode_changed ||
-   crtc_state->active_changed) {
+   if (drm_atomic_crtc_needs_modeset(crtc_state)) {
DRM_DEBUG_ATOMIC("[CRTC:%d] requires full 
modeset\n",
 crtc->base.id);
return -EINVAL;
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 536ae4da4665..b06a607db6c2 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -331,12 +331,6 @@ mode_fixup(struct drm_atomic_state *state)
return 0;
 }

-static bool
-needs_modeset(struct drm_crtc_state *state)
-{
-   return state->mode_changed || state->active_changed;
-}
-
 /**
  * drm_atomic_helper_check_modeset - validate state object for modeset changes
  * @dev: DRM device
@@ -414,7 +408,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
crtc_state->active_changed = true;
}

-   if (!needs_modeset(crtc_state))
+   if (!drm_atomic_crtc_needs_modeset(crtc_state))
continue;

DRM_DEBUG_ATOMIC("[CRTC:%d] needs all connectors, enable: %c, 
active: %c\n",
@@ -564,7 +558,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
old_crtc_state = 
old_state->crtc_states[drm_crtc_index(old_conn_state->crtc)];

if (!old_crtc_state->active ||
-   !needs_modeset(old_conn_state->crtc->state))
+   !drm_atomic_crtc_needs_modeset(old_conn_state->crtc->state))
continue;

encoder = old_conn_state->best_encoder;
@@ -601,7 +595,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
const struct drm_crtc_helper_funcs *funcs;

/* Shut down everything that needs a full modeset. */
-   if (!needs_modeset(crtc->state))
+   if (!drm_atomic_crtc_needs_modeset(crtc->state))
continue;

if (!old_crtc_state->active)
@@ -792,7 +786,7 @@ void drm_atomic_helper_commit_modeset_enables(struct 
drm_device *dev,
const struct drm_crtc_helper_funcs *funcs;

/* Need to filter out CRTCs where only planes change. */
-   if (!needs_modeset(crtc->state))
+   if (!drm_atomic_crtc_needs_modeset(crtc->state))
continue;

if (!crtc->state->active)
@@ -819,7 +813,7 @@ void drm_atomic_helper_commit_modeset_enables(struct 
drm_device *dev,
continue;

if (!connector->state->crtc->state->active ||
-   !needs_modeset(connector->state->crtc->state))
+   
!drm_atomic_crtc_needs_modeset(connector->state->crtc->state))
continue;

encoder = connector->state->best_encoder;
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 1bbfedf466b9..8a3a913320eb 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -163,5 +163,11 @@ int __must_check drm_atomic_async_commit(struct 
drm_atomic_state *state);
 (plane_state) = (state)->plane_states[__i], 1);\
 (__i)++)   \
if (plane_state)
+static inline bool
+drm_atomic_crtc_needs_modeset(struct drm_crtc_state *state)
+{
+   return state->mode_changed || state->active_changed;
+}
+

 #endif /* DRM_ATOMIC_H_ */
-- 
2.1.4

[PATCH 0/5] drm/omap: various small fixes

[Tomi Valkeinen]

Hi,

Here are a few small fixes for omapdrm. These are based on the recent omapdrm
atomic modesetting series, which is now in drm-next.

 Tomi

Tomi Valkeinen (5):
  drm/omap: return error if dma_alloc_writecombine fails
  drm/omap: check that plane is inside crtc
  drm/omap: increase DMM transaction timeout
  drm/omap: fix omap_framebuffer_unpin() error handling
  drm/omap: fix omap_gem_put_paddr() error handling

 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.h   |  4 ++--
 drivers/gpu/drm/omapdrm/omap_fb.c| 16 
 drivers/gpu/drm/omapdrm/omap_gem.c   | 20 +---
 drivers/gpu/drm/omapdrm/omap_plane.c | 26 ++
 5 files changed, 46 insertions(+), 22 deletions(-)

-- 
2.1.4

[PATCH 1/5] drm/omap: return error if dma_alloc_writecombine fails

[Tomi Valkeinen]

On a platform with no TILER (e.g. omap3, am43xx), when the user wants to
allocate buffer with flag OMAP_BO_SCANOUT, the buffer needs to be
allocated with dma_alloc_writecombine. For some reason the driver does
not return an error if that alloc fails, instead it continues without
backing memory. This leads to errors later when the user tries to use
the buffer.

This patch makes the driver return an error if dma_alloc_writecombine
fails.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 2ab77801cf5f..51c5635aff62 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1392,9 +1392,17 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
 */
omap_obj->vaddr =  dma_alloc_writecombine(dev->dev, size,
&omap_obj->paddr, GFP_KERNEL);
-   if (omap_obj->vaddr)
-   flags |= OMAP_BO_DMA;
+   if (!omap_obj->vaddr) {
+   spin_lock(&priv->list_lock);
+   list_del(&omap_obj->mm_list);
+   spin_unlock(&priv->list_lock);

+   kfree(omap_obj);
+
+   return NULL;
+   }
+
+   flags |= OMAP_BO_DMA;
}

omap_obj->flags = flags;
-- 
2.1.4

[PATCH 2/5] drm/omap: check that plane is inside crtc

[Tomi Valkeinen]

DRM allows planes to be partially off-screen, but DSS hardware does not.
This patch adds the necessary check to reject plane configs if the plane
is not fully inside the crtc.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_plane.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index cfa8276c4deb..53594a3b4e98 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -17,6 +17,7 @@
  * this program.  If not, see .
  */

+#include 
 #include 
 #include 

@@ -153,9 +154,34 @@ static void omap_plane_atomic_disable(struct drm_plane 
*plane,
dispc_ovl_enable(omap_plane->id, false);
 }

+static int omap_plane_atomic_check(struct drm_plane *plane,
+  struct drm_plane_state *state)
+{
+   struct drm_crtc_state *crtc_state;
+
+   if (!state->crtc)
+   return 0;
+
+   crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
+   if (!crtc_state)
+   return 0;
+
+   if (state->crtc_x < 0 || state->crtc_y < 0)
+   return -EINVAL;
+
+   if (state->crtc_x + state->crtc_w > crtc_state->adjusted_mode.hdisplay)
+   return -EINVAL;
+
+   if (state->crtc_y + state->crtc_h > crtc_state->adjusted_mode.vdisplay)
+   return -EINVAL;
+
+   return 0;
+}
+
 static const struct drm_plane_helper_funcs omap_plane_helper_funcs = {
.prepare_fb = omap_plane_prepare_fb,
.cleanup_fb = omap_plane_cleanup_fb,
+   .atomic_check = omap_plane_atomic_check,
.atomic_update = omap_plane_atomic_update,
.atomic_disable = omap_plane_atomic_disable,
 };
-- 
2.1.4

[PATCH 3/5] drm/omap: increase DMM transaction timeout

[Tomi Valkeinen]

The DMM driver uses a timeout of 1 ms to wait for DMM transaction to
finish. While DMM should always finish the operation within that time,
the timeout is rather strict. Small misbehavior of the system (e.g. an
irq taking too long) could trigger the timeout.

As the DMM is a critical piece of code for display memory management,
let's increase the timeout to 100 ms so that we are less likely to fail
a memory allocation in case of system misbehaviors. 100 ms is just a
guess of a reasonably large timeout. The HW should accomplish the task
in less than 1 ms.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index f2daad8c3d96..7841970de48d 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -285,7 +285,7 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)

if (wait) {
if (!wait_for_completion_timeout(&engine->compl,
-   msecs_to_jiffies(1))) {
+   msecs_to_jiffies(100))) {
dev_err(dmm->dev, "timed out waiting for done\n");
ret = -ETIMEDOUT;
}
-- 
2.1.4

[PATCH 5/5] drm/omap: fix omap_gem_put_paddr() error handling

[Tomi Valkeinen]

If tiler_unpin() call in omap_gem_put_paddr() fails,
omap_gem_put_paddr() will immediately stop processing and return an
error.

This patch remoes that error checking, and also removes
omap_gem_put_paddr()'s return value, because:

 * The caller of omap_gem_put_paddr() can do nothing if an error
   happens, so it's pointless to return an error value

 * If tiler_unpin() fails, the GEM object will possibly be left in an
   undefined state, where the DMM mapping may have been removed, but the
   GEM object still thinks everything is as it should be, leading to
   crashes later.

 * There's no point in returning an error from a "free" call, as the
   caller can do nothing about it. So it's better to clean up as much as
   possible.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.h | 2 +-
 drivers/gpu/drm/omapdrm/omap_gem.c | 8 +++-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 2ef89c0c3006..1ae8477e4289 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -211,7 +211,7 @@ void omap_gem_dma_sync(struct drm_gem_object *obj,
enum dma_data_direction dir);
 int omap_gem_get_paddr(struct drm_gem_object *obj,
dma_addr_t *paddr, bool remap);
-int omap_gem_put_paddr(struct drm_gem_object *obj);
+void omap_gem_put_paddr(struct drm_gem_object *obj);
 int omap_gem_get_pages(struct drm_gem_object *obj, struct page ***pages,
bool remap);
 int omap_gem_put_pages(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 51c5635aff62..d01d40245298 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -808,10 +808,10 @@ fail:
 /* Release physical address, when DMA is no longer being performed.. this
  * could potentially unpin and unmap buffers from TILER
  */
-int omap_gem_put_paddr(struct drm_gem_object *obj)
+void omap_gem_put_paddr(struct drm_gem_object *obj)
 {
struct omap_gem_object *omap_obj = to_omap_bo(obj);
-   int ret = 0;
+   int ret;

mutex_lock(&obj->dev->struct_mutex);
if (omap_obj->paddr_cnt > 0) {
@@ -821,7 +821,6 @@ int omap_gem_put_paddr(struct drm_gem_object *obj)
if (ret) {
dev_err(obj->dev->dev,
"could not unpin pages: %d\n", ret);
-   goto fail;
}
ret = tiler_release(omap_obj->block);
if (ret) {
@@ -832,9 +831,8 @@ int omap_gem_put_paddr(struct drm_gem_object *obj)
omap_obj->block = NULL;
}
}
-fail:
+
mutex_unlock(&obj->dev->struct_mutex);
-   return ret;
 }

 /* Get rotated scanout address (only valid if already pinned), at the
-- 
2.1.4

[PATCH 4/5] drm/omap: fix omap_framebuffer_unpin() error handling

[Tomi Valkeinen]

omap_framebuffer_unpin() check the return value of omap_gem_put_paddr()
and return immediately if omap_gem_put_paddr() fails.

This patch removes the check for the return value, and also removes the
return value of omap_framebuffer_unpin(), because:

 * Nothing checks the return value of omap_framebuffer_unpin(), and even
   something did check it, there's nothing the caller can do to handle
   the error.

 * If a omap_gem_put_paddr() fails, the framebuffer's other planes will
   be left unreleased. So it's better to call omap_gem_put_paddr() for
   all the planes, even if one would fail.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.h |  2 +-
 drivers/gpu/drm/omapdrm/omap_fb.c  | 16 
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index ae2df41f216f..2ef89c0c3006 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -177,7 +177,7 @@ struct drm_framebuffer *omap_framebuffer_init(struct 
drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
 struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb, int p);
 int omap_framebuffer_pin(struct drm_framebuffer *fb);
-int omap_framebuffer_unpin(struct drm_framebuffer *fb);
+void omap_framebuffer_unpin(struct drm_framebuffer *fb);
 void omap_framebuffer_update_scanout(struct drm_framebuffer *fb,
struct omap_drm_window *win, struct omap_overlay_info *info);
 struct drm_connector *omap_framebuffer_get_next_connector(
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 0b967e76df1a..51b1219af87f 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -287,10 +287,10 @@ fail:
 }

 /* unpin, no longer being scanned out: */
-int omap_framebuffer_unpin(struct drm_framebuffer *fb)
+void omap_framebuffer_unpin(struct drm_framebuffer *fb)
 {
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   int ret, i, n = drm_format_num_planes(fb->pixel_format);
+   int i, n = drm_format_num_planes(fb->pixel_format);

mutex_lock(&omap_fb->lock);

@@ -298,24 +298,16 @@ int omap_framebuffer_unpin(struct drm_framebuffer *fb)

if (omap_fb->pin_count > 0) {
mutex_unlock(&omap_fb->lock);
-   return 0;
+   return;
}

for (i = 0; i < n; i++) {
struct plane *plane = &omap_fb->planes[i];
-   ret = omap_gem_put_paddr(plane->bo);
-   if (ret)
-   goto fail;
+   omap_gem_put_paddr(plane->bo);
plane->paddr = 0;
}

mutex_unlock(&omap_fb->lock);
-
-   return 0;
-
-fail:
-   mutex_unlock(&omap_fb->lock);
-   return ret;
 }

 struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb, int p)
-- 
2.1.4

[PATCH 1/6] drm/rockchip: import dma_buf to gem

[Russell King - ARM Linux]

On Thu, Jun 18, 2015 at 03:49:25PM +0800, Mark Yao wrote:
> We want to display a buffer allocated by other driver, need import
> the buffer to gem.
> 
> Signed-off-by: Mark Yao 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |1 +
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c |   45 
> +--
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.h |5 ++-
>  3 files changed, 47 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 3962176..9001a90 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -287,6 +287,7 @@ static struct drm_driver rockchip_drm_driver = {
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>   .gem_prime_import   = drm_gem_prime_import,
> + .gem_prime_import_sg_table = rockchip_gem_prime_import_sg_table,
>   .gem_prime_export   = drm_gem_prime_export,
>   .gem_prime_get_sg_table = rockchip_gem_prime_get_sg_table,
>   .gem_prime_vmap = rockchip_gem_prime_vmap,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index eb2282c..2e30e23 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -18,6 +18,7 @@
>  #include 
>  
>  #include 
> +#include 
>  
>  #include "rockchip_drm_drv.h"
>  #include "rockchip_drm_gem.h"
> @@ -105,6 +106,38 @@ int rockchip_gem_mmap(struct file *filp, struct 
> vm_area_struct *vma)
>   return ret;
>  }
>  
> +struct drm_gem_object *
> +rockchip_gem_prime_import_sg_table(struct drm_device *drm,
> +struct dma_buf_attachment *attach,
> +struct sg_table *sgt)
> +{
> + struct rockchip_gem_object *rk_obj;
> + struct drm_gem_object *obj;
> + int ret;
> +
> + rk_obj = kzalloc(sizeof(*rk_obj), GFP_KERNEL);
> + if (!rk_obj)
> + return ERR_PTR(-ENOMEM);
> +
> + obj = &rk_obj->base;
> +
> + drm_gem_private_object_init(drm, obj, attach->dmabuf->size);
> +
> + if (!dma_map_sg(drm->dev, sgt->sgl, sgt->nents, DMA_TO_DEVICE)) {
> + ret = -ENOMEM;
> + goto err_free_obj;
> + }
> + rk_obj->dma_addr = sg_dma_address(sgt->sgl);
> + rk_obj->sgt = sgt;
> + obj->size = sg_dma_len(sgt->sgl);

This is wrong.

First, if you can only cope with a single scatterlist entry, you need to
enforce that.  You can do that in your gem_prime_import_sg_table() method
by checking sgt->nents.

Secondly, you're mapping an already mapped scatterlist - scatterlists
are mapped by the exporter inside dma_buf_map_attachment() for your
device.

Thirdly, I hate drm_gem_prime_import() being used on ARM... it forces
drivers to do something very buggy: the DMA buffer is mapped for DMA
when the buffer is imported.  If the buffer is a write-combine or cached
buffer, writes to the buffer after the import will not become visible to
the display hardware until sometime later (when they're evicted from the
caches and/or pushed out of the bus structure.)  The DMA mapping should
be performed as close to the start of DMA as possible.  However, this is
a long-standing issue I have with dma_buf itself and is not something you
should be too concerned with in your patch.  Just bear it in mind if you
start to see corruption of imported buffers - the answer is not more
dma_map_sg() calls, but to get dma_buf fixed.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] drm/radeon: don't probe MST on hw we don't support it on

[Christian König]

On 18.06.2015 10:31, Dave Airlie wrote:
> On 18 June 2015 at 17:39, Christian König  wrote:
>> On 18.06.2015 06:29, Dave Airlie wrote:
>>> From: Dave Airlie 
>>>
>>> If you do radeon.mst=1 on a gpu without mst hw, and then
>>> plug some mst hw it will oops instead of falling back.
>>>
>>> So check we have DCE5 at least before proceeding.
>>>
>>> Signed-off-by: Dave Airlie 
>>
>> Reviewed-by: Christian König 
>>
>> BTW: Since Alex is on vacation I'm managing drm-fixes for Radeon/Amdgpu for
>> a while.
>>
>> Should I add that patch to my pull request on Friday or do you wan to add it
>> directly?
>>
> Can you add it, and maybe send the fixes pull a bit earlier :-),

Only when I have to, as usually I'm quite busy ;)

> since Friday for you is my Saturday, and I don't always make it to the
> laptop before Sunday.

Hui? In what time zone are you? Keep in mind that unlike Alex I live and 
work from Germany, so I'm in CET as well.

Going to try to get together the branches for Radeon/Amdgpu till the 
evening, but can't promise that.

Regards,
Christian.

>
> Dave.

[PATCH] GPU: ipu: fix lockup caused by pending chained interrupts

[Russell King - ARM Linux]

Even with the oops fixed by a previous patch, the system still fails to
kexec, due to a stuck chained interrupt locking the system.  We must
disable the child interrupts prior to setting up the irq chip to ensure
we don't get stuck here.

Signed-off-by: Russell King 
---
Maybe this is all that's really needed... would also be nice if this
path had an etry in MAINTAINERS...

Having discussed with Thomas today, we've decided that (maybe) David
should take this patch.  It's rather unclear who to send these patches
to though.

 drivers/gpu/ipu-v3/ipu-common.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 6d2f39d36e44..00f2058944e5 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1107,6 +1107,9 @@ static int ipu_irq_init(struct ipu_soc *ipu)
return ret;
}

+   for (i = 0; i < IPU_NUM_IRQS; i += 32)
+   ipu_cm_write(ipu, 0, IPU_INT_CTRL(i / 32));
+
for (i = 0; i < IPU_NUM_IRQS; i += 32) {
gc = irq_get_domain_generic_chip(ipu->domain, i);
gc->reg_base = ipu->cm_reg;
-- 
2.1.0

[PATCH] rnndb/dsi: Add register descriptions for 20nm PHY

[Hai Li]

This change introduces new domains of PHY and PHY_REGULATOR
for 20nm DSI PHY registers.

Signed-off-by: Hai Li 
---
 rnndb/dsi/dsi.xml | 91 +++
 1 file changed, 91 insertions(+)

diff --git a/rnndb/dsi/dsi.xml b/rnndb/dsi/dsi.xml
index d19bea9..0f3d4ff 100644
--- a/rnndb/dsi/dsi.xml
+++ b/rnndb/dsi/dsi.xml
@@ -525,4 +525,95 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">

 

+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+
+   
+   
+
+   
+   
+   
+   
+   
+   
+
+   
+   
+
+
+
+   
+   
+   
+   
+   
+   
+   
+
+
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 0/2] drm/msm/dsi: msm8x94 configuration and support

[Hai Li]

Hai Li (2):
  drm/msm/dsi: Update generated headers with 20nm PHY support
  drm/msm/dsi: Add support for msm8x94

 Documentation/devicetree/bindings/drm/msm/dsi.txt |   7 +
 drivers/gpu/drm/msm/dsi/dsi.h |   1 +
 drivers/gpu/drm/msm/dsi/dsi.xml.h | 192 --
 drivers/gpu/drm/msm/dsi/dsi_host.c|  18 ++
 drivers/gpu/drm/msm/dsi/dsi_phy.c | 131 +++
 5 files changed, 338 insertions(+), 11 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 1/2] drm/msm/dsi: Update generated headers with 20nm PHY support

[Hai Li]

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/dsi/dsi.xml.h | 192 +++---
 1 file changed, 181 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h 
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index 9791ea0..9bb63a9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -8,17 +8,8 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git

 The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/freedreno/envytools/rnndb/msm.xml (
676 bytes, from 2014-12-05 15:34:49)
-- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2013-03-31 16:51:27)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml(  
20915 bytes, from 2015-03-24 22:05:22)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml  (   
2352 bytes, from 2015-04-12 15:02:42)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml(  
35083 bytes, from 2015-04-12 15:04:03)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (  
22094 bytes, from 2015-05-12 12:45:23)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
344 bytes, from 2013-08-11 19:26:32)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (   
1686 bytes, from 2014-10-31 16:48:57)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2013-07-05 19:21:12)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml   (  
29012 bytes, from 2015-05-12 12:45:23)
-- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml (  
10416 bytes, from 2015-05-12 12:45:23)
+- /usr2/hali/local/envytools/envytools/rnndb/dsi/dsi.xml (  25475 
bytes, from 2015-05-08 22:31:43)
+- /usr2/hali/local/envytools/envytools/rnndb/freedreno_copyright.xml (   1453 
bytes, from 2015-01-28 21:43:22)

 Copyright (C) 2013-2015 by the following authors:
 - Rob Clark  (robclark)
@@ -994,5 +985,184 @@ static inline uint32_t 
DSI_28nm_PHY_PLL_SDM_CFG3_FREQ_SEED_15_8(uint32_t val)

 #define REG_DSI_28nm_PHY_PLL_CTRL_54   0x00d4

+static inline uint32_t REG_DSI_20nm_PHY_LN(uint32_t i0) { return 0x + 
0x40*i0; }
+
+static inline uint32_t REG_DSI_20nm_PHY_LN_CFG_0(uint32_t i0) { return 
0x + 0x40*i0; }
+
+static inline uint32_t REG_DSI_20nm_PHY_LN_CFG_1(uint32_t i0) { return 
0x0004 + 0x40*i0; }
+
+static inline uint32_t REG_DSI_20nm_PHY_LN_CFG_2(uint32_t i0) { return 
0x0008 + 0x40*i0; }
+
+static inline uint32_t REG_DSI_20nm_PHY_LN_CFG_3(uint32_t i0) { return 
0x000c + 0x40*i0; }
+
+static inline uint32_t REG_DSI_20nm_PHY_LN_CFG_4(uint32_t i0) { return 
0x0010 + 0x40*i0; }
+
+static inline uint32_t REG_DSI_20nm_PHY_LN_TEST_DATAPATH(uint32_t i0) { return 
0x0014 + 0x40*i0; }
+
+static inline uint32_t REG_DSI_20nm_PHY_LN_DEBUG_SEL(uint32_t i0) { return 
0x0018 + 0x40*i0; }
+
+static inline uint32_t REG_DSI_20nm_PHY_LN_TEST_STR_0(uint32_t i0) { return 
0x001c + 0x40*i0; }
+
+static inline uint32_t REG_DSI_20nm_PHY_LN_TEST_STR_1(uint32_t i0) { return 
0x0020 + 0x40*i0; }
+
+#define REG_DSI_20nm_PHY_LNCK_CFG_00x0100
+
+#define REG_DSI_20nm_PHY_LNCK_CFG_10x0104
+
+#define REG_DSI_20nm_PHY_LNCK_CFG_20x0108
+
+#define REG_DSI_20nm_PHY_LNCK_CFG_30x010c
+
+#define REG_DSI_20nm_PHY_LNCK_CFG_40x0110
+
+#define REG_DSI_20nm_PHY_LNCK_TEST_DATAPATH0x0114
+
+#define REG_DSI_20nm_PHY_LNCK_DEBUG_SEL
0x0118
+
+#define REG_DSI_20nm_PHY_LNCK_TEST_STR0
0x011c
+
+#define REG_DSI_20nm_PHY_LNCK_TEST_STR1
0x0120
+
+#define REG_DSI_20nm_PHY_TIMING_CTRL_0 0x0140
+#define DSI_20nm_PHY_TIMING_CTRL_0_CLK_ZERO__MASK  0x00ff
+#define DSI_20nm_PHY_TIMING_CTRL_0_CLK_ZERO__SHIFT 0
+static inline uint32_t DSI_20nm_PHY_TIMING_CTRL_0_CLK_ZERO(uint32_t val)
+{
+   return ((val) << DSI_20nm_PHY_TIMING_CTRL_0_CLK_ZERO__SHIFT) & 
DSI_20nm_PHY_TIMING_CTRL_0_CLK_ZERO__MASK;
+}
+
+#define REG_DSI_20nm_PHY_TIMING_CTRL_1 0x0144
+#define DSI_20nm_PHY_TIMING_CTRL_1_CLK_TRAIL__MASK 0x00ff
+#define DSI_20nm_PHY_TIMING_CTRL_1_CLK_TRAIL__SHIFT0
+static inline uint32_t DSI_20nm_PHY_TIMING_CTRL_1_CLK_TRAIL(uint32_t val)
+{
+   return ((val) << DSI_20nm_PHY_TIMING_CTRL_1_CLK_TRAIL__SHIFT) & 
DSI_20nm_PHY_TIMING_CTRL_1_CLK_TRAIL__MASK;
+}
+
+#define REG_DSI_20nm_PHY_TIMING_CTRL_2 0x0148
+#define DSI_20nm_PHY_TIMING_CTRL_2_CLK_PREPARE__MASK   0x00ff
+#define DSI_20nm

[PATCH 2/2] drm/msm/dsi: Add support for msm8x94

[Hai Li]

DSI controller on msm8x94 is version 1.3, which requires different
power supplies and works with 20nm DSI PHY. This change is to add
the basic support for this version.

Signed-off-by: Hai Li 
---
 Documentation/devicetree/bindings/drm/msm/dsi.txt |   7 ++
 drivers/gpu/drm/msm/dsi/dsi.h |   1 +
 drivers/gpu/drm/msm/dsi/dsi_host.c|  18 +++
 drivers/gpu/drm/msm/dsi/dsi_phy.c | 131 ++
 4 files changed, 157 insertions(+)

diff --git a/Documentation/devicetree/bindings/drm/msm/dsi.txt 
b/Documentation/devicetree/bindings/drm/msm/dsi.txt
index 4edd6fa..4309f0f 100644
--- a/Documentation/devicetree/bindings/drm/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/drm/msm/dsi.txt
@@ -47,6 +47,7 @@ Required properties:
 - compatible: Could be the following
   * "qcom,dsi-phy-28nm-hpm"
   * "qcom,dsi-phy-28nm-lp"
+  * "qcom,dsi-phy-20nm"
 - reg: Physical base address and length of the registers of PLL, PHY and PHY
   regulator
 - reg-names: The names of register regions. The following regions are required:
@@ -62,6 +63,10 @@ Required properties:
   * "iface_clk"
 - vddio-supply: phandle to vdd-io regulator device node

+Optional properties:
+- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
+  regulator is wanted.
+
 Example:
mdss_dsi0: qcom,mdss_dsi at fd922800 {
compatible = "qcom,mdss-dsi-ctrl";
@@ -124,4 +129,6 @@ Example:
clock-names = "iface_clk";
clocks = <&mmcc MDSS_AHB_CLK>;
vddio-supply = <&pma8084_l12>;
+
+   qcom,dsi-phy-regulator-ldo-mode;
};
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 5e29aad..e18872a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -30,6 +30,7 @@
 enum msm_dsi_phy_type {
MSM_DSI_PHY_28NM_HPM,
MSM_DSI_PHY_28NM_LP,
+   MSM_DSI_PHY_20NM,
MSM_DSI_PHY_MAX
 };

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 69c1397..2d8f194 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -34,6 +34,7 @@
 #define MSM_DSI_6G_VER_MINOR_V1_1  0x1001
 #define MSM_DSI_6G_VER_MINOR_V1_1_10x10010001
 #define MSM_DSI_6G_VER_MINOR_V1_2  0x1002
+#define MSM_DSI_6G_VER_MINOR_V1_3  0x1003
 #define MSM_DSI_6G_VER_MINOR_V1_3_10x10030001

 #define DSI_6G_REG_SHIFT   4
@@ -117,6 +118,23 @@ static const struct dsi_config dsi_cfgs[] = {
},
},
},
+   { /* 8x94 */
+   .major = MSM_DSI_VER_MAJOR_6G,
+   .minor = MSM_DSI_6G_VER_MINOR_V1_3,
+   .io_offset = DSI_6G_REG_SHIFT,
+   .reg_cfg = {
+   .num = 7,
+   .regs = {
+   {"gdsc", -1, -1, -1, -1},
+   {"vdda", 125, 125, 10, 100},
+   {"vddio", 180, 180, 10, 100},
+   {"vcca", 100, 100, 1, 100},
+   {"vdd", 180, 180, 10, 100},
+   {"lab_reg", -1, -1, -1, -1},
+   {"ibb_reg", -1, -1, -1, -1},
+   },
+   }
+   },
 };

 static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/dsi_phy.c
index 52b463e..bd37e61 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_phy.c
@@ -66,6 +66,8 @@ struct msm_dsi_phy {
struct dsi_dphy_timing timing;
const struct dsi_phy_cfg *cfg;

+   bool regulator_ldo_mode;
+
struct msm_dsi_pll *pll;
 };

@@ -406,6 +408,115 @@ static int dsi_28nm_phy_disable(struct msm_dsi_phy *phy)
return 0;
 }

+static void dsi_20nm_phy_regulator_ctrl(struct msm_dsi_phy *phy, bool enable)
+{
+   void __iomem *base = phy->reg_base;
+
+   if (!enable) {
+   dsi_phy_write(base + REG_DSI_20nm_PHY_REGULATOR_CAL_PWR_CFG, 0);
+   return;
+   }
+
+   if (phy->regulator_ldo_mode) {
+   dsi_phy_write(phy->base + REG_DSI_20nm_PHY_LDO_CNTRL, 0x1d);
+   return;
+   }
+
+   /* non LDO mode */
+   dsi_phy_write(base + REG_DSI_20nm_PHY_REGULATOR_CTRL_1, 0x03);
+   dsi_phy_write(base + REG_DSI_20nm_PHY_REGULATOR_CTRL_2, 0x03);
+   dsi_phy_write(base + REG_DSI_20nm_PHY_REGULATOR_CTRL_3, 0x00);
+   dsi_phy_write(base + REG_DSI_20nm_PHY_REGULATOR_CTRL_4, 0x20);
+   dsi_phy_write(base + REG_DSI_20nm_PHY_REGULATOR_CAL_PWR_CFG, 0x01);
+   dsi_phy_write(phy->base + REG_DSI_20nm_PHY_LDO_CNTRL, 0x00);
+   dsi_phy_write(base + REG_DSI_20nm_PHY_REGULATOR_CTRL_0, 0x03);
+}
+
+static int dsi_20nm_phy_enable(struct msm_dsi_phy *phy, int

[PATCH 1/5] drm/omap: return error if dma_alloc_writecombine fails

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 18 June 2015 13:10:35 Tomi Valkeinen wrote:
> On a platform with no TILER (e.g. omap3, am43xx), when the user wants to
> allocate buffer with flag OMAP_BO_SCANOUT, the buffer needs to be
> allocated with dma_alloc_writecombine. For some reason the driver does
> not return an error if that alloc fails, instead it continues without
> backing memory. This leads to errors later when the user tries to use
> the buffer.
> 
> This patch makes the driver return an error if dma_alloc_writecombine
> fails.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_gem.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> b/drivers/gpu/drm/omapdrm/omap_gem.c index 2ab77801cf5f..51c5635aff62
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> @@ -1392,9 +1392,17 @@ struct drm_gem_object *omap_gem_new(struct drm_device
> *dev, */
>   omap_obj->vaddr =  dma_alloc_writecombine(dev->dev, size,
>   &omap_obj->paddr, GFP_KERNEL);
> - if (omap_obj->vaddr)
> - flags |= OMAP_BO_DMA;
> + if (!omap_obj->vaddr) {
> + spin_lock(&priv->list_lock);
> + list_del(&omap_obj->mm_list);
> + spin_unlock(&priv->list_lock);

Wouldn't it be simpler to move the list_add after the "if ((flags & 
OMAP_BO_SCANOUT) && !priv->has_dmm)" block ? You could then avoid the 
list_del.

> + kfree(omap_obj);
> +
> + return NULL;
> + }
> +
> + flags |= OMAP_BO_DMA;
>   }
> 
>   omap_obj->flags = flags;

-- 
Regards,

Laurent Pinchart

[PATCH 2/5] drm/omap: check that plane is inside crtc

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 18 June 2015 13:10:36 Tomi Valkeinen wrote:
> DRM allows planes to be partially off-screen, but DSS hardware does not.
> This patch adds the necessary check to reject plane configs if the plane
> is not fully inside the crtc.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_plane.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
> b/drivers/gpu/drm/omapdrm/omap_plane.c index cfa8276c4deb..53594a3b4e98
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -17,6 +17,7 @@
>   * this program.  If not, see .
>   */
> 
> +#include 
>  #include 
>  #include 
> 
> @@ -153,9 +154,34 @@ static void omap_plane_atomic_disable(struct drm_plane
> *plane, dispc_ovl_enable(omap_plane->id, false);
>  }
> 
> +static int omap_plane_atomic_check(struct drm_plane *plane,
> +struct drm_plane_state *state)
> +{
> + struct drm_crtc_state *crtc_state;
> +
> + if (!state->crtc)
> + return 0;
> +
> + crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
> + if (!crtc_state)
> + return 0;

drm_atomic_get_crtc_state() returns an ERR_PTR on error. You should then 
propagate the error to the caller:

crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);

> + if (state->crtc_x < 0 || state->crtc_y < 0)
> + return -EINVAL;
> +
> + if (state->crtc_x + state->crtc_w > crtc_state->adjusted_mode.hdisplay)
> + return -EINVAL;
> +
> + if (state->crtc_y + state->crtc_h > crtc_state->adjusted_mode.vdisplay)
> + return -EINVAL;

I wonder whether we couldn't clip the plane in software instead of failing. 
This patch is fine though (except for the problem above), clipping can be 
implemented in a separate patch.

> + return 0;
> +}
> +
>  static const struct drm_plane_helper_funcs omap_plane_helper_funcs = {
>   .prepare_fb = omap_plane_prepare_fb,
>   .cleanup_fb = omap_plane_cleanup_fb,
> + .atomic_check = omap_plane_atomic_check,
>   .atomic_update = omap_plane_atomic_update,
>   .atomic_disable = omap_plane_atomic_disable,
>  };

-- 
Regards,

Laurent Pinchart

[PATCH 0/6] Improve GK20A and introduce GM20B support

[Alexandre Courbot]

Hello everyone,

GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial support
for it, based on a rework of the already-supported GK20A. It also introduces
support for NVIDIA-provided firmware files, which is why I have added a few
NVIDIA people who are relevant to this discussion.

The first patch adds support for loading the FECS and GPCCS firmwares from
firmware files officially released by NVIDIA. As you know such firmwares will
soon become a necessity for newer GPUs because some falcons will require signed
firmware to operate. In addition there is no reverse-engineered version of the
GK20A firmwares yet, so since an external file is needed anyway, it may as well
be provided officially. NVIDIA plans to release firmwares as one file per binary
to keep things simple. The layout will be nvidia//.bin, so for
GK20A FECS/GPCCS we have:

nvidia/gk20a/fecs_inst.bin (aka fuc409c)
nvidia/gk20a/fecs_data.bin (aka fuc409d)
nvidia/gk20a/gpccs_inst.bin (aka fuc41ac)
nvidia/gk20a/gpccs_data.bin (aka fuc41ad)

All firmware files listed in this patchset are clean for release, and I am just
waiting for a community ack of the layout to send a patch to linux-firmware.

The second patch reworks existing GK20A support to make it closer to what our
nvgpu driver does. Support so far was heavily based on GK104, which somehow made
me feel uneasy - and quite scared after I looked more closely at what nvgpu
does. In particular the GK104 MMIO bundles differed significantly from what
nvgpu does. This change aligns things and (probably less significant, but still
safer) reorders the initialization sequence to match the one of nvgpu.

You will note that the MMIO bundles now come as firmware files of their own. I
am not sure the community will be pleased with an increase of firmware files,
however the rationale for this is as follows:
- These initialization sequences are related to the firmwares, so it makes sense
  to distribute them under the same medium
- If NVIDIA needs to update the firmwares for some reason, it can atomically
  update the MMIO bundles and provide a coherent set, instead of having to
  introduce versioning into the firmware and driver
- For IP reasons, I as an NVIDIA employee cannot extract these register
  sequences and link them into Nouveau
- These are just a bunch of register address/value pairs anyway

The new firmware files introduced are:

nvidia/gk20a/sw_nonctx.bin (gr_pack_mmio)
nvidia/gk20a/sw_ctx.bin (grctx_pack_hub, grctx_pack_gpc, grctx_pack_zcull,
 grctx_pack_tpc, grctx_pack_ppc)
nvidia/gk20a/sw_bundle_init.bin (grctx_pack_icmd)
nvidia/gk20a/sw_method_init.bin (grctx_pack_mthd)

Third patch is trivial and adds the GM20B FIFO device.

Fourth patch adds GM20B GR based on the reworked GK20A support. GM20B will rely
on the same firmware files as GK20A (also clean for release). Note that this is
not full support yet for released devices, which will require secure boot. This
will be my focus once this patchset is merged (Deepak got a working version,
but there is still a lot of work to do on it before it is upstreamable).

The last two patches recognize GM20B at the device and platform level. Nothing
really exciting.

I hope the addition of firmware files will not become too controversial. If it
does, I have good arguments to support it. ;) Besides the GK20A rework that
probably few people care about, the point is the addition of a basic layout for
the firmwares that NVIDIA will officially release to finally support secure
boot, and I would like to make sure we get this right.

Thanks,
Alex.

Alexandre Courbot (6):
  gr: support for NVIDIA-provided firmwares
  gr/gk20a: use same initialization sequence as nvgpu
  fifo: add GM20B fifo
  gr: add GM20B support
  device: recognize GM20B
  platform: recognize GM20B

 drm/nouveau/include/nvkm/engine/fifo.h |   1 +
 drm/nouveau/include/nvkm/engine/gr.h   |   1 +
 drm/nouveau/nouveau_platform.c |   1 +
 drm/nouveau/nvkm/engine/device/gm100.c |  20 ++
 drm/nouveau/nvkm/engine/fifo/Kbuild|   1 +
 drm/nouveau/nvkm/engine/fifo/gk104.h   |   4 +
 drm/nouveau/nvkm/engine/fifo/gm204.c   |   2 +-
 drm/nouveau/nvkm/engine/fifo/gm20b.c   |  34 
 drm/nouveau/nvkm/engine/gr/Kbuild  |   2 +
 drm/nouveau/nvkm/engine/gr/ctxgf100.h  |   7 +
 drm/nouveau/nvkm/engine/gr/ctxgk20a.c  |  65 +--
 drm/nouveau/nvkm/engine/gr/ctxgm107.c  |   2 +-
 drm/nouveau/nvkm/engine/gr/ctxgm204.c  |   4 +-
 drm/nouveau/nvkm/engine/gr/ctxgm20b.c  | 110 +++
 drm/nouveau/nvkm/engine/gr/gf100.c |  70 +--
 drm/nouveau/nvkm/engine/gr/gf100.h |  18 ++
 drm/nouveau/nvkm/engine/gr/gk20a.c | 336 +++--
 drm/nouveau/nvkm/engine/gr/gk20a.h |  35 
 drm/nouveau/nvkm/engine/gr/gm20b.c |  84 +
 19 files changed, 748 insertions(+), 49 deletions(-)
 create mode 100644 drm/nouveau/nvkm/engine/fifo/gm20b.c
 create mode 100644 drm/nouveau/nvkm/engine/gr/ctxgm20b.c
 create mode 100644 d

[PATCH 1/6] gr: support for NVIDIA-provided firmwares

[Alexandre Courbot]

NVIDIA will officially start providing signed firmwares through
linux-firmware. Change the GR firmware lookup function to look them up
in addition to the extracted firmwares.

Signed-off-by: Alexandre Courbot 
---
 drm/nouveau/nvkm/engine/gr/gf100.c | 66 +-
 1 file changed, 51 insertions(+), 15 deletions(-)

diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c 
b/drm/nouveau/nvkm/engine/gr/gf100.c
index ca11ddb..39d482f 100644
--- a/drm/nouveau/nvkm/engine/gr/gf100.c
+++ b/drm/nouveau/nvkm/engine/gr/gf100.c
@@ -1544,26 +1544,62 @@ gf100_gr_dtor_fw(struct gf100_gr_fuc *fuc)
fuc->data = NULL;
 }

+/**
+ * gf100_gr_ctor_fw - helper for loading external GR firmwares
+ *
+ * A firmware can either be officially provided by NVIDIA (in which case it 
will
+ * use a "NVIDIA name", or be extracted from the binary blob (and use a
+ * "Nouveau name". The fwname and nvfwname are to be given the Nouveau and
+ * NVIDIA names of a given firmware, respectively. This function will then
+ * try to load the NVIDIA firmware, then the extracted one, in that order.
+ *
+ */
 int
 gf100_gr_ctor_fw(struct gf100_gr_priv *priv, const char *fwname,
-struct gf100_gr_fuc *fuc)
+const char *nvfwname, struct gf100_gr_fuc *fuc)
 {
struct nvkm_device *device = nv_device(priv);
const struct firmware *fw;
-   char f[32];
-   int ret;
+   char f[64];
+   int ret = -EINVAL;
+   int i;

-   snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset, fwname);
-   ret = request_firmware(&fw, f, nv_device_base(device));
-   if (ret) {
-   snprintf(f, sizeof(f), "nouveau/%s", fwname);
-   ret = request_firmware(&fw, f, nv_device_base(device));
-   if (ret) {
-   nv_error(priv, "failed to load %s\n", fwname);
-   return ret;
+   /*
+* NVIDIA firmware name provided - try to load it
+* We try this first since most chips that require external firmware
+* are supported by NVIDIA
+*/
+   if (nvfwname) {
+   snprintf(f, sizeof(f), "nvidia/%s/%s.bin", device->cname,
+nvfwname);
+   i = strlen(f);
+   while (i) {
+   --i;
+   f[i] = tolower(f[i]);
}
+   ret = request_firmware_direct(&fw, f, nv_device_base(device));
+   if (!ret)
+   goto found;
+   }
+
+   /* Nouveau firmware name provided - try to load it */
+   if (fwname) {
+   snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset,
+fwname);
+   ret = request_firmware_direct(&fw, f, nv_device_base(device));
+   if (!ret)
+   goto found;
+
+   snprintf(f, sizeof(f), "nouveau/%s", fwname);
+   ret = request_firmware_direct(&fw, f, nv_device_base(device));
+   if (!ret)
+   goto found;
}

+   nv_error(priv, "failed to load %s / %s\n", fwname, nvfwname);
+   return ret;
+
+found:
fuc->size = fw->size;
fuc->data = kmemdup(fw->data, fuc->size, GFP_KERNEL);
release_firmware(fw);
@@ -1615,10 +1651,10 @@ gf100_gr_ctor(struct nvkm_object *parent, struct 
nvkm_object *engine,

if (use_ext_fw) {
nv_info(priv, "using external firmware\n");
-   if (gf100_gr_ctor_fw(priv, "fuc409c", &priv->fuc409c) ||
-   gf100_gr_ctor_fw(priv, "fuc409d", &priv->fuc409d) ||
-   gf100_gr_ctor_fw(priv, "fuc41ac", &priv->fuc41ac) ||
-   gf100_gr_ctor_fw(priv, "fuc41ad", &priv->fuc41ad))
+   if (gf100_gr_ctor_fw(priv, "fuc409c", "fecs_inst", 
&priv->fuc409c) ||
+   gf100_gr_ctor_fw(priv, "fuc409d", "fecs_data", 
&priv->fuc409d) ||
+   gf100_gr_ctor_fw(priv, "fuc41ac", "gpccs_inst", 
&priv->fuc41ac) ||
+   gf100_gr_ctor_fw(priv, "fuc41ad", "gpccs_data", 
&priv->fuc41ad))
return -ENODEV;
priv->firmware = true;
}
-- 
2.4.3

[PATCH 2/6] gr/gk20a: use same initialization sequence as nvgpu

[Alexandre Courbot]

GK20A's initialization was based on GK104, but differences exist in the
way the initial context is built and the initialization process itself.

This patch follows the same initialization sequence as nvgpu performs
to avoid bad surprises. Since the register bundles initialization also
differ considerably from GK104, the register packs are now loaded from
firmware files, again similarly to what is done with nvgpu.

Signed-off-by: Alexandre Courbot 
---
 drm/nouveau/nvkm/engine/gr/ctxgk20a.c |  65 +--
 drm/nouveau/nvkm/engine/gr/gf100.c|   3 +-
 drm/nouveau/nvkm/engine/gr/gf100.h|  12 ++
 drm/nouveau/nvkm/engine/gr/gk20a.c| 336 --
 drm/nouveau/nvkm/engine/gr/gk20a.h|  35 
 5 files changed, 421 insertions(+), 30 deletions(-)
 create mode 100644 drm/nouveau/nvkm/engine/gr/gk20a.h

diff --git a/drm/nouveau/nvkm/engine/gr/ctxgk20a.c 
b/drm/nouveau/nvkm/engine/gr/ctxgk20a.c
index 2f241f6..3fe080e 100644
--- a/drm/nouveau/nvkm/engine/gr/ctxgk20a.c
+++ b/drm/nouveau/nvkm/engine/gr/ctxgk20a.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ * Copyright (c) 2014-2015, NVIDIA CORPORATION. All rights reserved.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
@@ -19,14 +19,56 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
  * DEALINGS IN THE SOFTWARE.
  */
+
 #include "ctxgf100.h"
+#include "gk20a.h"
+
+#include 
+
+static void
+gk20a_grctx_generate_main(struct gf100_gr_priv *priv, struct gf100_grctx *info)
+{
+   struct gf100_grctx_oclass *oclass = (void *)nv_engine(priv)->cclass;
+   int idle_timeout_save;
+   int i;
+
+   gf100_gr_mmio(priv, priv->fuc_sw_ctx);
+
+   gf100_gr_wait_idle(priv);
+
+   idle_timeout_save = nv_rd32(priv, 0x404154);
+   nv_wr32(priv, 0x404154, 0x);
+
+   oclass->attrib(info);
+
+   oclass->unkn(priv);
+
+   gf100_grctx_generate_tpcid(priv);
+   gf100_grctx_generate_r406028(priv);
+   gk104_grctx_generate_r418bb8(priv);
+   gf100_grctx_generate_r406800(priv);
+
+   for (i = 0; i < 8; i++)
+   nv_wr32(priv, 0x4064d0 + (i * 0x04), 0x);
+
+   nv_wr32(priv, 0x405b00, (priv->tpc_total << 8) | priv->gpc_nr);
+
+   gk104_grctx_generate_rop_active_fbps(priv);
+
+   nv_mask(priv, 0x5044b0, 0x800, 0x800);
+
+   gf100_gr_wait_idle(priv);
+
+   nv_wr32(priv, 0x404154, idle_timeout_save);
+   gf100_gr_wait_idle(priv);
+
+   gf100_gr_mthd(priv, priv->fuc_method);
+   gf100_gr_wait_idle(priv);

-static const struct gf100_gr_pack
-gk20a_grctx_pack_mthd[] = {
-   { gk104_grctx_init_a097_0, 0xa297 },
-   { gf100_grctx_init_902d_0, 0x902d },
-   {}
-};
+   gf100_gr_icmd(priv, priv->fuc_bundle);
+   oclass->pagepool(info);
+   oclass->bundle(info);
+}

 struct nvkm_oclass *
 gk20a_grctx_oclass = &(struct gf100_grctx_oclass) {
@@ -39,15 +81,8 @@ gk20a_grctx_oclass = &(struct gf100_grctx_oclass) {
.rd32 = _nvkm_gr_context_rd32,
.wr32 = _nvkm_gr_context_wr32,
},
-   .main  = gk104_grctx_generate_main,
+   .main  = gk20a_grctx_generate_main,
.unkn  = gk104_grctx_generate_unkn,
-   .hub   = gk104_grctx_pack_hub,
-   .gpc   = gk104_grctx_pack_gpc,
-   .zcull = gf100_grctx_pack_zcull,
-   .tpc   = gk104_grctx_pack_tpc,
-   .ppc   = gk104_grctx_pack_ppc,
-   .icmd  = gk104_grctx_pack_icmd,
-   .mthd  = gk20a_grctx_pack_mthd,
.bundle = gk104_grctx_generate_bundle,
.bundle_size = 0x1800,
.bundle_min_gpm_fifo_depth = 0x62,
diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c 
b/drm/nouveau/nvkm/engine/gr/gf100.c
index 39d482f..d5c148f 100644
--- a/drm/nouveau/nvkm/engine/gr/gf100.c
+++ b/drm/nouveau/nvkm/engine/gr/gf100.c
@@ -1537,7 +1537,7 @@ gf100_gr_init(struct nvkm_object *object)
return gf100_gr_init_ctxctl(priv);
 }

-static void
+void
 gf100_gr_dtor_fw(struct gf100_gr_fuc *fuc)
 {
kfree(fuc->data);
@@ -1719,6 +1719,7 @@ gf100_gr_ctor(struct nvkm_object *parent, struct 
nvkm_object *engine,
break;
case 0xd7:
case 0xd9: /* 1/0/0/0, 1 */
+   case 0xea: /* gk20a */
priv->magic_not_rop_nr = 0x01;
break;
}
diff --git a/drm/nouveau/nvkm/engine/gr/gf100.h 
b/drm/nouveau/nvkm/engine/gr/gf100.h
index c9533fd..af4d70f 100644
--- a/drm/nouveau/nvkm/engine/gr/gf100.h
+++ b/drm/nouveau/nvkm/engine/gr/gf100.h
@@ -76,6 +76,15 @@ struct gf100_gr_priv {
struct gf100_gr_fuc fuc41ad;
bool firmware;

+   /*
+* Used if the register packs are loaded from NVIDIA fw instead of
+* using hardcoded arrays.
+*/
+   struct gf100_gr_pack *fuc_sw_nonctx;
+   struct gf100_gr_pack *fuc_sw_ctx;
+   struct gf100_gr_pack *fuc_bundle;

[PATCH 3/6] fifo: add GM20B fifo

[Alexandre Courbot]

GM20B has a 512-channels FIFO similar to GK104.

Signed-off-by: Alexandre Courbot 
---
 drm/nouveau/include/nvkm/engine/fifo.h |  1 +
 drm/nouveau/nvkm/engine/fifo/Kbuild|  1 +
 drm/nouveau/nvkm/engine/fifo/gk104.h   |  4 
 drm/nouveau/nvkm/engine/fifo/gm204.c   |  2 +-
 drm/nouveau/nvkm/engine/fifo/gm20b.c   | 34 ++
 5 files changed, 41 insertions(+), 1 deletion(-)
 create mode 100644 drm/nouveau/nvkm/engine/fifo/gm20b.c

diff --git a/drm/nouveau/include/nvkm/engine/fifo.h 
b/drm/nouveau/include/nvkm/engine/fifo.h
index 97cdeab..9100b80 100644
--- a/drm/nouveau/include/nvkm/engine/fifo.h
+++ b/drm/nouveau/include/nvkm/engine/fifo.h
@@ -117,6 +117,7 @@ extern struct nvkm_oclass *gk104_fifo_oclass;
 extern struct nvkm_oclass *gk20a_fifo_oclass;
 extern struct nvkm_oclass *gk208_fifo_oclass;
 extern struct nvkm_oclass *gm204_fifo_oclass;
+extern struct nvkm_oclass *gm20b_fifo_oclass;

 int  nvkm_fifo_uevent_ctor(struct nvkm_object *, void *, u32,
   struct nvkm_notify *);
diff --git a/drm/nouveau/nvkm/engine/fifo/Kbuild 
b/drm/nouveau/nvkm/engine/fifo/Kbuild
index 42891cb..dc81a8b 100644
--- a/drm/nouveau/nvkm/engine/fifo/Kbuild
+++ b/drm/nouveau/nvkm/engine/fifo/Kbuild
@@ -10,3 +10,4 @@ nvkm-y += nvkm/engine/fifo/gk104.o
 nvkm-y += nvkm/engine/fifo/gk20a.o
 nvkm-y += nvkm/engine/fifo/gk208.o
 nvkm-y += nvkm/engine/fifo/gm204.o
+nvkm-y += nvkm/engine/fifo/gm20b.o
diff --git a/drm/nouveau/nvkm/engine/fifo/gk104.h 
b/drm/nouveau/nvkm/engine/fifo/gk104.h
index 318d30d..b77d75f 100644
--- a/drm/nouveau/nvkm/engine/fifo/gk104.h
+++ b/drm/nouveau/nvkm/engine/fifo/gk104.h
@@ -15,4 +15,8 @@ struct gk104_fifo_impl {
 };

 extern struct nvkm_ofuncs gk104_fifo_chan_ofuncs;
+
+int  gm204_fifo_ctor(struct nvkm_object *, struct nvkm_object *,
+   struct nvkm_oclass *, void *, u32,
+   struct nvkm_object **);
 #endif
diff --git a/drm/nouveau/nvkm/engine/fifo/gm204.c 
b/drm/nouveau/nvkm/engine/fifo/gm204.c
index 749d525..7596587 100644
--- a/drm/nouveau/nvkm/engine/fifo/gm204.c
+++ b/drm/nouveau/nvkm/engine/fifo/gm204.c
@@ -31,7 +31,7 @@ gm204_fifo_sclass[] = {
{}
 };

-static int
+int
 gm204_fifo_ctor(struct nvkm_object *parent, struct nvkm_object *engine,
struct nvkm_oclass *oclass, void *data, u32 size,
struct nvkm_object **pobject)
diff --git a/drm/nouveau/nvkm/engine/fifo/gm20b.c 
b/drm/nouveau/nvkm/engine/fifo/gm20b.c
new file mode 100644
index 000..4abf547
--- /dev/null
+++ b/drm/nouveau/nvkm/engine/fifo/gm20b.c
@@ -0,0 +1,34 @@
+/*
+ * Copyright (c) 2015, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+#include "gk104.h"
+
+struct nvkm_oclass *
+gm20b_fifo_oclass = &(struct gk104_fifo_impl) {
+   .base.handle = NV_ENGINE(FIFO, 0x2b),
+   .base.ofuncs = &(struct nvkm_ofuncs) {
+   .ctor = gm204_fifo_ctor,
+   .dtor = gk104_fifo_dtor,
+   .init = gk104_fifo_init,
+   .fini = gk104_fifo_fini,
+   },
+   .channels = 512,
+}.base;
-- 
2.4.3

[PATCH 4/6] gr: add GM20B support

[Alexandre Courbot]

Add support for GM20B's graphics engine, based on GK20A. Note that this
code alone will not allow the engine to initialize on released devices
which require PMU-assisted secure boot.

Signed-off-by: Alexandre Courbot 
---
 drm/nouveau/include/nvkm/engine/gr.h  |   1 +
 drm/nouveau/nvkm/engine/gr/Kbuild |   2 +
 drm/nouveau/nvkm/engine/gr/ctxgf100.h |   7 +++
 drm/nouveau/nvkm/engine/gr/ctxgm107.c |   2 +-
 drm/nouveau/nvkm/engine/gr/ctxgm204.c |   4 +-
 drm/nouveau/nvkm/engine/gr/ctxgm20b.c | 110 ++
 drm/nouveau/nvkm/engine/gr/gf100.c|   1 +
 drm/nouveau/nvkm/engine/gr/gf100.h|   6 ++
 drm/nouveau/nvkm/engine/gr/gk20a.c|   6 +-
 drm/nouveau/nvkm/engine/gr/gm20b.c|  84 ++
 10 files changed, 217 insertions(+), 6 deletions(-)
 create mode 100644 drm/nouveau/nvkm/engine/gr/ctxgm20b.c
 create mode 100644 drm/nouveau/nvkm/engine/gr/gm20b.c

diff --git a/drm/nouveau/include/nvkm/engine/gr.h 
b/drm/nouveau/include/nvkm/engine/gr.h
index 7cbe202..c772497 100644
--- a/drm/nouveau/include/nvkm/engine/gr.h
+++ b/drm/nouveau/include/nvkm/engine/gr.h
@@ -74,6 +74,7 @@ extern struct nvkm_oclass *gk208_gr_oclass;
 extern struct nvkm_oclass *gm107_gr_oclass;
 extern struct nvkm_oclass *gm204_gr_oclass;
 extern struct nvkm_oclass *gm206_gr_oclass;
+extern struct nvkm_oclass *gm20b_gr_oclass;

 #include 

diff --git a/drm/nouveau/nvkm/engine/gr/Kbuild 
b/drm/nouveau/nvkm/engine/gr/Kbuild
index 2e1b92f..e91b4df 100644
--- a/drm/nouveau/nvkm/engine/gr/Kbuild
+++ b/drm/nouveau/nvkm/engine/gr/Kbuild
@@ -14,6 +14,7 @@ nvkm-y += nvkm/engine/gr/ctxgk208.o
 nvkm-y += nvkm/engine/gr/ctxgm107.o
 nvkm-y += nvkm/engine/gr/ctxgm204.o
 nvkm-y += nvkm/engine/gr/ctxgm206.o
+nvkm-y += nvkm/engine/gr/ctxgm20b.o
 nvkm-y += nvkm/engine/gr/nv04.o
 nvkm-y += nvkm/engine/gr/nv10.o
 nvkm-y += nvkm/engine/gr/nv20.o
@@ -38,3 +39,4 @@ nvkm-y += nvkm/engine/gr/gk208.o
 nvkm-y += nvkm/engine/gr/gm107.o
 nvkm-y += nvkm/engine/gr/gm204.o
 nvkm-y += nvkm/engine/gr/gm206.o
+nvkm-y += nvkm/engine/gr/gm20b.o
diff --git a/drm/nouveau/nvkm/engine/gr/ctxgf100.h 
b/drm/nouveau/nvkm/engine/gr/ctxgf100.h
index 3676a33..f89ab37 100644
--- a/drm/nouveau/nvkm/engine/gr/ctxgf100.h
+++ b/drm/nouveau/nvkm/engine/gr/ctxgf100.h
@@ -91,6 +91,10 @@ void gk104_grctx_generate_r418bb8(struct gf100_gr_priv *);
 void gk104_grctx_generate_rop_active_fbps(struct gf100_gr_priv *);


+void gm107_grctx_generate_bundle(struct gf100_grctx *);
+void gm107_grctx_generate_pagepool(struct gf100_grctx *);
+void gm107_grctx_generate_attrib(struct gf100_grctx *);
+
 extern struct nvkm_oclass *gk110_grctx_oclass;
 extern struct nvkm_oclass *gk110b_grctx_oclass;
 extern struct nvkm_oclass *gk208_grctx_oclass;
@@ -102,8 +106,11 @@ void gm107_grctx_generate_attrib(struct gf100_grctx *);

 extern struct nvkm_oclass *gm204_grctx_oclass;
 void gm204_grctx_generate_main(struct gf100_gr_priv *, struct gf100_grctx *);
+void gm204_grctx_generate_tpcid(struct gf100_gr_priv *);
+void gm204_grctx_generate_405b60(struct gf100_gr_priv *);

 extern struct nvkm_oclass *gm206_grctx_oclass;
+extern struct nvkm_oclass *gm20b_grctx_oclass;

 /* context init value lists */

diff --git a/drm/nouveau/nvkm/engine/gr/ctxgm107.c 
b/drm/nouveau/nvkm/engine/gr/ctxgm107.c
index fbeaae3..6bf2fd1 100644
--- a/drm/nouveau/nvkm/engine/gr/ctxgm107.c
+++ b/drm/nouveau/nvkm/engine/gr/ctxgm107.c
@@ -931,7 +931,7 @@ gm107_grctx_generate_attrib(struct gf100_grctx *info)
}
 }

-static void
+void
 gm107_grctx_generate_tpcid(struct gf100_gr_priv *priv)
 {
int gpc, tpc, id;
diff --git a/drm/nouveau/nvkm/engine/gr/ctxgm204.c 
b/drm/nouveau/nvkm/engine/gr/ctxgm204.c
index ea8e661..efc76bf 100644
--- a/drm/nouveau/nvkm/engine/gr/ctxgm204.c
+++ b/drm/nouveau/nvkm/engine/gr/ctxgm204.c
@@ -918,7 +918,7 @@ gm204_grctx_pack_ppc[] = {
  * PGRAPH context implementation
  
**/

-static void
+void
 gm204_grctx_generate_tpcid(struct gf100_gr_priv *priv)
 {
int gpc, tpc, id;
@@ -943,7 +943,7 @@ gm204_grctx_generate_rop_active_fbps(struct gf100_gr_priv 
*priv)
nv_mask(priv, 0x408958, 0x000f, fbp_count); /* crop */
 }

-static void
+void
 gm204_grctx_generate_405b60(struct gf100_gr_priv *priv)
 {
const u32 dist_nr = DIV_ROUND_UP(priv->tpc_total, 4);
diff --git a/drm/nouveau/nvkm/engine/gr/ctxgm20b.c 
b/drm/nouveau/nvkm/engine/gr/ctxgm20b.c
new file mode 100644
index 000..c011bf3
--- /dev/null
+++ b/drm/nouveau/nvkm/engine/gr/ctxgm20b.c
@@ -0,0 +1,110 @@
+/*
+ * Copyright (c) 2015, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of th

[PATCH 5/6] device: recognize GM20B

[Alexandre Courbot]

Recognize GM20B and assign the right engines and subdevs.

Signed-off-by: Alexandre Courbot 
---
 drm/nouveau/nvkm/engine/device/gm100.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drm/nouveau/nvkm/engine/device/gm100.c 
b/drm/nouveau/nvkm/engine/device/gm100.c
index 70abf1e..a51b3ce 100644
--- a/drm/nouveau/nvkm/engine/device/gm100.c
+++ b/drm/nouveau/nvkm/engine/device/gm100.c
@@ -181,6 +181,26 @@ gm100_identify(struct nvkm_device *device)
device->oclass[NVDEV_ENGINE_MSPPP  ] = &gf100_msppp_oclass;
 #endif
break;
+   case 0x12b:
+   device->cname = "GM20B";
+
+   device->oclass[NVDEV_SUBDEV_MC ] =  gk20a_mc_oclass;
+   device->oclass[NVDEV_SUBDEV_MMU] = &gf100_mmu_oclass;
+   device->oclass[NVDEV_SUBDEV_BUS] =  gf100_bus_oclass;
+   device->oclass[NVDEV_SUBDEV_FUSE   ] = &gm107_fuse_oclass;
+   device->oclass[NVDEV_SUBDEV_TIMER  ] = &gk20a_timer_oclass;
+   device->oclass[NVDEV_SUBDEV_FB ] =  gk20a_fb_oclass;
+   device->oclass[NVDEV_SUBDEV_LTC] =  gm107_ltc_oclass;
+   device->oclass[NVDEV_SUBDEV_IBUS   ] = &gk20a_ibus_oclass;
+   device->oclass[NVDEV_SUBDEV_INSTMEM] = gk20a_instmem_oclass;
+   device->oclass[NVDEV_SUBDEV_MMU] = &gf100_mmu_oclass;
+   device->oclass[NVDEV_SUBDEV_BAR] = &gk20a_bar_oclass;
+   device->oclass[NVDEV_ENGINE_DMAOBJ ] =  gf110_dmaeng_oclass;
+   device->oclass[NVDEV_ENGINE_FIFO   ] =  gm20b_fifo_oclass;
+   device->oclass[NVDEV_ENGINE_SW ] =  gf100_sw_oclass;
+   device->oclass[NVDEV_ENGINE_GR ] =  gm20b_gr_oclass;
+   device->oclass[NVDEV_ENGINE_CE2] = &gm204_ce2_oclass;
+   break;
default:
nv_fatal(device, "unknown Maxwell chipset\n");
return -EINVAL;
-- 
2.4.3

[PATCH 6/6] platform: recognize GM20B

[Alexandre Courbot]

Allow the platform driver to recognize GM20B.

Signed-off-by: Alexandre Courbot 
---
 drm/nouveau/nouveau_platform.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drm/nouveau/nouveau_platform.c b/drm/nouveau/nouveau_platform.c
index dcfbbfa..7a39d44 100644
--- a/drm/nouveau/nouveau_platform.c
+++ b/drm/nouveau/nouveau_platform.c
@@ -252,6 +252,7 @@ static int nouveau_platform_remove(struct platform_device 
*pdev)
 #if IS_ENABLED(CONFIG_OF)
 static const struct of_device_id nouveau_platform_match[] = {
{ .compatible = "nvidia,gk20a" },
+   { .compatible = "nvidia,gm20b" },
{ }
 };

-- 
2.4.3

[PATCH] drm/msm/dp: use flags argument of devm_gpiod_get to set direction

[Emil Velikov]

On 16 June 2015 at 02:00, Rob Clark  wrote:
> On Mon, Jun 15, 2015 at 5:00 PM, Uwe Kleine-König
>  wrote:
>> On Tue, Jun 09, 2015 at 11:38:45AM +0200, Uwe Kleine-König wrote:
>>> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
>>> which appeared in v3.17-rc1, the gpiod_get* functions take an additional
>>> parameter that allows to specify direction and initial value for output.
>>>
>>> Use this to simplify the driver. Furthermore this is one caller less
>>> that stops us making the flags argument to gpiod_get*() mandatory.
>>>
>>> Signed-off-by: Uwe Kleine-König 
>> gentle ping.
>>
>> I intend to make the flags parameter mandatory for 4.3. So if this patch
>> doesn't make it in for 4.2-rc1 I'd like to take it as part of the
>> respective gpio change via the gpio tree.
>>
>> What's your plan regarding this change?
>
> I had planned to send a second pull request for 4.2 with some
> additional hdcp patches that depend on scm changes coming in via
> arm-soc tree for 4.2.. if that is ok, I can include this patch with
> that second pull req..  otherwise I'm ok with Dave applying it
> directly or you taking it in via gpio tree.  Either way is fine by me.
>
Mildly related:

Rob, would it make things a bit easier if we have you listed in
MAINTAINERS for the msm/freedreno driver ?

Uwe, you might have greater input if you explicitly CC the
{unofficial,} maintainer of the relevant driver. Some drivers don't
have one explicitly listed in MAINTAINERS, so git log tends to help
there :-)

Cheers,
Emil

[PATCH v2 04/10] drm: Add Gamma correction structure

[Emil Velikov]

On 14 June 2015 at 10:02, Sharma, Shashank  wrote:
> Hi, Emil Velikov
>
> The reason behind a zero sized array is that we want to use the same variable 
> for various color correction possible across various driver .
> Due to current blob implementation, it doesn’t look very efficient to have 
> another pointer in the structure, so we are left with this option only.
>
Can you elaborate (to suggest any reading material) about those inefficiencies ?

> I guess as long as we are using gcc (which is for all Linux distributions), 
> we are good. The size of the zero sized array will be zero, so no alignment 
> errors as such.
>
Note that most of the DRM subsystem code is dual-licensed. As such it
is used in other OSes - Solaris, *BSD, not to mention the work (in
progress) about using clang/LLVM to build the kernel. In the former
case not everyone uses GCC.

Thanks
Emil

[PATCH 4/5] drm/omap: fix omap_framebuffer_unpin() error handling

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 18 June 2015 13:10:38 Tomi Valkeinen wrote:
> omap_framebuffer_unpin() check the return value of omap_gem_put_paddr()
> and return immediately if omap_gem_put_paddr() fails.
> 
> This patch removes the check for the return value, and also removes the
> return value of omap_framebuffer_unpin(), because:
> 
>  * Nothing checks the return value of omap_framebuffer_unpin(), and even
>something did check it, there's nothing the caller can do to handle
>the error.
> 
>  * If a omap_gem_put_paddr() fails, the framebuffer's other planes will
>be left unreleased. So it's better to call omap_gem_put_paddr() for
>all the planes, even if one would fail.
> 
> Signed-off-by: Tomi Valkeinen 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_drv.h |  2 +-
>  drivers/gpu/drm/omapdrm/omap_fb.c  | 16 
>  2 files changed, 5 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
> b/drivers/gpu/drm/omapdrm/omap_drv.h index ae2df41f216f..2ef89c0c3006
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.h
> @@ -177,7 +177,7 @@ struct drm_framebuffer *omap_framebuffer_init(struct
> drm_device *dev, struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object
> **bos); struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer
> *fb, int p); int omap_framebuffer_pin(struct drm_framebuffer *fb);
> -int omap_framebuffer_unpin(struct drm_framebuffer *fb);
> +void omap_framebuffer_unpin(struct drm_framebuffer *fb);
>  void omap_framebuffer_update_scanout(struct drm_framebuffer *fb,
>   struct omap_drm_window *win, struct omap_overlay_info *info);
>  struct drm_connector *omap_framebuffer_get_next_connector(
> diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
> b/drivers/gpu/drm/omapdrm/omap_fb.c index 0b967e76df1a..51b1219af87f 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fb.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fb.c
> @@ -287,10 +287,10 @@ fail:
>  }
> 
>  /* unpin, no longer being scanned out: */
> -int omap_framebuffer_unpin(struct drm_framebuffer *fb)
> +void omap_framebuffer_unpin(struct drm_framebuffer *fb)
>  {
>   struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
> - int ret, i, n = drm_format_num_planes(fb->pixel_format);
> + int i, n = drm_format_num_planes(fb->pixel_format);
> 
>   mutex_lock(&omap_fb->lock);
> 
> @@ -298,24 +298,16 @@ int omap_framebuffer_unpin(struct drm_framebuffer *fb)
> 
>   if (omap_fb->pin_count > 0) {
>   mutex_unlock(&omap_fb->lock);
> - return 0;
> + return;
>   }
> 
>   for (i = 0; i < n; i++) {
>   struct plane *plane = &omap_fb->planes[i];
> - ret = omap_gem_put_paddr(plane->bo);
> - if (ret)
> - goto fail;
> + omap_gem_put_paddr(plane->bo);
>   plane->paddr = 0;
>   }
> 
>   mutex_unlock(&omap_fb->lock);
> -
> - return 0;
> -
> -fail:
> - mutex_unlock(&omap_fb->lock);
> - return ret;
>  }
> 
>  struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb, int
> p)

-- 
Regards,

Laurent Pinchart

[PATCH 5/5] drm/omap: fix omap_gem_put_paddr() error handling

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thursday 18 June 2015 13:10:39 Tomi Valkeinen wrote:
> If tiler_unpin() call in omap_gem_put_paddr() fails,
> omap_gem_put_paddr() will immediately stop processing and return an
> error.
> 
> This patch remoes that error checking, and also removes
> omap_gem_put_paddr()'s return value, because:
> 
>  * The caller of omap_gem_put_paddr() can do nothing if an error
>happens, so it's pointless to return an error value
> 
>  * If tiler_unpin() fails, the GEM object will possibly be left in an
>undefined state, where the DMM mapping may have been removed, but the
>GEM object still thinks everything is as it should be, leading to
>crashes later.
> 
>  * There's no point in returning an error from a "free" call, as the
>caller can do nothing about it. So it's better to clean up as much as
>possible.
> 
> Signed-off-by: Tomi Valkeinen 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_drv.h | 2 +-
>  drivers/gpu/drm/omapdrm/omap_gem.c | 8 +++-
>  2 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
> b/drivers/gpu/drm/omapdrm/omap_drv.h index 2ef89c0c3006..1ae8477e4289
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.h
> @@ -211,7 +211,7 @@ void omap_gem_dma_sync(struct drm_gem_object *obj,
>   enum dma_data_direction dir);
>  int omap_gem_get_paddr(struct drm_gem_object *obj,
>   dma_addr_t *paddr, bool remap);
> -int omap_gem_put_paddr(struct drm_gem_object *obj);
> +void omap_gem_put_paddr(struct drm_gem_object *obj);
>  int omap_gem_get_pages(struct drm_gem_object *obj, struct page ***pages,
>   bool remap);
>  int omap_gem_put_pages(struct drm_gem_object *obj);
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> b/drivers/gpu/drm/omapdrm/omap_gem.c index 51c5635aff62..d01d40245298
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> @@ -808,10 +808,10 @@ fail:
>  /* Release physical address, when DMA is no longer being performed.. this
>   * could potentially unpin and unmap buffers from TILER
>   */
> -int omap_gem_put_paddr(struct drm_gem_object *obj)
> +void omap_gem_put_paddr(struct drm_gem_object *obj)
>  {
>   struct omap_gem_object *omap_obj = to_omap_bo(obj);
> - int ret = 0;
> + int ret;
> 
>   mutex_lock(&obj->dev->struct_mutex);
>   if (omap_obj->paddr_cnt > 0) {
> @@ -821,7 +821,6 @@ int omap_gem_put_paddr(struct drm_gem_object *obj)
>   if (ret) {
>   dev_err(obj->dev->dev,
>   "could not unpin pages: %d\n", ret);
> - goto fail;
>   }
>   ret = tiler_release(omap_obj->block);
>   if (ret) {
> @@ -832,9 +831,8 @@ int omap_gem_put_paddr(struct drm_gem_object *obj)
>   omap_obj->block = NULL;
>   }
>   }
> -fail:
> +
>   mutex_unlock(&obj->dev->struct_mutex);
> - return ret;
>  }
> 
>  /* Get rotated scanout address (only valid if already pinned), at the

-- 
Regards,

Laurent Pinchart

[PATCH 0/3] drm/exynos: improve vidi refresh rate + async commit

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

The first patch in this series add support to async page flips, but it doesn't
improve the refresh rate when using vidi+fimd.

The second patch fixes an issue on vidi that solves the refresh rate issue when
only vidi is used. For the case where vidi + fimd is used it improves the
refresh rate from 20Hz to 28Hz. There is room to improve this more, but I think
these patches can already be pushed upstream.

It is important to remember that the low refresh rate issue only happens when
vidi is used along with another crtc. It doesn't happen in a setup that has only
FIMD and/or Mixer, thus most of use cases out there are not affected.

Gustavo

---
Gustavo Padovan (3):
  drm/exynos: add atomic asynchronous commit
  drm/exynos: vidi: always handle vblank on planes updates
  drm/exynos: pass the correct pipe number

 drivers/gpu/drm/exynos/exynos_drm_crtc.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  6 
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |  6 
 drivers/gpu/drm/exynos/exynos_drm_fb.c   | 51 +---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |  3 +-
 5 files changed, 55 insertions(+), 13 deletions(-)

-- 
2.1.0

[PATCH 1/3] drm/exynos: add atomic asynchronous commit

[Gustavo Padovan]

From: Gustavo Padovan 

The atomic modesetting interfaces supports async commits that should be
implemented by the drivers. If drm core requests an async commit
exynos_atomic_commit() will schedule a work task to run the update later.
It also waits to an update to finishes to schedule a new one.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |  6 
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  6 
 drivers/gpu/drm/exynos/exynos_drm_fb.c  | 51 ++---
 3 files changed, 52 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 591bdec..aafb419 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -47,6 +47,9 @@ static int exynos_drm_load(struct drm_device *dev, unsigned 
long flags)
if (!private)
return -ENOMEM;

+   INIT_WORK(&private->work, exynos_drm_atomic_work);
+   private->dev = dev;
+
dev_set_drvdata(dev->dev, dev);
dev->dev_private = (void *)private;

@@ -127,6 +130,8 @@ err_free_private:

 static int exynos_drm_unload(struct drm_device *dev)
 {
+   struct exynos_drm_private *private = dev->dev_private;
+
exynos_drm_device_subdrv_remove(dev);

exynos_drm_fbdev_fini(dev);
@@ -137,6 +142,7 @@ static int exynos_drm_unload(struct drm_device *dev)
drm_mode_config_cleanup(dev);
drm_release_iommu_mapping(dev);

+   flush_work(&private->work);
kfree(dev->dev_private);
dev->dev_private = NULL;

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a384569..e94d527 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -243,6 +243,10 @@ struct exynos_drm_private {
unsigned long da_space_size;

unsigned int pipe;
+
+   struct drm_device *dev;
+   struct work_struct work;
+   struct drm_atomic_state *state;
 };

 /*
@@ -295,6 +299,8 @@ static inline int exynos_dpi_remove(struct 
exynos_drm_display *display)
 }
 #endif

+void exynos_drm_atomic_work(struct work_struct *work);
+
 /* This function creates a encoder and a connector, and initializes them. */
 int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 789db6f..d1b28fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -267,20 +267,18 @@ static void exynos_drm_output_poll_changed(struct 
drm_device *dev)
exynos_drm_fbdev_init(dev);
 }

-static int exynos_atomic_commit(struct drm_device *dev,
-   struct drm_atomic_state *state,
-   bool async)
+static void exynos_atomic_commit_schedule(struct drm_device *dev,
+   struct drm_atomic_state *state)
 {
-   int ret;
-
-   ret = drm_atomic_helper_prepare_planes(dev, state);
-   if (ret)
-   return ret;
-
-   /* This is the point of no return */
+   struct exynos_drm_private *private = dev->dev_private;

-   drm_atomic_helper_swap_state(dev, state);
+   private->state = state;
+   schedule_work(&private->work);
+}

+static void exynos_atomic_commit_complete(struct drm_device *dev,
+ struct drm_atomic_state *state)
+{
drm_atomic_helper_commit_modeset_disables(dev, state);

drm_atomic_helper_commit_modeset_enables(dev, state);
@@ -300,6 +298,37 @@ static int exynos_atomic_commit(struct drm_device *dev,
drm_atomic_helper_cleanup_planes(dev, state);

drm_atomic_state_free(state);
+}
+
+void exynos_drm_atomic_work(struct work_struct *work)
+{
+   struct exynos_drm_private *private = container_of(work,
+   struct exynos_drm_private, work);
+
+   exynos_atomic_commit_complete(private->dev, private->state);
+}
+
+static int exynos_atomic_commit(struct drm_device *dev,
+   struct drm_atomic_state *state,
+   bool async)
+{
+   struct exynos_drm_private *private = dev->dev_private;
+   int ret;
+
+   ret = drm_atomic_helper_prepare_planes(dev, state);
+   if (ret)
+   return ret;
+
+   /* This is the point of no return */
+
+   flush_work(&private->work);
+
+   drm_atomic_helper_swap_state(dev, state);
+
+   if (async)
+   exynos_atomic_commit_schedule(dev, state);
+   else
+   exynos_atomic_commit_complete(dev, state);

return 0;
 }
-- 
2.1.0

[PATCH 2/3] drm/exynos: vidi: always handle vblank on planes updates

[Gustavo Padovan]

From: Gustavo Padovan 

We need to call drm_handle_vblank() after each successful plane update
to update vblank counter and send the necessary events.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3413393..4706d45 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -193,10 +193,11 @@ static void vidi_fake_vblank_handler(struct work_struct 
*work)
/* refresh rate is about 50Hz. */
usleep_range(16000, 2);

+   drm_handle_vblank(ctx->drm_dev, ctx->pipe);
+
mutex_lock(&ctx->lock);

if (ctx->direct_vblank) {
-   drm_handle_vblank(ctx->drm_dev, ctx->pipe);
ctx->direct_vblank = false;
mutex_unlock(&ctx->lock);
return;
-- 
2.1.0

[PATCH 3/3] drm/exynos: pass the correct pipe number

[Gustavo Padovan]

From: Gustavo Padovan 

Instead of giving -1 to as arg to  drm_send_vblank_event() pass the
correct pipe number to it.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 644b4b7..22b9ca0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -203,7 +203,7 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
*dev, int pipe)
spin_lock_irqsave(&dev->event_lock, flags);
if (exynos_crtc->event) {

-   drm_send_vblank_event(dev, -1, exynos_crtc->event);
+   drm_send_vblank_event(dev, pipe, exynos_crtc->event);
drm_vblank_put(dev, pipe);
wake_up(&exynos_crtc->pending_flip_queue);

-- 
2.1.0

[Intel-gfx] [PATCH] drm: Avoid the double clflush on the last cache line in drm_clflush_virt_range()

[Imre Deak]

On to, 2015-06-11 at 09:33 +0100, Chris Wilson wrote:
> On Thu, Jun 11, 2015 at 09:25:16AM +0100, Dave Gordon wrote:
> > On 10/06/15 15:58, Chris Wilson wrote:
> > > As the clflush operates on cache lines, and we can flush any byte
> > > address, in order to flush all bytes given in the range we issue an
> > > extra clflush on the last byte to ensure the last cacheline is flushed.
> > > We can can the iteration to be over the actual cache lines to avoid this
> > > double clflush on the last byte.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/drm_cache.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> > > index 9a62d7a53553..6743ff7dccfa 100644
> > > --- a/drivers/gpu/drm/drm_cache.c
> > > +++ b/drivers/gpu/drm/drm_cache.c
> > > @@ -130,11 +130,12 @@ drm_clflush_virt_range(void *addr, unsigned long 
> > > length)
> > >  {
> > >  #if defined(CONFIG_X86)
> > >   if (cpu_has_clflush) {
> > > + const int size = boot_cpu_data.x86_clflush_size;
> > >   void *end = addr + length;
> > > + addr = (void *)(((unsigned long)addr) & -size);
> > 
> > Should this cast be to uintptr_t?
> 
> The kernel has a strict equivalence between sizeof(unsigned long) and
> sizeof(pointer). You will see unsigned long used universally to pass
> along pointers to functions and as closures.
> 
> > Or intptr_t, as size has somewhat
> > strangely been defined as signed? To complete the mix, x86_clflush_size
> > is 'u16'! So maybe we should write
> > 
> > +   const size_t size = boot_cpu_data.x86_clflush_size;
> > +   const size_t mask = ~(size - 1);
> > void *end = addr + length;
> > +   addr = (void *)(((uintptr_t)addr) & mask);
> 
> No. size_t has very poor definition inside the kernel - what does the
> maximum size of a userspace allocation have to do with kernel internals?
> 
> Let's keep userspace types in userspace, or else we end up with
> i915_gem_gtt.c.

I also think using unsigned long for virtual addresses is standard in
the kernel and I can't see how using int would lead to problems given
the expected range of x86_clflush_size, so this looks ok to me:
Reviewed-by: Imre Deak 

> -Chris
> 

[Intel-gfx] [PATCH] drm: Avoid the double clflush on the last cache line in drm_clflush_virt_range()

[Daniel Vetter]

On Thu, Jun 18, 2015 at 06:31:18PM +0300, Imre Deak wrote:
> On to, 2015-06-11 at 09:33 +0100, Chris Wilson wrote:
> > On Thu, Jun 11, 2015 at 09:25:16AM +0100, Dave Gordon wrote:
> > > On 10/06/15 15:58, Chris Wilson wrote:
> > > > As the clflush operates on cache lines, and we can flush any byte
> > > > address, in order to flush all bytes given in the range we issue an
> > > > extra clflush on the last byte to ensure the last cacheline is flushed.
> > > > We can can the iteration to be over the actual cache lines to avoid this
> > > > double clflush on the last byte.
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: Imre Deak 
> > > > ---
> > > >  drivers/gpu/drm/drm_cache.c | 5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> > > > index 9a62d7a53553..6743ff7dccfa 100644
> > > > --- a/drivers/gpu/drm/drm_cache.c
> > > > +++ b/drivers/gpu/drm/drm_cache.c
> > > > @@ -130,11 +130,12 @@ drm_clflush_virt_range(void *addr, unsigned long 
> > > > length)
> > > >  {
> > > >  #if defined(CONFIG_X86)
> > > > if (cpu_has_clflush) {
> > > > +   const int size = boot_cpu_data.x86_clflush_size;
> > > > void *end = addr + length;
> > > > +   addr = (void *)(((unsigned long)addr) & -size);
> > > 
> > > Should this cast be to uintptr_t?
> > 
> > The kernel has a strict equivalence between sizeof(unsigned long) and
> > sizeof(pointer). You will see unsigned long used universally to pass
> > along pointers to functions and as closures.
> > 
> > > Or intptr_t, as size has somewhat
> > > strangely been defined as signed? To complete the mix, x86_clflush_size
> > > is 'u16'! So maybe we should write
> > > 
> > > + const size_t size = boot_cpu_data.x86_clflush_size;
> > > + const size_t mask = ~(size - 1);
> > >   void *end = addr + length;
> > > + addr = (void *)(((uintptr_t)addr) & mask);
> > 
> > No. size_t has very poor definition inside the kernel - what does the
> > maximum size of a userspace allocation have to do with kernel internals?
> > 
> > Let's keep userspace types in userspace, or else we end up with
> > i915_gem_gtt.c.
> 
> I also think using unsigned long for virtual addresses is standard in
> the kernel and I can't see how using int would lead to problems given
> the expected range of x86_clflush_size, so this looks ok to me:
> Reviewed-by: Imre Deak 

Applied to drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

[Russell King - ARM Linux]

On Thu, Jun 18, 2015 at 08:26:39AM -0700, Doug Anderson wrote:
> Russell,
> 
> On Thu, Jun 18, 2015 at 1:53 AM, Russell King - ARM Linux
>  wrote:
> >> OK, so clearly my patch won't work against mainline.  I guess it's a
> >> good thing that I pointed out that it was only tested locally (would
> >> have been better to test against mainline, but I don't think that's so
> >> easy since there are several unlanded patches in mainline for
> >> Rockchip).
> >
> > As far as I'm aware, Freescale's original BSP version was the same, as is
> > their later BSPs, and Jon's maintained 3.14-stable kernel.
> 
> Was "the same"?  You mean was untested, or was 3.14?

I'm saying that the mdvi thing behaves the same in all the kernel sources
I've seen of this driver, and I'm unaware of anything that changes it -
and I've been looking at Jon's 3.14-stable kernels as well as Freescale's
git repository.

> >> As pointed out by others at , locally
> >> our kernel has a slightly older version of
> >> , which would change mdvi to be
> >> as needed.
> >
> > Please don't post unreliable lkml.org URLs, please use some other archive
> > site.  I can't access this URL at the moment.
> 
> Perhaps you can try 

Something like that needs to be done, but let's get rid of the mdvi
thing in struct hdmi_vmode - it doesn't belong there, it isn't part
of the currently set video mode, but becomes a property of the
connected sink.

I'd also prefer it to be called "is_dvi_sink", especially as its
function is changing from "is it a CEA mode" to "is the attached
device a DVI sink".

Even better would be to call it "is_hdmi_sink" to maintain positive
logic with single-negation where required, rather than double-
negation in places.

> >> ...so I guess my change is blocked on someone reviewing/landing that
> >> series.  If that series is rejected (or is changed sufficiently so
> >> that mdvi no longer is set via drm_detect_hdmi_monitor() then my patch
> >> will need to be re-spun.
> >
> > That's not what I said.  I said mdvi is set according to whether the mode
> > being set is a CEA mode or not.
> 
> Perhaps now that you can access the patch with the patchwork link you
> can re-read my email.  If/when that patch lands then mdvi _will_ be
> set as per drm_detect_hdmi_monitor().

Well, I object to that patch (see above.)

> I am nowhere near an HDMI expert.  If you have a better suggestion
> then I'm more than happy for you to post it and drop my patch.  In my
> non-expert opinion, it would seem awfully strange for an AV receiver
> to modify the EDID though unless it was actively interpreting the
> signal and generating a whole new signal on the other end.  In any
> case, perhaps you can find such a device and that will give insight to
> how we should deal with it.  Until such a device is found, it seems
> fruitless to speculate.

Neither am I, but I have had the ability to do some testing with AV
receivers in the path of a HDMI device, and I've seen how they behave.
(I made copious notes on this, which I intend to publish when I have
a round tuit.)  Unfortunately, I have no DVI devices to test with,
and DVI devices are a dying breed - most monitors today come with
HDMI sockets instead.

> Personally, I was pointed at "drivers/gpu/drm/i915/intel_hdmi.c".  If
> you look there you will find a similar bit of code.

Yea, I've also been using that for inspiration too, but I put personal
testing above what's in someone elses driver. :)

> To summarize: I am not planning to spin my patch.  I am hopeful that
> folks could review Yakir's series.  Would it help if he re-sent it
> with different people in the "To" line?

That's a shame... I'm not inclined to Ack it as-is - and I'd also like
to see Yakir's patch reworked as I mentioned above.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[Nouveau] [PATCH 1/6] gr: support for NVIDIA-provided firmwares

[Ilia Mirkin]

Why did you change request_firmware to request_firmware_direct?

On Thu, Jun 18, 2015 at 10:47 AM, Alexandre Courbot  wrote:
> NVIDIA will officially start providing signed firmwares through
> linux-firmware. Change the GR firmware lookup function to look them up
> in addition to the extracted firmwares.
>
> Signed-off-by: Alexandre Courbot 
> ---
>  drm/nouveau/nvkm/engine/gr/gf100.c | 66 
> +-
>  1 file changed, 51 insertions(+), 15 deletions(-)
>
> diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c 
> b/drm/nouveau/nvkm/engine/gr/gf100.c
> index ca11ddb..39d482f 100644
> --- a/drm/nouveau/nvkm/engine/gr/gf100.c
> +++ b/drm/nouveau/nvkm/engine/gr/gf100.c
> @@ -1544,26 +1544,62 @@ gf100_gr_dtor_fw(struct gf100_gr_fuc *fuc)
> fuc->data = NULL;
>  }
>
> +/**
> + * gf100_gr_ctor_fw - helper for loading external GR firmwares
> + *
> + * A firmware can either be officially provided by NVIDIA (in which case it 
> will
> + * use a "NVIDIA name", or be extracted from the binary blob (and use a
> + * "Nouveau name". The fwname and nvfwname are to be given the Nouveau and
> + * NVIDIA names of a given firmware, respectively. This function will then
> + * try to load the NVIDIA firmware, then the extracted one, in that order.
> + *
> + */
>  int
>  gf100_gr_ctor_fw(struct gf100_gr_priv *priv, const char *fwname,
> -struct gf100_gr_fuc *fuc)
> +const char *nvfwname, struct gf100_gr_fuc *fuc)
>  {
> struct nvkm_device *device = nv_device(priv);
> const struct firmware *fw;
> -   char f[32];
> -   int ret;
> +   char f[64];
> +   int ret = -EINVAL;
> +   int i;
>
> -   snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset, fwname);
> -   ret = request_firmware(&fw, f, nv_device_base(device));
> -   if (ret) {
> -   snprintf(f, sizeof(f), "nouveau/%s", fwname);
> -   ret = request_firmware(&fw, f, nv_device_base(device));
> -   if (ret) {
> -   nv_error(priv, "failed to load %s\n", fwname);
> -   return ret;
> +   /*
> +* NVIDIA firmware name provided - try to load it
> +* We try this first since most chips that require external firmware
> +* are supported by NVIDIA
> +*/
> +   if (nvfwname) {
> +   snprintf(f, sizeof(f), "nvidia/%s/%s.bin", device->cname,
> +nvfwname);
> +   i = strlen(f);
> +   while (i) {
> +   --i;
> +   f[i] = tolower(f[i]);
> }
> +   ret = request_firmware_direct(&fw, f, nv_device_base(device));
> +   if (!ret)
> +   goto found;
> +   }
> +
> +   /* Nouveau firmware name provided - try to load it */
> +   if (fwname) {
> +   snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset,
> +fwname);
> +   ret = request_firmware_direct(&fw, f, nv_device_base(device));
> +   if (!ret)
> +   goto found;
> +
> +   snprintf(f, sizeof(f), "nouveau/%s", fwname);
> +   ret = request_firmware_direct(&fw, f, nv_device_base(device));
> +   if (!ret)
> +   goto found;
> }
>
> +   nv_error(priv, "failed to load %s / %s\n", fwname, nvfwname);
> +   return ret;
> +
> +found:
> fuc->size = fw->size;
> fuc->data = kmemdup(fw->data, fuc->size, GFP_KERNEL);
> release_firmware(fw);
> @@ -1615,10 +1651,10 @@ gf100_gr_ctor(struct nvkm_object *parent, struct 
> nvkm_object *engine,
>
> if (use_ext_fw) {
> nv_info(priv, "using external firmware\n");
> -   if (gf100_gr_ctor_fw(priv, "fuc409c", &priv->fuc409c) ||
> -   gf100_gr_ctor_fw(priv, "fuc409d", &priv->fuc409d) ||
> -   gf100_gr_ctor_fw(priv, "fuc41ac", &priv->fuc41ac) ||
> -   gf100_gr_ctor_fw(priv, "fuc41ad", &priv->fuc41ad))
> +   if (gf100_gr_ctor_fw(priv, "fuc409c", "fecs_inst", 
> &priv->fuc409c) ||
> +   gf100_gr_ctor_fw(priv, "fuc409d", "fecs_data", 
> &priv->fuc409d) ||
> +   gf100_gr_ctor_fw(priv, "fuc41ac", "gpccs_inst", 
> &priv->fuc41ac) ||
> +   gf100_gr_ctor_fw(priv, "fuc41ad", "gpccs_data", 
> &priv->fuc41ad))
> return -ENODEV;
> priv->firmware = true;
> }
> --
> 2.4.3
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

[Russell King - ARM Linux]

On Thu, Jun 18, 2015 at 04:55:45PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 18, 2015 at 08:26:39AM -0700, Doug Anderson wrote:
> > Perhaps you can try 
> 
> Something like that needs to be done, but let's get rid of the mdvi
> thing in struct hdmi_vmode - it doesn't belong there, it isn't part
> of the currently set video mode, but becomes a property of the
> connected sink.
> 
> I'd also prefer it to be called "is_dvi_sink", especially as its
> function is changing from "is it a CEA mode" to "is the attached
> device a DVI sink".
> 
> Even better would be to call it "is_hdmi_sink" to maintain positive
> logic with single-negation where required, rather than double-
> negation in places.

This is actually a _very_ important point.  Changing the function of
mdvi when it's used in multiple places throughout the driver is not on -
it's too big a change:

/*check csc whether needed activated in HDMI mode */
cscon = (is_color_space_conversion(hdmi) &&
!hdmi->hdmi_data.video_mode.mdvi);

inv_val |= (vmode->mdvi ?
HDMI_FC_INVIDCONF_DVI_MODEZ_DVI_MODE :
HDMI_FC_INVIDCONF_DVI_MODEZ_HDMI_MODE);

if (hdmi->cable_plugin && !hdmi->hdmi_data.video_mode.mdvi)
hdmi_enable_overflow_interrupts(hdmi);

It's unclear what the effect would be to change the meaning of mdvi
from "this is a CEA mode" to "the attached device is DVI" in all these
locations, and it's just not on to do this in a patch which merely
says:

   If the monitor support audio, so we should support audio for it, even if
   the display resolution is No-CEA mode.

In other words, doesn't even describe this change.

In any case, this patch has been dropped from more recent audio driver
series.

So, what I'd like to see is a patch series which starts with the change
below, and builds on that, with explainations why each change is needed.
This is important, as this is shared IP, and we need to make sure that
we don't regress non-Rockchip users of this IP.  I'll try and do some
work in this area if nothing crops up in the next month.

 drivers/gpu/drm/bridge/dw_hdmi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 49cafb61d290..8834e8142ea6 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -119,6 +119,8 @@ struct dw_hdmi {

u8 edid[HDMI_EDID_LEN];
bool cable_plugin;
+   bool sink_is_hdmi;
+   bool sink_has_audio;

bool phy_enabled;
struct drm_display_mode previous_mode;
@@ -1402,6 +1404,9 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)

edid = drm_get_edid(connector, hdmi->ddc);
if (edid) {
+   hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
+   hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
+
dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
edid->width_cm, edid->height_cm);



-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

[Doug Anderson]

Russell,

On Thu, Jun 18, 2015 at 9:09 AM, Russell King - ARM Linux
 wrote:
> So, what I'd like to see is a patch series which starts with the change
> below, and builds on that, with explainations why each change is needed.
> This is important, as this is shared IP, and we need to make sure that
> we don't regress non-Rockchip users of this IP.  I'll try and do some
> work in this area if nothing crops up in the next month.

OK.  I've mostly been jumping in here to do a bugfix or two, not to
take over maintenance of the driver.  My general policy is to submit
things upstream if at all possible, but I think in the case of HDMI we
are just too different from upstream for this to be easy.

I'll let you and Yakir figure out the way forward to keep everyone
happy.  If that means you submitting some patches then great.  If that
means Yakir submitting some patches then that's great too.  In such a
case you can consider my patch to be a bug report and I'll be happy
with folks figure out the proper way to do this in the upstream
driver.  :)

-Doug

[RFC PATCH] Trim 1204 bytes from gm204_grctx_generate_405b60 stack frame

[George Spelvin]

This function keeps causing the kernel build to whine at me about
its 1200 byte stack frame.

(TPC_MAC = 8 * GPC_MAX = 8 * 32 = 256)

The following generates the same nv_wr32() operations in the same
order as the original, but without the 256-word dist[] array.

(I'm not sure if 4-bit fields inside the dist bytes can accomodate
priv->gpc_nr greater than 16, so the other arrays could have halved
in size, too, but that's a separate issue.)

I don't have the necessary hardware to test this, but would
someone mind doing so?

(If you want to declare *priv const while you're at it, I'm not likely
to object.)

Signed-off-by: George Spelvin 
---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c
index ea8e6615..00aa4a8b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c
@@ -946,8 +946,7 @@ gm204_grctx_generate_rop_active_fbps(struct gf100_gr_priv 
*priv)
 static void
 gm204_grctx_generate_405b60(struct gf100_gr_priv *priv)
 {
-   const u32 dist_nr = DIV_ROUND_UP(priv->tpc_total, 4);
-   u32 dist[TPC_MAX] = {};
+   u32 dist = 0;
u32 gpcs[GPC_MAX] = {};
u8  tpcnr[GPC_MAX];
int tpc, gpc, i;
@@ -964,12 +963,16 @@ gm204_grctx_generate_405b60(struct gf100_gr_priv *priv)
} while(!tpcnr[gpc]);
tpc = priv->tpc_nr[gpc] - tpcnr[gpc]--;

-   dist[i / 4] |= ((gpc << 4) | tpc) << ((i % 4) * 8);
+   dist |= ((gpc << 4) | tpc) << ((i % 4) * 8);
+   if ((i % 4) == 3) {
+   nv_wr32(priv, 0x405b60 + i - 3, dist);
+   dist = 0;
+   }
gpcs[gpc] |= i << (tpc * 8);
}
+   if (i % 4)
+   nv_wr32(priv, 0x405b60 + round_down(i, 4), dist);

-   for (i = 0; i < dist_nr; i++)
-   nv_wr32(priv, 0x405b60 + (i * 4), dist[i]);
for (i = 0; i < priv->gpc_nr; i++)
nv_wr32(priv, 0x405ba0 + (i * 4), gpcs[i]);
 }

[PATCH 9/9] [media] mm: Move get_vaddr_frames() behind a config option

[Jan Kara]

On Wed 10-06-15 09:37:20, Josh Triplett wrote:
> On Wed, Jun 10, 2015 at 06:20:52AM -0300, Mauro Carvalho Chehab wrote:
> > From: Jan Kara 
> > 
> > get_vaddr_frames() is used by relatively rare drivers so hide it and the
> > related functions behind a config option that is selected only by
> > drivers that need the infrastructure.
> > 
> > Suggested-by: Andrew Morton 
> > 
> > Signed-off-by: Jan Kara 
> > Signed-off-by: Hans Verkuil 
> > Signed-off-by: Mauro Carvalho Chehab 
> 
> Seems sensible to me.
> 
> Since this patch makes the kernel smaller, can you include the delta
> from bloat-o-meter between allnoconfig with and without this patch?

The results are:

add/remove: 0/6 grow/shrink: 0/0 up/down: 0/-868 (-868)
function old new   delta
frame_vector_destroy  55   - -55
frame_vector_to_pfns  56   - -56
frame_vector_create   81   - -81
put_vaddr_frames  93   - -93
frame_vector_to_pages 98   - -98
get_vaddr_frames 485   --485

I've added it to the changelog of the patch.

> Also, I assume you've compile-tested the kernel with allyesconfig minus
> the three options that now have "select FRAME_VECTOR", to make sure it
> builds?
  I did not because the config option VIDEOBUF2_MEMOPS is a virtual one
selected transitively by quite a few video drivers and I didn't bother with
tracking down all of them... But since that config option guards
compilation of the code I modified I'm pretty confident I got it right.

Honza

> >  create mode 100644 mm/frame_vector.c
> > 
> > diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> > index 0a6780367d28..fc678289cf79 100644
> > --- a/drivers/gpu/drm/exynos/Kconfig
> > +++ b/drivers/gpu/drm/exynos/Kconfig
> > @@ -71,6 +71,7 @@ config DRM_EXYNOS_VIDI
> >  config DRM_EXYNOS_G2D
> > bool "Exynos DRM G2D"
> > depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_G2D
> > +   select FRAME_VECTOR
> > help
> >   Choose this option if you want to use Exynos G2D for DRM.
> >  
> > diff --git a/drivers/media/platform/omap/Kconfig 
> > b/drivers/media/platform/omap/Kconfig
> > index dc2aaab54aef..217d613b0fe7 100644
> > --- a/drivers/media/platform/omap/Kconfig
> > +++ b/drivers/media/platform/omap/Kconfig
> > @@ -10,6 +10,7 @@ config VIDEO_OMAP2_VOUT
> > select OMAP2_DSS if HAS_IOMEM && ARCH_OMAP2PLUS
> > select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
> > select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT && OMAP2_VRFB
> > +   select FRAME_VECTOR
> > default n
> > ---help---
> >   V4L2 Display driver support for OMAP2/3 based boards.
> > diff --git a/drivers/media/v4l2-core/Kconfig 
> > b/drivers/media/v4l2-core/Kconfig
> > index f7a01a72eb9e..f38f6e387f04 100644
> > --- a/drivers/media/v4l2-core/Kconfig
> > +++ b/drivers/media/v4l2-core/Kconfig
> > @@ -73,6 +73,7 @@ config VIDEOBUF2_CORE
> >  
> >  config VIDEOBUF2_MEMOPS
> > tristate
> > +   select FRAME_VECTOR
> >  
> >  config VIDEOBUF2_DMA_CONTIG
> > tristate
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 390214da4546..2ca52e9986f0 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -635,3 +635,6 @@ config MAX_STACK_SIZE_MB
> >   changed to a smaller value in which case that is used.
> >  
> >   A sane initial value is 80 MB.
> > +
> > +config FRAME_VECTOR
> > +   bool
> > diff --git a/mm/Makefile b/mm/Makefile
> > index 98c4eaeabdcb..be5d5c866305 100644
> > --- a/mm/Makefile
> > +++ b/mm/Makefile
> > @@ -78,3 +78,4 @@ obj-$(CONFIG_CMA) += cma.o
> >  obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o
> >  obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o
> >  obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o
> > +obj-$(CONFIG_FRAME_VECTOR) += frame_vector.o
> > diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> > new file mode 100644
> > index ..31a2bd5f41d5
> > --- /dev/null
> > +++ b/mm/frame_vector.c
> > @@ -0,0 +1,232 @@
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/*
> > + * get_vaddr_frames() - map virtual addresses to pfns
> > + * @start: starting user address
> > + * @nr_frames: number of pages / pfns from start to map
> > + * @write: whether pages will be written to by the caller
> > + * @force: whether to force write access even if user mapping is
> > + * readonly. See description of the same argument of
> > +   get_user_pages().
> > + * @vec:   structure which receives pages / pfns of the addresses mapped.
> > + * It should have space for at least nr_frames entries.
> > + *
> > + * This function maps virtual addresses from @start and fills @vec 
> > structure
> > + * with page frame numbers or page pointers to corresponding pages (choice
> > + * d

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

[Doug Anderson]

Russell,

On Thu, Jun 18, 2015 at 1:53 AM, Russell King - ARM Linux
 wrote:
>> OK, so clearly my patch won't work against mainline.  I guess it's a
>> good thing that I pointed out that it was only tested locally (would
>> have been better to test against mainline, but I don't think that's so
>> easy since there are several unlanded patches in mainline for
>> Rockchip).
>
> As far as I'm aware, Freescale's original BSP version was the same, as is
> their later BSPs, and Jon's maintained 3.14-stable kernel.

Was "the same"?  You mean was untested, or was 3.14?  It is probably
not the same "3.14 with backports" that I'm testing on, which includes
backports + things from the mailing list that haven't landed yet, as
many of the unlanded patches are things that make Rockchip HDMI work
more correctly.  Perhaps I should have called my tree "3.14 with
backports + unlanded patches" or "the chromeos 3.14 tree" to make it
clearer.

In general I haven't been posting patches that I've made to HDMI since
it appears that our tree has significant differences from mainline.
In this case the function I was touching looked identical to mainline
so I figured posting a patch seemed reasonable.


>> As pointed out by others at , locally
>> our kernel has a slightly older version of
>> , which would change mdvi to be
>> as needed.
>
> Please don't post unreliable lkml.org URLs, please use some other archive
> site.  I can't access this URL at the moment.

Perhaps you can try 


>> ...so I guess my change is blocked on someone reviewing/landing that
>> series.  If that series is rejected (or is changed sufficiently so
>> that mdvi no longer is set via drm_detect_hdmi_monitor() then my patch
>> will need to be re-spun.
>
> That's not what I said.  I said mdvi is set according to whether the mode
> being set is a CEA mode or not.

Perhaps now that you can access the patch with the patchwork link you
can re-read my email.  If/when that patch lands then mdvi _will_ be
set as per drm_detect_hdmi_monitor().


> A thought occurs to me this morning though: what happens if you connect
> a DVI monitor to an AV receiver which is then connected to this device.
> Does the resulting EDID contain the HDMI vendor ID?  If it does, it
> means that drm_detect_hdmi_monitor() will return true, indicating that
> the connected device is HDMI, and we will still allow modes greater than
> 165MHz.

I am nowhere near an HDMI expert.  If you have a better suggestion
then I'm more than happy for you to post it and drop my patch.  In my
non-expert opinion, it would seem awfully strange for an AV receiver
to modify the EDID though unless it was actively interpreting the
signal and generating a whole new signal on the other end.  In any
case, perhaps you can find such a device and that will give insight to
how we should deal with it.  Until such a device is found, it seems
fruitless to speculate.

Personally, I was pointed at "drivers/gpu/drm/i915/intel_hdmi.c".  If
you look there you will find a similar bit of code.


To summarize: I am not planning to spin my patch.  I am hopeful that
folks could review Yakir's series.  Would it help if he re-sent it
with different people in the "To" line?

Maybe when Yakir spins his series next he can include my patch?


-Doug

[PATCH] nvidia/noveau: Fix color mask

[Michael Büsch]

On Wed, 17 Jun 2015 20:47:17 -0400
Ilia Mirkin  wrote:

> On Wed, Jun 17, 2015 at 1:05 PM, Michael Büsch  wrote:
> > The expression (~0 >> x) will always yield all-ones, because the right
> > shift is an arithmetic right shift that will always shift ones in.
> > Accordingly ~(~0 >> x) will always be zero.
> > Hence 'mask' will always be zero in this case.
> >
> > Fix this by forcing a logical right shift instead of an arithmetic
> > right shift by using an unsigned int constant.
> >
> > Signed-off-by: Michael Buesch 
> 
> Confirmed that this does indeed happen with
> 
> #include 
> int main(int argc, char *argv[]) {
>   unsigned mask = ~(~0 >> (32 - (argv[1][0] - '0')));
>   printf("%08x\n", mask);
> }
> 
> I guess fbdev/nvidia/nv_accel.c was the source of all this, as the
> code is identical, and it probably came first.


If anybody is able to help me in creating a working semantic patch
(coccinelle) for this, that would be great.

I found this using a very hacky and incorrect spatch (some
version is attached). It throws many false positives, doesn't find all
such bugs and does not create correct patch output (especially the
#define related rule is just meant as a hint).

Some basic thoughts that come to mind that could possibly be statically
checked somehow are:

- right shift of promoted variables. That is stuff like this:
  u8 x, y = 0x0F;
  x = ~y >> 1;
  /* x is 0xF8, not 0x78 as someone might expect. */
- Also check this for typedef'ed types where promotion takes place (that
  are smaller than int)?
- right shift of signed constants (like in this case). That probably is
  wrong in most cases.
  How to check signedness of constants in spatch? (123 vs 123U)
  Is that even possible?
- Also detect this stuff, if variables/constants are hidden via #define
  or such:
  #define REGVAL0x0F
  writereg(REGISTER, ~REGVAL >> 1);

Probably more stuff could be checked. Ideas are welcome. :)

-- 
Michael



@@
u8 e;
expression s;
@@
- ~e >> s
+ (u8)~e >> s

@@
s8 e;
expression s;
@@
- ~e >> s
+ (s8)~e >> s

@@
u16 e;
expression s;
@@
- ~e >> s
+ (u16)~e >> s

@@
s16 e;
expression s;
@@
- ~e >> s
+ (s16)~e >> s

@@
char e;
expression s;
@@
- ~e >> s
+ (char)~e >> s

@@
unsigned char e;
expression s;
@@
- ~e >> s
+ (unsigned char)~e >> s

@@
short e;
expression s;
@@
- ~e >> s
+ (short)~e >> s

@@
unsigned short e;
expression s;
@@
- ~e >> s
+ (unsigned short)~e >> s




@@
constant c;
expression s;
@@
- ~c >> s
+ (unsigned int)~c >> s





@sh expression@
identifier val;
expression shift;
@@
val >> shift


@@
expression e;
identifier sh.val;
@@
- #define val ~e
+ #define val e

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150618/aa8c5de0/attachment.sig>

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

[Doug Anderson]

Russell,

On Thu, Jun 18, 2015 at 8:55 AM, Russell King - ARM Linux
 wrote:
>> Perhaps you can try 
>
> Something like that needs to be done, but let's get rid of the mdvi
> thing in struct hdmi_vmode - it doesn't belong there, it isn't part
> of the currently set video mode, but becomes a property of the
> connected sink.
>
> I'd also prefer it to be called "is_dvi_sink", especially as its
> function is changing from "is it a CEA mode" to "is the attached
> device a DVI sink".
>
> Even better would be to call it "is_hdmi_sink" to maintain positive
> logic with single-negation where required, rather than double-
> negation in places.

Yakir: sounds like you now have some feedback on your patch now.
Perhaps you can spin it with Russell's feedback?

When you send it next, please make sure you include Russell in the
"To" line.  Based at looking at who committed things to dw_hdmi in the
past, I've been sending my patches "To":
Philipp Zabel
Russell King
Thierry Reding

...so perhaps that would be good for you to do, too?

>> I am nowhere near an HDMI expert.  If you have a better suggestion
>> then I'm more than happy for you to post it and drop my patch.  In my
>> non-expert opinion, it would seem awfully strange for an AV receiver
>> to modify the EDID though unless it was actively interpreting the
>> signal and generating a whole new signal on the other end.  In any
>> case, perhaps you can find such a device and that will give insight to
>> how we should deal with it.  Until such a device is found, it seems
>> fruitless to speculate.
>
> Neither am I, but I have had the ability to do some testing with AV
> receivers in the path of a HDMI device, and I've seen how they behave.
> (I made copious notes on this, which I intend to publish when I have
> a round tuit.)  Unfortunately, I have no DVI devices to test with,
> and DVI devices are a dying breed - most monitors today come with
> HDMI sockets instead.

Ah, OK.  Have you seen any that specifically confuse the DVI vs. HDMI bits?

I still have copious DVI devices around, personally.  I could have
sworn that supporting "older hardware" was actually pretty important
in Linux.  ...and I can still buy plenty of DVI devices out there.


> That's a shame... I'm not inclined to Ack it as-is - and I'd also like
> to see Yakir's patch reworked as I mentioned above.

Perhaps when Yakir spins his series he can include a patch like mine
in it.  It doesn't make sense for me to re-spin it until his is
resolved.

-Doug

[PATCH] drm/msm/dp: use flags argument of devm_gpiod_get to set direction

[Uwe Kleine-König]

Hello Emil,

On Thu, Jun 18, 2015 at 03:51:26PM +0100, Emil Velikov wrote:
> > I had planned to send a second pull request for 4.2 with some
> > additional hdcp patches that depend on scm changes coming in via
> > arm-soc tree for 4.2.. if that is ok, I can include this patch with
> > that second pull req..  otherwise I'm ok with Dave applying it
> > directly or you taking it in via gpio tree.  Either way is fine by me.
> >
> Mildly related:
> 
> Rob, would it make things a bit easier if we have you listed in
> MAINTAINERS for the msm/freedreno driver ?
> 
> Uwe, you might have greater input if you explicitly CC the
> {unofficial,} maintainer of the relevant driver. Some drivers don't
> have one explicitly listed in MAINTAINERS, so git log tends to help
> there :-)
I consider it hard to choose the right set of recipents for areas where
I don't usually patch. Addressing too much people is bad as is addressing
too less. And what is considered right differs per
subsystem/maintainer/contributor. I don't claim it's impossible to find
out the right person, but for a patch stack with more than say a dozen
patches distributed all over the source tree it's the easiest to check
scripts/get_maintainer.pl and select what looks reasonable from its
output. So having the maintainer listed is definitly nice because at
least for me it increases the chance considerably to pick him for cc.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

[Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver

[Paul Bolle]

Hi Shobhit,

On Thu, 2015-06-18 at 23:24 +0530, Shobhit Kumar wrote:
> On Fri, May 1, 2015 at 2:42 AM, Paul Bolle  wrote:
> > On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote:
> >> --- a/drivers/pwm/Kconfig
> >> +++ b/drivers/pwm/Kconfig
> >
> >> +config PWM_CRC
> >> + bool "Intel Crystalcove (CRC) PWM support"
> >> + depends on X86 && INTEL_SOC_PMIC
> >> + help
> >> +   Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
> >> +   control.
> >
> >> --- a/drivers/pwm/Makefile
> >> +++ b/drivers/pwm/Makefile
> >
> >> +obj-$(CONFIG_PWM_CRC)+= pwm-crc.o
> >
> > PWM_CRC is a bool symbol. So pwm-crc.o can never be part of a module.
> 
> I actually started this as a module but later decided to make it as
> bool because INTEL_SOC_PMIC on which this depends is itself a bool as
> well.

As does GPIO_CRYSTAL_COVE and that's a tristate. So?

> Still it is good to keep the module based initialization.
> Firstly because it causes no harm

If I got a dime for every time people used an argument like that I ... I
could treat myself to an ice cream. A really big ice cream. Hmm, that
doesn't sound too impressive. But still, "causes no harm" is below the
bar for kernel code. Kernel code needs to add value.

> and even though some of the macros
> are pre-processed out, gives info about the driver.

None of which can't be gotten elsewhere (ie, the commit message, or the
file these macro reside in).

> Secondly there
> were discussion on why INTEL_SOC_PMIC is bool (note this driver also
> has module based initialization even when bool).

Yes, there's copy and paste going on even in kernel development.

> I am guessing because
> of some tricky module load order dependencies. If ever that becomes a
> module, this can mostly be unchanged to be loaded as a module.

You put in a macro, or any other bit of code, when it's needed, not
beforehand, "just in case". That's silly.

Thanks,


Paul Bolle

[pull] radeon drm-fixes-4.1

[Christian König]

Hi Dave,

just your MST fix and another one from Michel which is CC stable as well.

Branch is based on drm-fixes, not sure if you still take stuff for 4.1 
or if that will go into 4.2. I won't mind either way.

Regards,
Christian.

The following changes since commit 25161084b1c1b0c29948f6f77266a35f302196b7:

   drm/mgag200: Reject non-character-cell-aligned mode widths 
(2015-06-16 10:01:16 +1000)

are available in the git repository at:

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

for you to fetch changes up to 7f017e56770e82c8fe2d4d8c59e58f519f455ad7:

   drm/radeon: don't probe MST on hw we don't support it on (2015-06-18 
20:36:56 +0200)


Dave Airlie (1):
   drm/radeon: don't probe MST on hw we don't support it on

Michel Dänzer (1):
   drm/radeon: Add RADEON_INFO_VA_UNMAP_WORKING query

  drivers/gpu/drm/radeon/radeon_dp_mst.c | 5 +
  drivers/gpu/drm/radeon/radeon_kms.c| 3 +++
  include/uapi/drm/radeon_drm.h  | 1 +
  3 files changed, 9 insertions(+)

[Bug 90873] Kernel hang, TearFree On, Mate desktop environment

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

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

--- Comment #6 from Tom  ---
(In reply to Michel Dänzer from comment #5)
> http://lists.freedesktop.org/archives/dri-devel/2015-June/084514.html fixes
> the hang for me (not a GPU hang but a kernel hang, because it tries to lock
> a mutex that's already locked).
> 
> 
> > [  141.232226] radeon :01:00.0: bo 8804236d3400 va 0x001000
> > conflict with (bo 88042a018800 0x001000 0x001563)
> 
> These still happen, but at least with GNOME it continues working for me
> somehow. I tried various workarounds for this in the Xorg driver, but I
> haven't found anything that avoids these. I think the proper solution for
> these would be for the kernel driver to track GPU VA ranges per GEM handle
> instead of per BO.

The latest patch applied to linux kernel rc8 fixed this issue, thanks.

-- 
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/20150618/e82ce6be/attachment.html>

[Bug 90873] Kernel hang, TearFree On, Mate desktop environment

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

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

Tom  changed:

   What|Removed |Added

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

--- Comment #7 from Tom  ---
Resolved in kernel 4.1-rc8

-- 
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/20150618/fbfb177a/attachment.html>

[PATCH 1/2] drm/exynos: calculate vrefresh instead of use a fixed value

[Gustavo Padovan]

From: Gustavo Padovan 

When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro. But if vrefresh is still zero we should fail the
update.

Suggested-by: Daniel Stone 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 1e3bb72..7ba348e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -41,7 +41,6 @@
  * CPU Interface.
  */

-#define FIMD_DEFAULT_FRAMERATE 60
 #define MIN_FB_WIDTH_FOR_16WORD_BURST 128

 /* position control register for hardware window 0, 2 ~ 4.*/
@@ -403,7 +402,9 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc *crtc,
struct drm_display_mode *adjusted_mode)
 {
if (adjusted_mode->vrefresh == 0)
-   adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
+   adjusted_mode->vrefresh = drm_mode_vrefresh(mode);
+   if (adjusted_mode->vrefresh == 0)
+   return false;

return true;
 }
-- 
2.1.0

[PATCH 2/2] drm/exynos: use KMS version of DRM vblanks functions

[Gustavo Padovan]

From: Gustavo Padovan 

Get rid of legacy DRM vblank function that are less clear to use.
The new only basically requires only the crtc as paramenters.

It also clean ups exynos_drm_crtc_finish_pageflip() parameters as a
consequence.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c |  4 ++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   | 14 ++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  8 
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   |  4 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c  |  4 ++--
 6 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 2b9221c..43c0ab7 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -652,8 +652,8 @@ static irqreturn_t decon_irq_handler(int irq, void *dev_id)
goto out;

if (!ctx->i80_if) {
-   drm_handle_vblank(ctx->drm_dev, ctx->pipe);
-   exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
+   drm_crtc_handle_vblank(&ctx->crtc->base);
+   exynos_drm_crtc_finish_pageflip(ctx->crtc);

/* set wait vsync event to zero and wake up queue. */
if (atomic_read(&ctx->wait_vsync_event)) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 22b9ca0..e9c291f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -193,24 +193,22 @@ void exynos_drm_crtc_disable_vblank(struct drm_device 
*dev, int pipe)
exynos_crtc->ops->disable_vblank(exynos_crtc);
 }

-void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe)
+void exynos_drm_crtc_finish_pageflip(struct exynos_drm_crtc *exynos_crtc)
 {
-   struct exynos_drm_private *dev_priv = dev->dev_private;
-   struct drm_crtc *drm_crtc = dev_priv->crtc[pipe];
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
+   struct drm_crtc *crtc = &exynos_crtc->base;
unsigned long flags;

-   spin_lock_irqsave(&dev->event_lock, flags);
+   spin_lock_irqsave(&crtc->dev->event_lock, flags);
if (exynos_crtc->event) {

-   drm_send_vblank_event(dev, pipe, exynos_crtc->event);
-   drm_vblank_put(dev, pipe);
+   drm_crtc_send_vblank_event(crtc, exynos_crtc->event);
+   drm_crtc_vblank_put(crtc);
wake_up(&exynos_crtc->pending_flip_queue);

}

exynos_crtc->event = NULL;
-   spin_unlock_irqrestore(&dev->event_lock, flags);
+   spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
 }

 void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 0f3aa70..d01d49a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -25,7 +25,7 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
drm_device *drm_dev,
void *context);
 int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int pipe);
 void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int pipe);
-void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe);
+void exynos_drm_crtc_finish_pageflip(struct exynos_drm_crtc *exynos_crtc);
 void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb);

 /* This function gets pipe value to crtc device matched with out_type. */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 7ba348e..659976c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -886,7 +886,7 @@ static void fimd_te_handler(struct exynos_drm_crtc *crtc)
}

if (test_bit(0, &ctx->irq_flags))
-   drm_handle_vblank(ctx->drm_dev, ctx->pipe);
+   drm_crtc_handle_vblank(&ctx->crtc->base);
 }

 static void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bool enable)
@@ -936,13 +936,13 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
goto out;

if (ctx->i80_if) {
-   exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
+   exynos_drm_crtc_finish_pageflip(ctx->crtc);

/* Exits triggering mode */
atomic_set(&ctx->triggering, 0);
} else {
-   drm_handle_vblank(ctx->drm_dev, ctx->pipe);
-   exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
+   drm_crtc_handle_vblank(&ctx->crtc->base);
+   exynos_drm_crtc_finish_pageflip(ctx->crtc);

/* set wait vsync event to zero and wake up queue. */
if (atomic_read(&ctx->wait_vsync_event

[PATCH v2 00/32] acpi-video: Rewrite backlight interface selection logic

[Darren Hart]

On Wed, Jun 17, 2015 at 11:36:13AM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 17, 2015 at 5:39 AM, Darren Hart  wrote:
> > On Tue, Jun 16, 2015 at 01:22:40AM +0200, Rafael Wysocki wrote:
> >> On Friday, June 12, 2015 01:23:19 PM Hans de Goede wrote:
> >> > Hi All,
> >> >
> >> > Here is v2 of my rewrite / cleanup of the acpi-video (and platform/x86)
> >> > backlight interface selection logic.
> >> >
> >> > The major change in v2 of this set are 2 changes to the patch titled
> >> > "acpi-video-detect: video: Make video_detect code part of the video 
> >> > module":
> >> >
> >> > 1) The __setup call for the acpi_backlight= handling is moved to
> >> >acpi/util.c as __setup may only be used by code which is always 
> >> > builtin
> >> > 2) video.c is renamed to acpi_video.c so that it can be combined with
> >> >video_detect.c into video.ko
> >> >
> >> > These 2 changes result in the backlight kernel commandline options after 
> >> > this
> >> > patch-set being 100% compatible with the old options, with the exception 
> >> > of
> >> > the removal of the video.use_native_backlight option as that now is 
> >> > folded
> >> > into acpi_backlight=[video|vendor|native|none] rather then having 2 
> >> > options
> >> > which influence each other in interesting ways.
> >> >
> >> > Besides that there is a small change to the dell-laptop port to the new 
> >> > API
> >> > removing an unnecessary #ifdef ACPI.
> >>
> >> I tried to queue this series up for 4.2, but patch [06/32] didn't apply 
> >> for me,
> >> so I decided to apply another patch I've got recently instead and which is 
> >> now
> >> in my linux-next branch.
> >>
> >> Can you please rebase the series on top of linux-pm.git/linux-next and 
> >> resend it?
> >
> > Rafael, do you intent to carry this entire series and submit via linux-pm?
> 
> Yes, I do.

In that case,

Acked-by: Darren Hart 

For the platform/drivers/x86 patches.

-- 
Darren Hart
Intel Open Source Technology Center

[PATCH 1/2] drm/radeon: compute ring fix hibernation (CI GPU family).

[j.gli...@gmail.com]

From: Jérôme Glisse 

In order for hibernation to reliably work we need to cleanup more
thoroughly the compute ring. Hibernation is different from suspend
resume as when we resume from hibernation the hardware is first
fully initialize by regular kernel then freeze callback happens
(which correspond to a suspend inside the radeon kernel driver)
and turn off each of the block. It turns out we were not cleanly
shutting down the compute ring. This patch fix that.

Hibernation and suspend to ram were tested (several times) on :
Bonaire
Hawaii
Mullins
Kaveri
Kabini

Cc: stable at vger.kernel.org
Signed-off-by: Jérôme Glisse 
---
 drivers/gpu/drm/radeon/cik.c |   55 ++
 1 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index ba50f3c..d2576d4 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4592,6 +4592,61 @@ static void cik_cp_compute_enable(struct radeon_device 
*rdev, bool enable)
if (enable)
WREG32(CP_MEC_CNTL, 0);
else {
+   u32 tmp;
+   int idx, j;
+
+   /*
+* To make hibernation reliable we need to clear compute ring
+* configuration before halting the compute ring.
+*/
+   mutex_lock(&rdev->srbm_mutex);
+
+   idx = CAYMAN_RING_TYPE_CP1_INDEX;
+   cik_srbm_select(rdev, rdev->ring[idx].me,
+   rdev->ring[idx].pipe,
+   rdev->ring[idx].queue, 0);
+   /* Disable wptr polling. */
+   tmp = RREG32(CP_PQ_WPTR_POLL_CNTL);
+   tmp &= ~WPTR_POLL_EN;
+   WREG32(CP_PQ_WPTR_POLL_CNTL, tmp);
+   /* Disable HQD. */
+   if (RREG32(CP_HQD_ACTIVE) & 1) {
+   WREG32(CP_HQD_DEQUEUE_REQUEST, 1);
+   for (j = 0; j < rdev->usec_timeout; j++) {
+   if (!(RREG32(CP_HQD_ACTIVE) & 1))
+   break;
+   udelay(1);
+   }
+   WREG32(CP_HQD_DEQUEUE_REQUEST, 0);
+   WREG32(CP_HQD_PQ_RPTR, 0);
+   WREG32(CP_HQD_PQ_WPTR, 0);
+   }
+   cik_srbm_select(rdev, 0, 0, 0, 0);
+
+   idx = CAYMAN_RING_TYPE_CP2_INDEX;
+   cik_srbm_select(rdev, rdev->ring[idx].me,
+   rdev->ring[idx].pipe,
+   rdev->ring[idx].queue, 0);
+   /* Disable wptr polling. */
+   tmp = RREG32(CP_PQ_WPTR_POLL_CNTL);
+   tmp &= ~WPTR_POLL_EN;
+   WREG32(CP_PQ_WPTR_POLL_CNTL, tmp);
+   /* Disable HQD. */
+   if (RREG32(CP_HQD_ACTIVE) & 1) {
+   WREG32(CP_HQD_DEQUEUE_REQUEST, 1);
+   for (j = 0; j < rdev->usec_timeout; j++) {
+   if (!(RREG32(CP_HQD_ACTIVE) & 1))
+   break;
+   udelay(1);
+   }
+   WREG32(CP_HQD_DEQUEUE_REQUEST, 0);
+   WREG32(CP_HQD_PQ_RPTR, 0);
+   WREG32(CP_HQD_PQ_WPTR, 0);
+   }
+   cik_srbm_select(rdev, 0, 0, 0, 0);
+
+   mutex_unlock(&rdev->srbm_mutex);
+
WREG32(CP_MEC_CNTL, (MEC_ME1_HALT | MEC_ME2_HALT));
rdev->ring[CAYMAN_RING_TYPE_CP1_INDEX].ready = false;
rdev->ring[CAYMAN_RING_TYPE_CP2_INDEX].ready = false;
-- 
1.7.1

[PATCH 2/2] drm/radeon: SDMA fix hibernation (CI GPU family).

[j.gli...@gmail.com]

From: Jérôme Glisse 

In order for hibernation to reliably work we need to properly turn
off the SDMA block, sadly after numerous attemps i haven't not found
proper sequence for clean and full shutdown. So simply reset both
SDMA block, this makes hibernation works reliably on sea island GPU
family (CI)

Hibernation and suspend to ram were tested (several times) on :
Bonaire
Hawaii
Mullins
Kaveri
Kabini

Cc: stable at vger.kernel.org
Signed-off-by: Jérôme Glisse 
---
 drivers/gpu/drm/radeon/cik_sdma.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index f86eb54..d16f2ee 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -268,6 +268,17 @@ static void cik_sdma_gfx_stop(struct radeon_device *rdev)
}
rdev->ring[R600_RING_TYPE_DMA_INDEX].ready = false;
rdev->ring[CAYMAN_RING_TYPE_DMA1_INDEX].ready = false;
+
+   /* FIXME use something else than big hammer but after few days can not
+* seem to find good combination so reset SDMA blocks as it seems we
+* do not shut them down properly. This fix hibernation and does not
+* affect suspend to ram.
+*/
+   WREG32(SRBM_SOFT_RESET, SOFT_RESET_SDMA | SOFT_RESET_SDMA1);
+   (void)RREG32(SRBM_SOFT_RESET);
+   udelay(50);
+   WREG32(SRBM_SOFT_RESET, 0);
+   (void)RREG32(SRBM_SOFT_RESET);
 }

 /**
-- 
1.7.1

[Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver

[Shobhit Kumar]

On Fri, May 1, 2015 at 2:42 AM, Paul Bolle  wrote:
> On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote:
>> --- a/drivers/pwm/Kconfig
>> +++ b/drivers/pwm/Kconfig
>
>> +config PWM_CRC
>> + bool "Intel Crystalcove (CRC) PWM support"
>> + depends on X86 && INTEL_SOC_PMIC
>> + help
>> +   Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
>> +   control.
>
>> --- a/drivers/pwm/Makefile
>> +++ b/drivers/pwm/Makefile
>
>> +obj-$(CONFIG_PWM_CRC)+= pwm-crc.o
>
> PWM_CRC is a bool symbol. So pwm-crc.o can never be part of a module.

I actually started this as a module but later decided to make it as
bool because INTEL_SOC_PMIC on which this depends is itself a bool as
well. Still it is good to keep the module based initialization.
Firstly because it causes no harm and even though some of the macros
are pre-processed out, gives info about the driver. Secondly there
were discussion on why INTEL_SOC_PMIC is bool (note this driver also
has module based initialization even when bool). I am guessing because
of some tricky module load order dependencies. If ever that becomes a
module, this can mostly be unchanged to be loaded as a module.

Regards
Shobhit

>
> (If I'm wrong, and that object file can actually be part of a module,
> you can stop reading here.)
>
>> --- /dev/null
>> +++ b/drivers/pwm/pwm-crc.c
>
>> +#include 
>
> Perhaps this include is not needed.
>
>> +static const struct pwm_ops crc_pwm_ops = {
>> + .config = crc_pwm_config,
>> + .enable = crc_pwm_enable,
>> + .disable = crc_pwm_disable,
>> + .owner = THIS_MODULE,
>
> For built-in only code THIS_MODULE is basically equivalent to NULL (see
> include/linux/export.h). So I guess this line can be dropped.
>
>> +};
>
>> +static struct platform_driver crystalcove_pwm_driver = {
>> + .probe = crystalcove_pwm_probe,
>> + .remove = crystalcove_pwm_remove,
>> + .driver = {
>> + .name = "crystal_cove_pwm",
>> + },
>> +};
>> +
>> +module_platform_driver(crystalcove_pwm_driver);
>
> Speaking from memory: for built-in only code this is equivalent to
> calling
> platform_driver_register(&crystalcove_pwm_driver);
>
> from a wrapper, and marking that wrapper with device_initcall().
>
>> +MODULE_AUTHOR("Shobhit Kumar ");
>> +MODULE_DESCRIPTION("Intel Crystal Cove PWM Driver");
>> +MODULE_LICENSE("GPL v2");
>
> These macros will be effectively preprocessed away for built-in only
> code.
>
>
> Paul Bolle
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx