date:20170530


On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?


Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete newbie when it
comes to mst.


I don't really have more clue, but yeah if you don't have an mst thing (a
simple dp port multiplexer is what I use for testing here, then plug in a
converter dongle or cable into that) then probably better to not wire up
the code for it.


I think my NUC already uses mst internally. But I was planning on buying a
dp multiplexer to make sure there is nothing special I need to do for mst.

The CEC Tunneling is all in the branch device, so if I understand things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware issue
or something else. The BIOS is able to do some CEC, but whether they hook
into the MegaChip or have the CEC pin connected to a GPIO or something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would be very
helpful.

It would be so nice to get MegaChip CEC Tunneling working on the NUC, because
then you have native CEC support without requiring any Pulse Eight adapter.

And add a CEC-capable USB-C to HDMI adapter and you have it on the USB-C
output as well.

Regards,

Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2017-05-30 Thread Jani Nikula

On Tue, 30 May 2017, Hans Verkuil  wrote:
> On 05/29/2017 09:00 PM, Daniel Vetter wrote:
>> On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
>>> On 05/26/2017 09:15 AM, Daniel Vetter wrote:
 Did you look into also wiring this up for dp mst chains?
>>>
>>> Isn't this sufficient? I have no way of testing mst chains.
>>>
>>> I think I need some pointers from you, since I am a complete newbie when it
>>> comes to mst.
>> 
>> I don't really have more clue, but yeah if you don't have an mst thing (a
>> simple dp port multiplexer is what I use for testing here, then plug in a
>> converter dongle or cable into that) then probably better to not wire up
>> the code for it.
>
> I think my NUC already uses mst internally. But I was planning on buying a
> dp multiplexer to make sure there is nothing special I need to do for mst.
>
> The CEC Tunneling is all in the branch device, so if I understand things
> correctly it is not affected by mst.
>
> BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they
> use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
> datasheet is supposed to implement CEC Tunneling, but if they do it is not
> exposed as a capability. I'm not sure if it is a MegaChip firmware issue
> or something else. The BIOS is able to do some CEC, but whether they hook
> into the MegaChip or have the CEC pin connected to a GPIO or something and
> have their own controller is something I do not know.
>
> If anyone can clarify what Intel did on the NUC, then that would be very
> helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


BR,
Jani.

>
> It would be so nice to get MegaChip CEC Tunneling working on the NUC, because
> then you have native CEC support without requiring any Pulse Eight adapter.
>
> And add a CEC-capable USB-C to HDMI adapter and you have it on the USB-C
> output as well.
>
> Regards,
>
>   Hans

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] dim: Enforce review requirements

On 05/24/2017 11:28 AM, Daniel Vetter wrote:
> We can't check this when applying (since r-b/a-b tags often get added
> afterwards), but we can check this when pushing. This only looks at
> patches authored by the pusher.
> 
> Also update the docs to highlight that review requirements hold
> especially also for bugfixes.
> 
> Cc: Patrik Jakobsson 
> Cc: Lukas Wunner 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: Sean Paul 
> Signed-off-by: Daniel Vetter 
> ---
>  dim  | 42 ++
>  drm-misc.rst |  4 +++-
>  2 files changed, 41 insertions(+), 5 deletions(-)
> 
> diff --git a/dim b/dim
> index baa0b3832314..79738a1b37a0 100755
> --- a/dim
> +++ b/dim
> @@ -340,6 +340,15 @@ function git_branch_exists # branch
>   fi
>  }
>  
> +function git_committer_email
> +{
> + if ! commiter_email=$(git config --get user.email) ; then
> + commiter_email=$EMAIL
> + fi
> +
> + echo $commiter_email
> +}
> +
>  # get message id from file
>  # $1 = file
>  message_get_id ()
> @@ -632,11 +641,32 @@ function dim_rebuild_tip
>   exit 1
>   fi
>  }
> +
> +# additional patch checks before pushing, e.g. for r-b tags
> +function checkpatch_commit_push
> +{
> + local sha1
> +
> + sha1=$1
> +
> + # check for a-b/r-b tag
> + if git show -s $sha1 | grep -qi '\(reviewed\|acked\)\S*-by:'  ; then
> + return
> + fi
> +
> + # check for commiter != author
> + if [[ $(git show -s $sha1 --format="format:%ce") != $(git show -s $sha1 
> --format="format:%ae") ]]; then
> + return
> + fi
> +
> + warn_or_fail "$sha1 is lacking mandatory review"
> +}
> +
>  # push branch $1, rebuild drm-tip. the rest of the arguments are passed to 
> git
>  # push.
>  function dim_push_branch
>  {
> - local branch remote
> + local branch remote commiter_email
>  
>   branch=${1:?$usage}
>   shift
> @@ -645,6 +675,12 @@ function dim_push_branch
>  
>   remote=$(branch_to_remote $branch)
>  
> + commiter_email=$(git_committer_email)
> +
> + for sha1 in $(git rev-list $branch@{u}..$branch 
> --committer="$commiter_email" --no-merges) ; do
> + checkpatch_commit_push $sha1
> + done
> +
>   git push $DRY_RUN $remote $branch "$@"
>  
>   update_linux_next $branch drm-intel-next-queued drm-intel-next-fixes 
> drm-intel-fixes
> @@ -690,9 +726,7 @@ function dim_apply_branch
>  
>   message_id=$(message_get_id $file)
>  
> - if ! commiter_email=$(git config --get user.email) ; then
> - commiter_email=$EMAIL
> - fi
> + commiter_email=$(git_committer_email)
>  
>   patch_from=$(grep "From:" "$file" | head -1)
>   if [[ "$patch_from" != *"$commiter_email"* ]] ; then
> diff --git a/drm-misc.rst b/drm-misc.rst
> index caba8dc77696..d56c3c7f92a3 100644
> --- a/drm-misc.rst
> +++ b/drm-misc.rst
> @@ -90,7 +90,9 @@ Merge Criteria
>  Right now the only hard merge criteria are:
>  
>  * Patch is properly reviewed or at least Ack, i.e. don't just push your own
> -  stuff directly.
> +  stuff directly. This rule holds even more for bugfix patches - it would be
> +  embarrassing if the bugfix contains a small gotcha that review would have
> +  caught.
>  
>  * drm-misc is for drm core (non-driver) patches, subsystem-wide refactorings,
>and small trivial patches all over (including drivers). For a detailed 
> list of
> 

Reviewed-by: Neil Armstrong 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/37] drm/doc: move printf helpers out of drmP.h

On 05/24/2017 04:51 PM, Daniel Vetter wrote:
> And document them lightly. Unfortunately kernel-doc isn't the most
> awesome for documenting #defines that don't look like functions, it
> makes functions out of them :-/
> 
> Signed-off-by: Daniel Vetter 
> ---
>  include/drm/drmP.h  | 17 -
>  include/drm/drm_modes.h | 17 +
>  include/drm/drm_rect.h  | 27 +++
>  3 files changed, 44 insertions(+), 17 deletions(-)
> 
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index b9b5566acfe6..575b29b47811 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -292,23 +292,6 @@ struct pci_controller;
>  /* Format strings and argument splitters to simplify printing
>   * various "complex" objects
>   */
> -#define DRM_MODE_FMT"%d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
> -#define DRM_MODE_ARG(m) \
> - (m)->base.id, (m)->name, (m)->vrefresh, (m)->clock, \
> - (m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
> - (m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
> - (m)->type, (m)->flags
> -
> -#define DRM_RECT_FMT"%dx%d%+d%+d"
> -#define DRM_RECT_ARG(r) drm_rect_width(r), drm_rect_height(r), (r)->x1, 
> (r)->y1
> -
> -/* for rect's in fixed-point format: */
> -#define DRM_RECT_FP_FMT "%d.%06ux%d.%06u%+d.%06u%+d.%06u"
> -#define DRM_RECT_FP_ARG(r) \
> - drm_rect_width(r) >> 16, ((drm_rect_width(r) & 0x) * 15625) 
> >> 10, \
> - drm_rect_height(r) >> 16, ((drm_rect_height(r) & 0x) * 
> 15625) >> 10, \
> - (r)->x1 >> 16, (((r)->x1 & 0x) * 15625) >> 10, \
> - (r)->y1 >> 16, (((r)->y1 & 0x) * 15625) >> 10
>  
>  /*@}*/
>  
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 6dd34280e892..94ac771fe460 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -197,6 +197,8 @@ enum drm_mode_status {
>   * there's the hardware timings, which are corrected for interlacing,
>   * double-clocking and similar things. They are provided as a convenience, 
> and
>   * can be appropriately computed using drm_mode_set_crtcinfo().
> + *
> + * For printing you can use %DRM_MODE_FMT and DRM_MODE_ARG().
>   */
>  struct drm_display_mode {
>   /**
> @@ -407,6 +409,21 @@ struct drm_display_mode {
>   enum hdmi_picture_aspect picture_aspect_ratio;
>  };
>  
> +/**
> + * DRM_MODE_FMT - printf string for &struct drm_display_mode
> + */
> +#define DRM_MODE_FMT"%d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
> +
> +/**
> + * DRM_MODE_ARG - printf arguments for &struct drm_display_mode
> + * @m: display mode
> + */
> +#define DRM_MODE_ARG(m) \
> + (m)->base.id, (m)->name, (m)->vrefresh, (m)->clock, \
> + (m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
> + (m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
> + (m)->type, (m)->flags
> +
>  #define obj_to_mode(x) container_of(x, struct drm_display_mode, base)
>  
>  /**
> diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> index 83bb156d4356..44bc122b9ee0 100644
> --- a/include/drm/drm_rect.h
> +++ b/include/drm/drm_rect.h
> @@ -43,6 +43,33 @@ struct drm_rect {
>  };
>  
>  /**
> + * DRM_RECT_FMT - printf string for &struct drm_rect
> + */
> +#define DRM_RECT_FMT"%dx%d%+d%+d"
> +/**
> + * DRM_RECT_ARG - printf arguments for &struct drm_rect
> + * @r: rectangle struct
> + */
> +#define DRM_RECT_ARG(r) drm_rect_width(r), drm_rect_height(r), (r)->x1, 
> (r)->y1
> +
> +/**
> + * DRM_RECT_FP_FMT - printf string for &struct drm_rect in 16.16 fixed point
> + */
> +#define DRM_RECT_FP_FMT "%d.%06ux%d.%06u%+d.%06u%+d.%06u"
> +/**
> + * DRM_RECT_FP_ARG - printf arguments for &struct drm_rect in 16.16 fixed 
> point
> + * @r: rectangle struct
> + *
> + * This is useful for e.g. printing plane source rectangles, which are in 
> 16.16
> + * fixed point.
> + */
> +#define DRM_RECT_FP_ARG(r) \
> + drm_rect_width(r) >> 16, ((drm_rect_width(r) & 0x) * 15625) 
> >> 10, \
> + drm_rect_height(r) >> 16, ((drm_rect_height(r) & 0x) * 
> 15625) >> 10, \
> + (r)->x1 >> 16, (((r)->x1 & 0x) * 15625) >> 10, \
> + (r)->y1 >> 16, (((r)->y1 & 0x) * 15625) >> 10
> +
> +/**
>   * drm_rect_adjust_size - adjust the size of the rectangle
>   * @r: rectangle to be adjusted
>   * @dw: horizontal adjustment
> 

Reviewed-by: Neil Armstrong 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/37] drm: Remove drm_device->virtdev

On 05/24/2017 04:51 PM, Daniel Vetter wrote:
> This is a leftover from the drm_bus days, where we've had a
> bus-specific device type for every bus type in drm_device. Except for
> pci (which we can't remove because dri1 drivers) this is all gone. And
> the virt driver also doesn't really need it, dev_to_virtio works
> perfectly fine.
> 
> Cc: David Airlie 
> Cc: Gerd Hoffmann 
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 1 -
>  drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++--
>  include/drm/drmP.h   | 2 --
>  3 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c 
> b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> index 43e1d5916c6c..7df8d0c9026a 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
> @@ -56,7 +56,6 @@ int drm_virtio_init(struct drm_driver *driver, struct 
> virtio_device *vdev)
>   dev = drm_dev_alloc(driver, &vdev->dev);
>   if (IS_ERR(dev))
>   return PTR_ERR(dev);
> - dev->virtdev = vdev;
>   vdev->priv = dev;
>  
>   if (strcmp(vdev->dev.parent->bus->name, "pci") == 0) {
> diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c 
> b/drivers/gpu/drm/virtio/virtgpu_kms.c
> index 1e1c90b30d4a..6400506a06b0 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_kms.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
> @@ -138,7 +138,7 @@ int virtio_gpu_driver_load(struct drm_device *dev, 
> unsigned long flags)
>   u32 num_scanouts, num_capsets;
>   int ret;
>  
> - if (!virtio_has_feature(dev->virtdev, VIRTIO_F_VERSION_1))
> + if (!virtio_has_feature(dev_to_virtio(dev->dev), VIRTIO_F_VERSION_1))
>   return -ENODEV;
>  
>   vgdev = kzalloc(sizeof(struct virtio_gpu_device), GFP_KERNEL);
> @@ -147,7 +147,7 @@ int virtio_gpu_driver_load(struct drm_device *dev, 
> unsigned long flags)
>  
>   vgdev->ddev = dev;
>   dev->dev_private = vgdev;
> - vgdev->vdev = dev->virtdev;
> + vgdev->vdev = dev_to_virtio(dev->dev);
>   vgdev->dev = dev->dev;
>  
>   spin_lock_init(&vgdev->display_info_lock);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 575b29b47811..c363f2fdff31 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -412,8 +412,6 @@ struct drm_device {
>   struct pci_controller *hose;
>  #endif
>  
> - struct virtio_device *virtdev;
> -
>   struct drm_sg_mem *sg;  /**< Scatter gather memory */
>   unsigned int num_crtcs;  /**< Number of CRTCs on this 
> device */
>  
> 

Reviewed-by: Neil Armstrong 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 13/37] drm: better document how to send out the crtc disable event

On 05/24/2017 04:51 PM, Daniel Vetter wrote:
> The kernel doc explained what needs to happen, but not how to most
> easily accomplish that using the functions. Fix that.
> 
> Cc: Boris Brezillon 
> Signed-off-by: Daniel Vetter 
> ---
>  include/drm/drm_crtc.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5f5d53973ca5..3a911a64c257 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -214,7 +214,9 @@ struct drm_crtc_state {
>*atomic commit. In that case the event can be send out any time
>*after the hardware has stopped scanning out the current
>*framebuffers. It should contain the timestamp and counter for the
> -  *last vblank before the display pipeline was shut off.
> +  *last vblank before the display pipeline was shut off. The simplest
> +  *way to achieve that is calling drm_crtc_send_vblank_event()
> +  *somewhen after drm_crtc_vblank_off() has been called.
>*
>*  - For a CRTC which is enabled at the end of the commit (even when it
>*undergoes an full modeset) the vblank timestamp and counter must
> 

Reviewed-by: Neil Armstrong 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add kerneldoc to describe i915_gem_object.vma_list

On to, 2017-05-25 at 21:48 +0100, Chris Wilson wrote:
> Add kerneldoc for the vma_list stored on the i915_gem_object, in
> particular, documenting the expected ordering of elements -- i.e. that
> we do expect GGTT VMA first followed by the ppGTT VMA.
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Fix locking in drm_atomic_helper_resume

2017-05-30 Thread Maarten Lankhorst

Hey,

Op 29-05-17 om 21:34 schreef Daniel Vetter:
> In the conversion to drop drm_modeset_lock_all and the magic implicit
> context I failed to realize that _resume starts out with a pile of
> state copies, but not with the locks. And hence drm_atomic_commit
> won't grab these for us.
>
> Cc: Jyri Sarha 
> Fixes: a5b8444e289c ("drm/atomic-helper: remove modeset_lock_all from 
> helper_resume")
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Signed-off-by: Daniel Vetter 
> ---
> Needs to be applied to drm-misc-fixes for 4.12.
> -Daniel
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index af07368846e0..a61291c29567 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2669,7 +2669,12 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>  
>   drm_modeset_acquire_init(&ctx, 0);
>   while (1) {
> + err = drm_modeset_lock_all_ctx(dev, &ctx);
> + if (err)
> + goto out;
> +
>   err = drm_atomic_helper_commit_duplicated_state(state, &ctx);
> +out:
>   if (err != -EDEADLK)
>   break;
>  

This either needs a WARN somewhere to make sure we trip this in the core,
or a big scary comment on why this is needed.

If fixed,
Reviewed-by: Maarten Lankhorst 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [CI v4 1/3] drm/i915/guc: Disable send function on fini

On pe, 2017-05-26 at 11:13 +, Michal Wajdeczko wrote:
> In earlier patch 789a625 we were enabling send function only
> after successful init. For completeness, we should make sure
> that we disable it on fini.
> 
> v2: don't group steps by submission flag (Chris)
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Joonas Lahtinen 
> Cc: Daniele Ceraolo Spurio 
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson 

Not worthy Fixes: ?

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Enable guest i915 full ppgtt functionality

On ma, 2017-05-22 at 16:19 +0800, Tina Zhang wrote:
> Enable the guest i915 full ppgtt functionality when host can provide this
> capability. vgt_caps is introduced to guest i915 driver to get the vgpu
> capabilities from the device model. VGT_CPAS_FULL_PPGTT is one of the
> capabilities type to let guest i915 dirver know that the guest i915 full
> ppgtt is supported by device model.
> 
> Changes since v1:
> - Use u32 instead of uint32_t (Joonas)
> - Move VGT_CAPS_FULL_PPGTT introduction to this patch and use #define
>   instead of enum (Joonas)
> - Rewrite the vgpu full ppgtt capability checking logic. (Joonas)
> - Some coding style refine. (Joonas)
> 
> Changes since v2:
> - Divide the whole patch set into two separate patch series, with one
>   patch in i915 side to check guest i915 full ppgtt capability and enable
>   it when this capability is supported by the device model, and the other
>   one in gvt side which fixs the blocking issue and enables the device
>   model to provide the capability to guest. And this patch focuses on guest
>   i915 side. (Joonas)
> - Change the title from "introduce vgt_caps to pvinfo" to
>   "Enable guest i915 full ppgtt functionality". (Tina)
> 
> Reviewed-by: Joonas Lahtinen 
> Signed-off-by: Tina Zhang 

I just noticed there is INTEL_VGT_IF_VERSION when I was looking to make
sure that vgt_if is zeroed. Neither the version is incremented nor do I
see VGT_PVINFO_PAGE getting zeroed.

What measures are in place to make sure running a new i915 under older
DOM0 won't result in corruption?

The dependencies between i915 and gvt are rather tricky, so we'd need
INTEL_VGT_IF_VERSION minor increment and also a one line change
(zeroing of the new caps register) from gvt code to the same patch,
otherwise bisecting will break.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove toplevel struct_mutex locking from debugfs/i915_drop_caches

On to, 2017-05-25 at 16:03 +0100, Chris Wilson wrote:
> On Thu, May 25, 2017 at 05:58:33PM +0300, Joonas Lahtinen wrote:



> > 
> > Lock used to work as a serializer, isn't this going to get contended
> > now?
> 
> lockdep_set_current ?
> 
> The intention is to allow the contention to reach i915_gem_shrink where
> we have the more complex locking.

Nevermind,

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/glk: Enable cold boot for GLK DSI

2017-05-30 Thread Chauhan, Madhav

> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, May 30, 2017 12:34 PM
> To: Chauhan, Madhav ; Ville Syrjälä
> 
> Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
> ; Hiremath, Shashidhar
> 
> Subject: RE: [Intel-gfx] [PATCH 2/2] drm/i915/glk: Enable cold boot for GLK
> DSI
> 
> On Wed, 24 May 2017, "Chauhan, Madhav" 
> wrote:
> >> -Original Message-
> >> From: Nikula, Jani
> >> Sent: Wednesday, May 24, 2017 7:22 PM
> >> To: Chauhan, Madhav ; Ville Syrjälä
> >> 
> >> Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
> >> ; Hiremath, Shashidhar
> >> 
> >> Subject: RE: [Intel-gfx] [PATCH 2/2] drm/i915/glk: Enable cold boot
> >> for GLK DSI
> >>
> >> On Mon, 15 May 2017, "Chauhan, Madhav"
> 
> >> wrote:
> >> >> -Original Message-
> >> >> From: Nikula, Jani
> >> >> Sent: Monday, May 15, 2017 9:19 PM
> >> >> To: Ville Syrjälä ; Chauhan, Madhav
> >> >> 
> >> >> Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
> >> >> ; Hiremath, Shashidhar
> >> >> 
> >> >> Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915/glk: Enable cold
> >> >> boot for GLK DSI
> >> >>
> >> >> On Tue, 09 May 2017, Ville Syrjälä 
> wrote:
> >> >> > On Tue, May 09, 2017 at 06:59:25PM +0530, Madhav Chauhan wrote:
> >> >> >> As per BSEPC, if device ready bit is '0' in enable IO sequence
> >> >> >> then its a cold boot/reset scenario eg: S3/S4 resume. In these
> >> >> >> conditions we need to program certain registers and prepare
> >> >> >> port from the middle of DSI enable sequence otherwise feature
> >> >> >> like S3/S4
> >> doesn't work.
> >> >> >
> >> >> > Can't we just always follow the "cold boot" sequence? Less
> >> >> > codepaths means less bugs.
> >> >>
> >> >> I agree. Madhav?
> >> >
> >> > Cold Boot  scenario represents  when DSI controller/IO is not
> >> > initialized
> >> even once before use  eg:
> >> > 1. Connected HDMI boot with DSI panel 2. S3/S4 While normal
> >> > scenario is:
> >> > 1. Boot with DSI panel without HDMI. DSI will be initialized once
> >> > by GOP/BIOS
> >> >
> >> > If we use cold boot sequence always, normal scenario doesn’t work
> >> > as few registers can’t be Programmed as per cold boot scenario.
> >> > LP_WAKE bit
> >> (MIPI_CTRL REG) is one of the example.
> >> >
> >> > Moreover, current changes works very well for all above scenarios :).
> >>
> >> Well, no. There's a very limited set of registers that can and must
> >> only be programmed in the "cold boot" case. This patch moves all of
> >> intel_dsi_prepare() for glk to only be done in the cold boot case,
> >> but there's a load of registers that aren't restricted in this way,
> >> and need to be programmed on enable regardless of device ready. Seems
> >> to me the change here is too coarse grained.
> >
> > Actually when we do GLK_MIPIIO_ENABLE in device_ready all the
> > registers are restored back When DSI is enabled after disable through
> > software *IF* power is not lost(normal scenario) so we can opt out not
> > to program during normal scenario. Found this in my testing.  Will
> > confirm this with HW team.
> >
> > While for cold boot scenario where power is lost during S3/S4, we need
> > to program all these registers And unfortunately when we program
> > *ONLY* register mentioned in BSPEC in device_ready DSI is not up and
> > Need to program all registers here itself to make it work.
> 
> But this assumes that on enable, when power has not been lost, all the
> registers contain the correct information already. We can't rely on that.

Can we try following then??
glk_dsi_device_ready()
{
-
-
Intel_dsi_prepare();// Call dsi_prepare for both the scenarios i.e. 
cold boot, normal scenario
--
-
}

> 
> BR,
> Jani.
> 
> 
> 
> >
> >>
> >> BR,
> >> Jani.
> >>
> >> >
> >> >>
> >> >> BR,
> >> >> Jani.
> >> >>
> >> >>
> >> >> >
> >> >> >>
> >> >> >> Signed-off-by: Madhav Chauhan 
> >> >> >> ---
> >> >> >>  drivers/gpu/drm/i915/intel_dsi.c | 79
> >> >> >> 
> >> >> >>  1 file changed, 48 insertions(+), 31 deletions(-)
> >> >> >>
> >> >> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> >> >> >> b/drivers/gpu/drm/i915/intel_dsi.c
> >> >> >> index fc0ef49..6b68864 100644
> >> >> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
> >> >> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> >> >> >> @@ -346,12 +346,17 @@ static bool
> >> >> >> intel_dsi_compute_config(struct
> >> >> intel_encoder *encoder,
> >> >> >>  return true;
> >> >> >>  }
> >> >> >>
> >> >> >> -static void glk_dsi_device_ready(struct intel_encoder
> >> >> >> *encoder)
> >> >> >> +static void intel_dsi_prepare(struct intel_encoder *intel_encoder,
> >> >> >> +  struct intel_crtc_state *pipe_config);
> >> >> >> +
> >> >> >> +static void glk_dsi_device_ready(struct intel_encoder *encoder,
> >> >> >> + struct intel_crtc_state *pipe_config)
> >> >> >>  {
> >> >> >>  struct drm_i9

Re: [Intel-gfx] [PATCH 1/3] drm/i915/skl+: Don't trust cached ddb values

2017-05-30 Thread Maarten Lankhorst

Op 26-05-17 om 17:15 schreef Mahesh Kumar:
> Don't trust cached DDB values. Recalculate the ddb value if cached value
> is zero.
>
> If i915 is build as a module, there may be a race condition when
> cursor_disable call comes even before intel_fbdev_initial_config.
> Which may lead to cached value being 0. And further commit will fail
> until a modeset.
>
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 936eef1634c7..b67be1355e39 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3721,6 +3721,7 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
> *dev,
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct drm_crtc *for_crtc = cstate->base.crtc;
>   unsigned int pipe_size, ddb_size;
> + unsigned int active_crtcs;
>   int nth_active_pipe;
>  
>   if (WARN_ON(!state) || !cstate->base.active) {
> @@ -3731,10 +3732,11 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
> *dev,
>   }
>  
>   if (intel_state->active_pipe_changes)
> - *num_active = hweight32(intel_state->active_crtcs);
> + active_crtcs = intel_state->active_crtcs;
>   else
> - *num_active = hweight32(dev_priv->active_crtcs);
> + active_crtcs = dev_priv->active_crtcs;
>  
> + *num_active = hweight32(active_crtcs);
>   ddb_size = INTEL_INFO(dev_priv)->ddb_size;
>   WARN_ON(ddb_size == 0);
>  
> @@ -3754,12 +3756,15 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
> *dev,
>* copy from old state to be sure
>*/
>   *alloc = to_intel_crtc_state(for_crtc->state)->wm.skl.ddb;
> - return;
> + if (!skl_ddb_entry_size(alloc))
> + DRM_DEBUG_KMS("Cached pipe DDB is 0 recalculate\n");
> + else
> + return;
>   }
>  
> - nth_active_pipe = hweight32(intel_state->active_crtcs &
> + nth_active_pipe = hweight32(active_crtcs &
>   (drm_crtc_mask(for_crtc) - 1));
> - pipe_size = ddb_size / hweight32(intel_state->active_crtcs);
> + pipe_size = ddb_size / hweight32(active_crtcs);
>   alloc->start = nth_active_pipe * ddb_size / *num_active;
>   alloc->end = alloc->start + pipe_size;
>  }

I'd love it if you also add a warning somewhere for active pipe with no ddb 
allocation to prevent this from reoccuring in the future. :)
But with the root cause being a invalid ddb allocation at boot, won't the below 
one liner should fix it too, but better?

I'l ltest it when f3-kbl becomes available again.

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a488e068c3d6..63a47909f618 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5051,7 +5051,7 @@ skl_compute_wm(struct drm_atomic_state *state)
 */
for_each_new_crtc_in_state(state, crtc, cstate, i)
changed = true;
-   if (!changed)
+   if (!changed && !to_i915(state->dev)->wm.distrust_bios_wm)
return 0;
 
/* Clear all dirty flags */

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g

2017-05-30 Thread Gerd Hoffmann

  Hi,

> This patch set adds the dma-buf support for intel GVT-g.
> dma-buf is a uniform mechanism to share DMA buffers across different
> devices and sub-systems.
> dma-buf for intel GVT-g is mainly used to share the vgpu's
> framebuffer
> to other users or sub-systems so they can use the dma-buf to show the
> desktop of a vm which uses intel vgpu.

Which branch is this based on?
Applying to gvt-stable-4.11 doesn't work.
Applying to drm-intel-next doesn't work either ...

cheers,
  Gerd
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 05/12] drm/i915: Add plumbing for digital connector state, v3.

2017-05-30 Thread Maarten Lankhorst

Hey,

Op 02-05-17 om 11:56 schreef Daniel Vetter:
> On Mon, May 01, 2017 at 03:37:57PM +0200, Maarten Lankhorst wrote:
>> Some atomic properties are common between the various kinds of
>> connectors, for example a lot of them use panel fitting mode.
>> It makes sense to put a lot of it in a common place, so each
>> connector can use it while they're being converted.
>>
>> Implement the properties required for the connectors:
>> - scaling mode property
>> - force audio property
>> - broadcast rgb
>> - aspect ratio
>>
>> While at it, make clear that intel_digital_connector_atomic_get_property
>> is a hack that has to be removed when all connector properties
>> are converted to atomic.
>>
>> Changes since v1:
>> - Scaling mode and aspect ratio are partly handled in core now.
>> Changes since v2:
>> - Split out the scaling mode / aspect ratio changes to a preparation
>>   patch.
>> - Use mode_changed for panel fitter, changes to this property
>>   are checked by fastset.
>> - Allowed_scaling_modes is removed, handled through core now.
>>
>> Signed-off-by: Maarten Lankhorst 
> Patches 3-5: Reviewed-by: Daniel Vetter 
>
> Pls ping Dave for an Ack for getting the first 2 landed through drm-intel
> (they'll still show up in the first pull request right after -rc1, so all
> good imo).
Merged, thanks for review.

~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [i-g-t PATCH v2 1/4] lib/igt_core: Add igt_exec helpers

2017-05-30 Thread Abdiel Janulgue

On 29.05.2017 16:01, Chris Wilson wrote:
> On Mon, May 29, 2017 at 03:08:07PM +0300, Abdiel Janulgue wrote:
>> Support executing external processes with the goal of capturing its
>> standard streams to the igt logging infrastructure in addition to its
>> exit status.
> 
> This is not an exec wrapper. This is a system() replacement. That it
> invokes shell to evaluate the cmd should be front and centre.
> -Chris
> 

The problem with system() is that it waits until the process is
completed. If the process' output is more than PIPE_BUF, it'll block. Do
you have any suggestions?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [i-g-t PATCH v2 1/4] lib/igt_core: Add igt_exec helpers

On Tue, May 30, 2017 at 01:31:46PM +0300, Abdiel Janulgue wrote:
> 
> 
> On 29.05.2017 16:01, Chris Wilson wrote:
> > On Mon, May 29, 2017 at 03:08:07PM +0300, Abdiel Janulgue wrote:
> >> Support executing external processes with the goal of capturing its
> >> standard streams to the igt logging infrastructure in addition to its
> >> exit status.
> > 
> > This is not an exec wrapper. This is a system() replacement. That it
> > invokes shell to evaluate the cmd should be front and centre.
> > 
> 
> The problem with system() is that it waits until the process is
> completed. If the process' output is more than PIPE_BUF, it'll block. Do
> you have any suggestions?

I'm just saying the name is misleading. igt_system() and explain the
improvements (concurrency and accessible piped output).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6] drm/i915: return the correct usable aperture size under gvt environment

On pe, 2017-05-26 at 09:37 +0800, Weinan Li wrote:
> I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace.
> In gvt environment, each vm only use the ballooned part of aperture, so we
> should return the correct available aperture size exclude the reserved part
> by balloon.
> 
> v2: add 'reserved' in struct i915_address_space to record the reserved size
> in ggtt (Chris)
> 
> v3: remain aper_size as total, adjust aper_available_size exclude reserved
> and pinned. UMD driver need to adjust the max allocation size according to
> the available aperture size but not total size. KMD return the correct
> usable aperture size any time (Chris, Joonas)
> 
> v4: decrease reserved in deballoon (Joonas)
> 
> v5: add onion teardown in balloon, add vgt_deballoon_space (Joonas)
> 
> v6: change title name (Zhenyu)
> 
> Suggested-by: Chris Wilson 
> Suggested-by: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Zhenyu Wang 
> Signed-off-by: Weinan Li 



> @@ -156,8 +156,8 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
>   mutex_unlock(&dev->struct_mutex);
>  
>   args->aper_size = ggtt->base.total;
> - args->aper_available_size = args->aper_size - pinned;
> -
> + args->aper_available_size = args->aper_size -
> + ggtt->base.reserved - pinned;

Wrong indentation here.

> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -92,6 +92,17 @@ struct _balloon_info_ {
>  
>  static struct _balloon_info_ bl_info;
>  
> +static void vgt_deballoon_space(struct i915_ggtt *ggtt,
> +  struct drm_mm_node *node)

Ditto.

> +{
> + DRM_INFO("deballoon space: range [ 0x%llx - 0x%llx ] %llu KiB.\n",
> +  node->start, node->start + node->size, node->size / 1024);
> +
> + ggtt->base.reserved -= node->size;
> + drm_mm_remove_node(node);
> + memset(node, 0, sizeof(*node));

memset() is not needed.

> @@ -127,9 +135,14 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
>  
>   DRM_INFO("balloon space: range [ 0x%lx - 0x%lx ] %lu KiB.\n",
>    start, end, size / 1024);
> - return i915_gem_gtt_reserve(&ggtt->base, node,
> + ret = i915_gem_gtt_reserve(&ggtt->base, node,
>   size, start, I915_COLOR_UNEVICTABLE,
>   0);
> + if (!ret)
> + ggtt->base.reserved += size;
> + else
> + memset(node, 0, sizeof(*node));

memset() is not needed.

> + return ret;
>  }
>  
>  /**
> @@ -215,14 +228,14 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
>   ggtt->mappable_end, unmappable_base);
>  
>   if (ret)
> - goto err;
> + goto err_out;

"err" is a good enough label for last level error path. "out" is used
when the path is also taken on a successful call of the function.

>   }
>  
>   if (unmappable_end < ggtt_end) {
>   ret = vgt_balloon_space(ggtt, &bl_info.space[3],
>   unmappable_end, ggtt_end);
>   if (ret)
> - goto err;
> + goto err_deballoon_upon_mappable;

This function is about ballooning, so "deballoon" is bit verbose. Just
"err_upon_mappable".

I commented about the whitespace issues and memsets in previous
revisions already, so please go through the review comments
systematically to expedite further reviews.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add kerneldoc to describe i915_gem_object.vma_list

On Tue, May 30, 2017 at 11:11:44AM +0300, Joonas Lahtinen wrote:
> On to, 2017-05-25 at 21:48 +0100, Chris Wilson wrote:
> > Add kerneldoc for the vma_list stored on the i915_gem_object, in
> > particular, documenting the expected ordering of elements -- i.e. that
> > we do expect GGTT VMA first followed by the ppGTT VMA.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> 
> Reviewed-by: Joonas Lahtinen 

Pushed the kerneldoc, thanks for the suggestion and review.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] igt: Fix detection of missing flex

2017-05-30 Thread Petri Latvala

On Fri, May 26, 2017 at 12:11:04PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> AM_PROG_FLEX macro will set the LEX variable using the missing
> script when the flex is not present. This will confuse the
> configure.ac check, which expects the AC_PROG_FLEX behaviour,
> and will so fail to detect the missing flex:
> 
>   AS_IF([test x"$LEX" != "x:" -a x"$YACC" != xyacc],
>   [enable_assembler=yes],
>   [enable_assembler=no])
> 
> This is because AM_PROG_LEX sets the LEX variable to
> "${SHELL} /home/sc/intel-gpu-tools/build-aux/missing flex",
> while AC_PROG_LEX would set it to ":".


Good catch!


> 
> If for some reason we really need to keep AM_PROG_LEX,
> alternative fix could be something like this placed before
> the above AS_IF check:
> 
>   AC_MSG_CHECKING([checking for working flex])
>   if ! eval "$LEX --version >/dev/null 2>&1"; then
>   AC_MSG_RESULT([failed])
>   LEX=:
>   else
>   AC_MSG_RESULT([pass])
>   fi
> 
> Note the evil eval needed to recursively expand variables.


As far as I can tell, A*_PROG_LEX is only used to be able to select
whether to build the assembler. In other words, we don't need to
AM_PROG_LEX behaviour.

There's still a bug left though: If flex is not found, but lex is,
AC_PROG_LEX sets $LEX to 'lex', but assembler/Makefile.am hardcodes
'flex -i' anyway if the assembler is enabled. That still happens
whether AM_ or AC_ is used so this patch is still an improvement.


I would also like to note that the ratio of
characters-in-commit-message to characters-changed-in-code is quite
the winner. :P



Reviewed-by: Petri Latvala 




> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 5342e33c8293..82857a8325b1 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -40,7 +40,7 @@ AM_INIT_AUTOMAKE([1.12 foreign subdir-objects dist-bzip2])
>  AM_PATH_PYTHON([3],, [:])
>  
>  AC_PROG_CC
> -AM_PROG_LEX
> +AC_PROG_LEX
>  AC_PROG_YACC
>  
>  # check for gtk-doc
> -- 
> 2.9.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 00/11] HDMI YCBCR output handling in DRM layer

This patch series adds DRM layer support for YCBCR HDMI output handling.
The target HDMI YCBCR outputs are:
- YCBCR444
- YCBCR422
- YCBCR420

As YCBCR420 output is added in HDMI 2.0, this patch series also
contain few patches to handle new EDID extention blocks, added
for YCBCR420 modes (CEA-861-F)

First two patches, complete the CEA modedb in drm driver, by adding
new 4k modes. Current CEA modedb contains 64 modes only (VIC 1-64),
whereas YCBCR420 output can support 4k modes, from VIC range 93-107.
First patch makes sure that it doesn't break existing HDMI 1.4 monitors,
adding new VICs.

Next 3 patches, parse and accomodate YCBCR420 suppor information from the
sink, and stores into display info strucure. This contains parsing YCBCR420
supported modes, and deep color information.

Next 2 patch create a property (hdmi_output) using which, as userspace can
set its preferred HDMI output from RGB, YCBCR444/422/420 etc. Default value
of the property is set to RGB(0) so that it doesnt affect existing
implementations. Other patch takes care of setting AVI IF colorspace as per
the selected output.

Last 3 patches contain implementation of YCBCR output in I915 HDMI subsystem.

V2: 
- V1 of this patch series was handling both VDB(YCBCR420 only) and VCB
  (YCBCR420 also) EDID blocks to extract YCBCR420 modes. This series
  handles only VCB blocks, a follow up series will handle VDB blocks.

This series is tested on Intel GLK platform, using ASTRO-VA-1844A HDMI
tester.

Shashank Sharma (11):
  drm: Add HDMI 2.0 VIC support for AVI info-frames
  drm/edid: Complete CEA modedb(VIC 1-107)
  drm: parse ycbcr420 cmdb block
  drm: parse ycbcr 420 deep color information
  drm: create hdmi output property
  drm: set output colorspace in AVI infoframe
  drm: add ycbcr helper functions
  drm/i915: handle ycbcr outputs
  drm/i915: handle csc for ycbcr HDMI output
  drm/i915: prepare ycbcr420 modeset
  drm/i915: set colorspace for ycbcr outputs

 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |   2 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c |   3 +-
 drivers/gpu/drm/bridge/sii902x.c  |   2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |   2 +-
 drivers/gpu/drm/drm_atomic.c  |   2 +
 drivers/gpu/drm/drm_atomic_helper.c   |   4 +
 drivers/gpu/drm/drm_connector.c   |  32 +++
 drivers/gpu/drm/drm_edid.c| 402 +-
 drivers/gpu/drm/drm_modes.c   | 177 +
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c |   2 +-
 drivers/gpu/drm/i915/i915_reg.h   |   3 +
 drivers/gpu/drm/i915/intel_atomic.c   |   6 +
 drivers/gpu/drm/i915/intel_color.c|  47 +++-
 drivers/gpu/drm/i915/intel_display.c  |  67 +
 drivers/gpu/drm/i915/intel_drv.h  |  13 +-
 drivers/gpu/drm/i915/intel_hdmi.c | 149 ++-
 drivers/gpu/drm/i915/intel_panel.c|   3 +-
 drivers/gpu/drm/i915/intel_sdvo.c |   3 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |   2 +-
 drivers/gpu/drm/omapdrm/omap_encoder.c|   3 +-
 drivers/gpu/drm/radeon/radeon_audio.c |   2 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c  |   2 +-
 drivers/gpu/drm/sti/sti_hdmi.c|   2 +-
 drivers/gpu/drm/tegra/hdmi.c  |   2 +-
 drivers/gpu/drm/tegra/sor.c   |   2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c|   2 +-
 drivers/gpu/drm/zte/zx_hdmi.c |   2 +-
 include/drm/drm_connector.h   |  33 +++
 include/drm/drm_edid.h|  14 +-
 include/drm/drm_mode_config.h |   5 +
 include/drm/drm_modes.h   |  16 ++
 34 files changed, 981 insertions(+), 31 deletions(-)

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

V2: Rebase, Added r-b from Andrzej

Reviewed-by: Andrzej Hajda 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
 drivers/gpu/drm/bridge/sii902x.c  |  2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
 drivers/gpu/drm/drm_edid.c| 12 +++-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
 drivers/gpu/drm/i915/intel_hdmi.c |  5 -
 drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
 drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
 drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
 drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
 drivers/gpu/drm/tegra/hdmi.c  |  2 +-
 drivers/gpu/drm/tegra/sor.c   |  2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
 drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
 include/drm/drm_edid.h|  3 ++-
 21 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 3c62c45..4923ddc 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index c8ed0fa..4101684 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 3e90c19..a7f6b32 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v8_0_audio_write_sad_regs(encoder);
dce_v8_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..f9b77b8 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge 
*bridge,
 
mutex_lock(&anx78xx->lock);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, adjusted_mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, adjusted_mode,
+  false);
if (err) {
DRM_ERROR("Failed to setup AVI infoframe: %d\n", err);
goto unlock;
diff --git a/drivers/gp

[Intel-gfx] [PATCH v2 02/11] drm/edid: Complete CEA modedb(VIC 1-107)

CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

The patch was originaly discussed and reviewed here:
https://patchwork.freedesktop.org/patch/135810/

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Harry Wentland 

V2: Rebase

Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 
Acked-by: Harry Wentland 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 215 +
 1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8b23435..c3fa3a1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] = 
{
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080@50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 76 - 1920x1080@60Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .p

[Intel-gfx] [PATCH v2 04/11] drm: parse ycbcr 420 deep color information

CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.

Cc: Ville Syrjälä 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  | 15 +++
 include/drm/drm_connector.h |  3 +++
 include/drm/drm_edid.h  |  5 +
 3 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ce86528..50fa96e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4142,6 +4142,19 @@ drm_default_rgb_quant_range(const struct 
drm_display_mode *mode)
 }
 EXPORT_SYMBOL(drm_default_rgb_quant_range);
 
+static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
+const u8 *db)
+{
+   struct drm_hdmi_info *info = &connector->display_info.hdmi;
+
+   if (db[7] & DRM_EDID_YCBCR420_DC_48)
+   info->ycbcr420_dc_modes |= DRM_EDID_YCBCR420_DC_48;
+   if (db[7] & DRM_EDID_YCBCR420_DC_36)
+   info->ycbcr420_dc_modes |= DRM_EDID_YCBCR420_DC_36;
+   if (db[7] & DRM_EDID_YCBCR420_DC_30)
+   info->ycbcr420_dc_modes |= DRM_EDID_YCBCR420_DC_30;
+}
+
 static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
 const u8 *hf_vsdb)
 {
@@ -4182,6 +4195,8 @@ static void drm_parse_hdmi_forum_vsdb(struct 
drm_connector *connector,
scdc->scrambling.low_rates = true;
}
}
+
+   drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
 }
 
 static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 07b10ab..49cc38c 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -148,6 +148,9 @@ struct drm_hdmi_info {
 
/** @ycbcr420_vcb_map: bitmap of SVD index, to extraxt vcb modes */
u64 ycbcr420_vcb_map;
+
+   /** @ycbcr420_dc_modes: bitmap of deep color support index */
+   u8 ycbcr420_dc_modes;
 };
 
 /**
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index c07eb81..a4d174e7 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -213,6 +213,11 @@ struct detailed_timing {
 #define DRM_EDID_HDMI_DC_30   (1 << 4)
 #define DRM_EDID_HDMI_DC_Y444 (1 << 3)
 
+/* YCBCR 420 deep color modes */
+#define DRM_EDID_YCBCR420_DC_48  (1 << 6)
+#define DRM_EDID_YCBCR420_DC_36  (1 << 5)
+#define DRM_EDID_YCBCR420_DC_30  (1 << 4)
+
 /* ELD Header Block */
 #define DRM_ELD_HEADER_BLOCK_SIZE  4
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 05/11] drm: create hdmi output property

HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
 - RGB
 - YCBCR 444
 - YCBCR 422
 - YCBCR 420

This patch adds a drm property, using which, a userspace
can specify its preference, for the HDMI output type.
The output type enums are similar to the mentioned outputs
above. To handle various subsampling of YCBCR output types,
this property allows two special cases:
 - DRM_HDMI_OUTPUT_YCBCR_HQ
This indicates preferred output should be YCBCR output, with highest
subsampling rate by the source/sink, which can be typically:
 - ycbcr444
 - ycbcr422
 - ycbcr420
 - DRM_HDMI_OUTPUT_YCBCR_LQ
This indicates preferred output should be YCBCR output, with lowest
subsampling rate supported by source/sink, which can be:
 - ycbcr420
 - ycbcr422
 - ycbcr444

Default value of the property is set to 0 = RGB, so no changes if you
dont set the property.

V2: Added description for the new variable to address build warning

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_atomic.c|  2 ++
 drivers/gpu/drm/drm_atomic_helper.c |  4 
 drivers/gpu/drm/drm_connector.c | 32 
 include/drm/drm_connector.h | 18 ++
 include/drm/drm_mode_config.h   |  5 +
 5 files changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e163701..8c4e040 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+   } else if (property == config->hdmi_output_property) {
+   state->hdmi_output = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 636e561..86b1780 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -567,6 +567,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->hdmi_output !=
+   new_connector_state->hdmi_output)
+   new_crtc_state->connectors_changed = true;
}
 
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5cd61af..f3c5928 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -227,6 +227,11 @@ int drm_connector_init(struct drm_device *dev,
  config->edid_property,
  0);
 
+   if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)
+   drm_object_attach_property(&connector->base,
+  config->hdmi_output_property,
+  0);
+
drm_object_attach_property(&connector->base,
  config->dpms_property, 0);
 
@@ -617,6 +622,26 @@ static const struct drm_prop_enum_list 
drm_link_status_enum_list[] = {
 };
 DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
 
+static const struct drm_prop_enum_list drm_hdmi_output_enum_list[] = {
+   { DRM_HDMI_OUTPUT_DEFAULT_RGB, "output_rgb" },
+   { DRM_HDMI_OUTPUT_YCBCR444, "output_ycbcr444" },
+   { DRM_HDMI_OUTPUT_YCBCR422, "output_ycbcr422" },
+   { DRM_HDMI_OUTPUT_YCBCR420, "output_ycbcr420" },
+   { DRM_HDMI_OUTPUT_YCBCR_HQ, "output_ycbcr_high_subsampling" },
+   { DRM_HDMI_OUTPUT_YCBCR_LQ, "output_ycbcr_low_subsampling" },
+   { DRM_HDMI_OUTPUT_INVALID, "invalid_output" },
+};
+
+/**
+ * drm_get_hdmi_output_name - return a string for a given hdmi output enum
+ * @type: enum of output type
+ */
+const char *drm_get_hdmi_output_name(enum drm_hdmi_output_type type)
+{
+   return drm_hdmi_output_enum_list[type].name;
+}
+EXPORT_SYMBOL(drm_get_hdmi_output_name);
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -789,6 +814,13 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.link_status_property = prop;
 
+   prop = drm_property_create_enum(dev, 0, "hdmi_output_format",
+   drm_hdmi_outp

[Intel-gfx] [PATCH v2 07/11] drm: add ycbcr helper functions

This patch adds helper functions for ycbcr HDMI output handling.
These functions provide functionality like:
- getting the highest subsamled ycbcr output
- getting the lowest subsamled ycbcr output
- check if a given source and sink combination can support any YCBCR output
- check if a given source and sink combination can support a particular
  YCBCR output
- check if a give mode can be driven in YCBCR420 subsampling.

These functions will be used in next few patches in this
series from I915 driver.

V2: Added YCBCR functions as helpers in DRM layer, instead of
keeping it in I915 layer

Cc: Ville Syrjala 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  |   2 +-
 drivers/gpu/drm/drm_modes.c | 177 
 include/drm/drm_edid.h  |   1 +
 include/drm/drm_modes.h |  16 
 4 files changed, 195 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 98e00ce..a9d9b1a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2949,7 +2949,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
 }
 EXPORT_SYMBOL(drm_match_cea_mode);
 
-static bool drm_valid_cea_vic(u8 vic)
+bool drm_valid_cea_vic(u8 vic)
 {
return vic > 0 && vic < ARRAY_SIZE(edid_cea_modes);
 }
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f2493b9..43c630e 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1576,3 +1576,180 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
 out:
return ret;
 }
+
+/**
+ * drm_mode_is_420 - if a given videomode can be supported in YCBCR420
+ * output format also
+ *
+ * @connector: drm connector under action.
+ * @mode: video mode to be tested.
+ *
+ * Returns:
+ * true if the mode can support YCBCR420 output
+ * false if not.
+ */
+bool drm_mode_is_420(struct drm_display_info *display,
+   struct drm_display_mode *mode)
+{
+   u8 vic = drm_match_cea_mode(mode);
+   u32 *vcb_map;
+   u8 index;
+
+   if (!drm_valid_cea_vic(vic))
+   return false;
+   /*
+* ycbcr420_vcb_modes is a fix position 128 bit bitmap. This indicates
+* support for ycbcr420 output per VIC. Arrangement is bit[n] indicates
+* if vic[n+1] supports ycbcr420 output.
+* ycbcr420_vcb_modes[0] = |VIC=32 |VIC=31 ||VIC=2 |VIC=1 |
+* ycbcr420_vcb_modes[1] = |VIC=64 |VIC=63 ||VIC=34|VIC=33|
+* ycbcr420_vcb_modes[2] = |VIC=96 |VIC=95 ||VIC=66|VIC=65|
+* ycbcr420_vcb_modes[3] = |VIC=128|VIC=127||VIC=34|VIC=97|
+*/
+   vcb_map = &(display->hdmi.ycbcr420_vcb_modes[(vic - 1) / 32]);
+   index = (vic - 1) % 32;
+   return  *vcb_map & (1 << index);
+}
+
+/**
+ * drm_can_support_this_ycbcr_output - can a given source and sink combination
+ * support a particular YCBCR output type.
+ *
+ * @display: sink information.
+ * @mode: video mode from modeset
+ * @type: enum indicating YCBCR output type
+ * @source_outputs: bitmap of source supported HDMI output formats.
+ *
+ * Returns:
+ * true on success.
+ * false on failure.
+ */
+bool drm_can_support_this_ycbcr_output(struct drm_display_info *display,
+   struct drm_display_mode *mode,
+   enum drm_hdmi_output_type type,
+   u32 source_outputs)
+{
+   /* YCBCR420 output support can be per mode basis */
+   if (type == DRM_HDMI_OUTPUT_YCBCR420 &&
+   !drm_mode_is_420(display, mode))
+   return false;
+
+   return display->color_formats & source_outputs & type;
+}
+
+/**
+ * drm_can_support_any_ycbcr_output - can a given source and sink combination
+ * support any YCBCR outputs.
+ *
+ * @display: sink information.
+ * @source_outputs: bitmap of source supported HDMI output formats.
+ *
+ * Returns:
+ * true on success.
+ * false on failure.
+ */
+bool drm_can_support_any_ycbcr_output(struct drm_display_info *display,
+   u32 source_outputs)
+{
+   u32 supported_formats;
+
+   if (!source_outputs || !display->color_formats) {
+   DRM_DEBUG_KMS("Source/Sink doesn't support any output ?\n");
+   return DRM_HDMI_OUTPUT_INVALID;
+   }
+
+   /* Get the common supported fromats between source and sink */
+   supported_formats = display->color_formats & source_outputs;
+   if (!supported_formats || (supported_formats ==
+   DRM_COLOR_FORMAT_RGB444)) {
+   DRM_ERROR("No common YCBCR formats between source and sink\n");
+   return false;
+   }
+
+   DRM_DEBUG_KMS("Src and Sink combination can support YCBCR output\n");
+   return true;
+}
+
+/**
+ * drm_get_highest_quality_ycbcr_supported - get the ycbcr output mode
+ * with highest subsampl

[Intel-gfx] [PATCH v2 08/11] drm/i915: handle ycbcr outputs

This patch adds support for HDMI ycbcr outputs in i915 layer.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.

V2: Split the patch into two, kept helper functions in DRM layer

Cc: Ville Syrjala 
Cc: Daniel Vetter 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_display.c |   1 +
 drivers/gpu/drm/i915/intel_drv.h |   3 +
 drivers/gpu/drm/i915/intel_hdmi.c| 125 ++-
 3 files changed, 126 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7fa21df..58907b3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11888,6 +11888,7 @@ intel_pipe_config_compare(struct drm_i915_private 
*dev_priv,
PIPE_CONF_CHECK_I(hdmi_scrambling);
PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
PIPE_CONF_CHECK_I(has_infoframe);
+   PIPE_CONF_CHECK_I(hdmi_output);
 
PIPE_CONF_CHECK_I(has_audio);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index bd50097..a56e260 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -771,6 +771,9 @@ struct intel_crtc_state {
 
/* HDMI High TMDS char rate ratio */
bool hdmi_high_tmds_clock_ratio;
+
+   /* HDMI output type */
+   enum drm_hdmi_output_type hdmi_output;
 };
 
 struct intel_crtc {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 702cbab..4b27b5d 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1301,7 +1301,8 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
return status;
 }
 
-static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
+static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state,
+   enum drm_hdmi_output_type hdmi_out)
 {
struct drm_i915_private *dev_priv =
to_i915(crtc_state->base.crtc->dev);
@@ -1313,6 +1314,16 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
if (HAS_GMCH_DISPLAY(dev_priv))
return false;
 
+   if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR422) {
+   /*
+* HDMI spec says YCBCR422 is 12bpc, but its not a deep
+* color format. So respect the spec, and not allow this
+* to be deep color
+*/
+   DRM_DEBUG_KMS("Not allowing deep color for YCBCR422 output\n");
+   return false;
+   }
+
/*
 * HDMI 12bpc affects the clocks, so it's only possible
 * when not cloning with other encoder types.
@@ -1326,6 +1337,12 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
if (connector_state->crtc != crtc_state->base.crtc)
continue;
 
+   if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR420) {
+   if (!(info->hdmi.ycbcr420_dc_modes &
+   DRM_EDID_YCBCR420_DC_36))
+   return false;
+   }
+
if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0)
return false;
}
@@ -1338,6 +1355,95 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
return true;
 }
 
+static u8
+intel_hdmi_get_src_output_support(struct drm_connector *connector)
+{
+   struct drm_i915_private *dev_priv = connector->dev->dev_private;
+   u8 supported_outputs = DRM_COLOR_FORMAT_RGB444;
+
+   if (dev_priv->info.gen < 7)
+   return supported_outputs;
+
+   /* Gen 7 and above support HDMI 1.4b outputs */
+   supported_outputs |= (DRM_COLOR_FORMAT_YCRCB444 |
+   DRM_COLOR_FORMAT_YCRCB422);
+
+   if (IS_GEMINILAKE(dev_priv))
+   supported_outputs |= DRM_COLOR_FORMAT_YCRCB420;
+
+   return supported_outputs;
+}
+
+static enum drm_hdmi_output_type
+intel_hdmi_compute_ycbcr_config(struct drm_connector_state *conn_state,
+  struct intel_crtc_state *config,
+  int *clock_12bpc, int *clock_8bpc)
+{
+   struct drm_connector *connector = conn_state->connector;
+   struct drm_display_info *info = &connector->display_info;
+   struct drm_display_mode *mode = &config->base.adjusted_mode;
+   enum drm_hdmi_output_type type = conn_state->hdmi_output;
+   u8 src_output_cap = intel_hdmi_get_src_output_support(connector);
+
+   /* If  this src/sink combination can support any YCBCR output */
+   if (!drm_can_support_any_ycbcr_output(info, src_output_cap)) {
+   DRM_ERROR("No support

[Intel-gfx] [PATCH v2 06/11] drm: set output colorspace in AVI infoframe

HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.

As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI infoframes.

V2: Rebase

Cc: Ville Syrjala 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 40 
 include/drm/drm_edid.h |  5 +
 2 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 50fa96e..98e00ce 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4728,6 +4728,46 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
 
 /**
+ * drm_hdmi_avi_infoframe_set_colorspace() - fill an HDMI AVI infoframe with
+ * colorspace data of the output type
+ *
+ * @frame: HDMI AVI infoframe
+ * @mode: DRM display mode
+ * @hdmi_output: HDMI output colorspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output)
+{
+   switch (hdmi_output) {
+   case DRM_HDMI_OUTPUT_YCBCR444:
+   frame->colorspace = HDMI_COLORSPACE_YUV444;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR422:
+   frame->colorspace = HDMI_COLORSPACE_YUV422;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR420:
+   frame->colorspace = HDMI_COLORSPACE_YUV420;
+   frame->pixel_repeat = 0;
+   break;
+   case DRM_HDMI_OUTPUT_DEFAULT_RGB:
+   frame->colorspace = HDMI_COLORSPACE_RGB;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR_HQ:
+   case DRM_HDMI_OUTPUT_YCBCR_LQ:
+   case DRM_HDMI_OUTPUT_INVALID:
+   DRM_ERROR("Invalid HDMI output type\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_set_colorspace);
+
+/**
  * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
  *quantization range information
  * @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index a4d174e7..8980366 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -329,6 +329,7 @@ struct cea_sad {
 struct drm_encoder;
 struct drm_connector;
 struct drm_display_mode;
+enum drm_hdmi_output_type;
 
 void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
 int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -351,6 +352,10 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2);
 int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output);
+int
 drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe 
*frame,
const struct drm_display_mode 
*mode);
 void
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 11/11] drm/i915: set colorspace for ycbcr outputs

When HDMI output is other than RGB, we have to load the
corresponding colorspace of output mode. This patch fills
the colorspace of AVI infoframe as per the HDMI output mode.

Cc: Ville Syrjala 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 5051347..ad5bd95 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -472,6 +472,14 @@ static void intel_hdmi_set_avi_infoframe(struct 
drm_encoder *encoder,
return;
}
 
+   ret = drm_hdmi_avi_infoframe_set_colorspace(&frame.avi,
+   adjusted_mode,
+   crtc_state->hdmi_output);
+   if (ret < 0) {
+   DRM_ERROR("couldn't fill AVI colorspace\n");
+   return;
+   }
+
drm_hdmi_avi_infoframe_quant_range(&frame.avi, adjusted_mode,
   crtc_state->limited_color_range ?
   HDMI_QUANTIZATION_RANGE_LIMITED :
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 09/11] drm/i915: handle csc for ycbcr HDMI output

To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.

Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.

This function adds a csc handler, to perform RGB->YCBCR conversion
as per recommended spec values.

V2: Rebase

Cc: Ville Syrjala 
Cc: Daniel Vetter 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_color.c   | 47 +++-
 drivers/gpu/drm/i915/intel_display.c | 32 
 2 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 306c6b0..12d5f21 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,19 @@
 
 #define LEGACY_LUT_LENGTH  (sizeof(struct drm_color_lut) * 256)
 
+/* Post offset values for RGB->YCBCR conversion */
+#define POSTOFF_RGB_TO_YUV_HI 0x800
+#define POSTOFF_RGB_TO_YUV_ME 0x100
+#define POSTOFF_RGB_TO_YUV_LO 0x800
+
+/* Direct spec values for RGB->YUV conversion matrix */
+#define CSC_RGB_TO_YUV_RU_GU 0x2ba809d8
+#define CSC_RGB_TO_YUV_BU 0x37e8
+#define CSC_RGB_TO_YUV_RY_GY 0x1e089cc0
+#define CSC_RGB_TO_YUV_BY 0xb528
+#define CSC_RGB_TO_YUV_RV_GV 0xbce89ad8
+#define CSC_RGB_TO_YUV_BV 0x1e08
+
 /*
  * Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
  * format). This macro takes the coefficient we want transformed and the
@@ -91,6 +104,35 @@ static void ctm_mult_by_limited(uint64_t *result, int64_t 
*input)
}
 }
 
+void i9xx_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
+{
+   int pipe = intel_crtc->pipe;
+   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+
+   /* We don't use high values for conversion */
+   I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+   /* Program direct spec values for RGB to YCBCR conversion matrix */
+   I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), CSC_RGB_TO_YUV_RU_GU);
+   I915_WRITE(PIPE_CSC_COEFF_BU(pipe), CSC_RGB_TO_YUV_BU);
+
+   I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), CSC_RGB_TO_YUV_RY_GY);
+   I915_WRITE(PIPE_CSC_COEFF_BY(pipe), CSC_RGB_TO_YUV_BY);
+
+   I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), CSC_RGB_TO_YUV_RV_GV);
+   I915_WRITE(PIPE_CSC_COEFF_BV(pipe), CSC_RGB_TO_YUV_BV);
+
+   /* Spec postoffset values */
+   I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
+   I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
+   I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
+
+   /* CSC mode before gamma */
+   I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+}
+
 /* Set up the pipe CSC unit. */
 static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
 {
@@ -101,7 +143,10 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state 
*crtc_state)
uint16_t coeffs[9] = { 0, };
struct intel_crtc_state *intel_crtc_state = 
to_intel_crtc_state(crtc_state);
 
-   if (crtc_state->ctm) {
+   if (intel_crtc_state->hdmi_output > DRM_HDMI_OUTPUT_DEFAULT_RGB) {
+   i9xx_load_ycbcr_conversion_matrix(intel_crtc);
+   return;
+   } else if (crtc_state->ctm) {
struct drm_color_ctm *ctm =
(struct drm_color_ctm *)crtc_state->ctm->data;
uint64_t input[9] = { 0, };
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 58907b3..58e4617 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6224,6 +6224,29 @@ static void intel_crtc_compute_pixel_rate(struct 
intel_crtc_state *crtc_state)
ilk_pipe_pixel_rate(crtc_state);
 }
 
+static int intel_crtc_ycbcr_config(struct intel_crtc_state *state)
+{
+   struct drm_crtc_state *drm_state = &state->base;
+   struct drm_i915_private *dev_priv = to_i915(drm_state->crtc->dev);
+
+   /* YCBCR420 is supported only in HDMI 2.0 controllers */
+   if ((state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420) &&
+   !IS_GEMINILAKE(dev_priv)) {
+   DRM_ERROR("YCBCR420 output is not supported\n");
+   return -EINVAL;
+   }
+
+   /* We need CSC for output conversion from RGB->YCBCR */
+   if (drm_state->ctm) {
+   DRM_ERROR("YCBCR output and CTM is not possible together\n");
+   return -EINVAL;
+   }
+
+   DRM_DEBUG_DRIVER("Output %s can be supported\n",
+drm_get_hdmi_output_name(state->hdmi_output));
+   return 0;
+}
+
 static int intel_crtc_compute_config(struct intel_crtc *crtc,
 struct intel_crtc_state *pipe_config)
 {
@@ -6253,6 +62

Re: [Intel-gfx] [PATCH] drm/i915: Consistent ordering of tracepoint binary data



On 11/05/2017 14:16, Tvrtko Ursulin wrote:


On 11/05/2017 14:07, Chris Wilson wrote:

On Thu, May 11, 2017 at 02:00:45PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

For userspace receiving binary data it is easier if all related
request tracepoints emit the binary data in the same order of
dev, ring, ctx, seqno, ...


We decided that dev, ctx, ring, seqno was the right heirachy last time.
After much debate :)
ctx is the logical view of the device for a user
ctx + ring = timeline


I couldn't remember so I thought it must have been what is documented in 
TP_printk. Now I am confused. On one hand it's true, but on the other 
ctx/seqno is also a pair as opposed to engine being stuck in the middle. 
So ring-ctx-seqno is easier for humans I think. Even since per 
ctx/engine seqno space.


[thread bump!]

Can we agree what to do here? Printk's are all engine-ctx-seqno which 
makes it sound like that was the order we agreed upon. But binary blobs 
are inconsistent as you have noticed - do we care enough to go and 
fiddle with that is the question? Is overlay the only userspace to your 
knowledge that accesses the binary blobs?


Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 03/11] drm: parse ycbcr420 cmdb block

HDMI 2.0 spec adds support for ycbcr420 sub-sampled output.
CEA-861-F adds two new blocks in EDID, to provide information
about sink's support for ycbcr420 output.

One of these new blocks is: ycbcr420cmdb(ycbcr 420 capability
map data block). This gives information about video modes which
can support ycbcr420 output mode also (along with RGB,YCBCR444/
422 etc)

This block contains a bitmap index of normal svd videomodes, which can
support ycbcr420 output too.
So if bit 0 from first vcb byte is set,first video mode in the svd list
can support ycbcr420 output too. Bit 2 means second video mode from svd
list can support ycbcr420 output too, and so on.

This patch adds parsing and handling of ycbcr420-cmdb in the DRM layer.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Emil Velikov 

V2: Addressed
Review comments from Emil:
- Use 1ULL< 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
  to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
  blocks.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  | 118 ++--
 include/drm/drm_connector.h |  12 +
 2 files changed, 127 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c3fa3a1..ce86528 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
 #define VIDEO_BLOCK 0x02
 #define VENDOR_BLOCK0x03
 #define SPEAKER_BLOCK  0x04
-#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420   0x0E
+#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
 #define EDID_BASIC_AUDIO   (1 << 6)
 #define EDID_CEA_YCRCB444  (1 << 5)
 #define EDID_CEA_YCRCB422  (1 << 4)
@@ -3143,15 +3145,50 @@ drm_display_mode_from_vic_index(struct drm_connector 
*connector,
return newmode;
 }
 
+static void
+drm_add_vcb_modes(struct drm_connector *connector, u8 vic)
+{
+   u32 *map;
+   u8 index = 0;
+   struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+   /* VICs are 1 to 127(107 defined till CEA-861-F) */
+   vic &= 127;
+
+   /*
+* ycbcr420_vcb_modes is a fix position 128 bit bitmap. This indicates
+* support for ycbcr420 output per VIC. Arrangement is bit[n] indicates
+* if vic[n+1] supports ycbcr420 output.
+* ycbcr420_vcb_modes[0] = |VIC=32 |VIC=31 ||VIC=2 |VIC=1 |
+* ycbcr420_vcb_modes[1] = |VIC=64 |VIC=63 ||VIC=34|VIC=33|
+* ycbcr420_vcb_modes[2] = |VIC=96 |VIC=95 ||VIC=66|VIC=65|
+* ycbcr420_vcb_modes[3] = |VIC=128|VIC=127||VIC=34|VIC=97|
+*/
+   map = &(hdmi->ycbcr420_vcb_modes[(vic - 1) / 32]);
+   index = (vic - 1) % 32;
+   *map |= (1 << index);
+}
+
 static int
 do_cea_modes(struct drm_connector *connector, const u8 *db, u8 len)
 {
int i, modes = 0;
+   struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+   u64 hdmi_vcb_map = hdmi->ycbcr420_vcb_map;
 
for (i = 0; i < len; i++) {
struct drm_display_mode *mode;
mode = drm_display_mode_from_vic_index(connector, db, len, i);
if (mode) {
+   /*
+* ycbcr420 capability block contains a bitmap which
+* gives the index of such CEA modes in VDB, which can
+* support ycbcr420 sampling output also.
+* For example, if the bit 0 in bitmap is set,
+* first mode in VDB can support ycbcr420 output too.
+*/
+   if (hdmi_vcb_map & (1 << i))
+   drm_add_vcb_modes(connector, db[i]);
drm_mode_probed_add(connector, mode);
modes++;
}
@@ -3427,6 +3464,12 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, 
const u8 *db, u8 len,
 }
 
 static int
+cea_db_extended_tag(const u8 *db)
+{
+   return db[1];
+}
+
+static int
 cea_db_payload_len(const u8 *db)
 {
return db[0] & 0x1f;
@@ -3487,9 +3530,70 @@ static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
return oui == HDMI_FORUM_IEEE_OUI;
 }
 
+static bool cea_db_is_y420cmdb(const u8 *db)
+{
+   u8 len = cea_db_payload_len(db);
+
+   if (cea_db_tag(db) != VIDEO_CAPABILITY_BLOCK)
+   return false;
+
+   if (!len)
+   return false;
+
+   if (cea_db_extended_tag(db) != VIDEO_CAP_BLOCK_Y420CMDB)
+   return false;
+
+   return true;
+}
+
 #define for_each_cea_db(cea, i, start, end) \
for ((i) = (start); (i) < (end) && (i) + 
cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)]) 
+ 1)
 
+static void drm_parse_y420cmdb_bitm

[Intel-gfx] [PATCH v2 10/11] drm/i915: prepare ycbcr420 modeset

To get a ycbcr420 output from intel platforms, there are two
major steps:
- RGB->YCBCR conversion using a pipe CSC.
- Program PIPE_MISC register to generate a ycbcr420 output.
- Scaling down YCBCR444 samples to YCBCR420 samples using a pipe
  scaler.

This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
  scaler framework. This output type is identified using bit
  30 of the scaler users bitmap.

Cc: Ville Syrjala 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/i915_reg.h  |  3 +++
 drivers/gpu/drm/i915/intel_atomic.c  |  6 ++
 drivers/gpu/drm/i915/intel_display.c | 34 ++
 drivers/gpu/drm/i915/intel_drv.h | 10 +-
 drivers/gpu/drm/i915/intel_hdmi.c| 11 +++
 drivers/gpu/drm/i915/intel_panel.c   |  3 ++-
 6 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 89888ad..1cb3bb4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5026,6 +5026,9 @@ enum {
 
 #define _PIPE_MISC_A   0x70030
 #define _PIPE_MISC_B   0x71030
+#define   PIPEMISC_YCBCR420_ENABLE (1<<27)
+#define   PIPEMISC_YCBCR420_MODE_BLEND (1<<26)
+#define   PIPEMISC_OUTPUT_YCBCR(1<<11)
 #define   PIPEMISC_DITHER_BPC_MASK (7<<5)
 #define   PIPEMISC_DITHER_8_BPC(0<<5)
 #define   PIPEMISC_DITHER_10_BPC   (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 50fb1f7..592b0d2 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -187,6 +187,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
 
/* panel fitter case: assign as a crtc scaler */
scaler_id = &scaler_state->scaler_id;
+   } else if (i == SKL_HDMI_OUTPUT_INDEX) {
+   name = "HDMI-OUTPUT";
+   idx = intel_crtc->base.base.id;
+
+   /* hdmi output case: needs a pipe scaler */
+   scaler_id = &scaler_state->scaler_id;
} else {
name = "PLANE";
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 58e4617..e5e3bc1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4623,6 +4623,11 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
(src_h != dst_w || src_w != dst_h):
(src_w != dst_w || src_h != dst_h);
 
+   if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
+   && scaler_user == SKL_HDMI_OUTPUT_INDEX)
+   /* YCBCR 444 -> 420 conversion needs a scaler */
+   need_scaling = true;
+
/*
 * if plane is being disabled or scaler is no more required or force 
detach
 *  - free scaler binded to this plane/crtc
@@ -4670,6 +4675,26 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 }
 
 /**
+ * skl_update_scaler_hdmi_output - Stages update to scaler state for HDMI.
+ * HDMI YCBCR 420 output needs a scaler, for downsampling.
+ *
+ * @state: crtc's scaler state
+ *
+ * Return
+ * 0 - scaler_usage updated successfully
+ *error - requested scaling cannot be supported or other error condition
+ */
+int skl_update_scaler_crtc_hdmi_output(struct intel_crtc_state *state)
+{
+   const struct drm_display_mode *mode = &state->base.adjusted_mode;
+
+   return skl_update_scaler(state, !state->base.active,
+   SKL_HDMI_OUTPUT_INDEX, &state->scaler_state.scaler_id,
+   DRM_MODE_ROTATE_0, state->pipe_src_w, state->pipe_src_h,
+   mode->crtc_hdisplay, mode->crtc_vdisplay);
+}
+
+/**
  * skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
  *
  * @state: crtc's scaler state
@@ -8071,6 +8096,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   enum drm_hdmi_output_type hdmi_out = intel_crtc->config->hdmi_output;
 
if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
u32 val = 0;
@@ -8096,6 +8122,14 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
if (intel_crtc->config->dither)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
 
+   if (hdmi_out) {
+   val |= PIPEMISC_OUTPUT_YCBCR;
+   if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR420) {
+   val |= PIPEMISC_YCBCR420_ENABLE |
+  PIPEMI

[Intel-gfx] [PATCH 3/3] drm/i915: Check the ring is empty when declaring the engines are idle

As another precaution when testing whether the CS engine is actually
idle, also inspect the ring's HEAD/TAIL registers, which should be equal
when there are no commands left to execute by the GPU.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 699f2d3861c7..bc38bd128b76 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1212,6 +1212,11 @@ static bool ring_is_idle(struct intel_engine_cs *engine)
 
intel_runtime_pm_get(dev_priv);
 
+   /* First check that no commands are left in the ring */
+   if ((I915_READ_HEAD(engine) & HEAD_ADDR) !=
+   (I915_READ_TAIL(engine) & TAIL_ADDR))
+   idle = false;
+
/* No bit for gen2, so assume the CS parser is idle */
if (INTEL_GEN(dev_priv) > 2 && !(I915_READ_MODE(engine) & MODE_IDLE))
idle = false;
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

If the device is asleep (no GT wakeref), we know the GPU is already idle.
If we add an early return, we can avoid touching registers and checking
hw state outside of the assumed GT wakelock. This prevents causing such
errors whilst debugging:

[ 2613.401647] RPM wakelock ref not held during HW access
[ 2613.401684] [ cut here ]
[ 2613.401720] WARNING: CPU: 5 PID: 7739 at 
drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi 
x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp 
snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei 
prime_numbers [last unloaded: i915]
[ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U  
4.12.0-rc2-CI-CI_DRM_421+ #1
[ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 
02/15/2016
[ 2613.401840] task: 880409e3a740 task.stack: c900084dc000
[ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401863] RSP: 0018:c900084dfce8 EFLAGS: 00010292
[ 2613.401869] RAX: 002a RBX: 8804016a8000 RCX: 0006
[ 2613.401871] RDX: 0006 RSI: 81cbf2d9 RDI: 81c9e3a7
[ 2613.401874] RBP: c900084dfd18 R08: 880409e3afc8 R09: 
[ 2613.401877] R10: 8a1c483f R11:  R12: 209c
[ 2613.401879] R13: 0001 R14: 8804016a8000 R15: 8804016ac150
[ 2613.401882] FS:  7f39ef3dd8c0() GS:88041fb4() 
knlGS:
[ 2613.401885] CS:  0010 DS:  ES:  CR0: 80050033
[ 2613.401887] CR2: 023717c8 CR3: 0002e7b34000 CR4: 001406e0
[ 2613.401889] Call Trace:
[ 2613.401912]  intel_engine_is_idle+0x76/0x90 [i915]
[ 2613.401931]  i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
[ 2613.401951]  fault_irq_set+0x40/0x90 [i915]
[ 2613.401970]  i915_ring_test_irq_set+0x42/0x50 [i915]
[ 2613.401976]  simple_attr_write+0xc7/0xe0
[ 2613.401981]  full_proxy_write+0x4f/0x70
[ 2613.401987]  __vfs_write+0x23/0x120
[ 2613.401992]  ? rcu_read_lock_sched_held+0x75/0x80
[ 2613.401996]  ? rcu_sync_lockdep_assert+0x2a/0x50
[ 2613.401999]  ? __sb_start_write+0xfa/0x1f0
[ 2613.402004]  vfs_write+0xc5/0x1d0
[ 2613.402008]  ? trace_hardirqs_on_caller+0xe7/0x1c0
[ 2613.402013]  SyS_write+0x44/0xb0
[ 2613.402020]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 2613.402022] RIP: 0033:0x7f39eded6670
[ 2613.402025] RSP: 002b:7fffdcdcb1a8 EFLAGS: 0246 ORIG_RAX: 
0001
[ 2613.402030] RAX: ffda RBX: 81470203 RCX: 7f39eded6670
[ 2613.402033] RDX: 0001 RSI: 0041bc33 RDI: 0006
[ 2613.402036] RBP: c900084dff88 R08: 7f39ef3dd8c0 R09: 0001
[ 2613.402038] R10:  R11: 0246 R12: 0041bc33
[ 2613.402041] R13: 0006 R14:  R15: 
[ 2613.402046]  ? __this_cpu_preempt_check+0x13/0x20
[ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 0f 
85 29 fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 <0f> ff 
e9 0f fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
[ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---

Fixes: Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part 
of i915_gem_wait_for_idle()")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7ab47a84671f..2ce915a1b607 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3348,6 +3348,10 @@ int i915_gem_wait_for_idle(struct drm_i915_private 
*i915, unsigned int flags)
 {
int ret;
 
+   /* If the device is asleep, we have no requests outstanding */
+   if (!i915->gt.awake)
+   return 0;
+
if (flags & I915_WAIT_LOCKED) {
struct i915_gem_timeline *tl;
 
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915: Hold a wakeref for probing the ring registers

Allow intel_engine_is_idle() to be called outside of the GT wakeref by
acquiring the device runtime pm for ourselves. This allows the function
to act as check after we assume the engine is idle and we release the GT
wakeref held whilst we have requests.

[ 2613.401647] RPM wakelock ref not held during HW access
[ 2613.401684] [ cut here ]
[ 2613.401720] WARNING: CPU: 5 PID: 7739 at 
drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi 
x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp 
snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei 
prime_numbers [last unloaded: i915]
[ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U  
4.12.0-rc2-CI-CI_DRM_421+ #1
[ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 
02/15/2016
[ 2613.401840] task: 880409e3a740 task.stack: c900084dc000
[ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401863] RSP: 0018:c900084dfce8 EFLAGS: 00010292
[ 2613.401869] RAX: 002a RBX: 8804016a8000 RCX: 0006
[ 2613.401871] RDX: 0006 RSI: 81cbf2d9 RDI: 81c9e3a7
[ 2613.401874] RBP: c900084dfd18 R08: 880409e3afc8 R09: 
[ 2613.401877] R10: 8a1c483f R11:  R12: 209c
[ 2613.401879] R13: 0001 R14: 8804016a8000 R15: 8804016ac150
[ 2613.401882] FS:  7f39ef3dd8c0() GS:88041fb4() 
knlGS:
[ 2613.401885] CS:  0010 DS:  ES:  CR0: 80050033
[ 2613.401887] CR2: 023717c8 CR3: 0002e7b34000 CR4: 001406e0
[ 2613.401889] Call Trace:
[ 2613.401912]  intel_engine_is_idle+0x76/0x90 [i915]
[ 2613.401931]  i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
[ 2613.401951]  fault_irq_set+0x40/0x90 [i915]
[ 2613.401970]  i915_ring_test_irq_set+0x42/0x50 [i915]
[ 2613.401976]  simple_attr_write+0xc7/0xe0
[ 2613.401981]  full_proxy_write+0x4f/0x70
[ 2613.401987]  __vfs_write+0x23/0x120
[ 2613.401992]  ? rcu_read_lock_sched_held+0x75/0x80
[ 2613.401996]  ? rcu_sync_lockdep_assert+0x2a/0x50
[ 2613.401999]  ? __sb_start_write+0xfa/0x1f0
[ 2613.402004]  vfs_write+0xc5/0x1d0
[ 2613.402008]  ? trace_hardirqs_on_caller+0xe7/0x1c0
[ 2613.402013]  SyS_write+0x44/0xb0
[ 2613.402020]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 2613.402022] RIP: 0033:0x7f39eded6670
[ 2613.402025] RSP: 002b:7fffdcdcb1a8 EFLAGS: 0246 ORIG_RAX: 
0001
[ 2613.402030] RAX: ffda RBX: 81470203 RCX: 7f39eded6670
[ 2613.402033] RDX: 0001 RSI: 0041bc33 RDI: 0006
[ 2613.402036] RBP: c900084dff88 R08: 7f39ef3dd8c0 R09: 0001
[ 2613.402038] R10:  R11: 0246 R12: 0041bc33
[ 2613.402041] R13: 0006 R14:  R15: 
[ 2613.402046]  ? __this_cpu_preempt_check+0x13/0x20
[ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 0f 
85 29 fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 <0f> ff 
e9 0f fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
[ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---

Fixes: 5400367a864d ("drm/i915: Ensure the engine is idle before manually 
changing HWS")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 413bfd8d4bf4..699f2d3861c7 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1205,6 +1205,22 @@ int intel_ring_workarounds_emit(struct 
drm_i915_gem_request *req)
return 0;
 }
 
+static bool ring_is_idle(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+   bool idle = true;
+
+   intel_runtime_pm_get(dev_priv);
+
+   /* No bit for gen2, so assume the CS parser is idle */
+   if (INTEL_GEN(dev_priv) > 2 && !(I915_READ_MODE(engine) & MODE_IDLE))
+   idle = false;
+
+   intel_runtime_pm_put(dev_priv);
+
+   return idle;
+}
+
 /**
  * intel_engine_is_idle() - Report if the engine has finished process all work
  * @engine: the intel_engine_cs
@@ -1237,7 +1253,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
return false;
 
/* Ring stopped? */
-   if (INTEL_GEN(dev_priv) > 2 && !(I915_READ_MODE(engine) & MODE_IDLE))
+   if (!ring_is_idle(engine))
return false;
 
return true;
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle



On 30/05/2017 13:13, Chris Wilson wrote:

If the device is asleep (no GT wakeref), we know the GPU is already idle.
If we add an early return, we can avoid touching registers and checking
hw state outside of the assumed GT wakelock. This prevents causing such
errors whilst debugging:

[ 2613.401647] RPM wakelock ref not held during HW access
[ 2613.401684] [ cut here ]
[ 2613.401720] WARNING: CPU: 5 PID: 7739 at 
drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi 
x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp 
snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei 
prime_numbers [last unloaded: i915]
[ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U  
4.12.0-rc2-CI-CI_DRM_421+ #1
[ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 
02/15/2016
[ 2613.401840] task: 880409e3a740 task.stack: c900084dc000
[ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401863] RSP: 0018:c900084dfce8 EFLAGS: 00010292
[ 2613.401869] RAX: 002a RBX: 8804016a8000 RCX: 0006
[ 2613.401871] RDX: 0006 RSI: 81cbf2d9 RDI: 81c9e3a7
[ 2613.401874] RBP: c900084dfd18 R08: 880409e3afc8 R09: 
[ 2613.401877] R10: 8a1c483f R11:  R12: 209c
[ 2613.401879] R13: 0001 R14: 8804016a8000 R15: 8804016ac150
[ 2613.401882] FS:  7f39ef3dd8c0() GS:88041fb4() 
knlGS:
[ 2613.401885] CS:  0010 DS:  ES:  CR0: 80050033
[ 2613.401887] CR2: 023717c8 CR3: 0002e7b34000 CR4: 001406e0
[ 2613.401889] Call Trace:
[ 2613.401912]  intel_engine_is_idle+0x76/0x90 [i915]
[ 2613.401931]  i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
[ 2613.401951]  fault_irq_set+0x40/0x90 [i915]
[ 2613.401970]  i915_ring_test_irq_set+0x42/0x50 [i915]
[ 2613.401976]  simple_attr_write+0xc7/0xe0
[ 2613.401981]  full_proxy_write+0x4f/0x70
[ 2613.401987]  __vfs_write+0x23/0x120
[ 2613.401992]  ? rcu_read_lock_sched_held+0x75/0x80
[ 2613.401996]  ? rcu_sync_lockdep_assert+0x2a/0x50
[ 2613.401999]  ? __sb_start_write+0xfa/0x1f0
[ 2613.402004]  vfs_write+0xc5/0x1d0
[ 2613.402008]  ? trace_hardirqs_on_caller+0xe7/0x1c0
[ 2613.402013]  SyS_write+0x44/0xb0
[ 2613.402020]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 2613.402022] RIP: 0033:0x7f39eded6670
[ 2613.402025] RSP: 002b:7fffdcdcb1a8 EFLAGS: 0246 ORIG_RAX: 
0001
[ 2613.402030] RAX: ffda RBX: 81470203 RCX: 7f39eded6670
[ 2613.402033] RDX: 0001 RSI: 0041bc33 RDI: 0006
[ 2613.402036] RBP: c900084dff88 R08: 7f39ef3dd8c0 R09: 0001
[ 2613.402038] R10:  R11: 0246 R12: 0041bc33
[ 2613.402041] R13: 0006 R14:  R15: 
[ 2613.402046]  ? __this_cpu_preempt_check+0x13/0x20
[ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 0f 85 29 
fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 <0f> ff e9 0f 
fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
[ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---

Fixes: Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of 
i915_gem_wait_for_idle()")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_gem.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7ab47a84671f..2ce915a1b607 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3348,6 +3348,10 @@ int i915_gem_wait_for_idle(struct drm_i915_private 
*i915, unsigned int flags)
  {
int ret;
  
+	/* If the device is asleep, we have no requests outstanding */

+   if (!i915->gt.awake)
+   return 0;
+
if (flags & I915_WAIT_LOCKED) {
struct i915_gem_timeline *tl;
  



Looks like it would be worth pulling up the lockdep_assert_held before 
the fast exit for the I915_WAIT_LOCKED case? Would be better at catching 
bugs which after this patch can become timing sensitive.


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

On Tue, May 30, 2017 at 01:21:29PM +0100, Tvrtko Ursulin wrote:
> 
> On 30/05/2017 13:13, Chris Wilson wrote:
> >If the device is asleep (no GT wakeref), we know the GPU is already idle.
> >If we add an early return, we can avoid touching registers and checking
> >hw state outside of the assumed GT wakelock. This prevents causing such
> >errors whilst debugging:
> >
> >[ 2613.401647] RPM wakelock ref not held during HW access
> >[ 2613.401684] [ cut here ]
> >[ 2613.401720] WARNING: CPU: 5 PID: 7739 at 
> >drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
> >[ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi 
> >x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp 
> >snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
> >snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei 
> >prime_numbers [last unloaded: i915]
> >[ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U
> >  4.12.0-rc2-CI-CI_DRM_421+ #1
> >[ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 
> >02/15/2016
> >[ 2613.401840] task: 880409e3a740 task.stack: c900084dc000
> >[ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
> >[ 2613.401863] RSP: 0018:c900084dfce8 EFLAGS: 00010292
> >[ 2613.401869] RAX: 002a RBX: 8804016a8000 RCX: 
> >0006
> >[ 2613.401871] RDX: 0006 RSI: 81cbf2d9 RDI: 
> >81c9e3a7
> >[ 2613.401874] RBP: c900084dfd18 R08: 880409e3afc8 R09: 
> >
> >[ 2613.401877] R10: 8a1c483f R11:  R12: 
> >209c
> >[ 2613.401879] R13: 0001 R14: 8804016a8000 R15: 
> >8804016ac150
> >[ 2613.401882] FS:  7f39ef3dd8c0() GS:88041fb4() 
> >knlGS:
> >[ 2613.401885] CS:  0010 DS:  ES:  CR0: 80050033
> >[ 2613.401887] CR2: 023717c8 CR3: 0002e7b34000 CR4: 
> >001406e0
> >[ 2613.401889] Call Trace:
> >[ 2613.401912]  intel_engine_is_idle+0x76/0x90 [i915]
> >[ 2613.401931]  i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
> >[ 2613.401951]  fault_irq_set+0x40/0x90 [i915]
> >[ 2613.401970]  i915_ring_test_irq_set+0x42/0x50 [i915]
> >[ 2613.401976]  simple_attr_write+0xc7/0xe0
> >[ 2613.401981]  full_proxy_write+0x4f/0x70
> >[ 2613.401987]  __vfs_write+0x23/0x120
> >[ 2613.401992]  ? rcu_read_lock_sched_held+0x75/0x80
> >[ 2613.401996]  ? rcu_sync_lockdep_assert+0x2a/0x50
> >[ 2613.401999]  ? __sb_start_write+0xfa/0x1f0
> >[ 2613.402004]  vfs_write+0xc5/0x1d0
> >[ 2613.402008]  ? trace_hardirqs_on_caller+0xe7/0x1c0
> >[ 2613.402013]  SyS_write+0x44/0xb0
> >[ 2613.402020]  entry_SYSCALL_64_fastpath+0x1c/0xb1
> >[ 2613.402022] RIP: 0033:0x7f39eded6670
> >[ 2613.402025] RSP: 002b:7fffdcdcb1a8 EFLAGS: 0246 ORIG_RAX: 
> >0001
> >[ 2613.402030] RAX: ffda RBX: 81470203 RCX: 
> >7f39eded6670
> >[ 2613.402033] RDX: 0001 RSI: 0041bc33 RDI: 
> >0006
> >[ 2613.402036] RBP: c900084dff88 R08: 7f39ef3dd8c0 R09: 
> >0001
> >[ 2613.402038] R10:  R11: 0246 R12: 
> >0041bc33
> >[ 2613.402041] R13: 0006 R14:  R15: 
> >
> >[ 2613.402046]  ? __this_cpu_preempt_check+0x13/0x20
> >[ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 
> >0f 85 29 fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 
> ><0f> ff e9 0f fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
> >[ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---
> >
> >Fixes: Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as 
> >part of i915_gem_wait_for_idle()")
> >Signed-off-by: Chris Wilson 
> >Cc: Joonas Lahtinen 
> >Cc: Tvrtko Ursulin 
> >---
> >  drivers/gpu/drm/i915/i915_gem.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 7ab47a84671f..2ce915a1b607 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -3348,6 +3348,10 @@ int i915_gem_wait_for_idle(struct drm_i915_private 
> >*i915, unsigned int flags)
> >  {
> > int ret;
> >+/* If the device is asleep, we have no requests outstanding */
> >+if (!i915->gt.awake)
> >+return 0;
> >+
> > if (flags & I915_WAIT_LOCKED) {
> > struct i915_gem_timeline *tl;
> >
> 
> Looks like it would be worth pulling up the lockdep_assert_held
> before the fast exit for the I915_WAIT_LOCKED case? Would be better
> at catching bugs which after this patch can become timing sensitive.

I have silently asked for lockdep_assert_held_if() before :|
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https:/

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Hold a wakeref for probing the ring registers



On 30/05/2017 13:13, Chris Wilson wrote:

Allow intel_engine_is_idle() to be called outside of the GT wakeref by
acquiring the device runtime pm for ourselves. This allows the function
to act as check after we assume the engine is idle and we release the GT
wakeref held whilst we have requests.

[ 2613.401647] RPM wakelock ref not held during HW access
[ 2613.401684] [ cut here ]
[ 2613.401720] WARNING: CPU: 5 PID: 7739 at 
drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi 
x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp 
snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei 
prime_numbers [last unloaded: i915]
[ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U  
4.12.0-rc2-CI-CI_DRM_421+ #1
[ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 
02/15/2016
[ 2613.401840] task: 880409e3a740 task.stack: c900084dc000
[ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401863] RSP: 0018:c900084dfce8 EFLAGS: 00010292
[ 2613.401869] RAX: 002a RBX: 8804016a8000 RCX: 0006
[ 2613.401871] RDX: 0006 RSI: 81cbf2d9 RDI: 81c9e3a7
[ 2613.401874] RBP: c900084dfd18 R08: 880409e3afc8 R09: 
[ 2613.401877] R10: 8a1c483f R11:  R12: 209c
[ 2613.401879] R13: 0001 R14: 8804016a8000 R15: 8804016ac150
[ 2613.401882] FS:  7f39ef3dd8c0() GS:88041fb4() 
knlGS:
[ 2613.401885] CS:  0010 DS:  ES:  CR0: 80050033
[ 2613.401887] CR2: 023717c8 CR3: 0002e7b34000 CR4: 001406e0
[ 2613.401889] Call Trace:
[ 2613.401912]  intel_engine_is_idle+0x76/0x90 [i915]
[ 2613.401931]  i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
[ 2613.401951]  fault_irq_set+0x40/0x90 [i915]
[ 2613.401970]  i915_ring_test_irq_set+0x42/0x50 [i915]
[ 2613.401976]  simple_attr_write+0xc7/0xe0
[ 2613.401981]  full_proxy_write+0x4f/0x70
[ 2613.401987]  __vfs_write+0x23/0x120
[ 2613.401992]  ? rcu_read_lock_sched_held+0x75/0x80
[ 2613.401996]  ? rcu_sync_lockdep_assert+0x2a/0x50
[ 2613.401999]  ? __sb_start_write+0xfa/0x1f0
[ 2613.402004]  vfs_write+0xc5/0x1d0
[ 2613.402008]  ? trace_hardirqs_on_caller+0xe7/0x1c0
[ 2613.402013]  SyS_write+0x44/0xb0
[ 2613.402020]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 2613.402022] RIP: 0033:0x7f39eded6670
[ 2613.402025] RSP: 002b:7fffdcdcb1a8 EFLAGS: 0246 ORIG_RAX: 
0001
[ 2613.402030] RAX: ffda RBX: 81470203 RCX: 7f39eded6670
[ 2613.402033] RDX: 0001 RSI: 0041bc33 RDI: 0006
[ 2613.402036] RBP: c900084dff88 R08: 7f39ef3dd8c0 R09: 0001
[ 2613.402038] R10:  R11: 0246 R12: 0041bc33
[ 2613.402041] R13: 0006 R14:  R15: 
[ 2613.402046]  ? __this_cpu_preempt_check+0x13/0x20
[ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 0f 85 29 
fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 <0f> ff e9 0f 
fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
[ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---

Fixes: 5400367a864d ("drm/i915: Ensure the engine is idle before manually changing 
HWS")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 413bfd8d4bf4..699f2d3861c7 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1205,6 +1205,22 @@ int intel_ring_workarounds_emit(struct 
drm_i915_gem_request *req)
return 0;
  }
  
+static bool ring_is_idle(struct intel_engine_cs *engine)

+{
+   struct drm_i915_private *dev_priv = engine->i915;
+   bool idle = true;
+
+   intel_runtime_pm_get(dev_priv);


I didn't find a path where this would be needed on top of the previous 
patch. I am not objecting to making it more robust, just checking if I 
have missed something?



+
+   /* No bit for gen2, so assume the CS parser is idle */
+   if (INTEL_GEN(dev_priv) > 2 && !(I915_READ_MODE(engine) & MODE_IDLE))
+   idle = false;


Could assign a logic evaluation to idle directly here but doesn't matter.


+
+   intel_runtime_pm_put(dev_priv);
+
+   return idle;
+}
+
  /**
   * intel_engine_is_idle() - Report if the engine has finished process all work
   * @engine: the intel_engine_cs
@@ -1237,7 +1253,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
return false;
  
  	/* Ring stopped?

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

On ti, 2017-05-30 at 13:13 +0100, Chris Wilson wrote:
> If the device is asleep (no GT wakeref), we know the GPU is already idle.
> If we add an early return, we can avoid touching registers and checking
> hw state outside of the assumed GT wakelock. This prevents causing such
> errors whilst debugging:
> 
> [ 2613.401647] RPM wakelock ref not held during HW access
> [ 2613.401684] [ cut here ]
> [ 2613.401720] WARNING: CPU: 5 PID: 7739 at 
> drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
> [ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi 
> x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp 
> snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
> snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei 
> prime_numbers [last unloaded: i915]
> [ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U 
>  4.12.0-rc2-CI-CI_DRM_421+ #1
> [ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 
> 02/15/2016
> [ 2613.401840] task: 880409e3a740 task.stack: c900084dc000
> [ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
> [ 2613.401863] RSP: 0018:c900084dfce8 EFLAGS: 00010292
> [ 2613.401869] RAX: 002a RBX: 8804016a8000 RCX: 
> 0006
> [ 2613.401871] RDX: 0006 RSI: 81cbf2d9 RDI: 
> 81c9e3a7
> [ 2613.401874] RBP: c900084dfd18 R08: 880409e3afc8 R09: 
> 
> [ 2613.401877] R10: 8a1c483f R11:  R12: 
> 209c
> [ 2613.401879] R13: 0001 R14: 8804016a8000 R15: 
> 8804016ac150
> [ 2613.401882] FS:  7f39ef3dd8c0() GS:88041fb4() 
> knlGS:
> [ 2613.401885] CS:  0010 DS:  ES:  CR0: 80050033
> [ 2613.401887] CR2: 023717c8 CR3: 0002e7b34000 CR4: 
> 001406e0
> [ 2613.401889] Call Trace:
> [ 2613.401912]  intel_engine_is_idle+0x76/0x90 [i915]
> [ 2613.401931]  i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
> [ 2613.401951]  fault_irq_set+0x40/0x90 [i915]
> [ 2613.401970]  i915_ring_test_irq_set+0x42/0x50 [i915]
> [ 2613.401976]  simple_attr_write+0xc7/0xe0
> [ 2613.401981]  full_proxy_write+0x4f/0x70
> [ 2613.401987]  __vfs_write+0x23/0x120
> [ 2613.401992]  ? rcu_read_lock_sched_held+0x75/0x80
> [ 2613.401996]  ? rcu_sync_lockdep_assert+0x2a/0x50
> [ 2613.401999]  ? __sb_start_write+0xfa/0x1f0
> [ 2613.402004]  vfs_write+0xc5/0x1d0
> [ 2613.402008]  ? trace_hardirqs_on_caller+0xe7/0x1c0
> [ 2613.402013]  SyS_write+0x44/0xb0
> [ 2613.402020]  entry_SYSCALL_64_fastpath+0x1c/0xb1
> [ 2613.402022] RIP: 0033:0x7f39eded6670
> [ 2613.402025] RSP: 002b:7fffdcdcb1a8 EFLAGS: 0246 ORIG_RAX: 
> 0001
> [ 2613.402030] RAX: ffda RBX: 81470203 RCX: 
> 7f39eded6670
> [ 2613.402033] RDX: 0001 RSI: 0041bc33 RDI: 
> 0006
> [ 2613.402036] RBP: c900084dff88 R08: 7f39ef3dd8c0 R09: 
> 0001
> [ 2613.402038] R10:  R11: 0246 R12: 
> 0041bc33
> [ 2613.402041] R13: 0006 R14:  R15: 
> 
> [ 2613.402046]  ? __this_cpu_preempt_check+0x13/0x20
> [ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 0f 
> 85 29 fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 <0f> 
> ff e9 0f fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
> [ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---
> 
> Fixes: Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as 
> part of i915_gem_wait_for_idle()")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 



> @@ -3348,6 +3348,10 @@ int i915_gem_wait_for_idle(struct drm_i915_private 
> *i915, unsigned int flags)
>  {
>   int ret;
>  
> + /* If the device is asleep, we have no requests outstanding */
> + if (!i915->gt.awake)

This seems to be surrounded by READ_ONCE here and there.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/gvt: Add gvt options sanitize function

On Sat, May 27, 2017 at 10:01:48AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v2,1/3] drm/i915/gvt: Add gvt options sanitize 
> function
> URL   : https://patchwork.freedesktop.org/series/24982/
> State : success

Sigh. Had to resort to checking pw, but it lgtm.
The series is
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

On Tue, May 30, 2017 at 03:41:15PM +0300, Joonas Lahtinen wrote:
> On ti, 2017-05-30 at 13:13 +0100, Chris Wilson wrote:
> > If the device is asleep (no GT wakeref), we know the GPU is already idle.
> > If we add an early return, we can avoid touching registers and checking
> > hw state outside of the assumed GT wakelock. This prevents causing such
> > errors whilst debugging:
> > 
> > [ 2613.401647] RPM wakelock ref not held during HW access
> > [ 2613.401684] [ cut here ]
> > [ 2613.401720] WARNING: CPU: 5 PID: 7739 at 
> > drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
> > [ 2613.401731] Modules linked in: snd_hda_intel i915 vgem 
> > snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp 
> > snd_hda_codec_realtek coretemp snd_hda_codec_generic crct10dif_pclmul 
> > crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core 
> > snd_pcm r8169 mii mei_me lpc_ich mei prime_numbers [last unloaded: i915]
> > [ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U   
> >    4.12.0-rc2-CI-CI_DRM_421+ #1
> > [ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 
> > 02/15/2016
> > [ 2613.401840] task: 880409e3a740 task.stack: c900084dc000
> > [ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
> > [ 2613.401863] RSP: 0018:c900084dfce8 EFLAGS: 00010292
> > [ 2613.401869] RAX: 002a RBX: 8804016a8000 RCX: 
> > 0006
> > [ 2613.401871] RDX: 0006 RSI: 81cbf2d9 RDI: 
> > 81c9e3a7
> > [ 2613.401874] RBP: c900084dfd18 R08: 880409e3afc8 R09: 
> > 
> > [ 2613.401877] R10: 8a1c483f R11:  R12: 
> > 209c
> > [ 2613.401879] R13: 0001 R14: 8804016a8000 R15: 
> > 8804016ac150
> > [ 2613.401882] FS:  7f39ef3dd8c0() GS:88041fb4() 
> > knlGS:
> > [ 2613.401885] CS:  0010 DS:  ES:  CR0: 80050033
> > [ 2613.401887] CR2: 023717c8 CR3: 0002e7b34000 CR4: 
> > 001406e0
> > [ 2613.401889] Call Trace:
> > [ 2613.401912]  intel_engine_is_idle+0x76/0x90 [i915]
> > [ 2613.401931]  i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
> > [ 2613.401951]  fault_irq_set+0x40/0x90 [i915]
> > [ 2613.401970]  i915_ring_test_irq_set+0x42/0x50 [i915]
> > [ 2613.401976]  simple_attr_write+0xc7/0xe0
> > [ 2613.401981]  full_proxy_write+0x4f/0x70
> > [ 2613.401987]  __vfs_write+0x23/0x120
> > [ 2613.401992]  ? rcu_read_lock_sched_held+0x75/0x80
> > [ 2613.401996]  ? rcu_sync_lockdep_assert+0x2a/0x50
> > [ 2613.401999]  ? __sb_start_write+0xfa/0x1f0
> > [ 2613.402004]  vfs_write+0xc5/0x1d0
> > [ 2613.402008]  ? trace_hardirqs_on_caller+0xe7/0x1c0
> > [ 2613.402013]  SyS_write+0x44/0xb0
> > [ 2613.402020]  entry_SYSCALL_64_fastpath+0x1c/0xb1
> > [ 2613.402022] RIP: 0033:0x7f39eded6670
> > [ 2613.402025] RSP: 002b:7fffdcdcb1a8 EFLAGS: 0246 ORIG_RAX: 
> > 0001
> > [ 2613.402030] RAX: ffda RBX: 81470203 RCX: 
> > 7f39eded6670
> > [ 2613.402033] RDX: 0001 RSI: 0041bc33 RDI: 
> > 0006
> > [ 2613.402036] RBP: c900084dff88 R08: 7f39ef3dd8c0 R09: 
> > 0001
> > [ 2613.402038] R10:  R11: 0246 R12: 
> > 0041bc33
> > [ 2613.402041] R13: 0006 R14:  R15: 
> > 
> > [ 2613.402046]  ? __this_cpu_preempt_check+0x13/0x20
> > [ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 
> > 0f 85 29 fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 
> > <0f> ff e9 0f fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
> > [ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---
> > 
> > Fixes: Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as 
> > part of i915_gem_wait_for_idle()")
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Cc: Tvrtko Ursulin 
> 
> 
> 
> > @@ -3348,6 +3348,10 @@ int i915_gem_wait_for_idle(struct drm_i915_private 
> > *i915, unsigned int flags)
> >  {
> >     int ret;
> >  
> > +   /* If the device is asleep, we have no requests outstanding */
> > +   if (!i915->gt.awake)
> 
> This seems to be surrounded by READ_ONCE here and there.

And I was debating using READ_ONCE here as well. Mostly we read it
locked, but since it is a triffling detail adding READ_ONCE to warn the
reader that the unlocked read is perfectly fine is ok.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Hold a wakeref for probing the ring registers

On Tue, May 30, 2017 at 01:37:23PM +0100, Tvrtko Ursulin wrote:
> 
> On 30/05/2017 13:13, Chris Wilson wrote:
> >Allow intel_engine_is_idle() to be called outside of the GT wakeref by
> >acquiring the device runtime pm for ourselves. This allows the function
> >to act as check after we assume the engine is idle and we release the GT
> >wakeref held whilst we have requests.
> >
> >[ 2613.401647] RPM wakelock ref not held during HW access
> >[ 2613.401684] [ cut here ]
> >[ 2613.401720] WARNING: CPU: 5 PID: 7739 at 
> >drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
> >[ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi 
> >x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp 
> >snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
> >snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei 
> >prime_numbers [last unloaded: i915]
> >[ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U
> >  4.12.0-rc2-CI-CI_DRM_421+ #1
> >[ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 
> >02/15/2016
> >[ 2613.401840] task: 880409e3a740 task.stack: c900084dc000
> >[ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
> >[ 2613.401863] RSP: 0018:c900084dfce8 EFLAGS: 00010292
> >[ 2613.401869] RAX: 002a RBX: 8804016a8000 RCX: 
> >0006
> >[ 2613.401871] RDX: 0006 RSI: 81cbf2d9 RDI: 
> >81c9e3a7
> >[ 2613.401874] RBP: c900084dfd18 R08: 880409e3afc8 R09: 
> >
> >[ 2613.401877] R10: 8a1c483f R11:  R12: 
> >209c
> >[ 2613.401879] R13: 0001 R14: 8804016a8000 R15: 
> >8804016ac150
> >[ 2613.401882] FS:  7f39ef3dd8c0() GS:88041fb4() 
> >knlGS:
> >[ 2613.401885] CS:  0010 DS:  ES:  CR0: 80050033
> >[ 2613.401887] CR2: 023717c8 CR3: 0002e7b34000 CR4: 
> >001406e0
> >[ 2613.401889] Call Trace:
> >[ 2613.401912]  intel_engine_is_idle+0x76/0x90 [i915]
> >[ 2613.401931]  i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
> >[ 2613.401951]  fault_irq_set+0x40/0x90 [i915]
> >[ 2613.401970]  i915_ring_test_irq_set+0x42/0x50 [i915]
> >[ 2613.401976]  simple_attr_write+0xc7/0xe0
> >[ 2613.401981]  full_proxy_write+0x4f/0x70
> >[ 2613.401987]  __vfs_write+0x23/0x120
> >[ 2613.401992]  ? rcu_read_lock_sched_held+0x75/0x80
> >[ 2613.401996]  ? rcu_sync_lockdep_assert+0x2a/0x50
> >[ 2613.401999]  ? __sb_start_write+0xfa/0x1f0
> >[ 2613.402004]  vfs_write+0xc5/0x1d0
> >[ 2613.402008]  ? trace_hardirqs_on_caller+0xe7/0x1c0
> >[ 2613.402013]  SyS_write+0x44/0xb0
> >[ 2613.402020]  entry_SYSCALL_64_fastpath+0x1c/0xb1
> >[ 2613.402022] RIP: 0033:0x7f39eded6670
> >[ 2613.402025] RSP: 002b:7fffdcdcb1a8 EFLAGS: 0246 ORIG_RAX: 
> >0001
> >[ 2613.402030] RAX: ffda RBX: 81470203 RCX: 
> >7f39eded6670
> >[ 2613.402033] RDX: 0001 RSI: 0041bc33 RDI: 
> >0006
> >[ 2613.402036] RBP: c900084dff88 R08: 7f39ef3dd8c0 R09: 
> >0001
> >[ 2613.402038] R10:  R11: 0246 R12: 
> >0041bc33
> >[ 2613.402041] R13: 0006 R14:  R15: 
> >
> >[ 2613.402046]  ? __this_cpu_preempt_check+0x13/0x20
> >[ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 
> >0f 85 29 fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 
> ><0f> ff e9 0f fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
> >[ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---
> >
> >Fixes: 5400367a864d ("drm/i915: Ensure the engine is idle before manually 
> >changing HWS")
> >Signed-off-by: Chris Wilson 
> >Cc: Mika Kuoppala 
> >Cc: Joonas Lahtinen 
> >Cc: Tvrtko Ursulin 
> >---
> >  drivers/gpu/drm/i915/intel_engine_cs.c | 18 +-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> >b/drivers/gpu/drm/i915/intel_engine_cs.c
> >index 413bfd8d4bf4..699f2d3861c7 100644
> >--- a/drivers/gpu/drm/i915/intel_engine_cs.c
> >+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> >@@ -1205,6 +1205,22 @@ int intel_ring_workarounds_emit(struct 
> >drm_i915_gem_request *req)
> > return 0;
> >  }
> >+static bool ring_is_idle(struct intel_engine_cs *engine)
> >+{
> >+struct drm_i915_private *dev_priv = engine->i915;
> >+bool idle = true;
> >+
> >+intel_runtime_pm_get(dev_priv);
> 
> I didn't find a path where this would be needed on top of the
> previous patch. I am not objecting to making it more robust, just
> checking if I have missed something?

I don't think there is currently. I thought this was suitable
"belt-and-braces" approach so that we could just write an assertion
later on (ignorant of the GPU state) without causing more pain.

> >+/* No bit for gen2, so

Re: [Intel-gfx] [PATCH 1/3] drm/i915/skl+: Don't trust cached ddb values

2017-05-30 Thread Mahesh Kumar


Hi Maarten,

Thanks for review :)


On Tuesday 30 May 2017 03:30 PM, Maarten Lankhorst wrote:

Op 26-05-17 om 17:15 schreef Mahesh Kumar:

Don't trust cached DDB values. Recalculate the ddb value if cached value
is zero.

If i915 is build as a module, there may be a race condition when
cursor_disable call comes even before intel_fbdev_initial_config.
Which may lead to cached value being 0. And further commit will fail
until a modeset.

Signed-off-by: Mahesh Kumar 
---
  drivers/gpu/drm/i915/intel_pm.c | 15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 936eef1634c7..b67be1355e39 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3721,6 +3721,7 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_crtc *for_crtc = cstate->base.crtc;
unsigned int pipe_size, ddb_size;
+   unsigned int active_crtcs;
int nth_active_pipe;
  
  	if (WARN_ON(!state) || !cstate->base.active) {

@@ -3731,10 +3732,11 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
*dev,
}
  
  	if (intel_state->active_pipe_changes)

-   *num_active = hweight32(intel_state->active_crtcs);
+   active_crtcs = intel_state->active_crtcs;
else
-   *num_active = hweight32(dev_priv->active_crtcs);
+   active_crtcs = dev_priv->active_crtcs;
  
+	*num_active = hweight32(active_crtcs);

ddb_size = INTEL_INFO(dev_priv)->ddb_size;
WARN_ON(ddb_size == 0);
  
@@ -3754,12 +3756,15 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,

 * copy from old state to be sure
 */
*alloc = to_intel_crtc_state(for_crtc->state)->wm.skl.ddb;
-   return;
+   if (!skl_ddb_entry_size(alloc))
+   DRM_DEBUG_KMS("Cached pipe DDB is 0 recalculate\n");
+   else
+   return;
}
  
-	nth_active_pipe = hweight32(intel_state->active_crtcs &

+   nth_active_pipe = hweight32(active_crtcs &
(drm_crtc_mask(for_crtc) - 1));
-   pipe_size = ddb_size / hweight32(intel_state->active_crtcs);
+   pipe_size = ddb_size / hweight32(active_crtcs);
alloc->start = nth_active_pipe * ddb_size / *num_active;
alloc->end = alloc->start + pipe_size;
  }

I'd love it if you also add a warning somewhere for active pipe with no ddb 
allocation to prevent this from reoccuring in the future. :)
But with the root cause being a invalid ddb allocation at boot, won't the below 
one liner should fix it too, but better?
Above DEBUG message is actually warning. That will hit only if pipe is 
active & DDB allocated for that pipe is "0" (we do return from caller if 
!cstate->active).
I can reword the msg to be WARN & make it something like "Pipe is active 
with No DDB allocated, recompute ddb now". This will fix the issue as 
well as add warning msg.




I'l ltest it when f3-kbl becomes available again.

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a488e068c3d6..63a47909f618 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5051,7 +5051,7 @@ skl_compute_wm(struct drm_atomic_state *state)
 */
for_each_new_crtc_in_state(state, crtc, cstate, i)
changed = true;
-   if (!changed)
+   if (!changed && !to_i915(state->dev)->wm.distrust_bios_wm)
return 0;
  

This change should also solve the issue during boot.

-Mahesh

/* Clear all dirty flags */



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC] drm: Optimise drm_ioctl() for small user args

When looking at simple ioctls coupled with conveniently small user
parameters, the overhead of the syscall and drm_ioctl() present large
low hanging fruit. Profiling trivial microbenchmarks around
i915_gem_busy_ioctl, the low hanging fruit comprises of the call to
copy_user(). Those calls are only inlined by the macro where the
constant is known at compile-time, but the ioctl argument size depends
on the ioctl number. To help the compiler, explicitly add switches for
the small sizes that expand to simple moves to/from user. Doing the
multiple inlines does add significant code bloat, so it is very
debatable as to its value. Back to the trivial, but frequently used,
example of i915_gem_busy_ioctl() on a Broadwell avoiding the call gives
us a 15-25% improvement:

 before   after
single  100.173ns84.496ns
parallel (x4)   204.275ns   152.957ns

On a baby Broxton nuc:

before   after
single  245.355ns   199.477ns
parallel (x2)   280.892ns   232.726ns

Looking at the cost distribution by moving an equivalent switch into
arch/x86/lib/usercopy, the overhead to the copy user is split almost
equally between the function call and the actual copy itself. It seems
copy_user_enhanced_fast_string simply is not that good at small (single
register) copies. Something as simple as

@@ -28,6 +28,9 @@ copy_user_generic(void *to, const void *from, unsigned len)
 {
unsigned ret;

+   if (len <= 16)
+   return copy_user_generic_unrolled(to, from, len);

is enough to speed up i915_gem_busy_ioctl() by 10% :|

Note that this overhead may entirely be x86 specific.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/drm_ioctl.c | 111 
 1 file changed, 82 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 865e3ee4d743..93ba59a30a85 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -715,11 +715,11 @@ long drm_ioctl(struct file *filp,
const struct drm_ioctl_desc *ioctl = NULL;
drm_ioctl_t *func;
unsigned int nr = DRM_IOCTL_NR(cmd);
-   int retcode = -EINVAL;
char stack_kdata[128];
-   char *kdata = NULL;
+   char *kdata = stack_kdata;
unsigned int in_size, out_size, drv_size, ksize;
bool is_driver_ioctl;
+   int retcode;
 
dev = file_priv->minor->dev;
 
@@ -731,12 +731,12 @@ long drm_ioctl(struct file *filp,
if (is_driver_ioctl) {
/* driver ioctl */
if (nr - DRM_COMMAND_BASE >= dev->driver->num_ioctls)
-   goto err_i1;
+   goto err_invalid_ioctl;
ioctl = &dev->driver->ioctls[nr - DRM_COMMAND_BASE];
} else {
/* core ioctl */
if (nr >= DRM_CORE_IOCTL_COUNT)
-   goto err_i1;
+   goto err_invalid_ioctl;
ioctl = &drm_ioctls[nr];
}
 
@@ -758,29 +758,50 @@ long drm_ioctl(struct file *filp,
 
if (unlikely(!func)) {
DRM_DEBUG("no function\n");
-   retcode = -EINVAL;
-   goto err_i1;
+   goto err_invalid;
}
 
retcode = drm_ioctl_permit(ioctl->flags, file_priv);
if (unlikely(retcode))
-   goto err_i1;
-
-   if (ksize <= sizeof(stack_kdata)) {
-   kdata = stack_kdata;
-   } else {
-   kdata = kmalloc(ksize, GFP_KERNEL);
-   if (!kdata) {
-   retcode = -ENOMEM;
-   goto err_i1;
+   goto out;
+
+   if (in_size) {
+   if (unlikely(!access_ok(VERIFY_READ, arg, in_size)))
+   goto err_invalid_user;
+
+   switch (in_size) {
+   case 4:
+   if (unlikely(__copy_from_user(kdata, (void __user *)arg,
+ 4)))
+   goto err_invalid_user;
+   break;
+   case 8:
+   if (unlikely(__copy_from_user(kdata, (void __user *)arg,
+ 8)))
+   goto err_invalid_user;
+   break;
+   case 16:
+   if (unlikely(__copy_from_user(kdata, (void __user *)arg,
+ 16)))
+   goto err_invalid_user;
+   break;
+
+   default:
+   if (ksize > sizeof(stack_kdata)) {
+   kdata = kmalloc(ksize, GFP_KERNEL);
+   if (unlikely(!kdata)) {
+   retcode = -ENOMEM;
+

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Hold a wakeref for probing the ring registers



On 30/05/2017 13:50, Chris Wilson wrote:

On Tue, May 30, 2017 at 01:37:23PM +0100, Tvrtko Ursulin wrote:


On 30/05/2017 13:13, Chris Wilson wrote:

Allow intel_engine_is_idle() to be called outside of the GT wakeref by
acquiring the device runtime pm for ourselves. This allows the function
to act as check after we assume the engine is idle and we release the GT
wakeref held whilst we have requests.

[ 2613.401647] RPM wakelock ref not held during HW access
[ 2613.401684] [ cut here ]
[ 2613.401720] WARNING: CPU: 5 PID: 7739 at 
drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi 
x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp 
snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei 
prime_numbers [last unloaded: i915]
[ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U  
4.12.0-rc2-CI-CI_DRM_421+ #1
[ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 
02/15/2016
[ 2613.401840] task: 880409e3a740 task.stack: c900084dc000
[ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401863] RSP: 0018:c900084dfce8 EFLAGS: 00010292
[ 2613.401869] RAX: 002a RBX: 8804016a8000 RCX: 0006
[ 2613.401871] RDX: 0006 RSI: 81cbf2d9 RDI: 81c9e3a7
[ 2613.401874] RBP: c900084dfd18 R08: 880409e3afc8 R09: 
[ 2613.401877] R10: 8a1c483f R11:  R12: 209c
[ 2613.401879] R13: 0001 R14: 8804016a8000 R15: 8804016ac150
[ 2613.401882] FS:  7f39ef3dd8c0() GS:88041fb4() 
knlGS:
[ 2613.401885] CS:  0010 DS:  ES:  CR0: 80050033
[ 2613.401887] CR2: 023717c8 CR3: 0002e7b34000 CR4: 001406e0
[ 2613.401889] Call Trace:
[ 2613.401912]  intel_engine_is_idle+0x76/0x90 [i915]
[ 2613.401931]  i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
[ 2613.401951]  fault_irq_set+0x40/0x90 [i915]
[ 2613.401970]  i915_ring_test_irq_set+0x42/0x50 [i915]
[ 2613.401976]  simple_attr_write+0xc7/0xe0
[ 2613.401981]  full_proxy_write+0x4f/0x70
[ 2613.401987]  __vfs_write+0x23/0x120
[ 2613.401992]  ? rcu_read_lock_sched_held+0x75/0x80
[ 2613.401996]  ? rcu_sync_lockdep_assert+0x2a/0x50
[ 2613.401999]  ? __sb_start_write+0xfa/0x1f0
[ 2613.402004]  vfs_write+0xc5/0x1d0
[ 2613.402008]  ? trace_hardirqs_on_caller+0xe7/0x1c0
[ 2613.402013]  SyS_write+0x44/0xb0
[ 2613.402020]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 2613.402022] RIP: 0033:0x7f39eded6670
[ 2613.402025] RSP: 002b:7fffdcdcb1a8 EFLAGS: 0246 ORIG_RAX: 
0001
[ 2613.402030] RAX: ffda RBX: 81470203 RCX: 7f39eded6670
[ 2613.402033] RDX: 0001 RSI: 0041bc33 RDI: 0006
[ 2613.402036] RBP: c900084dff88 R08: 7f39ef3dd8c0 R09: 0001
[ 2613.402038] R10:  R11: 0246 R12: 0041bc33
[ 2613.402041] R13: 0006 R14:  R15: 
[ 2613.402046]  ? __this_cpu_preempt_check+0x13/0x20
[ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 0f 85 29 
fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 <0f> ff e9 0f 
fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
[ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---

Fixes: 5400367a864d ("drm/i915: Ensure the engine is idle before manually changing 
HWS")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 413bfd8d4bf4..699f2d3861c7 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1205,6 +1205,22 @@ int intel_ring_workarounds_emit(struct 
drm_i915_gem_request *req)
return 0;
  }
+static bool ring_is_idle(struct intel_engine_cs *engine)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+   bool idle = true;
+
+   intel_runtime_pm_get(dev_priv);


I didn't find a path where this would be needed on top of the
previous patch. I am not objecting to making it more robust, just
checking if I have missed something?


I don't think there is currently. I thought this was suitable
"belt-and-braces" approach so that we could just write an assertion
later on (ignorant of the GPU state) without causing more pain.


+   /* No bit for gen2, so assume the CS parser is idle */
+   if (INTEL_GEN(dev_priv) > 2 && !(I915_READ_MODE(engine) & MODE_IDLE))
+   idle = false;


Could assign a logic evaluation to idle directly here but doesn't matter.


Yes, but patch 3 encouraged t

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/gvt: Add gvt options sanitize function

On ti, 2017-05-30 at 13:45 +0100, Chris Wilson wrote:
> On Sat, May 27, 2017 at 10:01:48AM -, Patchwork wrote:
> > 
> > == Series Details ==
> > 
> > Series: series starting with [v2,1/3] drm/i915/gvt: Add gvt options 
> > sanitize function
> > URL   : https://patchwork.freedesktop.org/series/24982/
> > State : success
> 
> Sigh. Had to resort to checking pw, but it lgtm.
> The series is
> Reviewed-by: Chris Wilson 

Fixed the order of the Suggested-by, Signed-off-by etc. to be in
chronological order and merged. Thanks for the patch and review.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] drm: Optimise drm_ioctl() for small user args

On ti, 2017-05-30 at 13:55 +0100, Chris Wilson wrote:
> When looking at simple ioctls coupled with conveniently small user
> parameters, the overhead of the syscall and drm_ioctl() present large
> low hanging fruit. Profiling trivial microbenchmarks around
> i915_gem_busy_ioctl, the low hanging fruit comprises of the call to
> copy_user(). Those calls are only inlined by the macro where the
> constant is known at compile-time, but the ioctl argument size depends
> on the ioctl number. To help the compiler, explicitly add switches for
> the small sizes that expand to simple moves to/from user. Doing the
> multiple inlines does add significant code bloat, so it is very
> debatable as to its value. Back to the trivial, but frequently used,
> example of i915_gem_busy_ioctl() on a Broadwell avoiding the call gives
> us a 15-25% improvement:
> 
>    before   after
>   single  100.173ns    84.496ns
>   parallel (x4)   204.275ns   152.957ns
> 
> On a baby Broxton nuc:
> 
>   before   after
>   single  245.355ns   199.477ns
>   parallel (x2)   280.892ns   232.726ns
> 
> Looking at the cost distribution by moving an equivalent switch into
> arch/x86/lib/usercopy, the overhead to the copy user is split almost
> equally between the function call and the actual copy itself. It seems
> copy_user_enhanced_fast_string simply is not that good at small (single
> register) copies. Something as simple as
> 
> @@ -28,6 +28,9 @@ copy_user_generic(void *to, const void *from, unsigned len)
>  {
> unsigned ret;
> 
> +   if (len <= 16)
> +   return copy_user_generic_unrolled(to, from, len);
> 
> is enough to speed up i915_gem_busy_ioctl() by 10% :|
> 
> Note that this overhead may entirely be x86 specific.
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 

I think this should be integrated into __copy_{to,from}_user directly,
but in the meanwhile the code is;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for HDMI YCBCR output handling in DRM layer (rev2)

== Series Details ==

Series: HDMI YCBCR output handling in DRM layer (rev2)
URL   : https://patchwork.freedesktop.org/series/22684/
State : failure

== Summary ==

Series 22684v2 HDMI YCBCR output handling in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/22684/revisions/2/mbox/

Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-skl-6260u)
dmesg-warn -> SKIP   (fi-skl-6700hq) fdo#101144 +2
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-bxt-j4205)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7560u)
Subgroup basic-flip-default-b:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-bxt-j4205)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7560u)
Subgroup basic-flip-default-c:
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-bxt-j4205) fdo#101047
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7560u)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m) fdo#100215 +15
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-6260u)
fail   -> SKIP   (fi-skl-6700hq) fdo#101154 +24
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-bxt-j4205)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7560u)
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-6260u)
pass

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

== Series Details ==

Series: series starting with [1/3] drm/i915: Short-circuit 
i915_gem_wait_for_idle() if already idle
URL   : https://patchwork.freedesktop.org/series/25039/
State : success

== Summary ==

Series 25039v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/25039/revisions/1/mbox/

Test kms_busy:
Subgroup basic-flip-default-a:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144 +2

fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:448s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:435s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:586s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:509s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:434s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:412s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:416s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:484s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:566s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:457s
fi-skl-6700hqtotal:278  pass:230  dwarn:1   dfail:0   fail:25  skip:22  
time:411s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:465s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:501s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:666s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:405s

f98c6d553b47ea4ad8eed33a9e768d8e30d8674a drm-tip: 2017y-05m-30d-13h-06m-42s UTC 
integration manifest
7cfa36f drm/i915: Check the ring is empty when declaring the engines are idle
065a329 drm/i915: Hold a wakeref for probing the ring registers
afb21de drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4830/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support




On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil  wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete newbie when it
comes to mst.

I don't really have more clue, but yeah if you don't have an mst thing (a
simple dp port multiplexer is what I use for testing here, then plug in a
converter dongle or cable into that) then probably better to not wire up
the code for it.

I think my NUC already uses mst internally. But I was planning on buying a
dp multiplexer to make sure there is nothing special I need to do for mst.

The CEC Tunneling is all in the branch device, so if I understand things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware issue
or something else. The BIOS is able to do some CEC, but whether they hook
into the MegaChip or have the CEC pin connected to a GPIO or something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would be very
helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux. 
The release notes for the NUC state that there is a BIOS configuration 
option for enabling support. My doesn't have the option but the LSPCON 
fully supports CEC.


-Clint




BR,
Jani.


It would be so nice to get MegaChip CEC Tunneling working on the NUC, because
then you have native CEC support without requiring any Pulse Eight adapter.

And add a CEC-capable USB-C to HDMI adapter and you have it on the USB-C
output as well.

Regards,

Hans


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Optimise drm_ioctl() for small user args

== Series Details ==

Series: drm: Optimise drm_ioctl() for small user args
URL   : https://patchwork.freedesktop.org/series/25044/
State : success

== Summary ==

Series 25044v1 drm: Optimise drm_ioctl() for small user args
https://patchwork.freedesktop.org/api/1.0/series/25044/revisions/1/mbox/

Test kms_busy:
Subgroup basic-flip-default-a:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144 +3
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
fail   -> PASS   (fi-skl-6700hq) fdo#101154 +7

fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144
fdo#101154 https://bugs.freedesktop.org/show_bug.cgi?id=101154

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:445s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:432s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:573s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:510s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:479s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:429s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:416s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:420s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:489s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:475s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:573s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:463s
fi-skl-6700hqtotal:278  pass:239  dwarn:0   dfail:1   fail:17  skip:21  
time:431s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:467s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:502s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:437s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:718s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:402s

f98c6d553b47ea4ad8eed33a9e768d8e30d8674a drm-tip: 2017y-05m-30d-13h-06m-42s UTC 
integration manifest
cb00df0 drm: Optimise drm_ioctl() for small user args

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4831/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915/skl+: Don't trust cached ddb values

2017-05-30 Thread Lankhorst, Maarten

Mahesh Kumar schreef op di 30-05-2017 om 18:26 [+0530]:
> Hi Maarten,
> 
> Thanks for review :)
> 
> 
> On Tuesday 30 May 2017 03:30 PM, Maarten Lankhorst wrote:
> > Op 26-05-17 om 17:15 schreef Mahesh Kumar:
> > > Don't trust cached DDB values. Recalculate the ddb value if
> > > cached value
> > > is zero.
> > > 
> > > If i915 is build as a module, there may be a race condition when
> > > cursor_disable call comes even before intel_fbdev_initial_config.
> > > Which may lead to cached value being 0. And further commit will
> > > fail
> > > until a modeset.
> > > 
> > > Signed-off-by: Mahesh Kumar 
> > > ---
> > >   drivers/gpu/drm/i915/intel_pm.c | 15 ++-
> > >   1 file changed, 10 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 936eef1634c7..b67be1355e39 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -3721,6 +3721,7 @@ skl_ddb_get_pipe_allocation_limits(struct
> > > drm_device *dev,
> > >   struct drm_i915_private *dev_priv = to_i915(dev);
> > >   struct drm_crtc *for_crtc = cstate->base.crtc;
> > >   unsigned int pipe_size, ddb_size;
> > > + unsigned int active_crtcs;
> > >   int nth_active_pipe;
> > >   
> > >   if (WARN_ON(!state) || !cstate->base.active) {
> > > @@ -3731,10 +3732,11 @@ skl_ddb_get_pipe_allocation_limits(struct
> > > drm_device *dev,
> > >   }
> > >   
> > >   if (intel_state->active_pipe_changes)
> > > - *num_active = hweight32(intel_state-
> > > >active_crtcs);
> > > + active_crtcs = intel_state->active_crtcs;
> > >   else
> > > - *num_active = hweight32(dev_priv->active_crtcs);
> > > + active_crtcs = dev_priv->active_crtcs;
> > >   
> > > + *num_active = hweight32(active_crtcs);
> > >   ddb_size = INTEL_INFO(dev_priv)->ddb_size;
> > >   WARN_ON(ddb_size == 0);
> > >   
> > > @@ -3754,12 +3756,15 @@ skl_ddb_get_pipe_allocation_limits(struct
> > > drm_device *dev,
> > >    * copy from old state to be sure
> > >    */
> > >   *alloc = to_intel_crtc_state(for_crtc->state)-
> > > >wm.skl.ddb;
> > > - return;
> > > + if (!skl_ddb_entry_size(alloc))
> > > + DRM_DEBUG_KMS("Cached pipe DDB is 0
> > > recalculate\n");
> > > + else
> > > + return;
> > >   }
> > >   
> > > - nth_active_pipe = hweight32(intel_state->active_crtcs &
> > > + nth_active_pipe = hweight32(active_crtcs &
> > >   (drm_crtc_mask(for_crtc) -
> > > 1));
> > > - pipe_size = ddb_size / hweight32(intel_state-
> > > >active_crtcs);
> > > + pipe_size = ddb_size / hweight32(active_crtcs);
> > >   alloc->start = nth_active_pipe * ddb_size /
> > > *num_active;
> > >   alloc->end = alloc->start + pipe_size;
> > >   }
> > 
> > I'd love it if you also add a warning somewhere for active pipe
> > with no ddb allocation to prevent this from reoccuring in the
> > future. :)
> > But with the root cause being a invalid ddb allocation at boot,
> > won't the below one liner should fix it too, but better?
> 
> Above DEBUG message is actually warning. That will hit only if pipe
> is 
> active & DDB allocated for that pipe is "0" (we do return from caller
> if 
> !cstate->active).
> I can reword the msg to be WARN & make it something like "Pipe is
> active 
> with No DDB allocated, recompute ddb now". This will fix the issue
> as 
> well as add warning msg.
> 
> > 
> > I'l ltest it when f3-kbl becomes available again.
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index a488e068c3d6..63a47909f618 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -5051,7 +5051,7 @@ skl_compute_wm(struct drm_atomic_state
> > *state)
> >      */
> >     for_each_new_crtc_in_state(state, crtc, cstate, i)
> >     changed = true;
> > -   if (!changed)
> > +   if (!changed && !to_i915(state->dev)->wm.distrust_bios_wm)
> >     return 0;
> >   
> 
> This change should also solve the issue during boot.

Yeah I did some testing and this fixes it.
Looks like a bug in the original implementation of skl_compute_wm that
the KBL just happened to hit.

So I guess if others are hitting it too, then this needs
Fixes: 98d39494d375 ("drm/i915/gen9: Compute DDB allocation at atomic
check time (v4)")
Cc:  # v4.8+

smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database




On 05/29/2017 04:06 AM, Jani Nikula wrote:

On Thu, 18 May 2017, Clint Taylor  wrote:

On 05/18/2017 04:10 AM, Jani Nikula wrote:

Face the fact, there are Display Port sink and branch devices out there
in the wild that don't follow the Display Port specifications, or they
have bugs, or just otherwise require special treatment. Start a common
quirk database the drivers can query based on the DP device
identification. At least for now, we leave the workarounds for the
drivers to implement as they see fit.

For starters, add a branch device that can't handle full 24-bit main
link Mdiv and Ndiv main link attributes properly. Naturally, the
workaround of reducing main link attributes for all devices ended up in
regressions for other devices. So here we are.

v2: Rebase on DRM DP desc read helpers

v3: Fix the OUI memcmp blunder (Clint)

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 

I pushed the series to drm-intel topic/dp-quirks branch based on
v4.12-rc3, with the goal of merging this to v4.12. Thanks for the review
and testing so far; would you mind giving that branch a go too, to
ensure I didn't screw anything up while applying?
Topic branch appears to work as expected. Quirk is applied only to OUI 
0x0022B9 and the n and m values are reduced.


Topic branch is:
Tested-by: Clinton Taylor 

-Clint



BR,
Jani.



Cc: Ville Syrjälä 
Cc: Dhinakaran Pandiyan 
Cc: Clint Taylor 
Cc: Adam Jackson 
Cc: Harry Wentland 
Signed-off-by: Jani Nikula 
---
   drivers/gpu/drm/drm_dp_helper.c | 52 
+++--
   include/drm/drm_dp_helper.h | 32 +
   2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 52e0ca9a5bb1..213fb837e1c4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1209,6 +1209,51 @@ int drm_dp_stop_crc(struct drm_dp_aux *aux)
   }
   EXPORT_SYMBOL(drm_dp_stop_crc);
   
+struct dpcd_quirk {

+   u8 oui[3];
+   bool is_branch;
+   u32 quirks;
+};
+
+#define OUI(first, second, third) { (first), (second), (third) }
+
+static const struct dpcd_quirk dpcd_quirk_list[] = {
+   /* Analogix 7737 needs reduced M and N at HBR2 link rates */
+   { OUI(0x00, 0x22, 0xb9), true, BIT(DP_DPCD_QUIRK_LIMITED_M_N) },
+};
+
+#undef OUI
+
+/*
+ * Get a bit mask of DPCD quirks for the sink/branch device identified by
+ * ident. The quirk data is shared but it's up to the drivers to act on the
+ * data.
+ *
+ * For now, only the OUI (first three bytes) is used, but this may be extended
+ * to device identification string and hardware/firmware revisions later.
+ */
+static u32
+drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, bool is_branch)
+{
+   const struct dpcd_quirk *quirk;
+   u32 quirks = 0;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(dpcd_quirk_list); i++) {
+   quirk = &dpcd_quirk_list[i];
+
+   if (quirk->is_branch != is_branch)
+   continue;
+
+   if (memcmp(quirk->oui, ident->oui, sizeof(ident->oui)) != 0)
+   continue;
+
+   quirks |= quirk->quirks;
+   }
+
+   return quirks;
+}
+
   /**
* drm_dp_read_desc - read sink/branch descriptor from DPCD
* @aux: DisplayPort AUX channel
@@ -1231,14 +1276,17 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct 
drm_dp_desc *desc,
if (ret < 0)
return ret;
   
+	desc->quirks = drm_dp_get_quirks(ident, is_branch);

+
dev_id_len = strnlen(ident->device_id, sizeof(ident->device_id));
   
-	DRM_DEBUG_KMS("DP %s: OUI %*phD dev-ID %*pE HW-rev %d.%d SW-rev %d.%d\n",

+   DRM_DEBUG_KMS("DP %s: OUI %*phD dev-ID %*pE HW-rev %d.%d SW-rev %d.%d quirks 
0x%04x\n",
  is_branch ? "branch" : "sink",
  (int)sizeof(ident->oui), ident->oui,
  dev_id_len, ident->device_id,
  ident->hw_rev >> 4, ident->hw_rev & 0xf,
- ident->sw_major_rev, ident->sw_minor_rev);
+ ident->sw_major_rev, ident->sw_minor_rev,
+ desc->quirks);
   
   	return 0;

   }
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index aee5b96b51d7..717cb8496725 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1090,12 +1090,44 @@ struct drm_dp_dpcd_ident {
   /**
* struct drm_dp_desc - DP branch/sink device descriptor
* @ident: DP device identification from DPCD 0x400 (sink) or 0x500 (branch).
+ * @quirks: Quirks; use drm_dp_has_quirk() to query for the quirks.
*/
   struct drm_dp_desc {
struct drm_dp_dpcd_ident ident;
+   u32 quirks;
   };
   
   int drm_dp_read_desc(struct drm_dp_aux *aux, struct drm_dp_desc *desc,

 bool is_branch);
   
+/**

+ * enum drm_dp_quirk - Display Port sink/branch device specific quirks
+ *
+ * Display Port sin

Re: [Intel-gfx] [RFC] drm: Optimise drm_ioctl() for small user args

On Tue, May 30, 2017 at 01:55:20PM +0100, Chris Wilson wrote:
> When looking at simple ioctls coupled with conveniently small user
> parameters, the overhead of the syscall and drm_ioctl() present large
> low hanging fruit. Profiling trivial microbenchmarks around
> i915_gem_busy_ioctl, the low hanging fruit comprises of the call to
> copy_user(). Those calls are only inlined by the macro where the
> constant is known at compile-time, but the ioctl argument size depends
> on the ioctl number. To help the compiler, explicitly add switches for
> the small sizes that expand to simple moves to/from user. Doing the
> multiple inlines does add significant code bloat, so it is very
> debatable as to its value. Back to the trivial, but frequently used,
> example of i915_gem_busy_ioctl() on a Broadwell avoiding the call gives
> us a 15-25% improvement:
> 
>before   after
>   single  100.173ns84.496ns
>   parallel (x4)   204.275ns   152.957ns
> 
> On a baby Broxton nuc:
> 
>   before   after
>   single  245.355ns   199.477ns
>   parallel (x2)   280.892ns   232.726ns
> 
> Looking at the cost distribution by moving an equivalent switch into
> arch/x86/lib/usercopy, the overhead to the copy user is split almost
> equally between the function call and the actual copy itself. It seems
> copy_user_enhanced_fast_string simply is not that good at small (single
> register) copies. Something as simple as
> 
> @@ -28,6 +28,9 @@ copy_user_generic(void *to, const void *from, unsigned len)
>  {
> unsigned ret;
> 
> +   if (len <= 16)
> +   return copy_user_generic_unrolled(to, from, len);
> 
> is enough to speed up i915_gem_busy_ioctl() by 10% :|
> 
> Note that this overhead may entirely be x86 specific.
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> ---
> + if (in_size) {
> + if (unlikely(!access_ok(VERIFY_READ, arg, in_size)))
> + goto err_invalid_user;
> +
> + switch (in_size) {
> + case 4:
> + if (unlikely(__copy_from_user(kdata, (void __user *)arg,
> +   4)))
> + goto err_invalid_user;
> + break;
> + case 8:
> + if (unlikely(__copy_from_user(kdata, (void __user *)arg,
> +   8)))
> + goto err_invalid_user;
> + break;
> + case 16:
> + if (unlikely(__copy_from_user(kdata, (void __user *)arg,
> +   16)))
> + goto err_invalid_user;
> + break;

For example, currently x86-32 only converts case 4 above. It could
trivially do case 8 as well, but by case 16 it may as well use the
function call to its loop in assembly. And currently x86-32 has no
optimisations for fixed sized puts.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915/glk: WA#0893: Also apply memory bw wa to Geminilake.

2017-05-30 Thread Vivi, Rodrigo


On Mon, 2017-05-29 at 11:26 +0300, Ander Conselvan De Oliveira wrote:
> On Fri, 2017-05-26 at 16:23 -0700, Rodrigo Vivi wrote:
> > According to spec this WA is needed for every gen9.
> 
> Actually GLK has a gen10 display, so the gen9 workarounds don't apply.

Oh, indeed!

Please ignore this patch.

> 
> Ander
> 
> > 
> > Cc:Arthur Runyan 
> > Cc: Ander Conselvan de Oliveira 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 5abeb3f..7a5f2e4 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2904,9 +2904,8 @@ static inline struct scatterlist *__sg_next(struct 
> > scatterlist *sg)
> >  #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
> > (IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> >  
> > -/* WA#0893 */
> > -#define NEEDS_WaIncreaseMemoryBW(dev_priv) (IS_GEN9_BC(dev_priv) || \
> > -IS_BROXTON(dev_priv))
> > +/* WA#0893: GEN9:ALL */
> > +#define NEEDS_WaIncreaseMemoryBW(dev_priv) (IS_GEN9(dev_priv))
> >  
> >  /*
> >   * dp aux and gmbus irq on gen4 seems to be able to generate legacy 
> > interrupts

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1-107).
> 
> This patch adds a bool input variable, which indicates if the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.
> 
> This patch touches all drm drivers, who are callers of this function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> no change in current behavior, is_hdmi2 is kept as false.
> 
> In case of I915 driver, this patch checks the connector->display_info
> to check if the connected display is HDMI 2.0.
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Cc: Daniel Vetter 
> 
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
> 
> V2: Rebase, Added r-b from Andrzej
> 
> Reviewed-by: Andrzej Hajda 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
>  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
>  drivers/gpu/drm/drm_edid.c| 12 +++-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
>  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
>  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
>  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
>  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
>  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
>  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
>  drivers/gpu/drm/tegra/sor.c   |  2 +-
>  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
>  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
>  include/drm/drm_edid.h|  3 ++-
>  21 files changed, 38 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 3c62c45..4923ddc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
> *encoder,
>   dce_v10_0_audio_write_sad_regs(encoder);
>   dce_v10_0_audio_write_latency_fields(encoder, mode);
>  
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>   if (err < 0) {
>   DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
>   return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index c8ed0fa..4101684 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
> *encoder,
>   dce_v11_0_audio_write_sad_regs(encoder);
>   dce_v11_0_audio_write_latency_fields(encoder, mode);
>  
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>   if (err < 0) {
>   DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
>   return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index 3e90c19..a7f6b32 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
> *encoder,
>   dce_v8_0_audio_write_sad_regs(encoder);
>   dce_v8_0_audio_write_latency_fields(encoder, mode);
>  
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>   if (err < 0) {
>   DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
>   return;
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> index a2a8236..f9b77b8 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> @@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge 
> *bridge,
>  
>   mutex_lock(&anx78xx->lock);
>  
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, adjusted_mode);
> + err = drm_hdmi_avi_infoframe_from_

Re: [Intel-gfx] [PATCH v2 02/11] drm/edid: Complete CEA modedb(VIC 1-107)

On Tue, May 30, 2017 at 05:43:41PM +0530, Shashank Sharma wrote:
> CEA-861-F specs defines new video modes to be used with
> HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
> 1-107.
> 
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse new CEA modes using the existing methods, we have
> to complete the modedb (VIC=65 onwards).
> 
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).

Still missing the "native bit" handling.

> 
> The patch was originaly discussed and reviewed here:
> https://patchwork.freedesktop.org/patch/135810/
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> 
> V2: Rebase
> 
> Reviewed-by: Jose Abreu 
> Reviewed-by: Alex Deucher 
> Acked-by: Harry Wentland 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c | 215 
> +
>  1 file changed, 215 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 8b23435..c3fa3a1 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] 
> = {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720@24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720@25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720@30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720@50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720@60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720@100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720@120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080@24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080@25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 74 - 1920x1080@30Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 75 - 1920x1080@50Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 76 - 1920x1080@60Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TY

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

On Tue, May 30, 2017 at 02:09:53PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/3] drm/i915: Short-circuit 
> i915_gem_wait_for_idle() if already idle
> URL   : https://patchwork.freedesktop.org/series/25039/
> State : success
> 
> == Summary ==
> 
> Series 25039v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/25039/revisions/1/mbox/
> 
> Test kms_busy:
> Subgroup basic-flip-default-a:
> dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144 +2
> 
> fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time:448s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time:435s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time:586s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:509s
> fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
> time:486s
> fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:483s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:434s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:412s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time:416s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:484s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:468s
> fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
> time:464s
> fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
> time:566s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:457s
> fi-skl-6700hqtotal:278  pass:230  dwarn:1   dfail:0   fail:25  skip:22  
> time:411s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:465s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:501s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time:436s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:666s
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
> time:405s
> 
> f98c6d553b47ea4ad8eed33a9e768d8e30d8674a drm-tip: 2017y-05m-30d-13h-06m-42s 
> UTC integration manifest
> 7cfa36f drm/i915: Check the ring is empty when declaring the engines are idle
> 065a329 drm/i915: Hold a wakeref for probing the ring registers
> afb21de drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

Pushed the first 2 as that will clear the error reported by CI. I'm
leaving the third until Mika can check as we have discussed something
similar in the past. Plus lockdep_assert_held_if() is still pending.

Thanks for the review,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 02/11] drm/edid: Complete CEA modedb(VIC 1-107)

2017-05-30 Thread Sharma, Shashank


Regards

Shashank


On 5/30/2017 9:48 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 05:43:41PM +0530, Shashank Sharma wrote:

CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

Still missing the "native bit" handling.
I tried searching the native bit handling in the code, but I could not 
get any thing. We are typically doing a (vic & 127) and that's all.

Can you please point out a bit here ?

- Shashank

The patch was originaly discussed and reviewed here:
https://patchwork.freedesktop.org/patch/135810/

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Harry Wentland 

V2: Rebase

Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 
Acked-by: Harry Wentland 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c | 215 +
  1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8b23435..c3fa3a1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] = 
{
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080@50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC |

Re: [Intel-gfx] [PATCH v2 03/11] drm: parse ycbcr420 cmdb block

On Tue, May 30, 2017 at 05:43:42PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec adds support for ycbcr420 sub-sampled output.
> CEA-861-F adds two new blocks in EDID, to provide information
> about sink's support for ycbcr420 output.
> 
> One of these new blocks is: ycbcr420cmdb(ycbcr 420 capability
> map data block). This gives information about video modes which
> can support ycbcr420 output mode also (along with RGB,YCBCR444/
> 422 etc)
> 
> This block contains a bitmap index of normal svd videomodes, which can
> support ycbcr420 output too.
> So if bit 0 from first vcb byte is set,first video mode in the svd list
> can support ycbcr420 output too. Bit 2 means second video mode from svd
> list can support ycbcr420 output too, and so on.
> 
> This patch adds parsing and handling of ycbcr420-cmdb in the DRM layer.
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Emil Velikov 
> 
> V2: Addressed
> Review comments from Emil:
> - Use 1ULL< - Use the suggested method for updating dbmap.
> - Add documentation for ycbcr420_vcb_map to fix kbuild warning.
> 
> Review comments from Ville:
> - Do not expose the ycbcr420 flags in uabi layer, keep it internal.
> - Save a map of ycbcr420 modes for future reference.
> - Check db length before trying to parse extended tag.
> - Add a warning if there are > 64 modes in capability map block.
> - Use y420cmdb in function names and macros while dealing with vcb
>   to be aligned with spec.
> - Move the display information parsing block ahead of mode parsing
>   blocks.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 118 
> ++--
>  include/drm/drm_connector.h |  12 +
>  2 files changed, 127 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c3fa3a1..ce86528 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
> struct edid *edid,
>  #define VIDEO_BLOCK 0x02
>  #define VENDOR_BLOCK0x03
>  #define SPEAKER_BLOCK0x04
> -#define VIDEO_CAPABILITY_BLOCK   0x07
> +#define VIDEO_CAPABILITY_BLOCK 0x07
> +#define VIDEO_DATA_BLOCK_420 0x0E
> +#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
>  #define EDID_BASIC_AUDIO (1 << 6)
>  #define EDID_CEA_YCRCB444(1 << 5)
>  #define EDID_CEA_YCRCB422(1 << 4)
> @@ -3143,15 +3145,50 @@ drm_display_mode_from_vic_index(struct drm_connector 
> *connector,
>   return newmode;
>  }
>  
> +static void
> +drm_add_vcb_modes(struct drm_connector *connector, u8 vic)
> +{
> + u32 *map;
> + u8 index = 0;
> + struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
> +
> + /* VICs are 1 to 127(107 defined till CEA-861-F) */
> + vic &= 127;
> +
> + /*
> +  * ycbcr420_vcb_modes is a fix position 128 bit bitmap. This indicates
> +  * support for ycbcr420 output per VIC. Arrangement is bit[n] indicates
> +  * if vic[n+1] supports ycbcr420 output.
> +  * ycbcr420_vcb_modes[0] = |VIC=32 |VIC=31 ||VIC=2 |VIC=1 |
> +  * ycbcr420_vcb_modes[1] = |VIC=64 |VIC=63 ||VIC=34|VIC=33|
> +  * ycbcr420_vcb_modes[2] = |VIC=96 |VIC=95 ||VIC=66|VIC=65|
> +  * ycbcr420_vcb_modes[3] = |VIC=128|VIC=127||VIC=34|VIC=97|
> +  */
> + map = &(hdmi->ycbcr420_vcb_modes[(vic - 1) / 32]);
> + index = (vic - 1) % 32;
> + *map |= (1 << index);

unsigned long whatever[BITS_TO_LONGS(nr)];

__set_bit(), test_bit(), etc.


> +}
> +
>  static int
>  do_cea_modes(struct drm_connector *connector, const u8 *db, u8 len)
>  {
>   int i, modes = 0;
> + struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
> + u64 hdmi_vcb_map = hdmi->ycbcr420_vcb_map;
>  
>   for (i = 0; i < len; i++) {
>   struct drm_display_mode *mode;
>   mode = drm_display_mode_from_vic_index(connector, db, len, i);
>   if (mode) {
> + /*
> +  * ycbcr420 capability block contains a bitmap which
> +  * gives the index of such CEA modes in VDB, which can
> +  * support ycbcr420 sampling output also.
> +  * For example, if the bit 0 in bitmap is set,
> +  * first mode in VDB can support ycbcr420 output too.
> +  */
> + if (hdmi_vcb_map & (1 << i))
> + drm_add_vcb_modes(connector, db[i]);
>   drm_mode_probed_add(connector, mode);
>   modes++;
>   }
> @@ -3427,6 +3464,12 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, 
> const u8 *db, u8 len,
>  }
>  
>  static int
> +cea_db_extended_tag(const u8 *db)
> +{
> + return db[1];
> +}
> +
> +static int
>  cea_db_payload_len(const u8 *db)
>  {
>   return db[0] & 0x1f;
>

Re: [Intel-gfx] [PATCH v2 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

2017-05-30 Thread Sharma, Shashank


Regards

Shashank


On 5/30/2017 9:43 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote:

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

V2: Rebase, Added r-b from Andrzej

Reviewed-by: Andrzej Hajda 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
  drivers/gpu/drm/drm_edid.c| 12 +++-
  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
  drivers/gpu/drm/tegra/sor.c   |  2 +-
  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
  include/drm/drm_edid.h|  3 ++-
  21 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 3c62c45..4923ddc 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
  
-	err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index c8ed0fa..4101684 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
  
-	err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 3e90c19..a7f6b32 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v8_0_audio_write_sad_regs(encoder);
dce_v8_0_audio_write_latency_fields(encoder, mode);
  
-	err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..f9b77b8 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge 
*bridge,
  
  	mutex_lock(&anx78xx->lock);
  
-	err = drm_hdmi_avi_infoframe_from_display_mode(&frame, adjusted_mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, adjusted_mode,
+  false);
i

Re: [Intel-gfx] [PATCH v2 04/11] drm: parse ycbcr 420 deep color information

On Tue, May 30, 2017 at 05:43:43PM +0530, Shashank Sharma wrote:
> CEA-861-F spec adds ycbcr420 deep color support information
> in hf-vsdb block. This patch extends the existing hf-vsdb parsing
> function by adding parsing of ycbcr420 deep color support from the
> EDID and adding it into display information stored.
> 
> Cc: Ville Syrjälä 
> Cc: Jose Abreu 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 15 +++
>  include/drm/drm_connector.h |  3 +++
>  include/drm/drm_edid.h  |  5 +
>  3 files changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index ce86528..50fa96e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4142,6 +4142,19 @@ drm_default_rgb_quant_range(const struct 
> drm_display_mode *mode)
>  }
>  EXPORT_SYMBOL(drm_default_rgb_quant_range);
>  
> +static void drm_parse_ycbcr420_deep_color_info(struct drm_connector 
> *connector,
> +  const u8 *db)
> +{
> + struct drm_hdmi_info *info = &connector->display_info.hdmi;
> +
> + if (db[7] & DRM_EDID_YCBCR420_DC_48)
> + info->ycbcr420_dc_modes |= DRM_EDID_YCBCR420_DC_48;
> + if (db[7] & DRM_EDID_YCBCR420_DC_36)
> + info->ycbcr420_dc_modes |= DRM_EDID_YCBCR420_DC_36;
> + if (db[7] & DRM_EDID_YCBCR420_DC_30)
> + info->ycbcr420_dc_modes |= DRM_EDID_YCBCR420_DC_30;
> +}
> +
>  static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
>const u8 *hf_vsdb)
>  {
> @@ -4182,6 +4195,8 @@ static void drm_parse_hdmi_forum_vsdb(struct 
> drm_connector *connector,
>   scdc->scrambling.low_rates = true;
>   }
>   }
> +
> + drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
>  }
>  
>  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 07b10ab..49cc38c 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -148,6 +148,9 @@ struct drm_hdmi_info {
>  
>   /** @ycbcr420_vcb_map: bitmap of SVD index, to extraxt vcb modes */
>   u64 ycbcr420_vcb_map;
> +
> + /** @ycbcr420_dc_modes: bitmap of deep color support index */
> + u8 ycbcr420_dc_modes;

We seem to be wasting quite a few bits by reusing the EDID bit
definition directly. Maybe we should consider packing these better?
But I suppose we can look into that later.

>  };
>  
>  /**
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index c07eb81..a4d174e7 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -213,6 +213,11 @@ struct detailed_timing {
>  #define DRM_EDID_HDMI_DC_30   (1 << 4)
>  #define DRM_EDID_HDMI_DC_Y444 (1 << 3)
>  
> +/* YCBCR 420 deep color modes */
> +#define DRM_EDID_YCBCR420_DC_48(1 << 6)
> +#define DRM_EDID_YCBCR420_DC_36(1 << 5)
> +#define DRM_EDID_YCBCR420_DC_30(1 << 4)
> +
>  /* ELD Header Block */
>  #define DRM_ELD_HEADER_BLOCK_SIZE4
>  
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 05/11] drm: create hdmi output property

On Tue, May 30, 2017 at 05:43:44PM +0530, Shashank Sharma wrote:
> HDMI displays can support various output types, based on
> the color space and subsampling type. The possible
> outputs from a HDMI 2.0 monitor could be:
>  - RGB
>  - YCBCR 444
>  - YCBCR 422
>  - YCBCR 420
> 
> This patch adds a drm property, using which, a userspace

I think we should add the 4:2:0 only mode support first since that
doesn't require new uapi. The uapi stuff probably needs more careful
thought as we might want to consider exposing more of the
colorimetry stuff supported by the HDMI infoframes, and DP MSA MISC
and VSC SDP.

> can specify its preference, for the HDMI output type.
> The output type enums are similar to the mentioned outputs
> above. To handle various subsampling of YCBCR output types,
> this property allows two special cases:
>  - DRM_HDMI_OUTPUT_YCBCR_HQ
> This indicates preferred output should be YCBCR output, with highest
> subsampling rate by the source/sink, which can be typically:
>  - ycbcr444
>  - ycbcr422
>  - ycbcr420
>  - DRM_HDMI_OUTPUT_YCBCR_LQ
> This indicates preferred output should be YCBCR output, with lowest
> subsampling rate supported by source/sink, which can be:
>  - ycbcr420
>  - ycbcr422
>  - ycbcr444
> 
> Default value of the property is set to 0 = RGB, so no changes if you
> dont set the property.
> 
> V2: Added description for the new variable to address build warning
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Daniel Vetter 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_atomic.c|  2 ++
>  drivers/gpu/drm/drm_atomic_helper.c |  4 
>  drivers/gpu/drm/drm_connector.c | 32 
>  include/drm/drm_connector.h | 18 ++
>  include/drm/drm_mode_config.h   |  5 +
>  5 files changed, 61 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index e163701..8c4e040 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->picture_aspect_ratio = val;
>   } else if (property == connector->scaling_mode_property) {
>   state->scaling_mode = val;
> + } else if (property == config->hdmi_output_property) {
> + state->hdmi_output = val;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 636e561..86b1780 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -567,6 +567,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   if (old_connector_state->link_status !=
>   new_connector_state->link_status)
>   new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->hdmi_output !=
> + new_connector_state->hdmi_output)
> + new_crtc_state->connectors_changed = true;
>   }
>  
>   if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 5cd61af..f3c5928 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -227,6 +227,11 @@ int drm_connector_init(struct drm_device *dev,
> config->edid_property,
> 0);
>  
> + if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)
> + drm_object_attach_property(&connector->base,
> +config->hdmi_output_property,
> +0);
> +
>   drm_object_attach_property(&connector->base,
> config->dpms_property, 0);
>  
> @@ -617,6 +622,26 @@ static const struct drm_prop_enum_list 
> drm_link_status_enum_list[] = {
>  };
>  DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
>  
> +static const struct drm_prop_enum_list drm_hdmi_output_enum_list[] = {
> + { DRM_HDMI_OUTPUT_DEFAULT_RGB, "output_rgb" },
> + { DRM_HDMI_OUTPUT_YCBCR444, "output_ycbcr444" },
> + { DRM_HDMI_OUTPUT_YCBCR422, "output_ycbcr422" },
> + { DRM_HDMI_OUTPUT_YCBCR420, "output_ycbcr420" },
> + { DRM_HDMI_OUTPUT_YCBCR_HQ, "output_ycbcr_high_subsampling" },
> + { DRM_HDMI_OUTPUT_YCBCR_LQ, "output_ycbcr_low_subsampling" },
> + { DRM_HDMI_OUTPUT_INVALID, "invalid_output" },
> +};
> +
> +/**
> + * drm_get_hdmi_output_name - return a string for a given hdmi output enum
> + * @type: enum of output type
> + */
> +const char *drm_get_hdmi_output_name(enum drm_hdmi_output_type type)
> +{
> + return drm_hdmi_

Re: [Intel-gfx] [PATCH v2 05/11] drm: create hdmi output property

2017-05-30 Thread Sharma, Shashank


Regards

Shashank


On 5/30/2017 10:06 PM, Ville Syrjälä wrote:

On Tue, May 30, 2017 at 05:43:44PM +0530, Shashank Sharma wrote:

HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
  - RGB
  - YCBCR 444
  - YCBCR 422
  - YCBCR 420

This patch adds a drm property, using which, a userspace

I think we should add the 4:2:0 only mode support first since that
doesn't require new uapi. The uapi stuff probably needs more careful
thought as we might want to consider exposing more of the
colorimetry stuff supported by the HDMI infoframes, and DP MSA MISC
and VSC SDP.
I was coming from the opposite school of thought. I was thinking 
420_only modes should
be handled carefully, whereas 420_also doesnt need any uapi (This patch 
series contains

420_also and doesnt modify the UAPI) due to following reasons:

assume there is a mode 3840x2160@60 appears to be in 2 different EDIDs, 
in first EDID as a 420_only mode

and in other as 420_also mode.
- If we add a 420_also mode in the mode_list, userspace might pick it 
for the modeset as favorite, as most of the

 420 modes are 4k modes.
- Now, if userspace doesn't set the hdmi_output property to YCBCR420, 
and sends a modeset on this mode:
 - the modeset will be successful in case of a 420_also mode, as it 
can be supported in RGB/YUV444 also.
 - the modeset will fail in case of 420_only mode, as this mode 
cant be supported in any other hdmi output format.


In this case, addition of 420_only mode, in the connectors->modes list 
should be done, only when the driver is ready to
handle the YCBCR420 output, or we have to inform userspace about these 
modes which need the hdmi_ouput property to

be set with the modeset, which might in turn need an uabi.

Does it make a case ?

- Shashank

can specify its preference, for the HDMI output type.
The output type enums are similar to the mentioned outputs
above. To handle various subsampling of YCBCR output types,
this property allows two special cases:
  - DRM_HDMI_OUTPUT_YCBCR_HQ
This indicates preferred output should be YCBCR output, with highest
subsampling rate by the source/sink, which can be typically:
  - ycbcr444
  - ycbcr422
  - ycbcr420
  - DRM_HDMI_OUTPUT_YCBCR_LQ
This indicates preferred output should be YCBCR output, with lowest
subsampling rate supported by source/sink, which can be:
  - ycbcr420
  - ycbcr422
  - ycbcr444

Default value of the property is set to 0 = RGB, so no changes if you
dont set the property.

V2: Added description for the new variable to address build warning

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_atomic.c|  2 ++
  drivers/gpu/drm/drm_atomic_helper.c |  4 
  drivers/gpu/drm/drm_connector.c | 32 
  include/drm/drm_connector.h | 18 ++
  include/drm/drm_mode_config.h   |  5 +
  5 files changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e163701..8c4e040 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+   } else if (property == config->hdmi_output_property) {
+   state->hdmi_output = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 636e561..86b1780 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -567,6 +567,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->hdmi_output !=
+   new_connector_state->hdmi_output)
+   new_crtc_state->connectors_changed = true;
}
  
  		if (funcs->atomic_check)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5cd61af..f3c5928 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -227,6 +227,11 @@ int drm_connector_init(struct drm_device *dev,
  config->edid_property,
  0);
  
+	if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)

+   drm_object_attach_property(&connector->base,
+

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support


On 05/30/2017 04:19 PM, Clint Taylor wrote:



On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil  wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete newbie when it
comes to mst.

I don't really have more clue, but yeah if you don't have an mst thing (a
simple dp port multiplexer is what I use for testing here, then plug in a
converter dongle or cable into that) then probably better to not wire up
the code for it.

I think my NUC already uses mst internally. But I was planning on buying a
dp multiplexer to make sure there is nothing special I need to do for mst.

The CEC Tunneling is all in the branch device, so if I understand things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware issue
or something else. The BIOS is able to do some CEC, but whether they hook
into the MegaChip or have the CEC pin connected to a GPIO or something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would be very
helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.


What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have actually
tested it somehow? The only working solution I have seen mentioned for the
NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.

Regards,

Hans



-Clint




BR,
Jani.


It would be so nice to get MegaChip CEC Tunneling working on the NUC, because
then you have native CEC support without requiring any Pulse Eight adapter.

And add a CEC-capable USB-C to HDMI adapter and you have it on the USB-C
output as well.

Regards,

Hans




___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support


On 05/30/2017 06:49 PM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:



On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil  wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete newbie when it
comes to mst.

I don't really have more clue, but yeah if you don't have an mst thing (a
simple dp port multiplexer is what I use for testing here, then plug in a
converter dongle or cable into that) then probably better to not wire up
the code for it.

I think my NUC already uses mst internally. But I was planning on buying a
dp multiplexer to make sure there is nothing special I need to do for mst.

The CEC Tunneling is all in the branch device, so if I understand things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware issue
or something else. The BIOS is able to do some CEC, but whether they hook
into the MegaChip or have the CEC pin connected to a GPIO or something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would be very
helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.


What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have actually
tested it somehow? The only working solution I have seen mentioned for the
NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.


If it really is working on your NUC, then can you add the output of
/sys/kernel/debug/dri/0/i915_display_info?

Thanks,

Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/psr: disable psr2 for resolution greater than 32X20

Patch merged to dinq, thanks.

I didn't put on fixes nor Cc'ed stable after chatting with Daniel about that.
Since PSR is currently disabled on 4.11 there is no risk of this
blowing anything nor changing the expected default behaviour.
So dinq seemed to be the right place for this patch.

Thanks,
Rodrigo.

On Mon, May 29, 2017 at 1:24 AM, Jani Nikula
 wrote:
> On Fri, 26 May 2017, Rodrigo Vivi  wrote:
>> I believe we need to cc:stable on this right?!
>>
>> Jani, is this ok to go ahead and merge after stable is cc'ed?
>
> Please add this, and it'll all happen automagically.
>
> Fixes: acf45d11050a ("drm/i915/psr: disable psr2 for resolution greater than 
> 32X20")
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Cc: Vathsala Nagaraju 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: intel-gfx@lists.freedesktop.org
> Cc:  # v4.11+
>
> BR,
> Jani.
>
>
>>
>> On Thu, May 25, 2017 at 9:43 AM, vathsala nagaraju
>>  wrote:
>>> psr1 is also disabled for panel resolution  greater than 32X20.
>>> Added psr2 check to disable only for psr2 panels having resolution
>>> greater than 32X20.
>>>
>>> issue was introduced by
>>> commit-id : "acf45d11050abd751dcec986ab121cb2367dcbba"
>>> commit message: "PSR2 is restricted to work with panel resolutions
>>> upto 3200x2000, move the check to intel_psr_match_conditions and fully
>>> block psr."
>>>
>>> v2: (Rodrigo)
>>>Add previous commit details which introduced the issue
>>>
>>> Cc: Rodrigo Vivi 
>>> Cc: Jim Bride 
>>> Cc: Yaroslav Shabalin 
>>> Reported-by: Yaroslav Shabalin 
>>> Reviewed-by: Rodrigo Vivi 
>>> Signed-off-by: vathsala nagaraju 
>>> ---
>>>  drivers/gpu/drm/i915/intel_psr.c | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
>>> b/drivers/gpu/drm/i915/intel_psr.c
>>> index c3780d0..559f1ab 100644
>>> --- a/drivers/gpu/drm/i915/intel_psr.c
>>> +++ b/drivers/gpu/drm/i915/intel_psr.c
>>> @@ -435,8 +435,9 @@ static bool intel_psr_match_conditions(struct intel_dp 
>>> *intel_dp)
>>> }
>>>
>>> /* PSR2 is restricted to work with panel resolutions upto 3200x2000 
>>> */
>>> -   if (intel_crtc->config->pipe_src_w > 3200 ||
>>> -   intel_crtc->config->pipe_src_h > 2000) {
>>> +   if (dev_priv->psr.psr2_support &&
>>> +   (intel_crtc->config->pipe_src_w > 3200 ||
>>> +intel_crtc->config->pipe_src_h > 2000)) {
>>> dev_priv->psr.psr2_support = false;
>>> return false;
>>> }
>>> --
>>> 1.9.1
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v14 13/14] drm/i915/perf: reprogram NOA muxes at the beginning of each workload

2017-05-30 Thread Lionel Landwerlin

There is pretty obvious bug with this patch as some OA configs spans 
more registers write than what MI_LOAD_REGISTER_IMM can do (> 128).

I'll send an updated patch.

That doesn't affect patch 14 though.

-
Lionel

On 26/05/17 12:56, Lionel Landwerlin wrote:

Dynamic slices/subslices shutdown will effectivelly loose the NOA
configuration uploaded in the slices/subslices. When i915 perf is in
use, we therefore need to reprogram it.

Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_drv.h |  2 ++
  drivers/gpu/drm/i915/i915_perf.c| 64 +
  drivers/gpu/drm/i915/intel_ringbuffer.c |  3 ++
  3 files changed, 69 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cd1dc9ee05cb..efa8a0b302ca 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2399,6 +2399,7 @@ struct drm_i915_private {
const struct i915_oa_reg *mux_regs[6];
int mux_regs_lens[6];
int n_mux_configs;
+   int total_n_mux_regs;
  
  			const struct i915_oa_reg *b_counter_regs;

int b_counter_regs_len;
@@ -3535,6 +3536,7 @@ int i915_perf_open_ioctl(struct drm_device *dev, void 
*data,
  void i915_oa_init_reg_state(struct intel_engine_cs *engine,
struct i915_gem_context *ctx,
uint32_t *reg_state);
+int i915_oa_emit_noa_config_locked(struct drm_i915_gem_request *req);
  
  /* i915_gem_evict.c */

  int __must_check i915_gem_evict_something(struct i915_address_space *vm,
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c281847eb56b..15b1f92fe5b5 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1438,11 +1438,24 @@ static void config_oa_regs(struct drm_i915_private 
*dev_priv,
}
  }
  
+static void count_total_mux_regs(struct drm_i915_private *dev_priv)

+{
+   int i;
+
+   dev_priv->perf.oa.total_n_mux_regs = 0;
+   for (i = 0; i < dev_priv->perf.oa.n_mux_configs; i++) {
+   dev_priv->perf.oa.total_n_mux_regs +=
+   dev_priv->perf.oa.mux_regs_lens[i];
+   }
+}
+
  static int hsw_enable_metric_set(struct drm_i915_private *dev_priv)
  {
int ret = i915_oa_select_metric_set_hsw(dev_priv);
int i;
  
+	count_total_mux_regs(dev_priv);

+
if (ret)
return ret;
  
@@ -1756,6 +1769,8 @@ static int gen8_enable_metric_set(struct drm_i915_private *dev_priv)

int ret = dev_priv->perf.oa.ops.select_metric_set(dev_priv);
int i;
  
+	count_total_mux_regs(dev_priv);

+
if (ret)
return ret;
  
@@ -2094,6 +2109,55 @@ void i915_oa_init_reg_state(struct intel_engine_cs *engine,

gen8_update_reg_state_unlocked(ctx, reg_state);
  }
  
+int i915_oa_emit_noa_config_locked(struct drm_i915_gem_request *req)

+{
+   struct drm_i915_private *dev_priv = req->i915;
+   u32 *cs;
+   int i, j;
+
+   lockdep_assert_held(&dev_priv->drm.struct_mutex);
+
+   if (!IS_GEN(dev_priv, 8, 9))
+   return 0;
+
+   /* Perf not supported or not enabled. */
+   if (!dev_priv->perf.initialized ||
+   !dev_priv->perf.oa.exclusive_stream)
+   return 0;
+
+   cs = intel_ring_begin(req,
+ 1 /* MI_LOAD_REGISTER_IMM */ +
+ dev_priv->perf.oa.total_n_mux_regs * 2 +
+ 4 /* GDT_CHICKEN_BITS */ +
+ 1 /* NOOP */);
+   if (IS_ERR(cs))
+   return PTR_ERR(cs);
+
+   *cs++ = MI_LOAD_REGISTER_IMM(dev_priv->perf.oa.total_n_mux_regs);
+
+   *cs++ = i915_mmio_reg_offset(GDT_CHICKEN_BITS);
+   *cs++ = 0xA0;
+
+   for (i = 0; i < dev_priv->perf.oa.n_mux_configs; i++) {
+   const struct i915_oa_reg *mux_regs =
+   dev_priv->perf.oa.mux_regs[i];
+   const int mux_regs_len = dev_priv->perf.oa.mux_regs_lens[i];
+
+   for (j = 0; j < mux_regs_len; j++) {
+   *cs++ = i915_mmio_reg_offset(mux_regs[j].addr);
+   *cs++ = mux_regs[j].value;
+   }
+   }
+
+   *cs++ = i915_mmio_reg_offset(GDT_CHICKEN_BITS);
+   *cs++ = 0x80;
+
+   *cs++ = MI_NOOP;
+   intel_ring_advance(req, cs);
+
+   return 0;
+}
+
  /**
   * i915_perf_read_locked - &i915_perf_stream_ops->read with error 
normalisation
   * @stream: An i915 perf stream
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index acd1da9b62a3..67aaaebb194b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1874,6 +1874,9 @@ gen8_emit_bb_start(struct drm_i915_gem_request *req,
!(dispatch_flags & I915_DISPATCH_SE

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

2017-05-30 Thread Saarinen, Jani

Hi, 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Chris Wilson
> Sent: Tuesday, May 30, 2017 7:21 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3]
> drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle
> 
> On Tue, May 30, 2017 at 02:09:53PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: series starting with [1/3] drm/i915: Short-circuit
> i915_gem_wait_for_idle() if already idle
> > URL   : https://patchwork.freedesktop.org/series/25039/
> > State : success
> >
> > == Summary ==
> >
> Pushed the first 2 as that will clear the error reported by CI. I'm leaving 
> the third
What was this error. Was there bug about it?

> until Mika can check as we have discussed something similar in the past. Plus
> lockdep_assert_held_if() is still pending.
> 
> Thanks for the review,
> -Chris
> 
> --
> Chris Wilson, Intel Open Source Technology Centre


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle

On Tue, May 30, 2017 at 07:18:20PM +, Saarinen, Jani wrote:
> Hi, 
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf 
> > Of
> > Chris Wilson
> > Sent: Tuesday, May 30, 2017 7:21 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3]
> > drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle
> > 
> > On Tue, May 30, 2017 at 02:09:53PM -, Patchwork wrote:
> > > == Series Details ==
> > >
> > > Series: series starting with [1/3] drm/i915: Short-circuit
> > i915_gem_wait_for_idle() if already idle
> > > URL   : https://patchwork.freedesktop.org/series/25039/
> > > State : success
> > >
> > > == Summary ==
> > >
> > Pushed the first 2 as that will clear the error reported by CI. I'm leaving 
> > the third
> What was this error. Was there bug about it?

The error was the warning reported in the changelog, no bug because Tomi
said look at this, and asked if I wanted him to file a bug. I said no need as
the patch was trivial and would be sent before he could file the bug.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] topic/e1000e-fix

2017-05-30 Thread Daniel Vetter

Hi Dave (both of them),

topic/e1000e-fix-2017-05-30:
Just an e1000e crash fix that somehow got stuck in a trivial bikeshed,
see

https://patchwork.ozlabs.org/patch/729312/

Sending this your way since not even the intel-internal escalation seems
to have worked out. If the e1000e maintainer wants to coalesce or not
return statements this simple way, that's imo on him to change the color
as needed. Also, it reliable spams dmesg, why does this take forever ...
we've carried this patch for a while no in our local fixup branch to keep
our CI happy. Pls make sure it reaches Linus' tree asap.

Thanks, Daniel


The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b:

  Linux 4.12-rc3 (2017-05-28 17:20:53 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/topic/e1000e-fix-2017-05-30

for you to fetch changes up to 4e5684f930587bd22565f404eb3c5e417a994ccc:

  e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails (2017-05-30 09:47:28 
+0200)


Just an e1000e crash fix that somehow got stuck in a trivial bikeshed,
see

https://patchwork.ozlabs.org/patch/729312/


Chris Wilson (1):
  e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

 drivers/net/ethernet/intel/e1000e/netdev.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_setmode: increase MAX_CRTCS to 6

2017-05-30 Thread Alex Deucher

On Tue, May 30, 2017 at 4:01 PM, Harry Wentland  wrote:
> AMD GPUs can have 6 CRTCs.
>
> This requires us to allocate the combinations on the heap.
>
> Signed-off-by: Harry Wentland 
> ---
>  tests/kms_setmode.c | 25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
> index 430568a1c24e..847ad650d27f 100644
> --- a/tests/kms_setmode.c
> +++ b/tests/kms_setmode.c
> @@ -35,11 +35,13 @@
>  #include "intel_bufmgr.h"
>
>  #define MAX_CONNECTORS  10
> -#define MAX_CRTCS   3
> +#define MAX_CRTCS   6
>
>  /* max combinations with repetitions */
> +/* MAX_CONNECTORS ^ MAX_CRTCS */
> +/* TODO should really be MAX_CONNECTORS ^ MAX_CONNECTORS ??? */
>  #define MAX_COMBINATION_COUNT   \
> -   (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS)
> +   (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS * 
> MAX_CONNECTORS * MAX_CONNECTORS)
>  #define MAX_COMBINATION_ELEMS   MAX_CRTCS
>
>  static int drm_fd;
> @@ -743,22 +745,25 @@ static void get_combinations(int n, int k, bool 
> allow_repetitions,
>  static void test_combinations(const struct test_config *tconf,
>   int connector_count)
>  {
> -   struct combination_set connector_combs;
> -   struct combination_set crtc_combs;
> +   struct combination_set *connector_combs;
> +   struct combination_set *crtc_combs;
> struct connector_config *cconfs;
> int i;
>
> if (connector_count > 2 && (tconf->flags & TEST_STEALING))
> return;
>
> +   connector_combs = malloc(sizeof(*connector_combs));
> +   crtc_combs = malloc(sizeof(*crtc_combs));

Shouldn't this get freed somewhere?


> +
> get_combinations(tconf->resources->count_connectors, connector_count,
> -false, &connector_combs);
> +false, connector_combs);
> get_combinations(tconf->resources->count_crtcs, connector_count,
> -true, &crtc_combs);
> +true, crtc_combs);
>
> igt_info("Testing: %s %d connector combinations\n", tconf->name,
>  connector_count);
> -   for (i = 0; i < connector_combs.count; i++) {
> +   for (i = 0; i < connector_combs->count; i++) {
> int *connector_idxs;
> int ret;
> int j;
> @@ -766,14 +771,14 @@ static void test_combinations(const struct test_config 
> *tconf,
> cconfs = malloc(sizeof(*cconfs) * connector_count);
> igt_assert(cconfs);
>
> -   connector_idxs = &connector_combs.items[i].elems[0];
> +   connector_idxs = &connector_combs->items[i].elems[0];
> ret = get_connectors(tconf->resources, connector_idxs,
>  connector_count, cconfs);
> if (ret < 0)
> goto free_cconfs;
>
> -   for (j = 0; j < crtc_combs.count; j++) {
> -   int *crtc_idxs = &crtc_combs.items[j].elems[0];
> +   for (j = 0; j < crtc_combs->count; j++) {
> +   int *crtc_idxs = &crtc_combs->items[j].elems[0];
> ret = assign_crtc_to_connectors(tconf, crtc_idxs,
> connector_count,
> cconfs);
> --
> 2.11.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support




On 05/30/2017 09:49 AM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:



On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil  wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete 
newbie when it

comes to mst.
I don't really have more clue, but yeah if you don't have an mst 
thing (a
simple dp port multiplexer is what I use for testing here, then 
plug in a
converter dongle or cable into that) then probably better to not 
wire up

the code for it.
I think my NUC already uses mst internally. But I was planning on 
buying a
dp multiplexer to make sure there is nothing special I need to do 
for mst.


The CEC Tunneling is all in the branch device, so if I understand 
things

correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output 
they

use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do it 
is not
exposed as a capability. I'm not sure if it is a MegaChip firmware 
issue
or something else. The BIOS is able to do some CEC, but whether 
they hook
into the MegaChip or have the CEC pin connected to a GPIO or 
something and

have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would be 
very

helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.


What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

slightly different command, but it still dumps DPCD 0x3000 for 48 bytes.

sudo dd if=/dev/drm_dp_aux0 bs=1 skip=12288 count=48 | hexdump -C
  07 00 00 00 00 00 00 00  00 00 00 00 00 00 00 80 
||
0010  f8 23 c4 8f 06 d8 59 7b  37 bb 1e 14 9c cb cd 88 
|.#Y{7...|
0020  4e 84 10 00 04 00 f7 f5  e2 fa a3 30 ad 42 ed 19 
|N..0.B..|





When you say "it does support CEC over Aux", does that mean you have 
actually
tested it somehow? The only working solution I have seen mentioned for 
the

NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.
I have a couple PS176 based devices that I purchased from Amazon that do 
not work even though they advertise support at DPCD 0x3000.


Club 3D USB-C->HDMI 2.0 UHD
UptabUSB-C->HDMI 2.0

-Clint




Regards,

Hans



-Clint




BR,
Jani.

It would be so nice to get MegaChip CEC Tunneling working on the 
NUC, because
then you have native CEC support without requiring any Pulse Eight 
adapter.


And add a CEC-capable USB-C to HDMI adapter and you have it on the 
USB-C

output as well.

Regards,

Hans






___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support




On 05/30/2017 09:54 AM, Hans Verkuil wrote:

On 05/30/2017 06:49 PM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:



On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil  wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete 
newbie when it

comes to mst.
I don't really have more clue, but yeah if you don't have an mst 
thing (a
simple dp port multiplexer is what I use for testing here, then 
plug in a
converter dongle or cable into that) then probably better to not 
wire up

the code for it.
I think my NUC already uses mst internally. But I was planning on 
buying a
dp multiplexer to make sure there is nothing special I need to do 
for mst.


The CEC Tunneling is all in the branch device, so if I understand 
things

correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output 
they

use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do 
it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware 
issue
or something else. The BIOS is able to do some CEC, but whether 
they hook
into the MegaChip or have the CEC pin connected to a GPIO or 
something and

have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would 
be very

helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.


What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have 
actually
tested it somehow? The only working solution I have seen mentioned 
for the

NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.


If it really is working on your NUC, then can you add the output of
/sys/kernel/debug/dri/0/i915_display_info?


[root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info
CRTC info
-
CRTC 32: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24
fb: 115, pos: 0x0, size: 3840x2160
encoder 47: type: DDI B, connectors:
connector 48: type: DP-1, status: connected, mode:
id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 
2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

cursor visible? no, position (0, 0), size 0x0, addr 0x
num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, 
mode=0, scalers[1]: use=no, mode=0
--Plane id 26: type=PRI, crtc_pos=   0x   0, crtc_size=1920x1080, 
src_pos=0.x0., src_size=1920.x1080., format=XR24 
little-endian (0x34325258), rotation=0 (0x0001)
--Plane id 28: type=OVL, crtc_pos=   0x   0, crtc_size=   0x 0, 
src_pos=0.x0., src_size=0.x0., format=N/A, rotation=0 
(0x0001)
--Plane id 30: type=CUR, crtc_pos=   0x   0, crtc_size=   0x 0, 
src_pos=0.x0., src_size=0.x0., format=N/A, rotation=0 
(0x0001)

underrun reporting: cpu=yes pch=yes
CRTC 39: pipe: B, active=yes, (size=3840x2160), dither=no, bpp=36
fb: 115, pos: 0x0, size: 3840x2160
encoder 54: type: DDI C, connectors:
connector 55: type: DP-2, status: connected, mode:
id 0:"3840x2160" freq 30 clock 296703 hdisp 3840 hss 4016 hse 
4104 htot 4400 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x48 flags 0x5

cursor visible? no, position (0, 0), size 0x0, addr 0x
num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, 
mode=0, scalers[1]: use=no, mode=0
--Plane id 33: type=PRI, crtc_pos=   0x   0, crtc_size=3840x2160, 
src_pos=0.x0., src_size=3840.x2160., format=XR24 
little-endian (0x34325258), rotation=0 (0x0001)
--Plane id 35: type=OVL, crtc_pos=   0x   0, crtc_size=   0x 0, 
src_pos=0.x0., src_size=0.x0., format=N/A, rotation=0 
(0x0001)
--Plane

Re: [Intel-gfx] [PATCH 19/37] drm/fsl: Drop drm_vblank_cleanup

2017-05-30 Thread Stefan Agner

On 2017-05-26 00:00, Daniel Vetter wrote:
> On Thu, May 25, 2017 at 10:18 AM, Stefan Agner  wrote:
>> On 2017-05-24 07:51, Daniel Vetter wrote:
>>> Again cleanup before irq disabling doesn't really stop the races,
>>> so just drop it. Proper fix would be to put drm_atomic_helper_shutdown
>>> before everything gets cleaned up.
>>
>> Hm, I already use the non-atomic drm_crtc_force_disable_all before, I
>> think that fixed the races I saw.
>>
>> But I guess what you are saying instead of using
>> drm_crtc_force_disable_all I should use drm_atomic_helper_shutdown...?
> 
> Yes. I thought I audited all existing users of the legacy
> force_disable (it won't work correctly for atomic drivers), but
> somehow I missed the one in fsl. See
> 
> commit 18dddadc78c91a91b546acc48506c24f5f840c4f
> Author: Daniel Vetter 
> Date:   Tue Mar 21 17:41:49 2017 +0100
> 
> drm/atomic: Introduce drm_atomic_helper_shutdown
> 

Ok, I see.

Since this leads to a change just a few lines above this patch, it has
potential for merge conflict. Can I take this change through my tree?

--
Stefan

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v2] tests/kms_setmode: increase MAX_CRTCS to 6

2017-05-30 Thread Harry Wentland

AMD GPUs can have 6 CRTCs.

This requires us to allocate the combinations on the heap.

v2:
  Of course We should free the new allocation. Thanks, Alex.

Signed-off-by: Harry Wentland 
---
 tests/kms_setmode.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index 430568a1c24e..62905ec27e80 100644
--- a/tests/kms_setmode.c
+++ b/tests/kms_setmode.c
@@ -35,11 +35,13 @@
 #include "intel_bufmgr.h"
 
 #define MAX_CONNECTORS  10
-#define MAX_CRTCS   3
+#define MAX_CRTCS   6
 
 /* max combinations with repetitions */
+/* MAX_CONNECTORS ^ MAX_CRTCS */
+/* TODO should really be MAX_CONNECTORS ^ MAX_CONNECTORS ??? */
 #define MAX_COMBINATION_COUNT   \
-   (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS)
+   (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS * 
MAX_CONNECTORS * MAX_CONNECTORS)
 #define MAX_COMBINATION_ELEMS   MAX_CRTCS
 
 static int drm_fd;
@@ -743,22 +745,25 @@ static void get_combinations(int n, int k, bool 
allow_repetitions,
 static void test_combinations(const struct test_config *tconf,
  int connector_count)
 {
-   struct combination_set connector_combs;
-   struct combination_set crtc_combs;
+   struct combination_set *connector_combs;
+   struct combination_set *crtc_combs;
struct connector_config *cconfs;
int i;
 
if (connector_count > 2 && (tconf->flags & TEST_STEALING))
return;
 
+   connector_combs = malloc(sizeof(*connector_combs));
+   crtc_combs = malloc(sizeof(*crtc_combs));
+
get_combinations(tconf->resources->count_connectors, connector_count,
-false, &connector_combs);
+false, connector_combs);
get_combinations(tconf->resources->count_crtcs, connector_count,
-true, &crtc_combs);
+true, crtc_combs);
 
igt_info("Testing: %s %d connector combinations\n", tconf->name,
 connector_count);
-   for (i = 0; i < connector_combs.count; i++) {
+   for (i = 0; i < connector_combs->count; i++) {
int *connector_idxs;
int ret;
int j;
@@ -766,14 +771,14 @@ static void test_combinations(const struct test_config 
*tconf,
cconfs = malloc(sizeof(*cconfs) * connector_count);
igt_assert(cconfs);
 
-   connector_idxs = &connector_combs.items[i].elems[0];
+   connector_idxs = &connector_combs->items[i].elems[0];
ret = get_connectors(tconf->resources, connector_idxs,
 connector_count, cconfs);
if (ret < 0)
goto free_cconfs;
 
-   for (j = 0; j < crtc_combs.count; j++) {
-   int *crtc_idxs = &crtc_combs.items[j].elems[0];
+   for (j = 0; j < crtc_combs->count; j++) {
+   int *crtc_idxs = &crtc_combs->items[j].elems[0];
ret = assign_crtc_to_connectors(tconf, crtc_idxs,
connector_count,
cconfs);
@@ -787,6 +792,9 @@ static void test_combinations(const struct test_config 
*tconf,
 free_cconfs:
free(cconfs);
}
+
+   free(connector_combs);
+   free(crtc_combs);
 }
 
 static void run_test(const struct test_config *tconf)
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

On 05/30/2017 10:32 PM, Clint Taylor wrote:

On 05/30/2017 09:54 AM, Hans Verkuil wrote:

On 05/30/2017 06:49 PM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:

On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete
newbie when it
comes to mst.

I don't really have more clue, but yeah if you don't have an mst
thing (a
simple dp port multiplexer is what I use for testing here, then
plug in a
converter dongle or cable into that) then probably better to not
wire up
the code for it.

I think my NUC already uses mst internally. But I was planning on
buying a
dp multiplexer to make sure there is nothing special I need to do
for mst.

The CEC Tunneling is all in the branch device, so if I understand
things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output
they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do
it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware
issue
or something else. The BIOS is able to do some CEC, but whether
they hook
into the MegaChip or have the CEC pin connected to a GPIO or
something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would
be very
helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.

My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.

What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have
actually
tested it somehow? The only working solution I have seen mentioned
for the
NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.

If it really is working on your NUC, then can you add the output of
/sys/kernel/debug/dri/0/i915_display_info?

[root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info

Connector info
--
connector 48: type DP-1, status: connected
name:
physical dimensions: 700x400mm
subpixel order: Unknown
CEA rev: 3
DPCD rev: 12
audio support: yes
DP branch device present: yes
Type: HDMI
ID: 175IB0
HW: 1.0
SW: 7.32
Max TMDS clock: 60 kHz
Max bpc: 12

Huh. Based on this document:

https://downloadmirror.intel.com/26061/eng/NUC6i7KYK%20HDMI%202.0%20Firmware%20update%20Instructions.pdf

this is the internal DP-to-HDMI adapter and it has the PS175. So it is a
Parade chipset, and I have seen that work before (at least the PS176).

connector 55: type DP-2, status: connected
name:
physical dimensions: 620x340mm
subpixel order: Unknown
CEA rev: 3
DPCD rev: 12
audio support: yes
DP branch device present: yes
Type: HDMI
ID: BCTRC0
HW: 2.0
SW: 0.26

And is this from a USB-C to HDMI adapter? Which one? I don't recognize the ID.

For the record, this is the internal HDMI output of my NUC7i5BNK:

connector 48: type DP-1, status: connected
name:
physical dimensions: 1050x590mm
subpixel order: Unknown
CEA rev: 3
DPCD rev: 12
audio support: yes
DP branch device present: yes
Type: HDMI
ID: MC2800
HW: 2.2
SW: 1.66
Max TMDS clock: 60 kHz
Max bpc: 16

Clearly a Megachip.

Regards,

Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/6] drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH

From: Dhinakaran Pandiyan 

The first two bytes of PCI ID for CNP_LP PCH are the same as that of
SPT_LP. We should really be looking at the first 9 bits instead of the
first 8 to identify platforms, although this seems to have not caused any
problems on earlier platforms. Introduce a 9 bit extended mask for SPT and
CNP while not touching the code for any of the other platforms.

v2: (Rodrigo) Make platform agnostic and fix commit message.

Signed-off-by: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_drv.c | 8 +++-
 drivers/gpu/drm/i915/i915_drv.h | 4 
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9e4c13e..90b646c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -170,6 +170,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
if (pch->vendor == PCI_VENDOR_ID_INTEL) {
unsigned short id = pch->device & 
INTEL_PCH_DEVICE_ID_MASK;
+   unsigned short id_ext = pch->device &
+   INTEL_PCH_DEVICE_ID_MASK_EXT;
+
dev_priv->pch_id = id;
 
if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
@@ -206,7 +209,7 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
-   } else if (id == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
+   } else if (id_ext == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_SPT;
DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
@@ -219,6 +222,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
} else if (id == INTEL_PCH_CNP_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_CNP;
DRM_DEBUG_KMS("Found CannonPoint PCH\n");
+   } else if (id_ext == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE) {
+   dev_priv->pch_type = PCH_CNP;
+   DRM_DEBUG_KMS("Found CannonPoint LP PCH\n");
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
   (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0b82604..c31c0cf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2959,6 +2959,7 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 #define HAS_POOLED_EU(dev_priv)((dev_priv)->info.has_pooled_eu)
 
 #define INTEL_PCH_DEVICE_ID_MASK   0xff00
+#define INTEL_PCH_DEVICE_ID_MASK_EXT   0xff80
 #define INTEL_PCH_IBX_DEVICE_ID_TYPE   0x3b00
 #define INTEL_PCH_CPT_DEVICE_ID_TYPE   0x1c00
 #define INTEL_PCH_PPT_DEVICE_ID_TYPE   0x1e00
@@ -2968,12 +2969,15 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
 #define INTEL_PCH_KBP_DEVICE_ID_TYPE   0xA200
 #define INTEL_PCH_CNP_DEVICE_ID_TYPE   0xA300
+#define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
 #define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
 #define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
+#define HAS_PCH_CNP_LP(dev_priv) \
+   ((dev_priv)->pch_id == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE)
 #define HAS_PCH_KBP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_KBP)
 #define HAS_PCH_SPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_SPT)
 #define HAS_PCH_LPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_LPT)
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/6] drm/i915/cnp: Backlight support for CNP.

Split out BXT and CNP's setup_backlight(),enable_backlight(),
disable_backlight() and hz_to_pwm() into
two separate functions instead of reusing BXT function.

Reuse set_backlight() and get_backlight() since they have
no reference to the utility pin.

v2: Reuse BXT functions with controller 0 instead of
redefining it. (Jani).
Use dev_priv->rawclk_freq instead of getting the value
from SFUSE_STRAP.
v3: Avoid setup backligh controller along with hooks and
fully reuse hooks setup as suggested by Jani.
v4: Clean up commit message.
v5: Implement per PCH instead per platform.

v6: Introduce a new function for CNP.(Jani and Ville)

v7: Squash the all CNP Backlight support patches into a
single patch. (Jani)

v8: Correct indentation, remove unneeded blank lines and
correct mail address (Jani).

Reviewed-by: Jani Nikula 
Suggested-by: Jani Nikula 
Suggested-by: Ville Syrjala 
Cc: Ville Syrjala 
Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_panel.c | 94 ++
 1 file changed, 94 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index c8103f8..426e5e8 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -796,6 +796,19 @@ static void bxt_disable_backlight(struct intel_connector 
*connector)
}
 }
 
+static void cnp_disable_backlight(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = &connector->panel;
+   u32 tmp;
+
+   intel_panel_actually_set_backlight(connector, 0);
+
+   tmp = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
+  tmp & ~BXT_BLC_PWM_ENABLE);
+}
+
 static void pwm_disable_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = &connector->panel;
@@ -1086,6 +1099,36 @@ static void bxt_enable_backlight(struct intel_connector 
*connector)
pwm_ctl | BXT_BLC_PWM_ENABLE);
 }
 
+static void cnp_enable_backlight(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = &connector->panel;
+   enum pipe pipe = intel_get_pipe_from_connector(connector);
+   u32 pwm_ctl;
+
+   pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+   if (pwm_ctl & BXT_BLC_PWM_ENABLE) {
+   DRM_DEBUG_KMS("backlight already enabled\n");
+   pwm_ctl &= ~BXT_BLC_PWM_ENABLE;
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
+  pwm_ctl);
+   }
+
+   I915_WRITE(BXT_BLC_PWM_FREQ(panel->backlight.controller),
+  panel->backlight.max);
+
+   intel_panel_actually_set_backlight(connector, panel->backlight.level);
+
+   pwm_ctl = 0;
+   if (panel->backlight.active_low_pwm)
+   pwm_ctl |= BXT_BLC_PWM_POLARITY;
+
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller), pwm_ctl);
+   POSTING_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
+  pwm_ctl | BXT_BLC_PWM_ENABLE);
+}
+
 static void pwm_enable_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = &connector->panel;
@@ -1250,6 +1293,18 @@ void intel_backlight_device_unregister(struct 
intel_connector *connector)
 #endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
 
 /*
+ * CNP: PWM clock frequency is 19.2 MHz or 24 MHz.
+ *  Value is found in SFUSE_STRAP.
+ *  PWM increment = 1
+ */
+static u32 cnp_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+
+   return DIV_ROUND_CLOSEST(KHz(dev_priv->rawclk_freq), pwm_freq_hz);
+}
+
+/*
  * BXT: PWM clock frequency = 19.2 MHz.
  */
 static u32 bxt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
@@ -1644,6 +1699,37 @@ static int vlv_setup_backlight(struct intel_connector 
*connector, enum pipe pipe
return 0;
 }
 
+static int
+cnp_setup_backlight(struct intel_connector *connector, enum pipe unused)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = &connector->panel;
+   u32 pwm_ctl, val;
+
+   panel->backlight.controller = dev_priv->vbt.backlight.controller;
+
+   pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+
+   panel->backlight.active_low_pwm = pwm_ctl & BXT_BLC_PWM_POLARITY;
+   panel->backlight.max =
+   I915_READ(BXT_BLC_PWM_FREQ(panel->backlight.controller));
+
+   if (!panel->backlight.max)
+   panel->backlight.max = get_backlight_max_vbt(connector);
+
+   if (!panel->backlight.max)
+

[Intel-gfx] [PATCH 6/6] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

As for BXT, PP_DIVISOR was removed from CNP PCH and power
cycle delay has been moved to PP_CONTROL.

Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 58dca87..1a27c72 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -798,7 +798,7 @@ static void intel_pps_get_registers(struct drm_i915_private 
*dev_priv,
regs->pp_stat = PP_STATUS(pps_idx);
regs->pp_on = PP_ON_DELAYS(pps_idx);
regs->pp_off = PP_OFF_DELAYS(pps_idx);
-   if (!IS_GEN9_LP(dev_priv))
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
regs->pp_div = PP_DIVISOR(pps_idx);
 }
 
@@ -5099,7 +5099,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
 
pp_on = I915_READ(regs.pp_on);
pp_off = I915_READ(regs.pp_off);
-   if (!IS_GEN9_LP(dev_priv)) {
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
I915_WRITE(regs.pp_ctrl, pp_ctl);
pp_div = I915_READ(regs.pp_div);
}
@@ -5117,7 +5117,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
   PANEL_POWER_DOWN_DELAY_SHIFT;
 
-   if (IS_GEN9_LP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
BXT_POWER_CYCLE_DELAY_SHIFT;
if (tmp > 0)
@@ -5274,7 +5274,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
 (seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
/* Compute the divisor for the pp clock, simply match the Bspec
 * formula. */
-   if (IS_GEN9_LP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
pp_div = I915_READ(regs.pp_ctrl);
pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)
@@ -5308,7 +5308,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, 
PP_OFF %#x, PP_DIV %#x\n",
  I915_READ(regs.pp_on),
  I915_READ(regs.pp_off),
- IS_GEN9_LP(dev_priv) ?
+ (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
  (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
  I915_READ(regs.pp_div));
 }
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

Most of south engine display that is in PCH is still the
same as SPT and KBP, except for this key differences:

- Backlight: Backlight programming changed in CNP PCH.
- Panel Power: Sligh programming changed in CNP PCH.
- GMBUS and GPIO: The pin mapping has changed in CNP PCH.

All of these changes follow more the BXT style.

v2: Update definition to use dev_priv isntead of dev (Tvrtko).

Cc: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_drv.c | 3 +++
 drivers/gpu/drm/i915/i915_drv.h | 3 +++
 drivers/gpu/drm/i915/i915_irq.c | 6 --
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2fdfaf1..9e4c13e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -216,6 +216,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS("Found KabyPoint PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
+   } else if (id == INTEL_PCH_CNP_DEVICE_ID_TYPE) {
+   dev_priv->pch_type = PCH_CNP;
+   DRM_DEBUG_KMS("Found CannonPoint PCH\n");
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
   (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bde554e..0b82604 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1151,6 +1151,7 @@ enum intel_pch {
PCH_LPT,/* Lynxpoint PCH */
PCH_SPT,/* Sunrisepoint PCH */
PCH_KBP,/* Kabypoint PCH */
+   PCH_CNP,/* Cannonpoint PCH */
PCH_NOP,
 };
 
@@ -2966,11 +2967,13 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 #define INTEL_PCH_SPT_DEVICE_ID_TYPE   0xA100
 #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
 #define INTEL_PCH_KBP_DEVICE_ID_TYPE   0xA200
+#define INTEL_PCH_CNP_DEVICE_ID_TYPE   0xA300
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
 #define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
+#define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
 #define HAS_PCH_KBP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_KBP)
 #define HAS_PCH_SPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_SPT)
 #define HAS_PCH_LPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_LPT)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7b7f55a..4cd9ee1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2548,7 +2548,8 @@ static void bxt_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
I915_WRITE(SDEIIR, iir);
ret = IRQ_HANDLED;
 
-   if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv))
+   if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv) ||
+   HAS_PCH_CNP(dev_priv))
spt_irq_handler(dev_priv, iir);
else
cpt_irq_handler(dev_priv, iir);
@@ -4289,7 +4290,8 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev->driver->disable_vblank = gen8_disable_vblank;
if (IS_GEN9_LP(dev_priv))
dev_priv->display.hpd_irq_setup = bxt_hpd_irq_setup;
-   else if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv))
+   else if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv) ||
+HAS_PCH_CNP(dev_priv))
dev_priv->display.hpd_irq_setup = spt_hpd_irq_setup;
else
dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/6] drm/i915/cnp: Get/set proper Raw clock frequency on CNP.

RAWCLK_FREQ register has changed for platforms with CNP+.

[29:26] This field provides the denominator for the fractional
part of the microsecond counter divider.  The numerator
is fixed at 1. Program this field to the denominator of
the fractional portion of reference frequency minus one.
If the fraction is 0, program to 0.
0100b = Fraction .2 MHz = Fraction 1/5.
b = Fraction .0 MHz.

[25:16] This field provides the integer part of the microsecond
counter divider. Program this field to the integer portion
of the reference frequenct minus one.

Also this register tells us that proper raw clock should be read
from SFUSE_STRAP and programmed to this register. Up to this point
on other platforms we are reading instead of programming it so
probably relying on whatever BIOS had configured here.

Now on let's follow the spec and also program this register
fetching the right value from SFUSE_STRAP as Spec tells us to do.

v2: Read from SFUSE_STRAP and Program RAWCLK_FREQ instead of
reading the value relying someone else will program that
for us.
v3: Add missing else. (Jani)
v4: Addressing all Ville's catches:
Use macro for shift bits instead of defining shift.
Remove shift from the cleaning bits with mask that already
has it.
Add missing I915_WRITE to actually write the reg.
Stop using useless DIV_ROUND_* on divider that is exact
dividion and use DIV_ROUND_CLOSEST for the fraction part.
v5: Remove useless Read-Modify-Write on raclk_freq reg. (Ville).
v6: Change is per PCH instead of per platform.

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h|  5 +
 drivers/gpu/drm/i915/intel_cdclk.c | 29 -
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 231ee86..cb83fb7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6838,6 +6838,10 @@ enum {
 #define  FDL_TP2_TIMER_SHIFT10
 #define  FDL_TP2_TIMER_MASK (3<<10)
 #define  RAWCLK_FREQ_MASK   0x3ff
+#define  CNP_RAWCLK_DIV_MASK   (0x3ff << 16)
+#define  CNP_RAWCLK_DIV(div)   ((div) << 16)
+#define  CNP_RAWCLK_FRAC_MASK  (0xf << 26)
+#define  CNP_RAWCLK_FRAC(frac) ((frac) << 26)
 
 #define PCH_DPLL_TMR_CFG_MMIO(0xc6208)
 
@@ -8141,6 +8145,7 @@ enum {
 /* SFUSE_STRAP */
 #define SFUSE_STRAP_MMIO(0xc2014)
 #define  SFUSE_STRAP_FUSE_LOCK (1<<13)
+#define  SFUSE_STRAP_RAW_FREQUENCY (1<<8)
 #define  SFUSE_STRAP_DISPLAY_DISABLED  (1<<7)
 #define  SFUSE_STRAP_CRT_DISABLED  (1<<6)
 #define  SFUSE_STRAP_DDIB_DETECTED (1<<2)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 2979297..634c89f 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1780,6 +1780,30 @@ void intel_update_cdclk(struct drm_i915_private 
*dev_priv)
   DIV_ROUND_UP(dev_priv->cdclk.hw.cdclk, 1000));
 }
 
+static int cnp_rawclk(struct drm_i915_private *dev_priv)
+{
+   u32 rawclk;
+   int divider, fraction;
+
+   if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
+   /* 24 MHz */
+   divider = 24000;
+   fraction = 0;
+   } else {
+   /* 19.2 MHz */
+   divider = 19000;
+   fraction = 200;
+   }
+
+   rawclk = CNP_RAWCLK_DIV((divider / 1000) - 1);
+   if (fraction)
+   rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
+   fraction) - 1);
+
+   I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
+   return divider + fraction;
+}
+
 static int pch_rawclk(struct drm_i915_private *dev_priv)
 {
return (I915_READ(PCH_RAWCLK_FREQ) & RAWCLK_FREQ_MASK) * 1000;
@@ -1827,7 +1851,10 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
  */
 void intel_update_rawclk(struct drm_i915_private *dev_priv)
 {
-   if (HAS_PCH_SPLIT(dev_priv))
+
+   if (HAS_PCH_CNP(dev_priv))
+   dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
+   else if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = pch_rawclk(dev_priv);
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
dev_priv->rawclk_freq = vlv_hrawclk(dev_priv);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/6] drm/i915/cnp: add CNP gmbus support

On CNP PCH based platforms the gmbus is on the south display that
is on PCH. The existing implementation for previous platforms
already covers the need for CNP expect for the pin pair configuration
that follows similar definitions that we had on BXT.

v2: Don't drop "_BXT" as the indicator of the first platform
supporting this pin numbers. Suggested by Daniel.
v3: Add missing else and fix register table since CNP GPIO_CTL
starts on 0xC5014.
v4: Fix pin number and map according to the current available VBT.
Re-add pin 4 for port D. Lost during some rebase.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_reg.h   |  3 ++-
 drivers/gpu/drm/i915/intel_hdmi.c |  8 +---
 drivers/gpu/drm/i915/intel_i2c.c  | 20 ++--
 3 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cb83fb7..1329420 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2626,9 +2626,10 @@ enum skl_disp_power_wells {
 #define   GMBUS_PIN_DPB5 /* SDVO, HDMIB */
 #define   GMBUS_PIN_DPD6 /* HDMID */
 #define   GMBUS_PIN_RESERVED   7 /* 7 reserved */
-#define   GMBUS_PIN_1_BXT  1
+#define   GMBUS_PIN_1_BXT  1 /* BXT+ (atom) and CNP+ (big core) */
 #define   GMBUS_PIN_2_BXT  2
 #define   GMBUS_PIN_3_BXT  3
+#define   GMBUS_PIN_4_CNP  4
 #define   GMBUS_NUM_PINS   7 /* including 0 */
 #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /* 
command/status */
 #define   GMBUS_SW_CLR_INT (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 41267ff..ec0779a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1802,19 +1802,21 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private 
*dev_priv,
 
switch (port) {
case PORT_B:
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
ddc_pin = GMBUS_PIN_1_BXT;
else
ddc_pin = GMBUS_PIN_DPB;
break;
case PORT_C:
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
ddc_pin = GMBUS_PIN_2_BXT;
else
ddc_pin = GMBUS_PIN_DPC;
break;
case PORT_D:
-   if (IS_CHERRYVIEW(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   ddc_pin = GMBUS_PIN_4_CNP;
+   else if (IS_CHERRYVIEW(dev_priv))
ddc_pin = GMBUS_PIN_DPD_CHV;
else
ddc_pin = GMBUS_PIN_DPD;
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index b6401e8..3eb4a91 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -68,11 +68,25 @@ struct gmbus_pin {
[GMBUS_PIN_3_BXT] = { "misc", GPIOD },
 };
 
+/*
+ * FIXME: Spec maps 3-misc-0xc541c and 4-portd-0xc5420.
+ * However, current available pre-prod VBT maps:
+ * portD to pin 3 using 0xc5420.
+ */
+static const struct gmbus_pin gmbus_pins_cnp[] = {
+   [GMBUS_PIN_1_BXT] = { "dpb", GPIOB },
+   [GMBUS_PIN_2_BXT] = { "dpc", GPIOC },
+   [GMBUS_PIN_3_BXT] = { "misc", GPIOE },
+   [GMBUS_PIN_4_CNP] = { "dpd", GPIOD },
+};
+
 /* pin is expected to be valid */
 static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
 unsigned int pin)
 {
-   if (IS_GEN9_LP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   return &gmbus_pins_cnp[pin];
+   else if (IS_GEN9_LP(dev_priv))
return &gmbus_pins_bxt[pin];
else if (IS_GEN9_BC(dev_priv))
return &gmbus_pins_skl[pin];
@@ -87,7 +101,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private 
*dev_priv,
 {
unsigned int size;
 
-   if (IS_GEN9_LP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   size = ARRAY_SIZE(gmbus_pins_cnp);
+   else if (IS_GEN9_LP(dev_priv))
size = ARRAY_SIZE(gmbus_pins_bxt);
else if (IS_GEN9_BC(dev_priv))
size = ARRAY_SIZE(gmbus_pins_skl);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/6] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

Jani, Daniel, could I merge the 5 patches already after CI respond?

I rebased and retest here on CNL But I'd like to start merging so
we unblock CFL as well, maybe on top of this CNP before CNL...

Jani, also I believe you would be the best reviewer for this 6th patch
here, could you please consider taking a look?

Thanks,
Rodrigo.

On Tue, May 30, 2017 at 2:53 PM, Rodrigo Vivi  wrote:
> As for BXT, PP_DIVISOR was removed from CNP PCH and power
> cycle delay has been moved to PP_CONTROL.
>
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 58dca87..1a27c72 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -798,7 +798,7 @@ static void intel_pps_get_registers(struct 
> drm_i915_private *dev_priv,
> regs->pp_stat = PP_STATUS(pps_idx);
> regs->pp_on = PP_ON_DELAYS(pps_idx);
> regs->pp_off = PP_OFF_DELAYS(pps_idx);
> -   if (!IS_GEN9_LP(dev_priv))
> +   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
> regs->pp_div = PP_DIVISOR(pps_idx);
>  }
>
> @@ -5099,7 +5099,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
>
> pp_on = I915_READ(regs.pp_on);
> pp_off = I915_READ(regs.pp_off);
> -   if (!IS_GEN9_LP(dev_priv)) {
> +   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
> I915_WRITE(regs.pp_ctrl, pp_ctl);
> pp_div = I915_READ(regs.pp_div);
> }
> @@ -5117,7 +5117,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
> seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
>PANEL_POWER_DOWN_DELAY_SHIFT;
>
> -   if (IS_GEN9_LP(dev_priv)) {
> +   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
> u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
> BXT_POWER_CYCLE_DELAY_SHIFT;
> if (tmp > 0)
> @@ -5274,7 +5274,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
>  (seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
> /* Compute the divisor for the pp clock, simply match the Bspec
>  * formula. */
> -   if (IS_GEN9_LP(dev_priv)) {
> +   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
> pp_div = I915_READ(regs.pp_ctrl);
> pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
> pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)
> @@ -5308,7 +5308,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
> intel_dp *intel_dp)
> DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, 
> PP_OFF %#x, PP_DIV %#x\n",
>   I915_READ(regs.pp_on),
>   I915_READ(regs.pp_off),
> - IS_GEN9_LP(dev_priv) ?
> + (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
>   (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
>   I915_READ(regs.pp_div));
>  }
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

== Series Details ==

Series: series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH.
URL   : https://patchwork.freedesktop.org/series/25066/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/intel_panel.o
drivers/gpu/drm/i915/intel_panel.c: In function ‘cnp_enable_backlight’:
drivers/gpu/drm/i915/intel_panel.c:1106:12: error: unused variable ‘pipe’ 
[-Werror=unused-variable]
  enum pipe pipe = intel_get_pipe_from_connector(connector);
^
cc1: all warnings being treated as errors
scripts/Makefile.build:302: recipe for target 
'drivers/gpu/drm/i915/intel_panel.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_panel.o] Error 1
scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:561: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1016: recipe for target 'drivers' failed
make: *** [drivers] Error 2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/6] drm/i915/cnp: Backlight support for CNP.

Split out BXT and CNP's setup_backlight(),enable_backlight(),
disable_backlight() and hz_to_pwm() into
two separate functions instead of reusing BXT function.

Reuse set_backlight() and get_backlight() since they have
no reference to the utility pin.

v2: Reuse BXT functions with controller 0 instead of
redefining it. (Jani).
Use dev_priv->rawclk_freq instead of getting the value
from SFUSE_STRAP.
v3: Avoid setup backligh controller along with hooks and
fully reuse hooks setup as suggested by Jani.
v4: Clean up commit message.
v5: Implement per PCH instead per platform.

v6: Introduce a new function for CNP.(Jani and Ville)

v7: Squash the all CNP Backlight support patches into a
single patch. (Jani)

v8: Correct indentation, remove unneeded blank lines and
correct mail address (Jani).

v9: Remove unused enum pipe. (by CI)

Reviewed-by: Jani Nikula 
Suggested-by: Jani Nikula 
Suggested-by: Ville Syrjala 
Cc: Ville Syrjala 
Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_panel.c | 93 ++
 1 file changed, 93 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index c8103f8..7e34a1b 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -796,6 +796,19 @@ static void bxt_disable_backlight(struct intel_connector 
*connector)
}
 }
 
+static void cnp_disable_backlight(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = &connector->panel;
+   u32 tmp;
+
+   intel_panel_actually_set_backlight(connector, 0);
+
+   tmp = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
+  tmp & ~BXT_BLC_PWM_ENABLE);
+}
+
 static void pwm_disable_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = &connector->panel;
@@ -1086,6 +1099,35 @@ static void bxt_enable_backlight(struct intel_connector 
*connector)
pwm_ctl | BXT_BLC_PWM_ENABLE);
 }
 
+static void cnp_enable_backlight(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = &connector->panel;
+   u32 pwm_ctl;
+
+   pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+   if (pwm_ctl & BXT_BLC_PWM_ENABLE) {
+   DRM_DEBUG_KMS("backlight already enabled\n");
+   pwm_ctl &= ~BXT_BLC_PWM_ENABLE;
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
+  pwm_ctl);
+   }
+
+   I915_WRITE(BXT_BLC_PWM_FREQ(panel->backlight.controller),
+  panel->backlight.max);
+
+   intel_panel_actually_set_backlight(connector, panel->backlight.level);
+
+   pwm_ctl = 0;
+   if (panel->backlight.active_low_pwm)
+   pwm_ctl |= BXT_BLC_PWM_POLARITY;
+
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller), pwm_ctl);
+   POSTING_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
+  pwm_ctl | BXT_BLC_PWM_ENABLE);
+}
+
 static void pwm_enable_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = &connector->panel;
@@ -1250,6 +1292,18 @@ void intel_backlight_device_unregister(struct 
intel_connector *connector)
 #endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
 
 /*
+ * CNP: PWM clock frequency is 19.2 MHz or 24 MHz.
+ *  Value is found in SFUSE_STRAP.
+ *  PWM increment = 1
+ */
+static u32 cnp_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+
+   return DIV_ROUND_CLOSEST(KHz(dev_priv->rawclk_freq), pwm_freq_hz);
+}
+
+/*
  * BXT: PWM clock frequency = 19.2 MHz.
  */
 static u32 bxt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
@@ -1644,6 +1698,37 @@ static int vlv_setup_backlight(struct intel_connector 
*connector, enum pipe pipe
return 0;
 }
 
+static int
+cnp_setup_backlight(struct intel_connector *connector, enum pipe unused)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = &connector->panel;
+   u32 pwm_ctl, val;
+
+   panel->backlight.controller = dev_priv->vbt.backlight.controller;
+
+   pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+
+   panel->backlight.active_low_pwm = pwm_ctl & BXT_BLC_PWM_POLARITY;
+   panel->backlight.max =
+   I915_READ(BXT_BLC_PWM_FREQ(panel->backlight.controller));
+
+   if (!panel->backlight.max)
+   panel->backlight.max = get_backlight_max_vbt(connector);
+
+   if (!panel->backlight.max)
+   return -ENODEV;
+

[Intel-gfx] [PATCH 2/6] drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH

From: Dhinakaran Pandiyan 

The first two bytes of PCI ID for CNP_LP PCH are the same as that of
SPT_LP. We should really be looking at the first 9 bits instead of the
first 8 to identify platforms, although this seems to have not caused any
problems on earlier platforms. Introduce a 9 bit extended mask for SPT and
CNP while not touching the code for any of the other platforms.

v2: (Rodrigo) Make platform agnostic and fix commit message.

Signed-off-by: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_drv.c | 8 +++-
 drivers/gpu/drm/i915/i915_drv.h | 4 
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9e4c13e..90b646c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -170,6 +170,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
if (pch->vendor == PCI_VENDOR_ID_INTEL) {
unsigned short id = pch->device & 
INTEL_PCH_DEVICE_ID_MASK;
+   unsigned short id_ext = pch->device &
+   INTEL_PCH_DEVICE_ID_MASK_EXT;
+
dev_priv->pch_id = id;
 
if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
@@ -206,7 +209,7 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
-   } else if (id == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
+   } else if (id_ext == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_SPT;
DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
@@ -219,6 +222,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
} else if (id == INTEL_PCH_CNP_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_CNP;
DRM_DEBUG_KMS("Found CannonPoint PCH\n");
+   } else if (id_ext == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE) {
+   dev_priv->pch_type = PCH_CNP;
+   DRM_DEBUG_KMS("Found CannonPoint LP PCH\n");
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
   (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0b82604..c31c0cf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2959,6 +2959,7 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 #define HAS_POOLED_EU(dev_priv)((dev_priv)->info.has_pooled_eu)
 
 #define INTEL_PCH_DEVICE_ID_MASK   0xff00
+#define INTEL_PCH_DEVICE_ID_MASK_EXT   0xff80
 #define INTEL_PCH_IBX_DEVICE_ID_TYPE   0x3b00
 #define INTEL_PCH_CPT_DEVICE_ID_TYPE   0x1c00
 #define INTEL_PCH_PPT_DEVICE_ID_TYPE   0x1e00
@@ -2968,12 +2969,15 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
 #define INTEL_PCH_KBP_DEVICE_ID_TYPE   0xA200
 #define INTEL_PCH_CNP_DEVICE_ID_TYPE   0xA300
+#define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
 #define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
 #define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
+#define HAS_PCH_CNP_LP(dev_priv) \
+   ((dev_priv)->pch_id == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE)
 #define HAS_PCH_KBP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_KBP)
 #define HAS_PCH_SPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_SPT)
 #define HAS_PCH_LPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_LPT)
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/6] drm/i915/cnp: Get/set proper Raw clock frequency on CNP.

RAWCLK_FREQ register has changed for platforms with CNP+.

[29:26] This field provides the denominator for the fractional
part of the microsecond counter divider.  The numerator
is fixed at 1. Program this field to the denominator of
the fractional portion of reference frequency minus one.
If the fraction is 0, program to 0.
0100b = Fraction .2 MHz = Fraction 1/5.
b = Fraction .0 MHz.

[25:16] This field provides the integer part of the microsecond
counter divider. Program this field to the integer portion
of the reference frequenct minus one.

Also this register tells us that proper raw clock should be read
from SFUSE_STRAP and programmed to this register. Up to this point
on other platforms we are reading instead of programming it so
probably relying on whatever BIOS had configured here.

Now on let's follow the spec and also program this register
fetching the right value from SFUSE_STRAP as Spec tells us to do.

v2: Read from SFUSE_STRAP and Program RAWCLK_FREQ instead of
reading the value relying someone else will program that
for us.
v3: Add missing else. (Jani)
v4: Addressing all Ville's catches:
Use macro for shift bits instead of defining shift.
Remove shift from the cleaning bits with mask that already
has it.
Add missing I915_WRITE to actually write the reg.
Stop using useless DIV_ROUND_* on divider that is exact
dividion and use DIV_ROUND_CLOSEST for the fraction part.
v5: Remove useless Read-Modify-Write on raclk_freq reg. (Ville).
v6: Change is per PCH instead of per platform.

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h|  5 +
 drivers/gpu/drm/i915/intel_cdclk.c | 29 -
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 231ee86..cb83fb7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6838,6 +6838,10 @@ enum {
 #define  FDL_TP2_TIMER_SHIFT10
 #define  FDL_TP2_TIMER_MASK (3<<10)
 #define  RAWCLK_FREQ_MASK   0x3ff
+#define  CNP_RAWCLK_DIV_MASK   (0x3ff << 16)
+#define  CNP_RAWCLK_DIV(div)   ((div) << 16)
+#define  CNP_RAWCLK_FRAC_MASK  (0xf << 26)
+#define  CNP_RAWCLK_FRAC(frac) ((frac) << 26)
 
 #define PCH_DPLL_TMR_CFG_MMIO(0xc6208)
 
@@ -8141,6 +8145,7 @@ enum {
 /* SFUSE_STRAP */
 #define SFUSE_STRAP_MMIO(0xc2014)
 #define  SFUSE_STRAP_FUSE_LOCK (1<<13)
+#define  SFUSE_STRAP_RAW_FREQUENCY (1<<8)
 #define  SFUSE_STRAP_DISPLAY_DISABLED  (1<<7)
 #define  SFUSE_STRAP_CRT_DISABLED  (1<<6)
 #define  SFUSE_STRAP_DDIB_DETECTED (1<<2)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 2979297..634c89f 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1780,6 +1780,30 @@ void intel_update_cdclk(struct drm_i915_private 
*dev_priv)
   DIV_ROUND_UP(dev_priv->cdclk.hw.cdclk, 1000));
 }
 
+static int cnp_rawclk(struct drm_i915_private *dev_priv)
+{
+   u32 rawclk;
+   int divider, fraction;
+
+   if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
+   /* 24 MHz */
+   divider = 24000;
+   fraction = 0;
+   } else {
+   /* 19.2 MHz */
+   divider = 19000;
+   fraction = 200;
+   }
+
+   rawclk = CNP_RAWCLK_DIV((divider / 1000) - 1);
+   if (fraction)
+   rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
+   fraction) - 1);
+
+   I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
+   return divider + fraction;
+}
+
 static int pch_rawclk(struct drm_i915_private *dev_priv)
 {
return (I915_READ(PCH_RAWCLK_FREQ) & RAWCLK_FREQ_MASK) * 1000;
@@ -1827,7 +1851,10 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
  */
 void intel_update_rawclk(struct drm_i915_private *dev_priv)
 {
-   if (HAS_PCH_SPLIT(dev_priv))
+
+   if (HAS_PCH_CNP(dev_priv))
+   dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
+   else if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = pch_rawclk(dev_priv);
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
dev_priv->rawclk_freq = vlv_hrawclk(dev_priv);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/6] drm/i915/cnp: add CNP gmbus support

On CNP PCH based platforms the gmbus is on the south display that
is on PCH. The existing implementation for previous platforms
already covers the need for CNP expect for the pin pair configuration
that follows similar definitions that we had on BXT.

v2: Don't drop "_BXT" as the indicator of the first platform
supporting this pin numbers. Suggested by Daniel.
v3: Add missing else and fix register table since CNP GPIO_CTL
starts on 0xC5014.
v4: Fix pin number and map according to the current available VBT.
Re-add pin 4 for port D. Lost during some rebase.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_reg.h   |  3 ++-
 drivers/gpu/drm/i915/intel_hdmi.c |  8 +---
 drivers/gpu/drm/i915/intel_i2c.c  | 20 ++--
 3 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cb83fb7..1329420 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2626,9 +2626,10 @@ enum skl_disp_power_wells {
 #define   GMBUS_PIN_DPB5 /* SDVO, HDMIB */
 #define   GMBUS_PIN_DPD6 /* HDMID */
 #define   GMBUS_PIN_RESERVED   7 /* 7 reserved */
-#define   GMBUS_PIN_1_BXT  1
+#define   GMBUS_PIN_1_BXT  1 /* BXT+ (atom) and CNP+ (big core) */
 #define   GMBUS_PIN_2_BXT  2
 #define   GMBUS_PIN_3_BXT  3
+#define   GMBUS_PIN_4_CNP  4
 #define   GMBUS_NUM_PINS   7 /* including 0 */
 #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /* 
command/status */
 #define   GMBUS_SW_CLR_INT (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 41267ff..ec0779a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1802,19 +1802,21 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private 
*dev_priv,
 
switch (port) {
case PORT_B:
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
ddc_pin = GMBUS_PIN_1_BXT;
else
ddc_pin = GMBUS_PIN_DPB;
break;
case PORT_C:
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
ddc_pin = GMBUS_PIN_2_BXT;
else
ddc_pin = GMBUS_PIN_DPC;
break;
case PORT_D:
-   if (IS_CHERRYVIEW(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   ddc_pin = GMBUS_PIN_4_CNP;
+   else if (IS_CHERRYVIEW(dev_priv))
ddc_pin = GMBUS_PIN_DPD_CHV;
else
ddc_pin = GMBUS_PIN_DPD;
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index b6401e8..3eb4a91 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -68,11 +68,25 @@ struct gmbus_pin {
[GMBUS_PIN_3_BXT] = { "misc", GPIOD },
 };
 
+/*
+ * FIXME: Spec maps 3-misc-0xc541c and 4-portd-0xc5420.
+ * However, current available pre-prod VBT maps:
+ * portD to pin 3 using 0xc5420.
+ */
+static const struct gmbus_pin gmbus_pins_cnp[] = {
+   [GMBUS_PIN_1_BXT] = { "dpb", GPIOB },
+   [GMBUS_PIN_2_BXT] = { "dpc", GPIOC },
+   [GMBUS_PIN_3_BXT] = { "misc", GPIOE },
+   [GMBUS_PIN_4_CNP] = { "dpd", GPIOD },
+};
+
 /* pin is expected to be valid */
 static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
 unsigned int pin)
 {
-   if (IS_GEN9_LP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   return &gmbus_pins_cnp[pin];
+   else if (IS_GEN9_LP(dev_priv))
return &gmbus_pins_bxt[pin];
else if (IS_GEN9_BC(dev_priv))
return &gmbus_pins_skl[pin];
@@ -87,7 +101,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private 
*dev_priv,
 {
unsigned int size;
 
-   if (IS_GEN9_LP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   size = ARRAY_SIZE(gmbus_pins_cnp);
+   else if (IS_GEN9_LP(dev_priv))
size = ARRAY_SIZE(gmbus_pins_bxt);
else if (IS_GEN9_BC(dev_priv))
size = ARRAY_SIZE(gmbus_pins_skl);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

Most of south engine display that is in PCH is still the
same as SPT and KBP, except for this key differences:

- Backlight: Backlight programming changed in CNP PCH.
- Panel Power: Sligh programming changed in CNP PCH.
- GMBUS and GPIO: The pin mapping has changed in CNP PCH.

All of these changes follow more the BXT style.

v2: Update definition to use dev_priv isntead of dev (Tvrtko).

Cc: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_drv.c | 3 +++
 drivers/gpu/drm/i915/i915_drv.h | 3 +++
 drivers/gpu/drm/i915/i915_irq.c | 6 --
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2fdfaf1..9e4c13e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -216,6 +216,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS("Found KabyPoint PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
+   } else if (id == INTEL_PCH_CNP_DEVICE_ID_TYPE) {
+   dev_priv->pch_type = PCH_CNP;
+   DRM_DEBUG_KMS("Found CannonPoint PCH\n");
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
   (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bde554e..0b82604 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1151,6 +1151,7 @@ enum intel_pch {
PCH_LPT,/* Lynxpoint PCH */
PCH_SPT,/* Sunrisepoint PCH */
PCH_KBP,/* Kabypoint PCH */
+   PCH_CNP,/* Cannonpoint PCH */
PCH_NOP,
 };
 
@@ -2966,11 +2967,13 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 #define INTEL_PCH_SPT_DEVICE_ID_TYPE   0xA100
 #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
 #define INTEL_PCH_KBP_DEVICE_ID_TYPE   0xA200
+#define INTEL_PCH_CNP_DEVICE_ID_TYPE   0xA300
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
 #define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
+#define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
 #define HAS_PCH_KBP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_KBP)
 #define HAS_PCH_SPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_SPT)
 #define HAS_PCH_LPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_LPT)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7b7f55a..4cd9ee1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2548,7 +2548,8 @@ static void bxt_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
I915_WRITE(SDEIIR, iir);
ret = IRQ_HANDLED;
 
-   if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv))
+   if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv) ||
+   HAS_PCH_CNP(dev_priv))
spt_irq_handler(dev_priv, iir);
else
cpt_irq_handler(dev_priv, iir);
@@ -4289,7 +4290,8 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev->driver->disable_vblank = gen8_disable_vblank;
if (IS_GEN9_LP(dev_priv))
dev_priv->display.hpd_irq_setup = bxt_hpd_irq_setup;
-   else if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv))
+   else if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv) ||
+HAS_PCH_CNP(dev_priv))
dev_priv->display.hpd_irq_setup = spt_hpd_irq_setup;
else
dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/6] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

As for BXT, PP_DIVISOR was removed from CNP PCH and power
cycle delay has been moved to PP_CONTROL.

Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 58dca87..1a27c72 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -798,7 +798,7 @@ static void intel_pps_get_registers(struct drm_i915_private 
*dev_priv,
regs->pp_stat = PP_STATUS(pps_idx);
regs->pp_on = PP_ON_DELAYS(pps_idx);
regs->pp_off = PP_OFF_DELAYS(pps_idx);
-   if (!IS_GEN9_LP(dev_priv))
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
regs->pp_div = PP_DIVISOR(pps_idx);
 }
 
@@ -5099,7 +5099,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
 
pp_on = I915_READ(regs.pp_on);
pp_off = I915_READ(regs.pp_off);
-   if (!IS_GEN9_LP(dev_priv)) {
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
I915_WRITE(regs.pp_ctrl, pp_ctl);
pp_div = I915_READ(regs.pp_div);
}
@@ -5117,7 +5117,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
   PANEL_POWER_DOWN_DELAY_SHIFT;
 
-   if (IS_GEN9_LP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
BXT_POWER_CYCLE_DELAY_SHIFT;
if (tmp > 0)
@@ -5274,7 +5274,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
 (seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
/* Compute the divisor for the pp clock, simply match the Bspec
 * formula. */
-   if (IS_GEN9_LP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
pp_div = I915_READ(regs.pp_ctrl);
pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)
@@ -5308,7 +5308,7 @@ static void intel_dp_init_panel_power_timestamps(struct 
intel_dp *intel_dp)
DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, 
PP_OFF %#x, PP_DIV %#x\n",
  I915_READ(regs.pp_on),
  I915_READ(regs.pp_off),
- IS_GEN9_LP(dev_priv) ?
+ (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
  (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
  I915_READ(regs.pp_div));
 }
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

== Series Details ==

Series: series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH.
URL   : https://patchwork.freedesktop.org/series/25068/
State : success

== Summary ==

Series 25068v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/25068/revisions/1/mbox/

Test kms_busy:
Subgroup basic-flip-default-b:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144 +1
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600) fdo#100215 +1

fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:446s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:571s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:512s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:486s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:428s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:417s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:420s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:486s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:470s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:570s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:454s
fi-skl-6700hqtotal:278  pass:230  dwarn:1   dfail:0   fail:25  skip:22  
time:413s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:463s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:504s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:441s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:546s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:407s

0af3152d8e2034d1491ef8738e7dfc6e08852606 drm-tip: 2017y-05m-30d-17h-20m-32s UTC 
integration manifest
eb2c335 drm/i915/cnp: Panel Power sequence changes for CNP PCH.
b77a08c drm/i915/cnp: add CNP gmbus support
dcd1303 drm/i915/cnp: Backlight support for CNP.
6439b2b drm/i915/cnp: Get/set proper Raw clock frequency on CNP.
b0beaea drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH
e777c58 drm/i915/cnp: Introduce Cannonpoint PCH.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4833/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests/kms_setmode: increase MAX_CRTCS to 6

2017-05-30 Thread Harry Wentland

AMD GPUs can have 6 CRTCs.

This requires us to allocate the combinations on the heap.

Signed-off-by: Harry Wentland 
---
 tests/kms_setmode.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index 430568a1c24e..847ad650d27f 100644
--- a/tests/kms_setmode.c
+++ b/tests/kms_setmode.c
@@ -35,11 +35,13 @@
 #include "intel_bufmgr.h"
 
 #define MAX_CONNECTORS  10
-#define MAX_CRTCS   3
+#define MAX_CRTCS   6
 
 /* max combinations with repetitions */
+/* MAX_CONNECTORS ^ MAX_CRTCS */
+/* TODO should really be MAX_CONNECTORS ^ MAX_CONNECTORS ??? */
 #define MAX_COMBINATION_COUNT   \
-   (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS)
+   (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS * 
MAX_CONNECTORS * MAX_CONNECTORS)
 #define MAX_COMBINATION_ELEMS   MAX_CRTCS
 
 static int drm_fd;
@@ -743,22 +745,25 @@ static void get_combinations(int n, int k, bool 
allow_repetitions,
 static void test_combinations(const struct test_config *tconf,
  int connector_count)
 {
-   struct combination_set connector_combs;
-   struct combination_set crtc_combs;
+   struct combination_set *connector_combs;
+   struct combination_set *crtc_combs;
struct connector_config *cconfs;
int i;
 
if (connector_count > 2 && (tconf->flags & TEST_STEALING))
return;
 
+   connector_combs = malloc(sizeof(*connector_combs));
+   crtc_combs = malloc(sizeof(*crtc_combs));
+
get_combinations(tconf->resources->count_connectors, connector_count,
-false, &connector_combs);
+false, connector_combs);
get_combinations(tconf->resources->count_crtcs, connector_count,
-true, &crtc_combs);
+true, crtc_combs);
 
igt_info("Testing: %s %d connector combinations\n", tconf->name,
 connector_count);
-   for (i = 0; i < connector_combs.count; i++) {
+   for (i = 0; i < connector_combs->count; i++) {
int *connector_idxs;
int ret;
int j;
@@ -766,14 +771,14 @@ static void test_combinations(const struct test_config 
*tconf,
cconfs = malloc(sizeof(*cconfs) * connector_count);
igt_assert(cconfs);
 
-   connector_idxs = &connector_combs.items[i].elems[0];
+   connector_idxs = &connector_combs->items[i].elems[0];
ret = get_connectors(tconf->resources, connector_idxs,
 connector_count, cconfs);
if (ret < 0)
goto free_cconfs;
 
-   for (j = 0; j < crtc_combs.count; j++) {
-   int *crtc_idxs = &crtc_combs.items[j].elems[0];
+   for (j = 0; j < crtc_combs->count; j++) {
+   int *crtc_idxs = &crtc_combs->items[j].elems[0];
ret = assign_crtc_to_connectors(tconf, crtc_idxs,
connector_count,
cconfs);
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 08/11] drm/i915: handle ycbcr outputs

2017-05-30 Thread kbuild test robot

Hi Shashank,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20170530]
[cannot apply to v4.12-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Shashank-Sharma/HDMI-YCBCR-output-handling-in-DRM-layer/20170531-045411
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "drm_get_highest_quality_ycbcr_supported" 
>> [drivers/gpu/drm/i915/i915.ko] undefined!
>> ERROR: "drm_get_lowest_quality_ycbcr_supported" 
>> [drivers/gpu/drm/i915/i915.ko] undefined!
>> ERROR: "drm_can_support_this_ycbcr_output" [drivers/gpu/drm/i915/i915.ko] 
>> undefined!
>> ERROR: "drm_can_support_any_ycbcr_output" [drivers/gpu/drm/i915/i915.ko] 
>> undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 05/13] drm/i915/cnp: add CNP gmbus support

On CNP PCH based platforms the gmbus is on the south display that
is on PCH. The existing implementation for previous platforms
already covers the need for CNP expect for the pin pair configuration
that follows similar definitions that we had on BXT.

v2: Don't drop "_BXT" as the indicator of the first platform
supporting this pin numbers. Suggested by Daniel.
v3: Add missing else and fix register table since CNP GPIO_CTL
starts on 0xC5014.
v4: Fix pin number and map according to the current available VBT.
Re-add pin 4 for port D. Lost during some rebase.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_reg.h   |  3 ++-
 drivers/gpu/drm/i915/intel_hdmi.c |  8 +---
 drivers/gpu/drm/i915/intel_i2c.c  | 20 ++--
 3 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cb83fb7..1329420 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2626,9 +2626,10 @@ enum skl_disp_power_wells {
 #define   GMBUS_PIN_DPB5 /* SDVO, HDMIB */
 #define   GMBUS_PIN_DPD6 /* HDMID */
 #define   GMBUS_PIN_RESERVED   7 /* 7 reserved */
-#define   GMBUS_PIN_1_BXT  1
+#define   GMBUS_PIN_1_BXT  1 /* BXT+ (atom) and CNP+ (big core) */
 #define   GMBUS_PIN_2_BXT  2
 #define   GMBUS_PIN_3_BXT  3
+#define   GMBUS_PIN_4_CNP  4
 #define   GMBUS_NUM_PINS   7 /* including 0 */
 #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /* 
command/status */
 #define   GMBUS_SW_CLR_INT (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 41267ff..ec0779a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1802,19 +1802,21 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private 
*dev_priv,
 
switch (port) {
case PORT_B:
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
ddc_pin = GMBUS_PIN_1_BXT;
else
ddc_pin = GMBUS_PIN_DPB;
break;
case PORT_C:
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
ddc_pin = GMBUS_PIN_2_BXT;
else
ddc_pin = GMBUS_PIN_DPC;
break;
case PORT_D:
-   if (IS_CHERRYVIEW(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   ddc_pin = GMBUS_PIN_4_CNP;
+   else if (IS_CHERRYVIEW(dev_priv))
ddc_pin = GMBUS_PIN_DPD_CHV;
else
ddc_pin = GMBUS_PIN_DPD;
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index b6401e8..3eb4a91 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -68,11 +68,25 @@ struct gmbus_pin {
[GMBUS_PIN_3_BXT] = { "misc", GPIOD },
 };
 
+/*
+ * FIXME: Spec maps 3-misc-0xc541c and 4-portd-0xc5420.
+ * However, current available pre-prod VBT maps:
+ * portD to pin 3 using 0xc5420.
+ */
+static const struct gmbus_pin gmbus_pins_cnp[] = {
+   [GMBUS_PIN_1_BXT] = { "dpb", GPIOB },
+   [GMBUS_PIN_2_BXT] = { "dpc", GPIOC },
+   [GMBUS_PIN_3_BXT] = { "misc", GPIOE },
+   [GMBUS_PIN_4_CNP] = { "dpd", GPIOD },
+};
+
 /* pin is expected to be valid */
 static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
 unsigned int pin)
 {
-   if (IS_GEN9_LP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   return &gmbus_pins_cnp[pin];
+   else if (IS_GEN9_LP(dev_priv))
return &gmbus_pins_bxt[pin];
else if (IS_GEN9_BC(dev_priv))
return &gmbus_pins_skl[pin];
@@ -87,7 +101,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private 
*dev_priv,
 {
unsigned int size;
 
-   if (IS_GEN9_LP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   size = ARRAY_SIZE(gmbus_pins_cnp);
+   else if (IS_GEN9_LP(dev_priv))
size = ARRAY_SIZE(gmbus_pins_bxt);
else if (IS_GEN9_BC(dev_priv))
size = ARRAY_SIZE(gmbus_pins_skl);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 10/13] drm/i915/cfl: Add Coffee Lake PCI IDs for H and S Skus.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_pci.c | 1 +
 include/drm/i915_pciids.h   | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 31ea988..0b1c96d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -477,6 +477,7 @@
INTEL_KBL_GT2_IDS(&intel_kabylake_info),
INTEL_KBL_GT3_IDS(&intel_kabylake_gt3_info),
INTEL_KBL_GT4_IDS(&intel_kabylake_gt3_info),
+   INTEL_CFL_IDS(&intel_coffeelake_info),
{0, 0, 0}
 };
 MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 27e0dba..a0e4d12 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -334,4 +334,8 @@
INTEL_KBL_GT3_IDS(info), \
INTEL_KBL_GT4_IDS(info)
 
+#define INTEL_CFL_IDS(info) \
+   INTEL_VGA_DEVICE(0x3E92, info), /* CFL-S GT2 */ \
+   INTEL_VGA_DEVICE(0x3E9B, info) /* CFL-H GT2 */
+
 #endif /* _I915_PCIIDS_H */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/13] drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH