[Bug 109554] Regression: short time display corruption during resume

[bugzilla-daemon]

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

Bug ID: 109554
   Summary: Regression: short time display corruption during
resume
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: zaj...@gmail.com

I use HP EliteBook 745 G5 with Ryzen 5 PRO 2500U.

Starting with the:
commit 009d9ed6c4b7b84dbff8314d74233da9237a4560
Author: Rex Zhu 
Date:   Sun Sep 30 17:37:27 2018 +0800

drm/amdgpu: Change AI gfx/sdma/smu init sequence

initialize gfx/sdma before dpm features enabled.

Acked-by: Alex Deucher 
Signed-off-by: Rex Zhu 
Signed-off-by: Alex Deucher 

During most resumes from RAM I see a display with black screen & some
corruptions for a 1 second or less.

This is *not* critical but since it's a tracked regression I decided to report
it with a hope it's something easy & possible to fix. After that second (or
less) displays shows an expected image (KDE lock screen) and everything works
normal afterwards.

This problem still exists in the 5.0.0-rc3.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver

[Stéphane Marchesin]

On Mon, Feb 4, 2019 at 1:07 AM Daniel Vetter  wrote:
>
> On Mon, Feb 04, 2019 at 10:57:24AM +0200, Joonas Lahtinen wrote:
> > Quoting Joonas Lahtinen (2019-01-15 16:47:27)
> > > Hi all,
> > >
> > > I would like to have some Acked-by's from you, the distro media
> > > folks Cc'd here, to document your intent to start using Intel's
> > > new media driver[1]. So if you recognize yourself (or are otherwise
> > > interested), please read on.
> > >
> > > TL;DR Distro folks, please give your Acked-by on patch [5/6]
> >
> > A gentle reminder, I'm still looking to hear back from Stephane
> > and Dave.
> >
> > We'd like to have this included in the final 5.1 drm-intel-next
> > pull request this week.
> >
> > If there are no further comments by Wed, I will conclude that we
> > have reached a silent agreement, and merge this to give enough
> > time for Rodrigo to send the PR.
>
> Maybe should add that ubunut/suse folks seem ok. Also, it's for libva, in
> the past that's been very far down the list of contentious topics. Mostly
> positive meh seems plenty good enough feedback I think.

FWIW I think the API changes are fine. Sure it feels a bit odd at
first, but there's no better alternative that I can see either.

Acked-by: Stéphane Marchesin 



> -Daniel
>
> >
> > Regards, Joonas
> >
> > > I believe most are already aware of the situation that Intel
> > > is moving to the new codebase for libva backend to support new Intel
> > > integrated graphics devices. The existing intel-libva-driver will
> > > be continue to be be supported for pre-Icelake platforms ( > > Icelake and further platforms will only be supported from the
> > > new codebase.
> > >
> > > There's the complication that some Icelake features of the new
> > > driver will require new kernel uAPIs to work... But the new driver
> > > has not yet been well-established in the community from perspective
> > > of fulfilling [2]. This is very much due to the demand being low
> > > as Icelake is not widely available yet. So it's bit of a chicken
> > > and egg problem as we have a new platform *and* a new codebase for
> > > it simultaneously.
> > >
> > > Ahead of that community adoption, to ensure that Icelake has good
> > > kernel support from day one, we'd like to merge kernel support for
> > > the parts that have functional effect (this series). This is to
> > > avoid the scenario where end users have to update their distro
> > > kernels, like happened with Skylake.
> > >
> > > So if I could get Acked-by's from distro folks on the patch [5/6] that
> > > adds the new uAPI. That would document their intent to become an active
> > > user of the media-driver[1]. If that happens in the next week or two,
> > > it would mean that Icelake hardware features would be supported in
> > > kernel version 5.1 fully from kernel driver point of view.
> > >
> > > The new uAPI is needed to make VME feature functionally work
> > > on Icelake. It's pretty much a simple enable/disable switch for
> > > hardware configuration that only includes hardware slices compatible
> > > with the VME workload. So it's currently limited to the required on/off
> > > choice to keep things straightforward. The uAPI can be extended in the
> > > future for possible performance gains for more fine-grained control.
> > >
> > > VME is shared function to handle motion estimation. One intended
> > > usercase is in Hierarchical Motion Estimation (HME) media kernel. It
> > > provides a bigger search range with reduced cost for the search. HME
> > > should improve the encode quality with scenarios where the video has
> > > a lot of motion in it. Carl (Cc'd) can provide more details if needed.
> > >
> > > The respective IGT tests are reviewed and can be found at:
> > >
> > >   https://patchwork.freedesktop.org/series/49190/
> > >
> > > The userspace changes are reviewed and rebased here:
> > >
> > >   https://github.com/intel/media-driver/pull/271
> > >   https://github.com/intel/media-driver/pull/463
> > >
> > > Best Regards, Joonas Lahtinen
> > >
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: Timo Aaltonen 
> > > Cc: Takashi Iwai 
> > > Cc: Stephane Marchesin 
> > > Cc: Dave Airlie 
> > > Cc: Daniel Vetter 
> > >
> > > PS. This series might result in some CI failures reported as it adds new 
> > > uAPI
> > > and Patchwork / CI synchronization of tests and kernel is currently 
> > > WIP.
> > >
> > > [1] https://github.com/intel/media-driver
> > > [2] 
> > > https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> > >
> > > Lionel Landwerlin (2):
> > >   drm/i915: Record the sseu configuration per-context & engine
> > >   drm/i915/perf: lock powergating configuration to default when active
> > >
> > > Tvrtko Ursulin (4):
> > >   drm/i915/execlists: Move RPCS setup to context pin
> > >   drm/i915: Add timeline barrier support
> > >   drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
> > >   drm/i915/selftests: Context SSEU reconfiguration tests

[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.

[bugzilla-daemon]

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

--- Comment #69 from jake.hed...@yahoo.com ---
Hi Alex, comment 64 did not resolve the issue.  It did seem to delay the crash,
but ultimately did not resolve it.  I will test the idle=nomwait param now and
begin testing.  If I am still stuck, I also have another suggestion to limit
the Mhz on the GPU itself.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH v3 4/4] drm/nouveau: Move PBN and VCPI allocation into nv50_head_atom

[Ben Skeggs]

On Sat, 2 Feb 2019 at 10:20, Lyude Paul  wrote:
>
> Atomic checks should never modify anything outside of the state that
> they're passed in. Unfortunately this appears to be exactly what we're
> doing in nv50_msto_atomic_check() where we update mstc->pbn every time
> the function is called. This hasn't caused any bugs yet, but it needs to
> be fixed in order to ensure that when committing an artificially
> duplicated state (like during system resume), that we reuse the PBN of
> that state to perform VCPI allocations and don't recalculate a different
> value from the drm connector's reported bpc.
>
> Also, move the VCPI slot allocations while we're at it as well. With
> this, removing a topology in suspend while using nouveau no longer
> causes the new atomic VCPI helpers to complain.
>
> Signed-off-by: Lyude Paul 
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Cc: Daniel Vetter 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/dispnv50/atom.h |  6 ++
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 28 +++--
>  drivers/gpu/drm/nouveau/dispnv50/head.c |  1 +
>  3 files changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h 
> b/drivers/gpu/drm/nouveau/dispnv50/atom.h
> index a194990d2b0d..b5fae5ab3fa8 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
> +++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
> @@ -116,6 +116,12 @@ struct nv50_head_atom {
> u8 depth:4;
> } or;
>
> +   /* Currently only used for MST */
> +   struct {
> +   int pbn;
> +   u8 tu:6;
> +   } dp;
> +
> union nv50_head_atom_mask {
> struct {
> bool olut:1;
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 60d858c2f2ce..e8bb35f6d015 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -659,8 +659,6 @@ struct nv50_mstc {
>
> struct drm_display_mode *native;
> struct edid *edid;
> -
> -   int pbn;
>  };
>
>  struct nv50_msto {
> @@ -765,17 +763,26 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
> struct drm_connector *connector = conn_state->connector;
> struct nv50_mstc *mstc = nv50_mstc(connector);
> struct nv50_mstm *mstm = mstc->mstm;
> -   int bpp = connector->display_info.bpc * 3;
> +   struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
> int slots;
>
> -   mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
> -bpp);
> +   /* When restoring duplicated states, we need to make sure that the
> +* bw remains the same and avoid recalculating it, as the connector's
> +* bpc may have changed after the state was duplicated
> +*/
> +   if (!state->duplicated)
> +   asyh->dp.pbn =
> +   drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
> +connector->display_info.bpc * 3);
>
> if (drm_atomic_crtc_needs_modeset(crtc_state)) {
> slots = drm_dp_atomic_find_vcpi_slots(state, >mgr,
> - mstc->port, mstc->pbn);
> + mstc->port,
> + asyh->dp.pbn);
> if (slots < 0)
> return slots;
> +
> +   asyh->dp.tu = slots;
> }
>
> return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
> @@ -786,13 +793,13 @@ static void
>  nv50_msto_enable(struct drm_encoder *encoder)
>  {
> struct nv50_head *head = nv50_head(encoder->crtc);
> +   struct nv50_head_atom *armh = nv50_head_atom(head->base.base.state);
> struct nv50_msto *msto = nv50_msto(encoder);
> struct nv50_mstc *mstc = NULL;
> struct nv50_mstm *mstm = NULL;
> struct drm_connector *connector;
> struct drm_connector_list_iter conn_iter;
> u8 proto, depth;
> -   int slots;
> bool r;
>
> drm_connector_list_iter_begin(encoder->dev, _iter);
> @@ -808,8 +815,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
> if (WARN_ON(!mstc))
> return;
>
> -   slots = drm_dp_find_vcpi_slots(>mgr, mstc->pbn);
> -   r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, mstc->pbn, 
> slots);
> +   r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, armh->dp.pbn,
> +armh->dp.tu);
> WARN_ON(!r);
>
> if (!mstm->links++)
> @@ -827,8 +834,7 @@ nv50_msto_enable(struct drm_encoder *encoder)
> default: depth = 0x6; break;
> }
>
> -   mstm->outp->update(mstm->outp, head->base.index,
> -  nv50_head_atom(head->base.base.state), 

[Bug 109548] Seeing visual corruption in totem after installing amdgpu 18.50 in Ubuntu 18.04.1

[bugzilla-daemon]

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

--- Comment #2 from spause+bugzi...@gmail.com ---
It seems like this issue is maybe the same as this one associated with Intel
driver here - https://bugs.freedesktop.org/show_bug.cgi?id=104536

But I may be misunderstanding.


I will say that the AMDgpu drivers appear to have usability issues in Ubuntu
18.50, as my primary intent is gaming, and there is almost no possible
configuration without major side effects. I did try amdgpu-pro,  which caused a
whole other set of issues.

I also edit videos almost daily. So I notice issues immediately.

Let me know what detail you require to proceed.  I'm not sure where the issue
could be, but mesa was mentioned in a similar bug report
(https://bugs.launchpad.net/ubuntu/+source/gstreamer-vaapi/+bug/1767312).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109548] Seeing visual corruption in totem after installing amdgpu 18.50 in Ubuntu 18.04.1

[bugzilla-daemon]

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

--- Comment #1 from spause+bugzi...@gmail.com ---
Created attachment 143293
  --> https://bugs.freedesktop.org/attachment.cgi?id=143293=edit
video (no issues) properties

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109548] Seeing visual corruption in totem after installing amdgpu 18.50 in Ubuntu 18.04.1

[bugzilla-daemon]

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

Bug ID: 109548
   Summary: Seeing visual corruption in totem after installing
amdgpu 18.50 in Ubuntu 18.04.1
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: spause+bugzi...@gmail.com

Created attachment 143292
  --> https://bugs.freedesktop.org/attachment.cgi?id=143292=edit
video (with issue) properties

Seeing visual corruption in totem after installing amdgpu 18.50 in Ubuntu
18.04.1.  Not present with default OS provided video driver.


I've just tested opening a specific video when my Ubuntu 18.04.1 LTS system
does not have the amdgpu driver installed from AMD, and AFTER the driver is
installed. 


The video is fine when the default (Ubuntu provided) video driver is used. 
After the latest (18.50) AMD video driver (amdgpu) is installed (and computer
is rebooted) this attached/linked video displays in bright colors.


See attached example screenshot of video issue/properties. I will try to attach
more pics if possible.


If I add the following to the /etc/drirc, the issue disappears.  The word is
that this indicates there is an issue with rgb10 support (10 bit RGB or 10bpc ?
)






-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109539] System freezing

[bugzilla-daemon]

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

--- Comment #5 from jon  ---
Created attachment 143291
  --> https://bugs.freedesktop.org/attachment.cgi?id=143291=edit
Xorg.0.log

xorg log from ~/.local/

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109539] System freezing

[bugzilla-daemon]

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

--- Comment #4 from jon  ---
Created attachment 143290
  --> https://bugs.freedesktop.org/attachment.cgi?id=143290=edit
dmesg output

dmesg output (direct code disabled)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109539] System freezing

[bugzilla-daemon]

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

--- Comment #3 from jon  ---
>The freezing doesn't seem to be necessarily caused by by something in amdgpu 
>>from a glance at your log.

I thought the same thing, but after disabling direct code I went from the
system freezing up to 5 or 6 times a day, depending on use, every day to having
an uptime over 2 days and 4 hours now.  So there's no question that disabling
direct code solved the problem.  It is night and day after that change.

>There are some DC warnings/errors that describe what you're seeing with your 
>monitor not waking from sleep however.
>
>Please post a full dmesg log from system boot and an xorg log if you're using 
>X. >It may also help to know what window manager you're using when you see 
>this >issue occur.

I am using X and my window manager is dwm.  I will attach an Xorg log as well
as dmesg.  Keep in mind these will be the most recent logs with direct code
disabled, which may not matter, just wanted to be clear.  

>Does adding idle=nomwait to the kernel command line in grub help?

No, according to my notes I added idle=nomwait on 1/31/19 and experienced many
freezes per day since then.  I also used the following kernel boot parameters,
which had no affect:

rcu_nocbs=0-15
processor.max_cstate=5

All three of these, along with disabling direct code, are still in my kernel
boot parameters.  None of those had any affect, frequent crashes still.  After
disabling direct code and restarting I have not had one freeze yet.  Stability
went from a couple of hours (usually long enough for me to be away from it long
enough to sleep) to an uptime of >2 days.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/dsc: Add kernel documentation for DRM DP DSC helpers

[Manasi Navare]

This patch adds appropiate kernel documentation for DRM DP helpers
used for enabling Display Stream compression functionality in
drm_dp_helper.h and drm_dp_helper.c as well as for the DSC spec
related structure definitions and helpers in drm_dsc.c and drm_dsc.h
Also add links between the functions and structures in the documentation.

Suggested-by: Daniel Vetter 
Suggested-by: Sean Paul 
Cc: Daniel Vetter 
Cc: Sean Paul 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_dp_helper.c |  42 +-
 drivers/gpu/drm/drm_dsc.c   |  13 ++-
 include/drm/drm_dp_helper.h |  15 +++-
 include/drm/drm_dsc.h   | 138 ++--
 4 files changed, 142 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 54120b6319e7..e9e0233f5b2f 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1360,7 +1360,20 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct 
drm_dp_desc *desc,
 EXPORT_SYMBOL(drm_dp_read_desc);
 
 /**
- * DRM DP Helpers for DSC
+ * drm_dp_dsc_sink_max_slice_count() - Get the max slice count
+ * supported by the DSC sink.
+ * @dsc_dpcd: DSC capabilities from DPCD
+ * @is_edp: true if its eDP, false for DP
+ *
+ * Read the slice capabilities DPCD register from DSC sink to get
+ * the maximum slice count supported. This is used to populate
+ * the DSC parameters in the  drm_dsc_config by the driver.
+ * Driver creates an infoframe using these parameters to populate
+ *  drm_dsc_pps_infoframe. These are sent to the sink using DSC
+ * infoframe using the helper function drm_dsc_pps_infoframe_pack()
+ *
+ * Returns:
+ * Maximum slice count supported by DSC sink or 0 its invalid
  */
 u8 drm_dp_dsc_sink_max_slice_count(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
   bool is_edp)
@@ -1405,6 +1418,19 @@ u8 drm_dp_dsc_sink_max_slice_count(const u8 
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
 }
 EXPORT_SYMBOL(drm_dp_dsc_sink_max_slice_count);
 
+/**
+ * drm_dp_dsc_sink_line_buf_depth() - Get the line buffer depth in bits which 
is
+ * number of bits of precision within the decoder line buffer supported by
+ * the DSC sink. This is used to populate the DSC parameters in the
+ *  drm_dsc_config by the driver.
+ * Driver creates an infoframe using these parameters to populate
+ *  drm_dsc_pps_infoframe. These are sent to the sink using DSC
+ * infoframe using the helper function drm_dsc_pps_infoframe_pack()
+ * @dsc_dpcd: DSC capabilities from DPCD
+ *
+ * Returns:
+ * Line buffer depth supported by DSC panel or 0 its invalid
+ */
 u8 drm_dp_dsc_sink_line_buf_depth(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
 {
u8 line_buf_depth = dsc_dpcd[DP_DSC_LINE_BUF_BIT_DEPTH - 
DP_DSC_SUPPORT];
@@ -1434,6 +1460,20 @@ u8 drm_dp_dsc_sink_line_buf_depth(const u8 
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
 }
 EXPORT_SYMBOL(drm_dp_dsc_sink_line_buf_depth);
 
+/**
+ * drm_dp_dsc_sink_supported_input_bpcs() - Get all the input bits per 
component
+ * values supported by the DSC sink. This is used to populate the DSC 
parameters
+ * in the  drm_dsc_config by the driver.
+ * Driver creates an infoframe using these parameters to populate
+ *  drm_dsc_pps_infoframe. These are sent to the sink using DSC
+ * infoframe using the helper function drm_dsc_pps_infoframe_pack()
+ * @dsc_dpcd: DSC capabilities from DPCD
+ * @dsc_bpc: An array to be filled by this helper with supported
+ *   input bpcs.
+ *
+ * Returns:
+ * Number of input BPC values parsed from the DPCD
+ */
 int drm_dp_dsc_sink_supported_input_bpcs(const u8 
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
 u8 dsc_bpc[3])
 {
diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
index bc2b23adb072..0fd56fbdf9b4 100644
--- a/drivers/gpu/drm/drm_dsc.c
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -17,6 +17,12 @@
 /**
  * DOC: dsc helpers
  *
+ * VESA specification for DP 1.4 adds a new feature called Display Stream
+ * Compression (DSC) used to compress the pixel bits before sending it on
+ * DP/eDP/MIPI DSI interface. DSC is required to be enabled so that the 
existing
+ * display interfaces can support high resolutions at higher frames rates uisng
+ * the maximum available link capacity of these interfaces.
+ *
  * These functions contain some common logic and helpers to deal with VESA
  * Display Stream Compression standard required for DSC on Display Port/eDP or
  * MIPI display interfaces.
@@ -26,6 +32,7 @@
  * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
  * for DisplayPort as per the DP 1.4 spec.
  * @pps_sdp: Secondary data packet for DSC Picture Parameter Set
+ *   as defined in  drm_dsc_pps_infoframe
  */
 void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
 {
@@ -44,9 +51,11 @@ EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
  * that span more than 1 byte.
  *
  * @pps_sdp:
- * Secondary data packet for DSC Picture Parameter Set
+ * 

RE: [PATCH v2 RESEND 2/2] drm/i915/icl: Implement half float formats

[Strasser, Kevin]

Ville Syrjälä wrote:
> Kevin Strasser wrote:
> > Ville Syrjälä wrote:
> > > is_hdr_plane() is around now, please use it.
> >
> > I don't think I can use icl_is_hdr_plane here without some refactoring. It
> > requires the plane->base to be initialized through drm_universal_plane_init,
> > which depends on formats/num_formats pointers to be already set.
>
> Hmm. We should probably just convert it into
>
> icl_is_hdr_plane(struct drm_i915_private *dev_priv,
>  enum plane_id plane_id);

That sounds reasonable, I'll include this in v3.

Thanks,
Kevin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] staging/vboxvideo: don't set dev_priv_size = 0

[Daniel Vetter]

On Mon, Feb 4, 2019 at 7:49 PM Sam Ravnborg  wrote:
>
> Hi Daniel
>
> On Mon, Feb 04, 2019 at 11:31:13AM +0100, Daniel Vetter wrote:
> > The compiler already clears this for us.
> >
> > More important, someone might look what this is actually used for,
> > and freak out about the dragon staring back at them.
> >
> > Signed-off-by: Daniel Vetter 
> > Cc: Greg Kroah-Hartman 
> > Cc: Hans de Goede 
> > Cc: Daniel Vetter 
> > Cc: Nicholas Mc Guire 
> > Cc: Emil Velikov 
> > Cc: Fabio Rafael da Rosa 
> > ---
> >  drivers/staging/vboxvideo/vbox_drv.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/staging/vboxvideo/vbox_drv.c 
> > b/drivers/staging/vboxvideo/vbox_drv.c
> > index b0d73d5fba5d..43c3d0a4fa1a 100644
> > --- a/drivers/staging/vboxvideo/vbox_drv.c
> > +++ b/drivers/staging/vboxvideo/vbox_drv.c
> > @@ -222,7 +222,6 @@ static void vbox_master_drop(struct drm_device *dev, 
> > struct drm_file *file_priv)
> >  static struct drm_driver driver = {
> >   .driver_features =
> >   DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | DRIVER_ATOMIC,
> > - .dev_priv_size = 0,
> >
> >   .lastclose = drm_fb_helper_lastclose,
> >   .master_set = vbox_master_set,
>
> I have stared at the file for a long time and so far no dragon
> was staring back at me. There was a few "#ifdef" that screamed
> at me, and a drm_fb_helper_fbdev_setup() that looked
> suspicious alas no dragon :-(

dev_priv_size is used by drm_bufs.c aka "you want a root-hole? have
it!" code from dri1 days. It's not running on any modern driver, at
least trinity/syzcaller stopped complaining (and I reviewed all the
entry points and made sure they go nowhere else than an immediate
return -errno). Except nouveau, for reasons (we accidentally made it
uapi there, but it's fixed, just need to wait for all those installs
to die so we can nuke it for good). The dragon was right there
breathing down your neck, and wouldn't have seen it coming  if it
decided to have a snack :-)

btw if you're bored, we should probably have a
CONFIG_FEWER_EXPLOITS_IN_DRM_NOUVEAU or so, default n, for the next
unaware traveller wandering into this dragon den.
-Daniel

> As for the change above, dragon or no dragon:
> Reviewed-by: Sam Ravnborg 
>
> Sam



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

Re: [PATCH v2 RESEND 2/2] drm/i915/icl: Implement half float formats

[Ville Syrjälä]

On Fri, Feb 01, 2019 at 09:38:57PM +, Strasser, Kevin wrote:
> Ville Syrjälä wrote:
> > > @@ -1774,6 +1776,45 @@ static const u32 skl_planar_formats[] = {
> > >DRM_FORMAT_NV12,
> > >  };
> > >
> > > +static const uint32_t icl_hdr_plane_formats[] = {
> >
> > Please switch to u32 & co. We recently had a mass conversion in the
> > driver.
> 
> Will do. Looks like the CI caught that too.
> 
> > >  static const u64 skl_plane_format_modifiers_noccs[] = {
> > >I915_FORMAT_MOD_Yf_TILED,
> > >I915_FORMAT_MOD_Y_TILED,
> > > @@ -1917,6 +1958,10 @@ static bool skl_plane_format_mod_supported(struct
> > > drm_plane *_plane,
> > >return true;
> > >/* fall through */
> > >case DRM_FORMAT_C8:
> > > + case DRM_FORMAT_XBGR16161616F:
> > > + case DRM_FORMAT_ABGR16161616F:
> > > + case DRM_FORMAT_XRGB16161616F:
> > > + case DRM_FORMAT_ARGB16161616F:
> > >if (modifier == DRM_FORMAT_MOD_LINEAR ||
> > >modifier == I915_FORMAT_MOD_X_TILED ||
> > >modifier == I915_FORMAT_MOD_Y_TILED)
> > > @@ -2053,11 +2098,21 @@ skl_universal_plane_create(struct drm_i915_private
> > > *dev_priv,
> > >plane->update_slave = icl_update_slave;
> > >
> > >if (skl_plane_has_planar(dev_priv, pipe, plane_id)) {
> > > - formats = skl_planar_formats;
> > > - num_formats = ARRAY_SIZE(skl_planar_formats);
> > > + if (INTEL_GEN(dev_priv) > 10 && plane_id < PLANE_SPRITE2) {
> >
> > is_hdr_plane() is around now, please use it.
> 
> I don't think I can use icl_is_hdr_plane here without some refactoring. It 
> requires the plane->base to be initialized through drm_universal_plane_init, 
> which depends on formats/num_formats pointers to be already set.

Hmm. We should probably just convert it into

icl_is_hdr_plane(struct drm_i915_private *dev_priv,
 enum plane_id plane_id);

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

Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel

[Rob Herring]

On Mon, Feb 4, 2019 at 2:26 PM Vasily Khoruzhick  wrote:
>
> On Mon, Feb 4, 2019 at 12:23 PM Rob Herring  wrote:
>
> > > simple-panel would probably work if you stuck in some mostly compatible
> > > string and provided a ddc-i2c-bus property in the device tree node. The
> > > generic-ish fallback case could be implemented by providing a fallback
> > > compatible string (we used to have "simple-panel", which I think would
> > > still be adequate for this I suppose) and adding a dummy descriptor in
> > > the driver, perhaps one with pre-defined delays that could be adjusted
> > > to work for all cases, or they could just be 0. At least that way we'd
> > > be explicitly documenting that we support this as a fallback.
> >
> > I'd like something more specific than 'simple-panel' that at least
> > implies it has EDID and whatever else we think it should imply.
> >
> > Looking into this a bit more, why don't we just do a connector here?
> > eDP has a standard connector (with power). It's just like other
> > connectors, but with power and no hotplug. If someone does their own
> > interface, then they should do their own connector or panel binding.
>
> Where do we put backlight in this case?

In the connector node. You'd need a backlight supply,
'backlight-enable-gpios' and backlight phandle to pwm-backlight node.

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

Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel

[Rob Herring]

On Mon, Feb 4, 2019 at 10:56 AM Thierry Reding  wrote:
>
> On Mon, Feb 04, 2019 at 10:27:09AM -0600, Rob Herring wrote:
> > On Mon, Feb 4, 2019 at 2:24 AM Thierry Reding  
> > wrote:
> > >
> > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding 
> > > >  wrote:
> > > > >
> > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > eDP panels usually have EDID EEPROM, so there's no need to define 
> > > > > > panel
> > > > > > width/height or any modes/timings in dts. But this panel still may 
> > > > > > have
> > > > > > regulator and/or backlight.
> > > > > >
> > > > > > Signed-off-by: Vasily Khoruzhick 
> > > > > > ---
> > > > > >  .../devicetree/bindings/display/panel/panel-edp.txt| 7 
> > > > > > +++
> > > > > >  1 file changed, 7 insertions(+)
> > > > > >  create mode 100644 
> > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > >
> > > > > Please don't try to make panels look more generic than they really 
> > > > > are.
> > > > > You're going to have to provide a compatible string for your device 
> > > > > that
> > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > extra information that is panel specific, but you don't know that now.
> > > > > We have in the past thought that we didn't need things like prepare
> > > > > delay, but then we ran into situations where we did need them.
> > > > >
> > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > is faulty on some device.
> > > >
> > > > Pinebook used several 768p panels that have slightly different timings
> > > > and recent batch uses 1080p panel.
> > > >
> > > > What panel descriptor should I use as fallback?
> > >
> > > You don't use panel descriptors as fallback. The simple-panel driver
> > > will bind to a panel device and use the corresponding descriptor. If
> > > your device tree contains the correct information, the descriptor is
> > > correct for the panel you have.
> > >
> > > In other words you need to ensure that you have the correct panel in
> > > device tree for the board that you're using. This is exactly the same
> > > thing as for other devices.
> > >
> > > One way to to this is to have separate device trees for each variant
> > > of the board that you want to support. Another variant may be to have
> > > a common device tree and then have some early firmware update the DTB
> > > with the correct panel information.
> >
> > That can be a pain to manage especially if panels are swapped run to
> > run with 2nd sources.
> >
> > I think it is perfectly fine to have a generic-ish fallback as long as
> > it is just that, a fallback. If the panel has quirks, then you'd
> > better make sure the firmware is stuffing in the right compatibles or
> > that you can update the firmware.
>
> simple-panel would probably work if you stuck in some mostly compatible
> string and provided a ddc-i2c-bus property in the device tree node. The
> generic-ish fallback case could be implemented by providing a fallback
> compatible string (we used to have "simple-panel", which I think would
> still be adequate for this I suppose) and adding a dummy descriptor in
> the driver, perhaps one with pre-defined delays that could be adjusted
> to work for all cases, or they could just be 0. At least that way we'd
> be explicitly documenting that we support this as a fallback.

I'd like something more specific than 'simple-panel' that at least
implies it has EDID and whatever else we think it should imply.

Looking into this a bit more, why don't we just do a connector here?
eDP has a standard connector (with power). It's just like other
connectors, but with power and no hotplug. If someone does their own
interface, then they should do their own connector or panel binding.

> I'm not sure how you'd want to enforce that people provide the right
> compatible strings that way. Currently there's no way to make your panel
> work without adding a panel driver, so people are forced to write the
> DT bindings and a driver, or add support to an existing one. If we open
> this backdoor, I suspect many people will just take the easy route and
> rely on the fallback. And then what do we do when we get bug reports
> about panels not working, or requiring some quirks. How do we go and
> find out what the right compatible strings are for each board, or how to
> fix things for something we don't have access to.

We'll simply reject anything that should be implied by compatible. And
now we can enforce with schema that DTs aren't populated with
fallbacks alone. Of course, we can't make anyone pass all schema
checks before shipping a dtb.

Rob

[Bug 109539] System freezing

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher  ---
Does adding idle=nomwait to the kernel command line in grub help?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] staging/vboxvideo: Add TODO

[Sam Ravnborg]

Hi Daniel

On Mon, Feb 04, 2019 at 11:31:14AM +0100, Daniel Vetter wrote:
> Noticed why wonder what vboxvideo is using the ->master_set/drop hooks
> for.
Can you improve the gammar a little, I find it hard to read.

> 
> Signed-off-by: Daniel Vetter 
> Cc: Greg Kroah-Hartman 
> Cc: Fabio Rafael da Rosa 
> Cc: Nicholas Mc Guire 
> Cc: Daniel Vetter 
> Cc: Hans de Goede 
> ---
>  drivers/staging/vboxvideo/TODO | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/vboxvideo/TODO b/drivers/staging/vboxvideo/TODO
> index 2e0f99c3f10c..2953e7f794fb 100644
> --- a/drivers/staging/vboxvideo/TODO
> +++ b/drivers/staging/vboxvideo/TODO
> @@ -1,5 +1,7 @@
>  TODO:
>  -Get a full review from the drm-maintainers on dri-devel done on this driver
> +-Drop all the logic around initial_mode_queried/master_set&_drop and 
> everything
> +related to this. kms clients can handle hotplugs.
>  -Extend this TODO with the results of that review
>  
>  Please send any patches to Greg Kroah-Hartman ,

The syntax around "master_set&_drop" could be better.
I wondered if the "&" was some rst syntax.

But anyway, despite grammar nit and syntax nit:
Reviewed-by: Sam Ravnborg 

Which bring me back to a question asked a week ago or so.
What is missing before we can move vboxvideo out of staging/

Could we carry a few TODO items over in drm/ ar do we need a clean TODO?

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

Re: [pull] amdgpu, amdkfd, ttm, sched drm-next-5.1

[Dave Airlie]

On Tue, 5 Feb 2019 at 04:35, Alex Deucher  wrote:
>
> On Sun, Feb 3, 2019 at 11:57 PM Dave Airlie  wrote:
> >
> > On Mon, 4 Feb 2019 at 13:27, Dave Airlie  wrote:
> > >
> > > On Sat, 26 Jan 2019 at 09:15, Alex Deucher  wrote:
> > > >
> > > > Hi Dave, Daniel,
> > > >
> > > > New stuff for 5.1.
> > > > amdgpu:
> > > > - DC bandwidth formula updates
> > > > - Support for DCC on scanout surfaces
> > > > - Support for multiple IH rings on soc15 asics
> > > > - Fix xgmi locking
> > > > - Add sysfs interface to get pcie usage stats
> > > > - Simplify DC i2c/aux code
> > > > - Initial support for BACO on vega10/20
> > > > - New runtime SMU feature debug interface
> > > > - Expand existing sysfs power interfaces to new clock domains
> > > > - Handle kexec properly
> > > > - Simplify IH programming
> > > > - Rework doorbell handling across asics
> > > > - Drop old CI DPM implementation
> > > > - DC page flipping fixes
> > > > - Misc SR-IOV fixes
> > > >
> > >
> > > Hi Alex,
> > >
> > > I pulled this, but it introduced a warning, so I dropped it for now
> > > and the fix is on the list, please add it and resend,
> > >
> >
> > Just realised the warning was already there, so I pulled this again,
> > please send another next with the warning fix when you can.
>
> I was planning to send it via -fixes since the original patch was in
> 5.0, but I can include it in both -fixes and -next if you'd prefer.

Oh wow, I'm not sure how I missed it, please send via -fixes and I'll backmerge.

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

Re: [PATCH 1/2] staging/vboxvideo: don't set dev_priv_size = 0

[Sam Ravnborg]

Hi Daniel

On Mon, Feb 04, 2019 at 11:31:13AM +0100, Daniel Vetter wrote:
> The compiler already clears this for us.
> 
> More important, someone might look what this is actually used for,
> and freak out about the dragon staring back at them.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Greg Kroah-Hartman 
> Cc: Hans de Goede 
> Cc: Daniel Vetter 
> Cc: Nicholas Mc Guire 
> Cc: Emil Velikov 
> Cc: Fabio Rafael da Rosa 
> ---
>  drivers/staging/vboxvideo/vbox_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/staging/vboxvideo/vbox_drv.c 
> b/drivers/staging/vboxvideo/vbox_drv.c
> index b0d73d5fba5d..43c3d0a4fa1a 100644
> --- a/drivers/staging/vboxvideo/vbox_drv.c
> +++ b/drivers/staging/vboxvideo/vbox_drv.c
> @@ -222,7 +222,6 @@ static void vbox_master_drop(struct drm_device *dev, 
> struct drm_file *file_priv)
>  static struct drm_driver driver = {
>   .driver_features =
>   DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | DRIVER_ATOMIC,
> - .dev_priv_size = 0,
>  
>   .lastclose = drm_fb_helper_lastclose,
>   .master_set = vbox_master_set,

I have stared at the file for a long time and so far no dragon
was staring back at me. There was a few "#ifdef" that screamed
at me, and a drm_fb_helper_fbdev_setup() that looked
suspicious alas no dragon :-(

As for the change above, dragon or no dragon:
Reviewed-by: Sam Ravnborg 

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

Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV*

[Sam Ravnborg]

Hi Joe.

> My preference would also convert all the
> DRM_DEV_ uses to drm_dev_ eventually.
> 
> Also, the macros themselves could change to use a
> more consistent mechanism.
> 
> This would make the drm logging mechanisms more like
> other logging mechanisms used in the kernel.
> 
> Something like:

I like your patch, but do not have the time to follow-up on it.
It is for now saved and I will re-visit it when I have a bit more
time on my hands.

Thanks,

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

[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.

[bugzilla-daemon]

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

--- Comment #68 from Alex Deucher  ---
(In reply to jake.hedges from comment #66)
> It really did not take too long to crash it with even with the params.  I
> back to square one.  Thinking I will at least try a few different distros
> and possibly upgrade some hardware though I am not disappointed in their
> performance until I have used linux.  Anyways, I will keep experimenting and
> report back.

Do the suggestions in comment 64 or comment 67 help?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bochs: fix bochs_gem_prime_mmap

[Gerd Hoffmann]

ttm_fbdev_mmap() just doesn't work.  It appears to work fine, mmap()
returns success, but any attempt to actually access the mapping causes a
SIGBUS.

We can just use drm_gem_prime_mmap() instead.  Almost.  We have to copy
over the start offset from the ttm_buffer_object vm_node to the
drm_gem_object vm_node so the offset math in drm_gem_prime_mmap() works
correctly for us even though we use ttm to manage our objects.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/bochs/bochs_mm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 641a33f134..49463348a0 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -442,5 +442,6 @@ int bochs_gem_prime_mmap(struct drm_gem_object *obj,
 {
struct bochs_bo *bo = gem_to_bochs_bo(obj);
 
-   return ttm_fbdev_mmap(vma, >bo);
+   bo->gem.vma_node.vm_node.start = bo->bo.vma_node.vm_node.start;
+   return drm_gem_prime_mmap(obj, vma);
 }
-- 
2.9.3

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

[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.

[bugzilla-daemon]

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

--- Comment #66 from jake.hed...@yahoo.com ---
It really did not take too long to crash it with even with the params.  I back
to square one.  Thinking I will at least try a few different distros and
possibly upgrade some hardware though I am not disappointed in their
performance until I have used linux.  Anyways, I will keep experimenting and
report back.

--- Comment #67 from Alex Deucher  ---
For those with AMD platforms, does adding idle=nomwait on the kernel command
line in grub help?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] amdgpu, amdkfd, ttm, sched drm-next-5.1

[Alex Deucher]

On Sun, Feb 3, 2019 at 11:57 PM Dave Airlie  wrote:
>
> On Mon, 4 Feb 2019 at 13:27, Dave Airlie  wrote:
> >
> > On Sat, 26 Jan 2019 at 09:15, Alex Deucher  wrote:
> > >
> > > Hi Dave, Daniel,
> > >
> > > New stuff for 5.1.
> > > amdgpu:
> > > - DC bandwidth formula updates
> > > - Support for DCC on scanout surfaces
> > > - Support for multiple IH rings on soc15 asics
> > > - Fix xgmi locking
> > > - Add sysfs interface to get pcie usage stats
> > > - Simplify DC i2c/aux code
> > > - Initial support for BACO on vega10/20
> > > - New runtime SMU feature debug interface
> > > - Expand existing sysfs power interfaces to new clock domains
> > > - Handle kexec properly
> > > - Simplify IH programming
> > > - Rework doorbell handling across asics
> > > - Drop old CI DPM implementation
> > > - DC page flipping fixes
> > > - Misc SR-IOV fixes
> > >
> >
> > Hi Alex,
> >
> > I pulled this, but it introduced a warning, so I dropped it for now
> > and the fix is on the list, please add it and resend,
> >
>
> Just realised the warning was already there, so I pulled this again,
> please send another next with the warning fix when you can.

I was planning to send it via -fixes since the original patch was in
5.0, but I can include it in both -fixes and -next if you'd prefer.

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

Re: [PATCH libdrm] intel: sync i915_pciids.h with kernel

[Lionel Landwerlin]

On 02/02/2019 08:07, Rodrigo Vivi wrote:

Straight copy from the kernel file.

Add more PCI Device IDs for Coffee Lake, Ice Lake,
and Amber Lake. It also include a reorg on Whiskey Lake IDs.

Align with kernel commits:

5e0f5a58b167 ("drm/i915/cfl: Adding another PCI Device ID.")
03ca3cf8e9aa ("drm/i915/icl: Adding few more device IDs for Ice Lake")
c0c46ca461f1 ("drm/i915/aml: Add new Amber Lake PCI ID")
c1c8f6fa731b ("drm/i915: Redefine some Whiskey Lake SKUs")

Cc: José Roberto de Souza 
Signed-off-by: Rodrigo Vivi 



Acked-by: Lionel Landwerlin 




---
  intel/i915_pciids.h | 29 +
  1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
index fd965ffb..d2fad7b0 100644
--- a/intel/i915_pciids.h
+++ b/intel/i915_pciids.h
@@ -365,16 +365,20 @@
INTEL_VGA_DEVICE(0x593B, info) /* Halo GT4 */
  
  /* AML/KBL Y GT2 */

-#define INTEL_AML_GT2_IDS(info) \
+#define INTEL_AML_KBL_GT2_IDS(info) \
INTEL_VGA_DEVICE(0x591C, info),  /* ULX GT2 */ \
INTEL_VGA_DEVICE(0x87C0, info) /* ULX GT2 */
  
+/* AML/CFL Y GT2 */

+#define INTEL_AML_CFL_GT2_IDS(info) \
+   INTEL_VGA_DEVICE(0x87CA, info)
+
  #define INTEL_KBL_IDS(info) \
INTEL_KBL_GT1_IDS(info), \
INTEL_KBL_GT2_IDS(info), \
INTEL_KBL_GT3_IDS(info), \
INTEL_KBL_GT4_IDS(info), \
-   INTEL_AML_GT2_IDS(info)
+   INTEL_AML_KBL_GT2_IDS(info)
  
  /* CFL S */

  #define INTEL_CFL_S_GT1_IDS(info) \
@@ -390,6 +394,9 @@
INTEL_VGA_DEVICE(0x3E9A, info)  /* SRV GT2 */
  
  /* CFL H */

+#define INTEL_CFL_H_GT1_IDS(info) \
+   INTEL_VGA_DEVICE(0x3E9C, info)
+
  #define INTEL_CFL_H_GT2_IDS(info) \
INTEL_VGA_DEVICE(0x3E9B, info), /* Halo GT2 */ \
INTEL_VGA_DEVICE(0x3E94, info)  /* Halo GT2 */
@@ -407,27 +414,29 @@
  
  /* WHL/CFL U GT1 */

  #define INTEL_WHL_U_GT1_IDS(info) \
-   INTEL_VGA_DEVICE(0x3EA1, info)
+   INTEL_VGA_DEVICE(0x3EA1, info), \
+   INTEL_VGA_DEVICE(0x3EA4, info)
  
  /* WHL/CFL U GT2 */

  #define INTEL_WHL_U_GT2_IDS(info) \
-   INTEL_VGA_DEVICE(0x3EA0, info)
+   INTEL_VGA_DEVICE(0x3EA0, info), \
+   INTEL_VGA_DEVICE(0x3EA3, info)
  
  /* WHL/CFL U GT3 */

  #define INTEL_WHL_U_GT3_IDS(info) \
-   INTEL_VGA_DEVICE(0x3EA2, info), \
-   INTEL_VGA_DEVICE(0x3EA3, info), \
-   INTEL_VGA_DEVICE(0x3EA4, info)
+   INTEL_VGA_DEVICE(0x3EA2, info)
  
  #define INTEL_CFL_IDS(info)	   \

INTEL_CFL_S_GT1_IDS(info), \
INTEL_CFL_S_GT2_IDS(info), \
+   INTEL_CFL_H_GT1_IDS(info), \
INTEL_CFL_H_GT2_IDS(info), \
INTEL_CFL_U_GT2_IDS(info), \
INTEL_CFL_U_GT3_IDS(info), \
INTEL_WHL_U_GT1_IDS(info), \
INTEL_WHL_U_GT2_IDS(info), \
-   INTEL_WHL_U_GT3_IDS(info)
+   INTEL_WHL_U_GT3_IDS(info), \
+   INTEL_AML_CFL_GT2_IDS(info)
  
  /* CNL */

  #define INTEL_CNL_IDS(info) \
@@ -452,9 +461,13 @@
INTEL_VGA_DEVICE(0x8A51, info), \
INTEL_VGA_DEVICE(0x8A5C, info), \
INTEL_VGA_DEVICE(0x8A5D, info), \
+   INTEL_VGA_DEVICE(0x8A59, info), \
+   INTEL_VGA_DEVICE(0x8A58, info), \
INTEL_VGA_DEVICE(0x8A52, info), \
INTEL_VGA_DEVICE(0x8A5A, info), \
INTEL_VGA_DEVICE(0x8A5B, info), \
+   INTEL_VGA_DEVICE(0x8A57, info), \
+   INTEL_VGA_DEVICE(0x8A56, info), \
INTEL_VGA_DEVICE(0x8A71, info), \
INTEL_VGA_DEVICE(0x8A70, info)
  



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

RE: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Monday, February 4, 2019 10:54 PM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ; 
>dri-
>de...@lists.freedesktop.org; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
>
>On Mon, Feb 04, 2019 at 05:08:40PM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> >Sent: Monday, February 4, 2019 8:55 PM
>> >To: Shankar, Uma 
>> >Cc: intel-...@lists.freedesktop.org; Syrjala, Ville
>> >; Lankhorst, Maarten
>> >; dri- de...@lists.freedesktop.org
>> >Subject: Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
>> >
>> >On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
>> >> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
>> >> > Create a new connector property to program colorspace to sink
>> >> > devices. Modern sink devices support more than 1 type of
>> >> > colorspace like 601, 709, BT2020 etc. This helps to switch based
>> >> > on content type which is to be displayed. The decision lies with
>> >> > compositors as to in which scenarios, a particular colorspace will be
>picked.
>> >> >
>> >> > This will be helpful mostly to switch to higher gamut colorspaces
>> >> > like BT2020 when the media content is encoded as BT2020. Thereby
>> >> > giving a good visual experience to users.
>> >> >
>> >> > The expectation from userspace is that it should parse the EDID
>> >> > and get supported colorspaces. Use this property and switch to
>> >> > the one supported. Sink supported colorspaces should be retrieved
>> >> > by userspace from EDID and driver will not explicitly expose them.
>> >> >
>> >> > Basically the expectation from userspace is:
>> >> >  - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>> >> >colorspace
>> >> >  - Set this new property to let the sink know what it
>> >> >converted the CRTC output to.
>> >> >
>> >> > v2: Addressed Maarten and Ville's review comments. Enhanced the
>> >> > colorspace enum to incorporate both HDMI and DP supported
>> >> > colorspaces. Also, added a default option for colorspace.
>> >> >
>> >> > v3: Removed Adobe references from enum definitions as per Ville,
>> >> > Hans Verkuil and Jonas Karlman suggestions. Changed Default to an
>> >> > unset state where driver will assign the colorspace is not chosen
>> >> > by user, suggested by Ville and Maarten. Addressed other misc
>> >> > review comments from Maarten. Split the changes to have separate
>> >> > colorspace property for DP and HDMI.
>> >> >
>> >> > v4: Addressed Chris and Ville's review comments, and created a
>> >> > common colorspace property for DP and HDMI, filtered the list
>> >> > based on the colorspaces supported by the respective protocol standard.
>> >> >
>> >> > v5: Made the property creation helper accept enum list based on
>> >> > platform capabilties as suggested by Shashank. Consolidated HDMI
>> >> > and DP property creation in the common helper.
>> >> >
>> >> > v6: Addressed Shashank's review comments.
>> >> >
>> >> > v7: Added defines instead of enum in uapi as per Brian Starkey's
>> >> > suggestion in order to go with string matching at userspace.
>> >> > Updated the commit message to add more details as well kernel docs.
>> >> >
>> >> > v8: Addressed Maarten's review comments.
>> >> >
>> >> > v9: Removed macro defines from uapi as per Brian Starkey and
>> >> > Daniel Stone's comments and moved to drm include file. Moved back
>> >> > to older design with exposing all HDMI colorspaces to userspace
>> >> > since infoframe capability is there even on legacy platforms, as
>> >> > per Ville's review comments.
>> >> >
>> >> > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>> >> >
>> >> > Signed-off-by: Uma Shankar 
>> >> > Acked-by: Jani Nikula 
>> >> > Reviewed-by: Shashank Sharma 
>> >> > Reviewed-by: Maarten Lankhorst
>> >> > 
>> >> > ---
>> >> >  drivers/gpu/drm/drm_atomic_uapi.c |  4 +++
>> >> >  drivers/gpu/drm/drm_connector.c   | 75
>> >+++
>> >> >  include/drm/drm_connector.h   | 46 
>> >> >  3 files changed, 125 insertions(+)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> > b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> > index 9a1f41a..9b5d44f 100644
>> >> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> > @@ -746,6 +746,8 @@ static int
>> >> > drm_atomic_connector_set_property(struct
>> >drm_connector *connector,
>> >> > return -EINVAL;
>> >> > }
>> >> > state->content_protection = val;
>> >> > +   } else if (property == connector->colorspace_property) {
>> >> > +   state->colorspace = val;
>> >> > } else if (property == 

Re: [Intel-gfx] [PATCH] drm/i915: do not return invalid pointers as a *dentry

[Rodrigo Vivi]

On Thu, Jan 31, 2019 at 07:17:02PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 31, 2019 at 09:59:26AM -0800, Rodrigo Vivi wrote:
> > On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote:
> > > When calling debugfs functions, they can now return error values if
> > > something went wrong.  If that happens, return a NULL as a *dentry to
> > > the relay core instead of passing it an illegal pointer.
> > > 
> > > The relay core should be able to handle an illegal pointer, but add this
> > > check to be safe.
> > > 
> > > Cc: Jani Nikula 
> > > Cc: Joonas Lahtinen 
> > > Cc: Rodrigo Vivi 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Cc: intel-...@lists.freedesktop.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Signed-off-by: Greg Kroah-Hartman 
> > > ---
> > >  drivers/gpu/drm/i915/intel_guc_log.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
> > > b/drivers/gpu/drm/i915/intel_guc_log.c
> > > index d3ebdbc0182e..8bf03497dcd8 100644
> > > --- a/drivers/gpu/drm/i915/intel_guc_log.c
> > > +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> > > @@ -140,6 +140,9 @@ static struct dentry *create_buf_file_callback(const 
> > > char *filename,
> > >  
> > >   buf_file = debugfs_create_file(filename, mode,
> > >  parent, buf, _file_operations);
> > > + if (IS_ERR(buf_file))
> > > + return NULL;
> > 
> > I still see a return NULL inside debugfs_create_file on master,
> > but probably you are ahead with some change that I didn't see yet right?
> 
> Yes, this patch is in linux-next now and should go to Linus for
> 5.0-final:
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=driver-core-linus=ff9fb72bc07705c00795ca48631f7fffe24d2c6b
> 
> > I'm just wondering if it wouldn't be better for now to go with
> > 
> > if (IS_ERR_OR_NULL(buf_file))
> 
> Not really, because the next line is:
> 
> > >   return buf_file;
> 
> So it's the same thing :)
> 
> > apparently we also need it on i915_debugfs.c i915_debugfs_register()
> 
> I have a bunch of patches I'm working on to go through and fix up all of
> this (you shouldn't be checking the return value at all, unless you
> really want to use it as a "real" dentry and not just something that
> debugfs uses internally.
> 
> But for now, you should be fine, that call will only fail if you are out
> of memory, or did something really wrong.

Reviewed-by: Rodrigo Vivi 

do you wanna push this with your own stuff or do you want me to pick
up on drm-intel-next?

> 
> thanks,
> 
> greg k-h
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/6] drm/drv: Prepare to remove drm_dev_unplug()

[Noralf Trønnes]

Den 04.02.2019 16.41, skrev Daniel Vetter:
> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
>> The only thing now that makes drm_dev_unplug() special is that it sets
>> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
>> can remove drm_dev_unplug().
>>
>> Signed-off-by: Noralf Trønnes 
>> ---

[...]

>>  drivers/gpu/drm/drm_drv.c | 27 +++
>>  include/drm/drm_drv.h | 10 --
>>  2 files changed, 19 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 05bbc2b622fc..e0941200edc6 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -366,15 +366,6 @@ EXPORT_SYMBOL(drm_dev_exit);
>>   */
>>  void drm_dev_unplug(struct drm_device *dev)
>>  {
>> -/*
>> - * After synchronizing any critical read section is guaranteed to see
>> - * the new value of ->unplugged, and any critical section which might
>> - * still have seen the old value of ->unplugged is guaranteed to have
>> - * finished.
>> - */
>> -dev->unplugged = true;
>> -synchronize_srcu(_unplug_srcu);
>> -
>>  drm_dev_unregister(dev);
>>  drm_dev_put(dev);
>>  }
>> @@ -832,11 +823,14 @@ EXPORT_SYMBOL(drm_dev_register);
>>   * drm_dev_register() but does not deallocate the device. The caller must 
>> call
>>   * drm_dev_put() to drop their final reference.
>>   *
>> - * A special form of unregistering for hotpluggable devices is 
>> drm_dev_unplug(),
>> - * which can be called while there are still open users of @dev.
>> + * This function can be called while there are still open users of @dev as 
>> long
>> + * as the driver protects its device resources using drm_dev_enter() and
>> + * drm_dev_exit().
>>   *
>>   * This should be called first in the device teardown code to make sure
>> - * userspace can't access the device instance any more.
>> + * userspace can't access the device instance any more. Drivers that support
>> + * device unplug will probably want to call drm_atomic_helper_shutdown() 
>> first
> 
> Read once more with a bit more coffee, spotted this:
> 
> s/first/afterwards/ - shutting down the hw before we've taken it away from
> userspace is kinda the wrong way round. It should be the inverse of driver
> load, which is 1) allocate structures 2) prep hw 3) register driver with
> the world (simplified ofc).
> 

The problem is that drm_dev_unregister() sets the device as unplugged
and if drm_atomic_helper_shutdown() is called afterwards it's not
allowed to touch hardware.

I know it's the wrong order, but the only way to do it in the right
order is to have a separate function that sets unplugged:

drm_dev_unregister();
drm_atomic_helper_shutdown();
drm_dev_set_unplugged();

Noralf.

>> + * in order to disable the hardware on regular driver module unload.
>>   */
>>  void drm_dev_unregister(struct drm_device *dev)
>>  {
>> @@ -845,6 +839,15 @@ void drm_dev_unregister(struct drm_device *dev)
>>  if (drm_core_check_feature(dev, DRIVER_LEGACY))
>>  drm_lastclose(dev);
>>  
>> +/*
>> + * After synchronizing any critical read section is guaranteed to see
>> + * the new value of ->unplugged, and any critical section which might
>> + * still have seen the old value of ->unplugged is guaranteed to have
>> + * finished.
>> + */
>> +dev->unplugged = true;
>> +synchronize_srcu(_unplug_srcu);
>> +
>>  dev->registered = false;
>>  
>>  drm_client_dev_unregister(dev);
>> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
>> index ca46a45a9cce..c50696c82a42 100644
>> --- a/include/drm/drm_drv.h
>> +++ b/include/drm/drm_drv.h
>> @@ -736,13 +736,11 @@ void drm_dev_unplug(struct drm_device *dev);
>>   * drm_dev_is_unplugged - is a DRM device unplugged
>>   * @dev: DRM device
>>   *
>> - * This function can be called to check whether a hotpluggable is unplugged.
>> - * Unplugging itself is singalled through drm_dev_unplug(). If a device is
>> - * unplugged, these two functions guarantee that any store before calling
>> - * drm_dev_unplug() is visible to callers of this function after it 
>> completes
>> + * This function can be called to check whether @dev is unregistered. This 
>> can
>> + * be used to detect that the underlying parent device is gone.
> 
> I think it'd be good to keep the first part, and just update the reference
> to drm_dev_unregister. So:
> 
>  * This function can be called to check whether a hotpluggable is unplugged.
>  * Unplugging itself is singalled through drm_dev_unregister(). If a device is
>  * unplugged, these two functions guarantee that any store before calling
>  * drm_dev_unregister() is visible to callers of this function after it
>  * completes.
> 
> I think your version shrugs a few important details under the rug. With
> those nits addressed:
> 
> Reviewed-by: Daniel Vetter 
> 
> Cheers, Daniel
> 
>>   *
>> - * WARNING: This function 

Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property

[Ville Syrjälä]

On Mon, Feb 04, 2019 at 05:08:40PM +, Shankar, Uma wrote:
> 
> 
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Monday, February 4, 2019 8:55 PM
> >To: Shankar, Uma 
> >Cc: intel-...@lists.freedesktop.org; Syrjala, Ville 
> >;
> >Lankhorst, Maarten ; dri-
> >de...@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
> >
> >On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
> >> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
> >> > Create a new connector property to program colorspace to sink
> >> > devices. Modern sink devices support more than 1 type of colorspace
> >> > like 601, 709, BT2020 etc. This helps to switch based on content
> >> > type which is to be displayed. The decision lies with compositors as
> >> > to in which scenarios, a particular colorspace will be picked.
> >> >
> >> > This will be helpful mostly to switch to higher gamut colorspaces
> >> > like BT2020 when the media content is encoded as BT2020. Thereby
> >> > giving a good visual experience to users.
> >> >
> >> > The expectation from userspace is that it should parse the EDID and
> >> > get supported colorspaces. Use this property and switch to the one
> >> > supported. Sink supported colorspaces should be retrieved by
> >> > userspace from EDID and driver will not explicitly expose them.
> >> >
> >> > Basically the expectation from userspace is:
> >> >  - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> >> >colorspace
> >> >  - Set this new property to let the sink know what it
> >> >converted the CRTC output to.
> >> >
> >> > v2: Addressed Maarten and Ville's review comments. Enhanced the
> >> > colorspace enum to incorporate both HDMI and DP supported
> >> > colorspaces. Also, added a default option for colorspace.
> >> >
> >> > v3: Removed Adobe references from enum definitions as per Ville,
> >> > Hans Verkuil and Jonas Karlman suggestions. Changed Default to an
> >> > unset state where driver will assign the colorspace is not chosen by
> >> > user, suggested by Ville and Maarten. Addressed other misc review
> >> > comments from Maarten. Split the changes to have separate colorspace
> >> > property for DP and HDMI.
> >> >
> >> > v4: Addressed Chris and Ville's review comments, and created a
> >> > common colorspace property for DP and HDMI, filtered the list based
> >> > on the colorspaces supported by the respective protocol standard.
> >> >
> >> > v5: Made the property creation helper accept enum list based on
> >> > platform capabilties as suggested by Shashank. Consolidated HDMI and
> >> > DP property creation in the common helper.
> >> >
> >> > v6: Addressed Shashank's review comments.
> >> >
> >> > v7: Added defines instead of enum in uapi as per Brian Starkey's
> >> > suggestion in order to go with string matching at userspace. Updated
> >> > the commit message to add more details as well kernel docs.
> >> >
> >> > v8: Addressed Maarten's review comments.
> >> >
> >> > v9: Removed macro defines from uapi as per Brian Starkey and Daniel
> >> > Stone's comments and moved to drm include file. Moved back to older
> >> > design with exposing all HDMI colorspaces to userspace since
> >> > infoframe capability is there even on legacy platforms, as per
> >> > Ville's review comments.
> >> >
> >> > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
> >> >
> >> > Signed-off-by: Uma Shankar 
> >> > Acked-by: Jani Nikula 
> >> > Reviewed-by: Shashank Sharma 
> >> > Reviewed-by: Maarten Lankhorst 
> >> > ---
> >> >  drivers/gpu/drm/drm_atomic_uapi.c |  4 +++
> >> >  drivers/gpu/drm/drm_connector.c   | 75
> >+++
> >> >  include/drm/drm_connector.h   | 46 
> >> >  3 files changed, 125 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> > b/drivers/gpu/drm/drm_atomic_uapi.c
> >> > index 9a1f41a..9b5d44f 100644
> >> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> > @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
> >drm_connector *connector,
> >> >  return -EINVAL;
> >> >  }
> >> >  state->content_protection = val;
> >> > +} else if (property == connector->colorspace_property) {
> >> > +state->colorspace = val;
> >> >  } else if (property == config->writeback_fb_id_property) {
> >> >  struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
> >NULL, val);
> >> >  int ret = 
> >> > drm_atomic_set_writeback_fb_for_connector(state,
> >fb);
> >> > @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
> >drm_connector *connector,
> >> >  *val = state->picture_aspect_ratio;
> >> >  } else if (property == config->content_type_property) {
> >> >  *val 

RE: [Intel-gfx] [v10 3/3] drm/i915: Attach colorspace property and enable modeset

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Saturday, February 2, 2019 12:31 AM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst, Maarten ; dri-
>de...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v10 3/3] drm/i915: Attach colorspace property and
>enable modeset
>
>On Wed, Jan 30, 2019 at 06:24:26PM +0530, Uma Shankar wrote:
>> This patch attaches the colorspace connector property to the hdmi
>> connector. Based on colorspace change, modeset will be triggered to
>> switch to new colorspace.
>>
>> Based on colorspace property value create an infoframe with
>> appropriate colorspace. This can be used to send an infoframe packet
>> with proper colorspace value set which will help to enable wider color
>> gamut like BT2020 on sink.
>>
>> This patch attaches and enables HDMI colorspace, DP will be taken care
>> separately.
>>
>> v2: Merged the changes of creating infoframe as well to this patch as
>> per Maarten's suggestion.
>>
>> v3: Addressed review comments from Shashank. Separated HDMI and DP
>> colorspaces as suggested by Ville and Maarten.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard. Handle the
>> default case properly.
>>
>> v5: Merged the DP handling along with platform colorspace handling as
>> per Shashank's comments.
>>
>> v6: Reverted to old design of exposing all colorspaces to userspace as
>> per Ville's review comment
>>
>> v7: Fixed a checkpatch complaint, Addressed  Maarten' review comment,
>> updated the RB from Maarten and Jani's ack.
>>
>> Signed-off-by: Uma Shankar 
>> Acked-by: Jani Nikula 
>> Reviewed-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_atomic.c|  1 +
>>  drivers/gpu/drm/i915/intel_connector.c |  8 
>>  drivers/gpu/drm/i915/intel_drv.h   |  1 +
>>  drivers/gpu/drm/i915/intel_hdmi.c  | 25 +
>>  4 files changed, 35 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index 16263ad..a4bb906 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
>drm_connector *conn,
>>   */
>>  if (new_conn_state->force_audio != old_conn_state->force_audio ||
>>  new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb
>> ||
>> +new_conn_state->base.colorspace !=
>> +old_conn_state->base.colorspace ||
>>  new_conn_state->base.picture_aspect_ratio != old_conn_state-
>>base.picture_aspect_ratio ||
>>  new_conn_state->base.content_type != old_conn_state-
>>base.content_type ||
>>  new_conn_state->base.scaling_mode !=
>> old_conn_state->base.scaling_mode)
>> diff --git a/drivers/gpu/drm/i915/intel_connector.c
>> b/drivers/gpu/drm/i915/intel_connector.c
>> index ee16758..8352d0b 100644
>> --- a/drivers/gpu/drm/i915/intel_connector.c
>> +++ b/drivers/gpu/drm/i915/intel_connector.c
>> @@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector
>*connector,
>>  connector->dev->mode_config.aspect_ratio_property,
>>  DRM_MODE_PICTURE_ASPECT_NONE);
>>  }
>> +
>> +void
>> +intel_attach_colorspace_property(struct drm_connector *connector) {
>> +if (!drm_mode_create_colorspace_property(connector))
>> +drm_object_attach_property(>base,
>> +   connector->colorspace_property, 0); }
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index 85b913e..5178a9a 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1783,6 +1783,7 @@ int intel_connector_update_modes(struct
>> drm_connector *connector,  void
>> intel_attach_force_audio_property(struct drm_connector *connector);
>> void intel_attach_broadcast_rgb_property(struct drm_connector
>> *connector);  void intel_attach_aspect_ratio_property(struct
>> drm_connector *connector);
>> +void intel_attach_colorspace_property(struct drm_connector
>> +*connector);
>>
>>  /* intel_csr.c */
>>  void intel_csr_ucode_init(struct drm_i915_private *); diff --git
>> a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 97a98e1..5c5009d 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -498,6 +498,24 @@ static void intel_hdmi_set_avi_infoframe(struct
>intel_encoder *encoder,
>>  else
>>  frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>>
>> +if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
>> +/* Set ITU 709 as default for HDMI */
>> +frame.avi.colorimetry = DRM_MODE_COLORIMETRY_ITU_709;
>
>Default should map 

RE: [v10 2/3] drm: Add DP colorspace property

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Saturday, February 2, 2019 12:48 AM
>To: Shankar, Uma 
>Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
>; Lankhorst, Maarten ;
>dri-devel@lists.freedesktop.org
>Subject: Re: [v10 2/3] drm: Add DP colorspace property
>
>On Wed, Jan 30, 2019 at 06:24:25PM +0530, Uma Shankar wrote:
>> This patch adds a DP colorspace property, enabling userspace to switch
>> to various supported colorspaces.
>> This will help enable BT2020 along with other colorspaces.
>>
>> v2: Addressed Maarten and Ville's review comments. Enhanced
>> the colorspace enum to incorporate both HDMI and DP supported
>> colorspaces. Also, added a default option for colorspace.
>>
>> v3: Split the changes to have separate colorspace property for DP and
>> HDMI.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard.
>>
>> v5: Merged the DP handling along with platform colorspace handling as
>> per Shashank's comments.
>>
>> v6: Reverted to old design of exposing all colorspaces to userspace as
>> per Ville's review comment
>>
>> v7: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>>
>> Signed-off-by: Uma Shankar 
>> Acked-by: Jani Nikula 
>> Reviewed-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_connector.c | 31 +++
>>  1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index ed10dd9..b331be8 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -850,6 +850,29 @@ int drm_display_info_set_bus_formats(struct
>drm_display_info *info,
>>  { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },  };
>>
>> +static const struct drm_prop_enum_list dp_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>> +{ DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
>
>What's with the duplicated 601/709 values? I think in the HDMI verison you had
>only these ones here. Maybe we want to actually state explicitly that they are 
>for
>YCbCr, if only to be consistent with the
>BT2020 values.

Yeah they are for YCbCr, will add that detail to be clear.

>
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> +/* Colorimetry based on IEC 61966-2-5 */
>> +{ DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
>> +/* DP MSA Colorimetry */
>> +{ DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601, "YCBCR_ITU_601"
>},
>> +{ DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709, "YCBCR_ITU_709"
>},
>> +{ DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
>> +{ DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide
>Gamut" },
>> +{ DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" },
>> +{ DRM_MODE_DP_COLORIMETRY_DCI_P3, "DCI-P3" },
>> +{ DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE, "Custom
>Profile" },
>
>I don't think we want this last one since we don't implement anything that 
>could
>transmit the custom profile.
>
>The MSA bits are have "CEA RGB" which we probably want to keep hidden since it
>seems to be just a poorly specced limited range vs. full range knob, and we
>already have a mechanism for that. The Y-only and RAW I guess we can skip. Not
>sure anyone would ever have use for those.

Ok Sure, Will drop this.

Regards,
Uma Shankar
>
>> +};
>> +
>> +
>>  /**
>>   * DOC: standard connector properties
>>   *
>> @@ -1611,6 +1634,14 @@ int drm_mode_create_colorspace_property(struct
>drm_connector *connector)
>>
>   ARRAY_SIZE(hdmi_colorspaces));
>>  if (!prop)
>>  return -ENOMEM;
>> +} else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP
>||
>> +   connector->connector_type ==
>DRM_MODE_CONNECTOR_DisplayPort) {
>> +prop = drm_property_create_enum(dev,
>DRM_MODE_PROP_ENUM,
>> +"Colorspace", dp_colorspaces,
>> +ARRAY_SIZE(dp_colorspaces));
>> +
>> +if (!prop)
>> +return -ENOMEM;
>>  } else {
>>  DRM_DEBUG_KMS("Colorspace property not supported\n");
>>  return 0;
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Ville Syrjälä
>Intel

RE: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property

[Shankar, Uma]

>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Monday, February 4, 2019 8:55 PM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst, Maarten ; dri-
>de...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
>
>On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
>> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
>> > Create a new connector property to program colorspace to sink
>> > devices. Modern sink devices support more than 1 type of colorspace
>> > like 601, 709, BT2020 etc. This helps to switch based on content
>> > type which is to be displayed. The decision lies with compositors as
>> > to in which scenarios, a particular colorspace will be picked.
>> >
>> > This will be helpful mostly to switch to higher gamut colorspaces
>> > like BT2020 when the media content is encoded as BT2020. Thereby
>> > giving a good visual experience to users.
>> >
>> > The expectation from userspace is that it should parse the EDID and
>> > get supported colorspaces. Use this property and switch to the one
>> > supported. Sink supported colorspaces should be retrieved by
>> > userspace from EDID and driver will not explicitly expose them.
>> >
>> > Basically the expectation from userspace is:
>> >  - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>> >colorspace
>> >  - Set this new property to let the sink know what it
>> >converted the CRTC output to.
>> >
>> > v2: Addressed Maarten and Ville's review comments. Enhanced the
>> > colorspace enum to incorporate both HDMI and DP supported
>> > colorspaces. Also, added a default option for colorspace.
>> >
>> > v3: Removed Adobe references from enum definitions as per Ville,
>> > Hans Verkuil and Jonas Karlman suggestions. Changed Default to an
>> > unset state where driver will assign the colorspace is not chosen by
>> > user, suggested by Ville and Maarten. Addressed other misc review
>> > comments from Maarten. Split the changes to have separate colorspace
>> > property for DP and HDMI.
>> >
>> > v4: Addressed Chris and Ville's review comments, and created a
>> > common colorspace property for DP and HDMI, filtered the list based
>> > on the colorspaces supported by the respective protocol standard.
>> >
>> > v5: Made the property creation helper accept enum list based on
>> > platform capabilties as suggested by Shashank. Consolidated HDMI and
>> > DP property creation in the common helper.
>> >
>> > v6: Addressed Shashank's review comments.
>> >
>> > v7: Added defines instead of enum in uapi as per Brian Starkey's
>> > suggestion in order to go with string matching at userspace. Updated
>> > the commit message to add more details as well kernel docs.
>> >
>> > v8: Addressed Maarten's review comments.
>> >
>> > v9: Removed macro defines from uapi as per Brian Starkey and Daniel
>> > Stone's comments and moved to drm include file. Moved back to older
>> > design with exposing all HDMI colorspaces to userspace since
>> > infoframe capability is there even on legacy platforms, as per
>> > Ville's review comments.
>> >
>> > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>> >
>> > Signed-off-by: Uma Shankar 
>> > Acked-by: Jani Nikula 
>> > Reviewed-by: Shashank Sharma 
>> > Reviewed-by: Maarten Lankhorst 
>> > ---
>> >  drivers/gpu/drm/drm_atomic_uapi.c |  4 +++
>> >  drivers/gpu/drm/drm_connector.c   | 75
>+++
>> >  include/drm/drm_connector.h   | 46 
>> >  3 files changed, 125 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> > b/drivers/gpu/drm/drm_atomic_uapi.c
>> > index 9a1f41a..9b5d44f 100644
>> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> > @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> >return -EINVAL;
>> >}
>> >state->content_protection = val;
>> > +  } else if (property == connector->colorspace_property) {
>> > +  state->colorspace = val;
>> >} else if (property == config->writeback_fb_id_property) {
>> >struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
>NULL, val);
>> >int ret = drm_atomic_set_writeback_fb_for_connector(state,
>fb);
>> > @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> >*val = state->picture_aspect_ratio;
>> >} else if (property == config->content_type_property) {
>> >*val = state->content_type;
>> > +  } else if (property == connector->colorspace_property) {
>> > +  *val = state->colorspace;
>> >} else if (property == connector->scaling_mode_property) {
>> >*val = state->scaling_mode;
>> >} else if (property == connector->content_protection_property) {
>> > diff --git 

Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel

[Thierry Reding]

On Mon, Feb 04, 2019 at 10:27:09AM -0600, Rob Herring wrote:
> On Mon, Feb 4, 2019 at 2:24 AM Thierry Reding  
> wrote:
> >
> > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding  
> > > wrote:
> > > >
> > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > eDP panels usually have EDID EEPROM, so there's no need to define 
> > > > > panel
> > > > > width/height or any modes/timings in dts. But this panel still may 
> > > > > have
> > > > > regulator and/or backlight.
> > > > >
> > > > > Signed-off-by: Vasily Khoruzhick 
> > > > > ---
> > > > >  .../devicetree/bindings/display/panel/panel-edp.txt| 7 
> > > > > +++
> > > > >  1 file changed, 7 insertions(+)
> > > > >  create mode 100644 
> > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > >
> > > > Please don't try to make panels look more generic than they really are.
> > > > You're going to have to provide a compatible string for your device that
> > > > is more specific than "panel-edp". You claim that you don't need any
> > > > extra information that is panel specific, but you don't know that now.
> > > > We have in the past thought that we didn't need things like prepare
> > > > delay, but then we ran into situations where we did need them.
> > > >
> > > > Just do what everybody else does. Provide a specific compatible string
> > > > and match on that in the panel-simple driver. Even if you can read all
> > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > is faulty on some device.
> > >
> > > Pinebook used several 768p panels that have slightly different timings
> > > and recent batch uses 1080p panel.
> > >
> > > What panel descriptor should I use as fallback?
> >
> > You don't use panel descriptors as fallback. The simple-panel driver
> > will bind to a panel device and use the corresponding descriptor. If
> > your device tree contains the correct information, the descriptor is
> > correct for the panel you have.
> >
> > In other words you need to ensure that you have the correct panel in
> > device tree for the board that you're using. This is exactly the same
> > thing as for other devices.
> >
> > One way to to this is to have separate device trees for each variant
> > of the board that you want to support. Another variant may be to have
> > a common device tree and then have some early firmware update the DTB
> > with the correct panel information.
> 
> That can be a pain to manage especially if panels are swapped run to
> run with 2nd sources.
> 
> I think it is perfectly fine to have a generic-ish fallback as long as
> it is just that, a fallback. If the panel has quirks, then you'd
> better make sure the firmware is stuffing in the right compatibles or
> that you can update the firmware.

simple-panel would probably work if you stuck in some mostly compatible
string and provided a ddc-i2c-bus property in the device tree node. The
generic-ish fallback case could be implemented by providing a fallback
compatible string (we used to have "simple-panel", which I think would
still be adequate for this I suppose) and adding a dummy descriptor in
the driver, perhaps one with pre-defined delays that could be adjusted
to work for all cases, or they could just be 0. At least that way we'd
be explicitly documenting that we support this as a fallback.

I'm not sure how you'd want to enforce that people provide the right
compatible strings that way. Currently there's no way to make your panel
work without adding a panel driver, so people are forced to write the
DT bindings and a driver, or add support to an existing one. If we open
this backdoor, I suspect many people will just take the easy route and
rely on the fallback. And then what do we do when we get bug reports
about panels not working, or requiring some quirks. How do we go and
find out what the right compatible strings are for each board, or how to
fix things for something we don't have access to.

This all sounds like a Pandora's box to me.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108893] Slow redrawing of menu in Gothic 2 under wine

[bugzilla-daemon]

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

supercoolem...@seznam.cz changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108893] Slow redrawing of menu in Gothic 2 under wine

[bugzilla-daemon]

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

--- Comment #3 from supercoolem...@seznam.cz ---
This led me to another round of testing with LIGL_ALWAYS_SOFTWARE=0. Not so
surprisingly, this is also product of random chance, so this is after all
probably Wine bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/rockchip: Use drm_fbdev_generic_setup()

[Rob Herring]

On Mon, Feb 4, 2019 at 9:01 AM Rob Herring  wrote:
>
> On Sat, Feb 2, 2019 at 12:22 PM Noralf Trønnes  wrote:
> > Den 02.02.2019 18.07, skrev Rob Herring:
> > > Other than using a rockchip_gem_object directly, the Rockchip fbdev
> > > setup has nothing special and can be converted to use the generic fbdev
> > > emulation instead.
>
> [...]
>
> > > -static int rockchip_drm_fbdev_create(struct drm_fb_helper *helper,
> > > -  struct drm_fb_helper_surface_size 
> > > *sizes)
> > > -{
> > > - struct rockchip_drm_private *private = to_drm_private(helper);
> > > - struct drm_mode_fb_cmd2 mode_cmd = { 0 };
> > > - struct drm_device *dev = helper->dev;
> > > - struct rockchip_gem_object *rk_obj;
> > > - struct drm_framebuffer *fb;
> > > - unsigned int bytes_per_pixel;
> > > - unsigned long offset;
> > > - struct fb_info *fbi;
> > > - size_t size;
> > > - int ret;
> > > -
> > > - bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
> > > -
> > > - mode_cmd.width = sizes->surface_width;
> > > - mode_cmd.height = sizes->surface_height;
> > > - mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel;
> > > - mode_cmd.pixel_format = 
> > > drm_mode_legacy_fb_format(sizes->surface_bpp,
> > > - sizes->surface_depth);
> > > -
> > > - size = mode_cmd.pitches[0] * mode_cmd.height;
> > > -
> > > - rk_obj = rockchip_gem_create_object(dev, size, true);
> >
> > I don't think the generic emulation in it's current form will work for
> > rockchip. rockchip treats fbdev buffers and dumb buffers differently. If
> > it uses DMA buffers, then the dumb buffer can't get a virtual address.
>
> Yes, you are right. I tested the iommu case.
>
> > From rockchip_gem_alloc_dma():
> >
> > if (!alloc_kmap)
> > rk_obj->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
> >
> > From rockchip_gem_prime_vmap():
> >
> > if (rk_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> > return NULL;
> >
> > Maybe it's possible to vmap a buffer created using dma_alloc_attrs()
> > after the allocation?
>
> It should be possible I think as that is what
> drm_gem_cma_prime_import_sg_table_vmap() does. One problem though is
> you may already have a mapping because DMA_ATTR_NO_KERNEL_MAPPING is
> just a suggestion (only 32-bit ARM implements) and there's not a way
> to tell if you got a mapping or not. Maybe it's not all that important
> if there are 2 mappings because I think only fbcon needs a kernel
> mapping.

As another data point, exynos always uses DMA_ATTR_NO_KERNEL_MAPPING
and then vmap's its fbdev buffer.

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

[Bug 108893] Slow redrawing of menu in Gothic 2 under wine

[bugzilla-daemon]

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

--- Comment #2 from supercoolem...@seznam.cz ---
(In reply to supercoolemail from comment #1)
> Suprisingly, enabling GALLIUM_HUD="GPU-load;fps;cpu" workarounds this too
> and lowers the delay to HUD update step.

Ok, it does not. The delay just varies for some reason and multple tests
confirming HUD influence were just product of random chance.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel

[Rob Herring]

On Mon, Feb 4, 2019 at 10:11 AM Vasily Khoruzhick  wrote:
>
> On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding  
> wrote:
> > >
> > > Pinebook used several 768p panels that have slightly different timings
> > > and recent batch uses 1080p panel.
> > >
> > > What panel descriptor should I use as fallback?
> >
> > You don't use panel descriptors as fallback. The simple-panel driver
> > will bind to a panel device and use the corresponding descriptor. If
> > your device tree contains the correct information, the descriptor is
> > correct for the panel you have.
> >
> > In other words you need to ensure that you have the correct panel in
> > device tree for the board that you're using. This is exactly the same
> > thing as for other devices.
> >
> > One way to to this is to have separate device trees for each variant
> > of the board that you want to support. Another variant may be to have
> > a common device tree and then have some early firmware update the DTB
> > with the correct panel information.
>
> That defeats the purpose of using eDP panels. Panel can identify
> itself and report what timings it supports.

If you are confident that this works for all panels, then the firmware
can identify the right panel and update the DTB with the correct
information. If this doesn't work in the firmware, then it is not
going to work in the kernel either and you are SOL without specific
panel information in the DT.

> If we use separate DTBs then users will have to figure out what panel
> is installed in their hardware and use appropriate software image -
> that's something I'd like to avoid.

I think Thierry meant either way this is a firmware problem. If you
have a SKU per device and panel type, then the firmware just picks a
dtb among a set.

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

RE: [PATCH v10 38/40] drm/i915: Fix KBL HDCP2.2 encrypt status signalling

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 38/40] drm/i915: Fix KBL HDCP2.2 encrypt status signalling
>
>Implement the required WA sequence for KBL to fix the incorrect positioning of
>the window of oppurtunity and enc_en signalling.

Typo in opportunity.

>
>v2:
>  WA is moved into the toggle_signalling [Daniel]
>
>Signed-off-by: Ramalingam C 
>---
> drivers/gpu/drm/i915/intel_hdmi.c | 42
>+++
> 1 file changed, 42 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>b/drivers/gpu/drm/i915/intel_hdmi.c
>index 2c4bf6d0c39f..ae20288f7bbf 100644
>--- a/drivers/gpu/drm/i915/intel_hdmi.c
>+++ b/drivers/gpu/drm/i915/intel_hdmi.c
>@@ -1083,10 +1083,44 @@ int intel_hdmi_hdcp_read_v_prime_part(struct
>intel_digital_port *intel_dig_port,
>   return ret;
> }
>
Would be good to add a comment here as to what exactly is the WA and what
you are trying to do here.

>+static int kbl_repositioning_enc_en_signal(struct intel_connector
>+*connector) {
>+  struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct drm_crtc *crtc = connector->base.state->crtc;
>+  struct intel_crtc *intel_crtc = container_of(crtc,
>+   struct intel_crtc, base);
>+  u32 scanline;
>+  int ret;
>+
>+  for (;;) {
>+  scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
>+  if (scanline > 100 && scanline < 200)
>+  break;
>+  usleep_range(25, 50);
>+  }
>+
>+  ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, false);
>+  if (ret) {
>+  DRM_ERROR("Disable HDCP signalling failed (%d)\n", ret);
>+  return ret;
>+  }
>+  ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, true);
>+  if (ret) {
>+  DRM_ERROR("Enable HDCP signalling failed (%d)\n", ret);
>+  return ret;
>+  }
>+
>+  return 0;
>+}
>+
> static
> int intel_hdmi_hdcp_toggle_signalling(struct intel_digital_port 
> *intel_dig_port,
> bool enable)
> {
>+  struct intel_hdmi *hdmi = _dig_port->hdmi;
>+  struct intel_connector *connector = hdmi->attached_connector;
>+  struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   int ret;
>
>   if (!enable)
>@@ -1098,6 +1132,14 @@ int intel_hdmi_hdcp_toggle_signalling(struct
>intel_digital_port *intel_dig_port,
> enable ? "Enable" : "Disable", ret);
>   return ret;
>   }
>+
>+  /*
>+   * WA: To fix incorrect positioning of the window of
>+   * opportunity and enc_en signalling in KABYLAKE.
>+   */
>+  if (IS_KABYLAKE(dev_priv) && enable)
>+  return kbl_repositioning_enc_en_signal(connector);
>+
>   return 0;
> }
>
>--
>2.7.4

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

[Bug 108893] Slow redrawing of menu in Gothic 2 under wine

[bugzilla-daemon]

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

supercoolem...@seznam.cz changed:

   What|Removed |Added

Version|18.2|18.3

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108893] Slow redrawing of menu in Gothic 2 under wine

[bugzilla-daemon]

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

--- Comment #1 from supercoolem...@seznam.cz ---
Suprisingly, enabling GALLIUM_HUD="GPU-load;fps;cpu" workarounds this too and
lowers the delay to HUD update step.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering

[bugzilla-daemon]

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

--- Comment #15 from Clément Guérin (li...@protonmail.com) ---
Created attachment 280949
  --> https://bugzilla.kernel.org/attachment.cgi?id=280949=edit
dmesg drm.debug=4

Here's the dmesg output as requested. I'm running gnome-shell 3.30.2.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v10 36/40] misc/mei/hdcp: Component framework for I915 Interface

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 36/40] misc/mei/hdcp: Component framework for I915
>Interface
>
>Mei hdcp driver is designed as component slave for the I915 component master.
>
>v2: Rebased.
>v3:
>  Notifier chain is adopted for cldev state update [Tomas]
>v4:
>  Made static dummy functions as inline in mei_hdcp.h
>  API for polling client device status
>  IS_ENABLED used in header, for config status for mei_hdcp.
>v5:
>  Replacing the notifier with component framework. [Daniel]
>v6:
>  Rebased on the I915 comp master redesign.
>v7:
>  mei_hdcp_component_registered is made static [Uma]
>  Need for global static variable mei_cldev is removed.
>v8:
>  master comp is added to be matched with i915 subcomponent [daniel]
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

This is a new interface change and definitely a lot is changed from the time I 
reviewed.
You can drop my RB and I would suggest to go with Daniel and Tomas's feedback 
for the same.

>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 90
>+++-
> drivers/misc/mei/hdcp/mei_hdcp.h |  5 +++
> 2 files changed, 93 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index edfc70fb0617..be2ce12ca460 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -23,6 +23,7 @@
> #include 
> #include 
> #include 
>+#include 
> #include 
> #include 
> #include  @@ -692,8 +693,7 @@
>mei_close_hdcp_session(struct device *dev, struct hdcp_port_data *data)
>   return 0;
> }
>
>-static __attribute__((unused))
>-struct i915_hdcp_component_ops mei_hdcp_ops = {
>+static struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
>   .initiate_hdcp2_session = mei_initiate_hdcp2_session,
>   .verify_receiver_cert_prepare_km =
>mei_verify_receiver_cert_prepare_km,
>@@ -708,20 +708,106 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .close_hdcp_session = mei_close_hdcp_session,  };
>
>+static int mei_component_master_bind(struct device *dev) {
>+  struct mei_cl_device *cldev = to_mei_cl_device(dev);
>+  struct mei_hdcp_drv_data *drv_data = mei_cldev_get_drvdata(cldev);
>+  int ret;
>+
>+  dev_info(dev, "%s\n", __func__);
>+  drv_data->comp_master->ops = _hdcp_ops;
>+  drv_data->comp_master->mei_dev = dev;
>+  ret = component_bind_all(dev, drv_data->comp_master);
>+  if (ret < 0)
>+  return ret;
>+
>+  return 0;
>+}
>+
>+static void mei_component_master_unbind(struct device *dev) {
>+  struct mei_cl_device *cldev = to_mei_cl_device(dev);
>+  struct mei_hdcp_drv_data *drv_data = mei_cldev_get_drvdata(cldev);
>+
>+  dev_info(dev, "%s\n", __func__);
>+  component_unbind_all(dev, drv_data->comp_master); }
>+
>+static const struct component_master_ops mei_component_master_ops = {
>+  .bind = mei_component_master_bind,
>+  .unbind = mei_component_master_unbind, };
>+
>+static int mei_hdcp_component_match(struct device *dev, int subcomponent,
>+  void *data)
>+{
>+  return !strcmp(dev->driver->name, "i915") &&
>+ subcomponent == I915_COMPONENT_HDCP; }
>+
> static int mei_hdcp_probe(struct mei_cl_device *cldev,
> const struct mei_cl_device_id *id)  {
>+  struct mei_hdcp_drv_data *drv_data;
>   int ret;
>
>   ret = mei_cldev_enable(cldev);
>   if (ret < 0)
>   dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
>
>+  drv_data = kzalloc(sizeof(*drv_data), GFP_KERNEL);
>+  if (!drv_data) {
>+  ret = -ENOMEM;
>+  goto drv_data_exit;
>+  }
>+
>+  drv_data->comp_master = kzalloc(sizeof(*drv_data->comp_master),
>+  GFP_KERNEL);
>+  if (!drv_data->comp_master) {
>+  ret = -ENOMEM;
>+  goto comp_master_exit;
>+  }
>+
>+  drv_data->master_match = NULL;
>+  component_match_add_typed(>dev, _data->master_match,
>+mei_hdcp_component_match,
>+drv_data->comp_master);
>+  if (IS_ERR_OR_NULL(drv_data->master_match)) {
>+  ret = -ENOMEM;
>+  goto match_add_exit;
>+  }
>+
>+  mei_cldev_set_drvdata(cldev, drv_data);
>+  ret = component_master_add_with_match(>dev,
>+_component_master_ops,
>+drv_data->master_match);
>+  if (ret < 0) {
>+  dev_err(>dev, "Master comp add failed %d\n", ret);
>+  mei_cldev_set_drvdata(cldev, NULL);
>+  goto match_add_exit;
>+  }
>+
>+  return 0;
>+

Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel

[Rob Herring]

On Mon, Feb 4, 2019 at 2:24 AM Thierry Reding  wrote:
>
> On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding  
> > wrote:
> > >
> > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > width/height or any modes/timings in dts. But this panel still may have
> > > > regulator and/or backlight.
> > > >
> > > > Signed-off-by: Vasily Khoruzhick 
> > > > ---
> > > >  .../devicetree/bindings/display/panel/panel-edp.txt| 7 +++
> > > >  1 file changed, 7 insertions(+)
> > > >  create mode 100644 
> > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > >
> > > Please don't try to make panels look more generic than they really are.
> > > You're going to have to provide a compatible string for your device that
> > > is more specific than "panel-edp". You claim that you don't need any
> > > extra information that is panel specific, but you don't know that now.
> > > We have in the past thought that we didn't need things like prepare
> > > delay, but then we ran into situations where we did need them.
> > >
> > > Just do what everybody else does. Provide a specific compatible string
> > > and match on that in the panel-simple driver. Even if you can read all
> > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > is faulty on some device.
> >
> > Pinebook used several 768p panels that have slightly different timings
> > and recent batch uses 1080p panel.
> >
> > What panel descriptor should I use as fallback?
>
> You don't use panel descriptors as fallback. The simple-panel driver
> will bind to a panel device and use the corresponding descriptor. If
> your device tree contains the correct information, the descriptor is
> correct for the panel you have.
>
> In other words you need to ensure that you have the correct panel in
> device tree for the board that you're using. This is exactly the same
> thing as for other devices.
>
> One way to to this is to have separate device trees for each variant
> of the board that you want to support. Another variant may be to have
> a common device tree and then have some early firmware update the DTB
> with the correct panel information.

That can be a pain to manage especially if panels are swapped run to
run with 2nd sources.

I think it is perfectly fine to have a generic-ish fallback as long as
it is just that, a fallback. If the panel has quirks, then you'd
better make sure the firmware is stuffing in the right compatibles or
that you can update the firmware.

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

Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel

[Thierry Reding]

On Mon, Feb 04, 2019 at 08:11:05AM -0800, Vasily Khoruzhick wrote:
> On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding  
> wrote:
> > >
> > > Pinebook used several 768p panels that have slightly different timings
> > > and recent batch uses 1080p panel.
> > >
> > > What panel descriptor should I use as fallback?
> >
> > You don't use panel descriptors as fallback. The simple-panel driver
> > will bind to a panel device and use the corresponding descriptor. If
> > your device tree contains the correct information, the descriptor is
> > correct for the panel you have.
> >
> > In other words you need to ensure that you have the correct panel in
> > device tree for the board that you're using. This is exactly the same
> > thing as for other devices.
> >
> > One way to to this is to have separate device trees for each variant
> > of the board that you want to support. Another variant may be to have
> > a common device tree and then have some early firmware update the DTB
> > with the correct panel information.
> 
> That defeats the purpose of using eDP panels. Panel can identify
> itself and report what timings it supports.
> 
> If we use separate DTBs then users will have to figure out what panel
> is installed in their hardware and use appropriate software image -
> that's something I'd like to avoid.
> 
> I can add a descriptor for something like "pinebook eDP panel" if it
> works for you, but it won't have any display timings in it.

I'd like to point you to this:


http://sietch-tagr.blogspot.com/2016/04/display-panels-are-not-special.html

it addresses some of your questions. Hopefully that will also help you
understand that this isn't only about display timings.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel

[Thierry Reding]

On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding 
> > > > >  wrote:
> > > > > >
> > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define 
> > > > > > > panel
> > > > > > > width/height or any modes/timings in dts. But this panel still 
> > > > > > > may have
> > > > > > > regulator and/or backlight.
> > > > > > >
> > > > > > > Signed-off-by: Vasily Khoruzhick 
> > > > > > > ---
> > > > > > >  .../devicetree/bindings/display/panel/panel-edp.txt| 7 
> > > > > > > +++
> > > > > > >  1 file changed, 7 insertions(+)
> > > > > > >  create mode 100644 
> > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > >
> > > > > > Please don't try to make panels look more generic than they really 
> > > > > > are.
> > > > > > You're going to have to provide a compatible string for your device 
> > > > > > that
> > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > extra information that is panel specific, but you don't know that 
> > > > > > now.
> > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > delay, but then we ran into situations where we did need them.
> > > > > >
> > > > > > Just do what everybody else does. Provide a specific compatible 
> > > > > > string
> > > > > > and match on that in the panel-simple driver. Even if you can read 
> > > > > > all
> > > > > > the video timings from an EDID EEPROM, you can still provide a mode 
> > > > > > in
> > > > > > the panel descriptor to serve as a fallback if for example the 
> > > > > > EEPROM
> > > > > > is faulty on some device.
> > > > > 
> > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > and recent batch uses 1080p panel.
> > > > > 
> > > > > What panel descriptor should I use as fallback?
> > > > 
> > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > will bind to a panel device and use the corresponding descriptor. If
> > > > your device tree contains the correct information, the descriptor is
> > > > correct for the panel you have.
> > > > 
> > > > In other words you need to ensure that you have the correct panel in
> > > > device tree for the board that you're using. This is exactly the same
> > > > thing as for other devices.
> > > > 
> > > > One way to to this is to have separate device trees for each variant
> > > > of the board that you want to support. Another variant may be to have
> > > > a common device tree and then have some early firmware update the DTB
> > > > with the correct panel information.
> > > 
> > > This would defeat the point of edp, which is to standardize the mess of
> > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > infrastructure already (using the OUI), I think if there's something that
> > > doesn't work then we should quirk it there.
> > 
> > The problem is that while the attempt may have been to standardize, it
> > failed. It doesn't take into account any of the details such as timing
> > between things like powering up the display and enabling the backlight
> > or similar. I don't know how you'd want to "quirk" those kinds of
> > requirements because they are highly panel specific.
> 
> Hm right, we get these from some firmware tables (and mix them with the
> spec one, since some of the firmware values are nonsense). I don't even
> know whether we can read the timings over dp aux somehow (you can power up
> the panel with some pessimistic values to figure those out, and you only
> need dp aux to work, which is much simpler than the entire panel).
> 
> > > What does make sense though imo is if we try not to stuff the edp panel
> > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > also some integration awkwardness since with this panel you need to do dp
> > > aux/i2c transactions to get at the information (edid alone isn't good
> > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > takes both a DT node and the dp_aux controller would be much better,
> > > instead of trying to auto-match against a DT compatible string and load a
> > > panel driver which is almost all fake.
> > > 
> > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > can get hold of the dp_aux channel it needs.
> > 
> > We already do that. drm_dp_aux registers as an I2C 

RE: [PATCH v10 35/40] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 35/40] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
>
>Request the ME to terminate the HDCP2.2 session for a port.
>
>On Success, ME FW will mark the intel port as Deauthenticated and terminate the
>wired HDCP2.2 Tx session started due to the cmd
>WIRED_INITIATE_HDCP2_SESSION.
>
>v2: Rebased.
>v3:
>  cldev is passed as first parameter [Tomas]
>  Redundant comments and cast are removed [Tomas]
>v4:
>  %zd for ssize_t [Alexander]
>  %s/return -1/return -EIO [Alexander]
>  Style and typos fixed [Uma]
>v5:
>  Extra line is removed.
>v6:
>  Collected the Rb-ed by.
>  Rebased.
>v7:
>  Adjust to the new mei interface.
>  Fix for Kdoc.
>v8:
>  K-Doc addition.[Tomas]
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

Latest set looks ok. You can keep the RB.

>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 55
>+++-
> 1 file changed, 54 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 5303c729612b..edfc70fb0617 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -639,6 +639,59 @@ mei_enable_hdcp_authentication(struct device *dev,
>struct hdcp_port_data *data)
>   return 0;
> }
>
>+/**
>+ * mei_close_hdcp_session() - Close the Wired HDCP Tx session of ME FW per
>port.
>+ * This also disables the authenticated state of the port.
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int
>+mei_close_hdcp_session(struct device *dev, struct hdcp_port_data *data)
>+{
>+  struct wired_cmd_close_session_in session_close_in = { { 0 } };
>+  struct wired_cmd_close_session_out session_close_out = { { 0 } };
>+  struct mei_cl_device *cldev;
>+  ssize_t byte;
>+
>+  if (!dev || !data)
>+  return -EINVAL;
>+
>+  cldev = to_mei_cl_device(dev);
>+
>+  session_close_in.header.api_version = HDCP_API_VERSION;
>+  session_close_in.header.command_id = WIRED_CLOSE_SESSION;
>+  session_close_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+  session_close_in.header.buffer_len =
>+  WIRED_CMD_BUF_LEN_CLOSE_SESSION_IN;
>+
>+  session_close_in.port.integrated_port_type = data->port_type;
>+  session_close_in.port.physical_port =
>+(u8)GET_MEI_DDI_INDEX(data->port);
>+
>+  byte = mei_cldev_send(cldev, (u8 *)_close_in,
>+sizeof(session_close_in));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  byte = mei_cldev_recv(cldev, (u8 *)_close_out,
>+sizeof(session_close_out));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  if (session_close_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+  dev_dbg(dev, "Session Close Failed. status: 0x%X\n",
>+  session_close_out.header.status);
>+  return -EIO;
>+  }
>+
>+  return 0;
>+}
>+
> static __attribute__((unused))
> struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
>@@ -652,7 +705,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .repeater_check_flow_prepare_ack =
>mei_repeater_check_flow_prepare_ack,
>   .verify_mprime = mei_verify_mprime,
>   .enable_hdcp_authentication = mei_enable_hdcp_authentication,
>-  .close_hdcp_session = NULL,
>+  .close_hdcp_session = mei_close_hdcp_session,
> };
>
> static int mei_hdcp_probe(struct mei_cl_device *cldev,
>--
>2.7.4

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

RE: [PATCH v10 34/40] misc/mei/hdcp: Enabling the HDCP authentication

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 34/40] misc/mei/hdcp: Enabling the HDCP authentication
>
>Request to ME to configure a port as authenticated.
>
>On Success, ME FW will mark the port as authenticated and provides HDCP cipher
>with the encryption keys.
>
>Enabling the Authentication can be requested once all stages of
>HDCP2.2 authentication is completed by interacting with ME FW.
>
>Only after this stage, driver can enable the HDCP encryption for the port, 
>through
>HW registers.
>
>v2: Rebased.
>v3:
>  cldev is passed as first parameter [Tomas]
>  Redundant comments and cast are removed [Tomas]
>v4:
>  %zd for ssize_t [Alexander]
>  %s/return -1/return -EIO [Alexander]
>  Style and typos fixed [Uma]
>v5: Rebased.
>v6:
>  Collected the Rb-ed by.
>  Rebased.
>v7:
>  Adjust to the new mei interface.
>  Fix for Kdoc.
>v8:
>  K-Doc addition. [Tomas]
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

Latest set looks ok. You can keep the RB.

>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 54
>+++-
> 1 file changed, 53 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 91f7b08d1df1..5303c729612b 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -587,6 +587,58 @@ static int mei_verify_mprime(struct device *dev, struct
>hdcp_port_data *data,
>   return 0;
> }
>
>+/**
>+ * mei_enable_hdcp_authentication() - Mark a port as authenticated
>+through ME FW
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int
>+mei_enable_hdcp_authentication(struct device *dev, struct
>+hdcp_port_data *data) {
>+  struct wired_cmd_enable_auth_in enable_auth_in = { { 0 } };
>+  struct wired_cmd_enable_auth_out enable_auth_out = { { 0 } };
>+  struct mei_cl_device *cldev;
>+  ssize_t byte;
>+
>+  if (!dev || !data)
>+  return -EINVAL;
>+
>+  cldev = to_mei_cl_device(dev);
>+
>+  enable_auth_in.header.api_version = HDCP_API_VERSION;
>+  enable_auth_in.header.command_id = WIRED_ENABLE_AUTH;
>+  enable_auth_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+  enable_auth_in.header.buffer_len =
>WIRED_CMD_BUF_LEN_ENABLE_AUTH_IN;
>+
>+  enable_auth_in.port.integrated_port_type = data->port_type;
>+  enable_auth_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data-
>>port);
>+  enable_auth_in.stream_type = data->streams[0].stream_type;
>+
>+  byte = mei_cldev_send(cldev, (u8 *)_auth_in,
>+sizeof(enable_auth_in));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  byte = mei_cldev_recv(cldev, (u8 *)_auth_out,
>+sizeof(enable_auth_out));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  if (enable_auth_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+  dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
>+  WIRED_ENABLE_AUTH,
>enable_auth_out.header.status);
>+  return -EIO;
>+  }
>+
>+  return 0;
>+}
>+
> static __attribute__((unused))
> struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
>@@ -599,7 +651,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .get_session_key = mei_get_session_key,
>   .repeater_check_flow_prepare_ack =
>mei_repeater_check_flow_prepare_ack,
>   .verify_mprime = mei_verify_mprime,
>-  .enable_hdcp_authentication = NULL,
>+  .enable_hdcp_authentication = mei_enable_hdcp_authentication,
>   .close_hdcp_session = NULL,
> };
>
>--
>2.7.4

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

RE: [PATCH v10 33/40] misc/mei/hdcp: Verify M_prime

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 33/40] misc/mei/hdcp: Verify M_prime
>
>Request to ME to verify the M_Prime received from the HDCP sink.
>
>ME FW will calculate the M and compare with M_prime received as part of
>RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg.
>
>On successful completion of this stage, downstream propagation of the stream
>management info is completed.
>
>v2: Rebased.
>v3:
>  cldev is passed as first parameter [Tomas]
>  Redundant comments and cast are removed [Tomas]
>v4:
>  %zd for ssize_t [Alexander]
>  %s/return -1/return -EIO [Alexander]
>  endianness conversion func is moved to drm_hdcp.h [Uma]
>v5: Rebased.
>v6:
>  Collected the Rb-ed by.
>  Rebasing.
>v7:
>  Adjust to the new mei interface.
>  Fix for Kdoc.
>v8:
>  K-Doc addition. [Tomas]
>  drm_hdcp2_u32_to_seq_num() is used for u32 to seq_num.
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

Latest set looks ok. You can keep the RB.

>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 66
>+++-
> 1 file changed, 65 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index c157c18371b4..91f7b08d1df1 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -523,6 +523,70 @@ mei_repeater_check_flow_prepare_ack(struct device
>*dev,
>   return 0;
> }
>
>+/**
>+ * mei_verify_mprime() - Verify mprime.
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ * @stream_ready: RepeaterAuth_Stream_Ready msg for ME FW verification.
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int mei_verify_mprime(struct device *dev, struct hdcp_port_data *data,
>+   struct hdcp2_rep_stream_ready *stream_ready) {
>+  struct wired_cmd_repeater_auth_stream_req_in
>+  verify_mprime_in = { { 0 } };
>+  struct wired_cmd_repeater_auth_stream_req_out
>+  verify_mprime_out = { { 0 } };
>+  struct mei_cl_device *cldev;
>+  ssize_t byte;
>+
>+  if (!dev || !stream_ready || !data)
>+  return -EINVAL;
>+
>+  cldev = to_mei_cl_device(dev);
>+
>+  verify_mprime_in.header.api_version = HDCP_API_VERSION;
>+  verify_mprime_in.header.command_id =
>WIRED_REPEATER_AUTH_STREAM_REQ;
>+  verify_mprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+  verify_mprime_in.header.buffer_len =
>+
>   WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN;
>+
>+  verify_mprime_in.port.integrated_port_type = data->port_type;
>+  verify_mprime_in.port.physical_port =
>+(u8)GET_MEI_DDI_INDEX(data->port);
>+
>+  memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
>+ HDCP_2_2_MPRIME_LEN);
>+  drm_hdcp2_u32_to_seq_num(verify_mprime_in.seq_num_m, data-
>>seq_num_m);
>+  memcpy(verify_mprime_in.streams, data->streams,
>+ (data->k * sizeof(struct hdcp2_streamid_type)));
>+
>+  verify_mprime_in.k = __swab16(data->k);
>+
>+  byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
>+sizeof(verify_mprime_in));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  byte = mei_cldev_recv(cldev, (u8 *)_mprime_out,
>+sizeof(verify_mprime_out));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  if (verify_mprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+  dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
>+  WIRED_REPEATER_AUTH_STREAM_REQ,
>+  verify_mprime_out.header.status);
>+  return -EIO;
>+  }
>+
>+  return 0;
>+}
>+
> static __attribute__((unused))
> struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
>@@ -534,7 +598,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .verify_lprime = mei_verify_lprime,
>   .get_session_key = mei_get_session_key,
>   .repeater_check_flow_prepare_ack =
>mei_repeater_check_flow_prepare_ack,
>-  .verify_mprime = NULL,
>+  .verify_mprime = mei_verify_mprime,
>   .enable_hdcp_authentication = NULL,
>   .close_hdcp_session = NULL,
> };
>--
>2.7.4

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

RE: [PATCH v10 32/40] misc/mei/hdcp: Repeater topology verification and ack

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 32/40] misc/mei/hdcp: Repeater topology verification and
>ack
>
>Request ME to verify the downstream topology information received.
>
>ME FW will validate the Repeaters receiver id list and downstream topology.
>
>On Success ME FW will provide the Least Significant 128bits of VPrime, which
>forms the repeater ack.
>
>v2: Rebased.
>v3:
>  cldev is passed as first parameter [Tomas]
>  Redundant comments and cast are removed [Tomas]
>v4:
>  %zd for ssize_t [Alexander]
>  %s/return -1/return -EIO [Alexander]
>  Style and typos fixed [Uma]
>v5: Rebased.
>v6: Rebasing.
>v7:
>  Adjust to the new mei interface.
>  Fix for Kdoc.
>v8:
>  K-Doc addition. [Tomas]
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

Latest set looks ok. You can keep the RB.

>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 76
>+++-
> 1 file changed, 75 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 2be7b6b949c2..c157c18371b4 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -449,6 +449,80 @@ static int mei_get_session_key(struct device *dev,
>struct hdcp_port_data *data,
>   return 0;
> }
>
>+/**
>+ * mei_repeater_check_flow_prepare_ack() - Validate the Downstream
>+topology
>+ * and prepare rep_ack.
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ * @rep_topology: Receiver ID List to be validated
>+ * @rep_send_ack : repeater ack from ME FW.
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int
>+mei_repeater_check_flow_prepare_ack(struct device *dev,
>+  struct hdcp_port_data *data,
>+  struct hdcp2_rep_send_receiverid_list
>+  *rep_topology,
>+  struct hdcp2_rep_send_ack *rep_send_ack) {
>+  struct wired_cmd_verify_repeater_in verify_repeater_in = { { 0 } };
>+  struct wired_cmd_verify_repeater_out verify_repeater_out = { { 0 } };
>+  struct mei_cl_device *cldev;
>+  ssize_t byte;
>+
>+  if (!dev || !rep_topology || !rep_send_ack || !data)
>+  return -EINVAL;
>+
>+  cldev = to_mei_cl_device(dev);
>+
>+  verify_repeater_in.header.api_version = HDCP_API_VERSION;
>+  verify_repeater_in.header.command_id = WIRED_VERIFY_REPEATER;
>+  verify_repeater_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+  verify_repeater_in.header.buffer_len =
>+
>   WIRED_CMD_BUF_LEN_VERIFY_REPEATER_IN;
>+
>+  verify_repeater_in.port.integrated_port_type = data->port_type;
>+  verify_repeater_in.port.physical_port =
>+  (u8)GET_MEI_DDI_INDEX(data->port);
>+
>+  memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
>+ HDCP_2_2_RXINFO_LEN);
>+  memcpy(verify_repeater_in.seq_num_v, rep_topology->seq_num_v,
>+ HDCP_2_2_SEQ_NUM_LEN);
>+  memcpy(verify_repeater_in.v_prime, rep_topology->v_prime,
>+ HDCP_2_2_V_PRIME_HALF_LEN);
>+  memcpy(verify_repeater_in.receiver_ids, rep_topology->receiver_ids,
>+ HDCP_2_2_RECEIVER_IDS_MAX_LEN);
>+
>+  byte = mei_cldev_send(cldev, (u8 *)_repeater_in,
>+sizeof(verify_repeater_in));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  byte = mei_cldev_recv(cldev, (u8 *)_repeater_out,
>+sizeof(verify_repeater_out));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  if (verify_repeater_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+  dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
>+  WIRED_VERIFY_REPEATER,
>+  verify_repeater_out.header.status);
>+  return -EIO;
>+  }
>+
>+  memcpy(rep_send_ack->v, verify_repeater_out.v,
>+ HDCP_2_2_V_PRIME_HALF_LEN);
>+  rep_send_ack->msg_id = HDCP_2_2_REP_SEND_ACK;
>+
>+  return 0;
>+}
>+
> static __attribute__((unused))
> struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
>@@ -459,7 +533,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .initiate_locality_check = mei_initiate_locality_check,
>   .verify_lprime = mei_verify_lprime,
>   .get_session_key = mei_get_session_key,
>-  .repeater_check_flow_prepare_ack = NULL,
>+  .repeater_check_flow_prepare_ack =
>+mei_repeater_check_flow_prepare_ack,
>   .verify_mprime = NULL,
>  

RE: [PATCH v10 31/40] misc/mei/hdcp: Prepare Session Key

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 31/40] misc/mei/hdcp: Prepare Session Key
>
>Request to ME to prepare the encrypted session key.
>
>On Success, ME provides Encrypted session key. Function populates the HDCP2.2
>authentication msg SKE_Send_Eks.
>
>v2: Rebased.
>v3:
>  cldev is passed as first parameter [Tomas]
>  Redundant comments and cast are removed [Tomas]
>v4:
>  %zd for ssize_t [Alexander]
>  %s/return -1/return -EIO [Alexander]
>  Style fixed [Uma]
>v5: Rebased.
>v6:
>  Collected the Rb-ed by.
>  Rebasing.
>v7:
>  Adjust to the new mei interface.
>  Fix for Kdoc.
>v8:
>  K-Doc addition. [Tomas]
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

Latest set looks ok. You can keep the RB.

>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 58
>+++-
> 1 file changed, 57 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 3d7767d944dc..2be7b6b949c2 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -393,6 +393,62 @@ static int mei_verify_lprime(struct device *dev, struct
>hdcp_port_data *data,
>   return 0;
> }
>
>+/**
>+ * mei_get_session_key() - Prepare SKE_Send_Eks.
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ * @ske_data: SKE_Send_Eks msg output from ME FW.
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int mei_get_session_key(struct device *dev, struct hdcp_port_data 
>*data,
>+ struct hdcp2_ske_send_eks *ske_data) {
>+  struct wired_cmd_get_session_key_in get_skey_in = { { 0 } };
>+  struct wired_cmd_get_session_key_out get_skey_out = { { 0 } };
>+  struct mei_cl_device *cldev;
>+  ssize_t byte;
>+
>+  if (!dev || !data || !ske_data)
>+  return -EINVAL;
>+
>+  cldev = to_mei_cl_device(dev);
>+
>+  get_skey_in.header.api_version = HDCP_API_VERSION;
>+  get_skey_in.header.command_id = WIRED_GET_SESSION_KEY;
>+  get_skey_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+  get_skey_in.header.buffer_len =
>WIRED_CMD_BUF_LEN_GET_SESSION_KEY_IN;
>+
>+  get_skey_in.port.integrated_port_type = data->port_type;
>+  get_skey_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
>+
>+  byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  byte = mei_cldev_recv(cldev, (u8 *)_skey_out,
>+sizeof(get_skey_out));
>+
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  if (get_skey_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+  dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
>+  WIRED_GET_SESSION_KEY,
>get_skey_out.header.status);
>+  return -EIO;
>+  }
>+
>+  ske_data->msg_id = HDCP_2_2_SKE_SEND_EKS;
>+  memcpy(ske_data->e_dkey_ks, get_skey_out.e_dkey_ks,
>+ HDCP_2_2_E_DKEY_KS_LEN);
>+  memcpy(ske_data->riv, get_skey_out.r_iv, HDCP_2_2_RIV_LEN);
>+
>+  return 0;
>+}
>+
> static __attribute__((unused))
> struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
>@@ -402,7 +458,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .store_pairing_info = mei_store_pairing_info,
>   .initiate_locality_check = mei_initiate_locality_check,
>   .verify_lprime = mei_verify_lprime,
>-  .get_session_key = NULL,
>+  .get_session_key = mei_get_session_key,
>   .repeater_check_flow_prepare_ack = NULL,
>   .verify_mprime = NULL,
>   .enable_hdcp_authentication = NULL,
>--
>2.7.4

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

RE: [PATCH v10 30/40] misc/mei/hdcp: Verify L_prime

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 30/40] misc/mei/hdcp: Verify L_prime
>
>Request to ME to verify the LPrime received from HDCP sink.
>
>On Success, ME FW will verify the received Lprime by calculating and comparing
>with L.
>
>This represents the completion of Locality Check.
>
>v2: Rebased.
>v3:
>  cldev is passed as first parameter [Tomas]
>  Redundant comments and cast are removed [Tomas]
>v4:
>  %zd for ssize_t [Alexander]
>  %s/return -1/return -EIO [Alexander]
>  Style fixed [Uma]
>v5: Rebased.
>v6:
>  Collected the Rb-ed by.
>  Rebasing.
>v7:
>  Adjust to the new mei interface.
>  Fix for Kdoc.
>v8:
>  K-Doc addition. [Tomas]
>  memcpy for const length.
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

Latest set looks ok. You can keep the RB.

>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 59
>+++-
> 1 file changed, 58 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 412a33e29d7d..3d7767d944dc 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -336,6 +336,63 @@ mei_initiate_locality_check(struct device *dev, struct
>hdcp_port_data *data,
>   return 0;
> }
>
>+/**
>+ * mei_verify_lprime() - Verify lprime.
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ * @rx_lprime: LC_Send_L_prime msg for ME FW verification
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int mei_verify_lprime(struct device *dev, struct hdcp_port_data *data,
>+   struct hdcp2_lc_send_lprime *rx_lprime) {
>+  struct wired_cmd_validate_locality_in verify_lprime_in = { { 0 } };
>+  struct wired_cmd_validate_locality_out verify_lprime_out = { { 0 } };
>+  struct mei_cl_device *cldev;
>+  ssize_t byte;
>+
>+  if (!dev || !data || !rx_lprime)
>+  return -EINVAL;
>+
>+  cldev = to_mei_cl_device(dev);
>+
>+  verify_lprime_in.header.api_version = HDCP_API_VERSION;
>+  verify_lprime_in.header.command_id = WIRED_VALIDATE_LOCALITY;
>+  verify_lprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+  verify_lprime_in.header.buffer_len =
>+
>   WIRED_CMD_BUF_LEN_VALIDATE_LOCALITY_IN;
>+
>+  verify_lprime_in.port.integrated_port_type = data->port_type;
>+  verify_lprime_in.port.physical_port =
>+(u8)GET_MEI_DDI_INDEX(data->port);
>+
>+  memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
>+ HDCP_2_2_L_PRIME_LEN);
>+
>+  byte = mei_cldev_send(cldev, (u8 *)_lprime_in,
>+sizeof(verify_lprime_in));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  byte = mei_cldev_recv(cldev, (u8 *)_lprime_out,
>+sizeof(verify_lprime_out));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  if (verify_lprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+  dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
>+  WIRED_VALIDATE_LOCALITY,
>+  verify_lprime_out.header.status);
>+  return -EIO;
>+  }
>+
>+  return 0;
>+}
>+
> static __attribute__((unused))
> struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
>@@ -344,7 +401,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .verify_hprime = mei_verify_hprime,
>   .store_pairing_info = mei_store_pairing_info,
>   .initiate_locality_check = mei_initiate_locality_check,
>-  .verify_lprime = NULL,
>+  .verify_lprime = mei_verify_lprime,
>   .get_session_key = NULL,
>   .repeater_check_flow_prepare_ack = NULL,
>   .verify_mprime = NULL,
>--
>2.7.4

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

RE: [PATCH v10 29/40] misc/mei/hdcp: Initiate Locality check

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 29/40] misc/mei/hdcp: Initiate Locality check
>
>Requests ME to start the second stage of HDCP2.2 authentication, called 
>Locality
>Check.
>
>On Success, ME FW will provide LC_Init message to send to hdcp sink.
>
>v2: Rebased.
>v3:
>  cldev is passed as first parameter [Tomas]
>  Redundant comments and cast are removed [Tomas]
>v4:
>  %zd used for ssize_t [Alexander]
>  %s/return -1/return -EIO [Alexander]
>  Style fixed [Uma]
>v5: Rebased.
>v6:
>  Collected the Rb-ed by.
>  Rebasing.
>v7:
>  Adjust to the new mei interface.
>  Fix for Kdoc.
>v8:
>  K-Doc addition. [Tomas]
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

Latest set looks ok. You can keep the RB.

>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 56
>+++-
> 1 file changed, 55 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index e8396c723ab0..412a33e29d7d 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -282,6 +282,60 @@ mei_store_pairing_info(struct device *dev, struct
>hdcp_port_data *data,
>   return 0;
> }
>
>+/**
>+ * mei_initiate_locality_check() - Prepare LC_Init
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ * @lc_init_data: LC_Init msg output
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int
>+mei_initiate_locality_check(struct device *dev, struct hdcp_port_data *data,
>+  struct hdcp2_lc_init *lc_init_data) {
>+  struct wired_cmd_init_locality_check_in lc_init_in = { { 0 } };
>+  struct wired_cmd_init_locality_check_out lc_init_out = { { 0 } };
>+  struct mei_cl_device *cldev;
>+  ssize_t byte;
>+
>+  if (!dev || !data || !lc_init_data)
>+  return -EINVAL;
>+
>+  cldev = to_mei_cl_device(dev);
>+
>+  lc_init_in.header.api_version = HDCP_API_VERSION;
>+  lc_init_in.header.command_id = WIRED_INIT_LOCALITY_CHECK;
>+  lc_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+  lc_init_in.header.buffer_len =
>+WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
>+
>+  lc_init_in.port.integrated_port_type = data->port_type;
>+  lc_init_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
>+
>+  byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  byte = mei_cldev_recv(cldev, (u8 *)_init_out, sizeof(lc_init_out));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  if (lc_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+  dev_dbg(dev, "ME cmd 0x%08X Failed. status: 0x%X\n",
>+  WIRED_INIT_LOCALITY_CHECK,
>lc_init_out.header.status);
>+  return -EIO;
>+  }
>+
>+  lc_init_data->msg_id = HDCP_2_2_LC_INIT;
>+  memcpy(lc_init_data->r_n, lc_init_out.r_n, HDCP_2_2_RN_LEN);
>+
>+  return 0;
>+}
>+
> static __attribute__((unused))
> struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
>@@ -289,7 +343,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .verify_receiver_cert_prepare_km =
>mei_verify_receiver_cert_prepare_km,
>   .verify_hprime = mei_verify_hprime,
>   .store_pairing_info = mei_store_pairing_info,
>-  .initiate_locality_check = NULL,
>+  .initiate_locality_check = mei_initiate_locality_check,
>   .verify_lprime = NULL,
>   .get_session_key = NULL,
>   .repeater_check_flow_prepare_ack = NULL,
>--
>2.7.4

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

[PATCH v1 3/6] drm/msm/gpu: Attach to the GPU GX power domain

[Jordan Crouse]

99.999% of the time during normal operation the GMU is responsible
for power and clock control on the GX domain and the CPU remains
blissfully unaware. However, there is one situation where the CPU
needs to get involved:

The power sequencing rules dictate that the GX needs to be turned
off before the CX so that the CX can be turned on before the GX
during power up. During normal operation when the CPU is taking
down the CX domain a stop command is sent to the GMU which turns
off the GX domain and then the CPU handles the CX domain.

But if the GMU happened to be unresponsive while the GX domain was
left then the CPU will need to step in and turn off the GX domain
before resetting the CX and rebooting the GMU. This unfortunately
means that the CPU needs to be marginally aware of the GX domain
even though it is expected to usually keep its hands off.

To support this we create a semi-disabled GX power domain that
does nothing to the hardware on power up but tries to shut it
down normally on power down. In this method the reference counting
is correct and we can step in with the pm_runtime_put() at the right
time during the failure path.

This patch sets up the connection to the GX power domain and does
the magic to "enable" and disable it at the right points.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 41 ++-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h |  2 ++
 2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index f1baf64f..a527c50 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -2,6 +2,7 @@
 /* Copyright (c) 2017-2018 The Linux Foundation. All rights reserved. */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -671,6 +672,16 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
gmu_poll_timeout(gmu, REG_A6XX_RSCC_TCS3_DRV0_STATUS, val,
(val & 1), 100, 1000);
 
+   /*
+* Depending on the state of the GMU at this point the GX domain might
+* have been left on. Hardware sequencing rules state that the GX has to
+* be turned off before the CX domain so this is that one time that
+* that calling pm_runtime_put_sync() is expected to do something useful
+* (turn off the headswitch)
+*/
+   if (!IS_ERR(gmu->gxpd))
+   pm_runtime_put_sync(gmu->gxpd);
+
/* Disable the resources */
clk_bulk_disable_unprepare(gmu->nr_clocks, gmu->clocks);
pm_runtime_put_sync(gmu->dev);
@@ -732,6 +743,14 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
/* Set the GPU to the highest power frequency */
__a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
 
+   /*
+* "enable" the GX power domain which won't actually do anything but it
+* will make sure that the refcounting is correct in case we need to
+* bring down the GX after a GMU failure
+*/
+   if (!IS_ERR(gmu->gxpd))
+   pm_runtime_get(gmu->gxpd);
+
 out:
/* Make sure to turn off the boot OOB request on error */
if (ret)
@@ -803,6 +822,14 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
/* Tell RPMh to power off the GPU */
a6xx_rpmh_stop(gmu);
 
+   /*
+* Mark the GPU power domain as off. During the shutdown process the GMU
+* should actually turn off the power so this is really just a
+* houskeeping step
+*/
+   if (!IS_ERR(gmu->gxpd))
+   pm_runtime_put_sync(gmu->gxpd);
+
clk_bulk_disable_unprepare(gmu->nr_clocks, gmu->clocks);
 
pm_runtime_put_sync(gmu->dev);
@@ -1172,9 +1199,15 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
if (IS_ERR_OR_NULL(gmu->mmio))
return;
 
-   pm_runtime_disable(gmu->dev);
a6xx_gmu_stop(a6xx_gpu);
 
+   pm_runtime_disable(gmu->dev);
+
+   if (!IS_ERR(gmu->gxpd)) {
+   pm_runtime_disable(gmu->gxpd);
+   dev_pm_domain_detach(gmu->gxpd, false);
+   }
+
a6xx_gmu_irq_disable(gmu);
a6xx_gmu_memory_free(gmu, gmu->hfi);
 
@@ -1233,6 +1266,12 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct 
device_node *node)
if (gmu->hfi_irq < 0 || gmu->gmu_irq < 0)
goto err;
 
+   /*
+* Get a link to the GX power domain to reset the GPU in case of GMU
+* crash
+*/
+   gmu->gxpd = dev_pm_domain_attach_by_name(gmu->dev, "gx");
+
/* Get the power levels for the GMU and GPU */
a6xx_gmu_pwrlevels_probe(gmu);
 
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 8081083..078d418 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -55,6 +55,8 @@ struct a6xx_gmu {
struct iommu_domain *domain;
u64 uncached_iova_base;
 
+   struct 

[PATCH v1 6/6] drm/msm/a6xx: Remove an unused struct member

[Jordan Crouse]

The HFI tasklet was removed in df0dff1 ("drm/msm/a6xx: Poll for HFI
responses") but the tasklet_struct was accidentally left behind.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index c5b1887..bedd8e6 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -75,7 +75,6 @@ struct a6xx_gmu {
 
struct a6xx_hfi_queue queues[2];
 
-   struct tasklet_struct hfi_tasklet;
bool hung;
 };
 
-- 
2.7.4

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

[PATCH v1 2/6] dt-bindings: drm/msm/a6xx: Add GX power-domain for GMU bindings

[Jordan Crouse]

The GMU should have two power domains defined: "cx" and "gx". "cx" is the
actual power domain for the device and "gx" will be attached at runtime
to manage reference counting on the GPU device in case of a GMU crash.

Signed-off-by: Jordan Crouse 
---

 Documentation/devicetree/bindings/display/msm/gmu.txt | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
b/Documentation/devicetree/bindings/display/msm/gmu.txt
index 3439b38..90af5b0 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -24,7 +24,10 @@ Required properties:
* "cxo"
* "axi"
* "mnoc"
-- power-domains: should be <_gpucc GPU_CX_GDSC>
+- power-domains: should be:
+   <_gpucc GPU_CX_GDSC>
+   <_gpucc GPU_GX_GDSC>
+- power-domain-names: Matching names for the power domains
 - iommus: phandle to the adreno iommu
 - operating-points-v2: phandle to the OPP operating points
 
@@ -51,7 +54,10 @@ Example:
< GCC_GPU_MEMNOC_GFX_CLK>;
clock-names = "gmu", "cxo", "axi", "memnoc";
 
-   power-domains = < GPU_CX_GDSC>;
+   power-domains = < GPU_CX_GDSC>,
+   < GPU_GX_GDSC>;
+   power-domain-names = "cx", "gx";
+
iommus = <_smmu 5>;
 
operating-points-v2 = <_opp_table>;
-- 
2.7.4

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

[PATCH v1 1/6] drm/msm/a6xx: Remove unwanted regulator code

[Jordan Crouse]

The GMU code currently has some misguided code to try to work around
a hardware quirk that requires the power domains on the GPU be
collapsed in a certain order. Upcoming patches will do this the
right way so get rid of the unused and unwanted regulator
code.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 4 
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 --
 2 files changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index ce1b3cc..f1baf64f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -671,9 +671,6 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
gmu_poll_timeout(gmu, REG_A6XX_RSCC_TCS3_DRV0_STATUS, val,
(val & 1), 100, 1000);
 
-   /* Force off the GX GSDC */
-   regulator_force_disable(gmu->gx);
-
/* Disable the resources */
clk_bulk_disable_unprepare(gmu->nr_clocks, gmu->clocks);
pm_runtime_put_sync(gmu->dev);
@@ -1203,7 +1200,6 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct 
device_node *node)
gmu->idle_level = GMU_IDLE_STATE_ACTIVE;
 
pm_runtime_enable(gmu->dev);
-   gmu->gx = devm_regulator_get(gmu->dev, "vdd");
 
/* Get the list of clocks */
ret = a6xx_gmu_clocks_probe(gmu);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index c721d91..8081083 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -52,8 +52,6 @@ struct a6xx_gmu {
int hfi_irq;
int gmu_irq;
 
-   struct regulator *gx;
-
struct iommu_domain *domain;
u64 uncached_iova_base;
 
-- 
2.7.4

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

[PATCH v1 0/6] drm/msm: Improved a6xx GMU reset

[Jordan Crouse]

This is a stack of changes for 5.1 (if I'm not already too late). The bulk of
the changes implement a better GMU reset sequence using the new gpucc power
domain added in 5.0. If a GMU fault occurs during runtime we try to do a
standard GPU recovery and if the fault happens during GMU start then try to
fail somewhat gracefully than BUG_ON.

There will be a DT change to go along with this, but we can send that along
after the core code is merged. The downside for not having the domain
properly listed is that the runtime reset sequence probably won't work which
is no worse than it is today.

Jordan Crouse (6):
  drm/msm/a6xx: Remove unwanted regulator code
  dt-bindings: drm/msm/a6xx: Add GX power-domain for GMU bindings
  drm/msm/gpu: Attach to the GPU GX power domain
  drm/msm/a6xx: Make GMU reset useful
  msm/drm/a6xx: Turn off the GMU if resume fails
  drm/msm/a6xx: Remove an unused struct member

 .../devicetree/bindings/display/msm/gmu.txt|  10 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 200 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h  |   9 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  20 +--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   3 +-
 drivers/gpu/drm/msm/adreno/adreno_device.c |   1 +
 6 files changed, 144 insertions(+), 99 deletions(-)

-- 
2.7.4

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

[PATCH v1 4/6] drm/msm/a6xx: Make GMU reset useful

[Jordan Crouse]

Now that the GX domain is sorted we can wire up a working GMU reset.
IF a GMU hang was detected then try to forcefully shut down the GMU
in the power down sequence which should ensure that it can recover
normally on the next power up.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 109 --
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h |   4 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c |   2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h |   3 +-
 4 files changed, 55 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index a527c50..e16d55d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -9,6 +9,24 @@
 #include "a6xx_gpu.h"
 #include "a6xx_gmu.xml.h"
 
+static void a6xx_gmu_fault(struct a6xx_gmu *gmu)
+{
+   struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
+   struct adreno_gpu *adreno_gpu = _gpu->base;
+   struct msm_gpu *gpu = _gpu->base;
+   struct drm_device *dev = gpu->dev;
+   struct msm_drm_private *priv = dev->dev_private;
+
+   /* FIXME: add a banner here */
+   gmu->hung = true;
+
+   /* Turn off the hangcheck timer while we are resetting */
+   del_timer(>hangcheck_timer);
+
+   /* Queue the GPU handler because we need to treat this as a recovery */
+   queue_work(priv->wq, >recover_work);
+}
+
 static irqreturn_t a6xx_gmu_irq(int irq, void *data)
 {
struct a6xx_gmu *gmu = data;
@@ -20,8 +38,7 @@ static irqreturn_t a6xx_gmu_irq(int irq, void *data)
if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_WDOG_BITE) {
dev_err_ratelimited(gmu->dev, "GMU watchdog expired\n");
 
-   /* Temporary until we can recover safely */
-   BUG();
+   a6xx_gmu_fault(gmu);
}
 
if (status &  A6XX_GMU_AO_HOST_INTERRUPT_STATUS_HOST_AHB_BUS_ERROR)
@@ -45,8 +62,7 @@ static irqreturn_t a6xx_hfi_irq(int irq, void *data)
if (status & A6XX_GMU_GMU2HOST_INTR_INFO_CM3_FAULT) {
dev_err_ratelimited(gmu->dev, "GMU firmware fault\n");
 
-   /* Temporary until we can recover safely */
-   BUG();
+   a6xx_gmu_fault(gmu);
}
 
return IRQ_HANDLED;
@@ -156,10 +172,8 @@ static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
 }
 
 /* Wait for the GMU to get to its most idle state */
-int a6xx_gmu_wait_for_idle(struct a6xx_gpu *a6xx_gpu)
+int a6xx_gmu_wait_for_idle(struct a6xx_gmu *gmu)
 {
-   struct a6xx_gmu *gmu = _gpu->gmu;
-
return spin_until(a6xx_gmu_check_idle_level(gmu));
 }
 
@@ -558,7 +572,7 @@ static int a6xx_gmu_fw_start(struct a6xx_gmu *gmu, unsigned 
int state)
if (!rpmh_init) {
a6xx_gmu_rpmh_init(gmu);
rpmh_init = true;
-   } else if (state != GMU_RESET) {
+   } else {
ret = a6xx_rpmh_start(gmu);
if (ret)
return ret;
@@ -647,10 +661,9 @@ static void a6xx_gmu_irq_disable(struct a6xx_gmu *gmu)
gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_MASK, ~0);
 }
 
-int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
+/* Force the GMU off in case it isn't responsive */
+static void a6xx_gmu_force_off(struct a6xx_gmu *gmu)
 {
-   struct a6xx_gmu *gmu = _gpu->gmu;
-   int ret;
u32 val;
 
/* Flush all the queues */
@@ -671,44 +684,6 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
(val & 1), 100, 1);
gmu_poll_timeout(gmu, REG_A6XX_RSCC_TCS3_DRV0_STATUS, val,
(val & 1), 100, 1000);
-
-   /*
-* Depending on the state of the GMU at this point the GX domain might
-* have been left on. Hardware sequencing rules state that the GX has to
-* be turned off before the CX domain so this is that one time that
-* that calling pm_runtime_put_sync() is expected to do something useful
-* (turn off the headswitch)
-*/
-   if (!IS_ERR(gmu->gxpd))
-   pm_runtime_put_sync(gmu->gxpd);
-
-   /* Disable the resources */
-   clk_bulk_disable_unprepare(gmu->nr_clocks, gmu->clocks);
-   pm_runtime_put_sync(gmu->dev);
-
-   /* Re-enable the resources */
-   pm_runtime_get_sync(gmu->dev);
-
-   /* Use a known rate to bring up the GMU */
-   clk_set_rate(gmu->core_clk, 2);
-   ret = clk_bulk_prepare_enable(gmu->nr_clocks, gmu->clocks);
-   if (ret)
-   goto out;
-
-   a6xx_gmu_irq_enable(gmu);
-
-   ret = a6xx_gmu_fw_start(gmu, GMU_RESET);
-   if (!ret)
-   ret = a6xx_hfi_start(gmu, GMU_COLD_BOOT);
-
-   /* Set the GPU back to the highest power frequency */
-   __a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
-
-out:
-   if (ret)
-   a6xx_gmu_clear_oob(gmu, 

[PATCH v1 5/6] msm/drm/a6xx: Turn off the GMU if resume fails

[Jordan Crouse]

Currently if the GMU resume function fails all we try to do is clear the
BOOT_SLUMBER oob which usually times out and ends up in a cycle of death.
If the resume function fails at any point remove any RPMh votes that might
have been added and try to shut down the GMU hardware cleanly.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 82 +++---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  | 20 ++--
 drivers/gpu/drm/msm/adreno/adreno_device.c |  1 +
 3 files changed, 58 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index e16d55d..2e89ca3 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -638,20 +638,6 @@ static int a6xx_gmu_fw_start(struct a6xx_gmu *gmu, 
unsigned int state)
 A6XX_GMU_AO_HOST_INTERRUPT_STATUS_HOST_AHB_BUS_ERROR | \
 A6XX_GMU_AO_HOST_INTERRUPT_STATUS_FENCE_ERR)
 
-static void a6xx_gmu_irq_enable(struct a6xx_gmu *gmu)
-{
-   gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_CLR, ~0);
-   gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_CLR, ~0);
-
-   gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_MASK,
-   ~A6XX_GMU_IRQ_MASK);
-   gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_MASK,
-   ~A6XX_HFI_IRQ_MASK);
-
-   enable_irq(gmu->gmu_irq);
-   enable_irq(gmu->hfi_irq);
-}
-
 static void a6xx_gmu_irq_disable(struct a6xx_gmu *gmu)
 {
disable_irq(gmu->gmu_irq);
@@ -661,11 +647,24 @@ static void a6xx_gmu_irq_disable(struct a6xx_gmu *gmu)
gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_MASK, ~0);
 }
 
-/* Force the GMU off in case it isn't responsive */
-static void a6xx_gmu_force_off(struct a6xx_gmu *gmu)
+static void a6xx_gmu_rpmh_off(struct a6xx_gmu *gmu)
 {
u32 val;
 
+   /* Make sure there are no outstanding RPMh votes */
+   gmu_poll_timeout(gmu, REG_A6XX_RSCC_TCS0_DRV0_STATUS, val,
+   (val & 1), 100, 1);
+   gmu_poll_timeout(gmu, REG_A6XX_RSCC_TCS1_DRV0_STATUS, val,
+   (val & 1), 100, 1);
+   gmu_poll_timeout(gmu, REG_A6XX_RSCC_TCS2_DRV0_STATUS, val,
+   (val & 1), 100, 1);
+   gmu_poll_timeout(gmu, REG_A6XX_RSCC_TCS3_DRV0_STATUS, val,
+   (val & 1), 100, 1000);
+}
+
+/* Force the GMU off in case it isn't responsive */
+static void a6xx_gmu_force_off(struct a6xx_gmu *gmu)
+{
/* Flush all the queues */
a6xx_hfi_stop(gmu);
 
@@ -676,14 +675,7 @@ static void a6xx_gmu_force_off(struct a6xx_gmu *gmu)
a6xx_sptprac_disable(gmu);
 
/* Make sure there are no outstanding RPMh votes */
-   gmu_poll_timeout(gmu, REG_A6XX_RSCC_TCS0_DRV0_STATUS, val,
-   (val & 1), 100, 1);
-   gmu_poll_timeout(gmu, REG_A6XX_RSCC_TCS1_DRV0_STATUS, val,
-   (val & 1), 100, 1);
-   gmu_poll_timeout(gmu, REG_A6XX_RSCC_TCS2_DRV0_STATUS, val,
-   (val & 1), 100, 1);
-   gmu_poll_timeout(gmu, REG_A6XX_RSCC_TCS3_DRV0_STATUS, val,
-   (val & 1), 100, 1000);
+   a6xx_gmu_rpmh_off(gmu);
 }
 
 int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
@@ -702,10 +694,15 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
/* Use a known rate to bring up the GMU */
clk_set_rate(gmu->core_clk, 2);
ret = clk_bulk_prepare_enable(gmu->nr_clocks, gmu->clocks);
-   if (ret)
-   goto out;
+   if (ret) {
+   pm_runtime_put(gmu->dev);
+   return ret;
+   }
 
-   a6xx_gmu_irq_enable(gmu);
+   /* Enable the GMU interrupt */
+   gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_CLR, ~0);
+   gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_MASK, ~A6XX_GMU_IRQ_MASK);
+   enable_irq(gmu->gmu_irq);
 
/* Check to see if we are doing a cold or warm boot */
status = gmu_read(gmu, REG_A6XX_GMU_GENERAL_7) == 1 ?
@@ -716,6 +713,16 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
goto out;
 
ret = a6xx_hfi_start(gmu, status);
+   if (ret)
+   goto out;
+
+   /*
+* Turn on the GMU firmware fault interrupt after we know the boot
+* sequence is successful
+*/
+   gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_CLR, ~0);
+   gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_MASK, ~A6XX_HFI_IRQ_MASK);
+   enable_irq(gmu->hfi_irq);
 
/* Set the GPU to the highest power frequency */
__a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
@@ -729,9 +736,12 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
pm_runtime_get(gmu->gxpd);
 
 out:
-   /* Make sure to turn off the boot OOB request on error */
-   if (ret)
-   a6xx_gmu_clear_oob(gmu, GMU_OOB_BOOT_SLUMBER);
+   /* On failure, shut down the GMU to leave it in a good state */
+   if (ret) {
+   disable_irq(gmu->gmu_irq);
+   

RE: [PATCH v10 28/40] misc/mei/hdcp: Store the HDCP Pairing info

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Subject: [PATCH v10 28/40] misc/mei/hdcp: Store the HDCP Pairing info
>
>Provides Pairing info to ME to store.
>
>Pairing is a process to fast track the subsequent authentication with the same
>HDCP sink.
>
>On Success, received HDCP pairing info is stored in non-volatile memory of ME.
>
>v2: Rebased.
>v3:
>  cldev is passed as first parameter [Tomas]
>  Redundant comments and cast are removed [Tomas]
>v4:
>  %zd for ssize_t [Alexander]
>  %s/return -1/return -EIO [Alexander]
>  Style fixed [Uma]
>v5: Rebased.
>v6:
>  Collected the Rb-ed by.
>  Rebasing.
>v7:
>  Adjust to the new mei interface.
>  Fix for Kdoc.
>v8:
>  K-Doc addition. [Tomas]
>  memcpy for const length.
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

Latest set looks ok. You can keep the RB.

>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 60
>+++-
> 1 file changed, 59 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 74219e1487d3..e8396c723ab0 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -224,13 +224,71 @@ static int mei_verify_hprime(struct device *dev, struct
>hdcp_port_data *data,
>   return 0;
> }
>
>+/**
>+ * mei_store_pairing_info() - Store pairing info received at ME FW
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ * @pairing_info: AKE_Send_Pairing_Info msg input to ME FW
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int
>+mei_store_pairing_info(struct device *dev, struct hdcp_port_data *data,
>+ struct hdcp2_ake_send_pairing_info *pairing_info) {
>+  struct wired_cmd_ake_send_pairing_info_in pairing_info_in = { { 0 } };
>+  struct wired_cmd_ake_send_pairing_info_out pairing_info_out = { { 0 } };
>+  struct mei_cl_device *cldev;
>+  ssize_t byte;
>+
>+  if (!dev || !data || !pairing_info)
>+  return -EINVAL;
>+
>+  cldev = to_mei_cl_device(dev);
>+
>+  pairing_info_in.header.api_version = HDCP_API_VERSION;
>+  pairing_info_in.header.command_id =
>WIRED_AKE_SEND_PAIRING_INFO;
>+  pairing_info_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+  pairing_info_in.header.buffer_len =
>+
>   WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
>+
>+  pairing_info_in.port.integrated_port_type = data->port_type;
>+  pairing_info_in.port.physical_port =
>+(u8)GET_MEI_DDI_INDEX(data->port);
>+
>+  memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
>+ HDCP_2_2_E_KH_KM_LEN);
>+
>+  byte = mei_cldev_send(cldev, (u8 *)_info_in,
>+sizeof(pairing_info_in));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  byte = mei_cldev_recv(cldev, (u8 *)_info_out,
>+sizeof(pairing_info_out));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  if (pairing_info_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+  dev_dbg(dev, "ME cmd 0x%08X failed. Status: 0x%X\n",
>+  WIRED_AKE_SEND_PAIRING_INFO,
>+  pairing_info_out.header.status);
>+  return -EIO;
>+  }
>+
>+  return 0;
>+}
>+
> static __attribute__((unused))
> struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
>   .initiate_hdcp2_session = mei_initiate_hdcp2_session,
>   .verify_receiver_cert_prepare_km =
>mei_verify_receiver_cert_prepare_km,
>   .verify_hprime = mei_verify_hprime,
>-  .store_pairing_info = NULL,
>+  .store_pairing_info = mei_store_pairing_info,
>   .initiate_locality_check = NULL,
>   .verify_lprime = NULL,
>   .get_session_key = NULL,
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v10 27/40] misc/mei/hdcp: Verify H_prime

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 27/40] misc/mei/hdcp: Verify H_prime
>
>Requests for the verification of AKE_Send_H_prime.
>
>ME will calculate the H and comparing it with received H_Prime.
>The result will be returned as status.
>
>Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.
>
>v2: Rebased.
>v3:
>  cldev is passed as first parameter [Tomas]
>  Redundant comments and cast are removed [Tomas]
>v4:
>  %zd for ssize_t [Alexander]
>  %s/return -1/return -EIO [Alexander]
>  Styles and typos fixed [Uma]
>v5: Rebased.
>v6:
>  Collected the Rb-ed by.
>  Rebasing.
>v7:
>  Adjust to the new mei interface.
>  Fix for Kdoc.
>v8:
>  K-Doc Addition [Tomas]
>  memcpy for const length.
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

Latest set look ok. You can keep the RB.

>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 57
>+++-
> 1 file changed, 56 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 24665fff640d..74219e1487d3 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -169,12 +169,67 @@ mei_verify_receiver_cert_prepare_km(struct device
>*dev,
>   return 0;
> }
>
>+/**
>+ * mei_verify_hprime() - Verify AKE_Send_H_prime at ME FW.
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ * @rx_hprime: AKE_Send_H_prime msg for ME FW verification
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int mei_verify_hprime(struct device *dev, struct hdcp_port_data *data,
>+   struct hdcp2_ake_send_hprime *rx_hprime) {
>+  struct wired_cmd_ake_send_hprime_in send_hprime_in = { { 0 } };
>+  struct wired_cmd_ake_send_hprime_out send_hprime_out = { { 0 } };
>+  struct mei_cl_device *cldev;
>+  ssize_t byte;
>+
>+  if (!dev || !data || !rx_hprime)
>+  return -EINVAL;
>+
>+  cldev = to_mei_cl_device(dev);
>+
>+  send_hprime_in.header.api_version = HDCP_API_VERSION;
>+  send_hprime_in.header.command_id = WIRED_AKE_SEND_HPRIME;
>+  send_hprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+  send_hprime_in.header.buffer_len =
>+WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
>+
>+  send_hprime_in.port.integrated_port_type = data->port_type;
>+  send_hprime_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data-
>>port);
>+
>+  memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
>+ HDCP_2_2_H_PRIME_LEN);
>+
>+  byte = mei_cldev_send(cldev, (u8 *)_hprime_in,
>+sizeof(send_hprime_in));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  byte = mei_cldev_recv(cldev, (u8 *)_hprime_out,
>+sizeof(send_hprime_out));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  if (send_hprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+  dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
>+  WIRED_AKE_SEND_HPRIME,
>send_hprime_out.header.status);
>+  return -EIO;
>+  }
>+
>+  return 0;
>+}
>+
> static __attribute__((unused))
> struct i915_hdcp_component_ops mei_hdcp_ops = {
>   .owner = THIS_MODULE,
>   .initiate_hdcp2_session = mei_initiate_hdcp2_session,
>   .verify_receiver_cert_prepare_km =
>mei_verify_receiver_cert_prepare_km,
>-  .verify_hprime = NULL,
>+  .verify_hprime = mei_verify_hprime,
>   .store_pairing_info = NULL,
>   .initiate_locality_check = NULL,
>   .verify_lprime = NULL,
>--
>2.7.4

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

Re: [PATCH v10 20/40] drm/i915: Add HDCP2.2 support for HDMI connectors

[C, Ramalingam]

On 2/4/2019 9:34 PM, Winkler, Tomas wrote:

On HDMI connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.

v2:
   Rebased.
v3:
   Collected the reviewed-by received.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 3b4fe7048af9..2c4bf6d0c39f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2621,7 +2621,8 @@ void intel_hdmi_init_connector(struct
intel_digital_port *intel_dig_port,

if (is_hdcp_supported(dev_priv, port)) {
int ret = intel_hdcp_init(intel_connector,
- _hdmi_hdcp_shim, false);
+_hdmi_hdcp_shim,
+is_hdcp2_supported(dev_priv));

intel_hdcp_init is always called with is_hdcp2_supported() both for DP and 
HDMI, so you can just remove the argument it's redundant.

Thanks for the review Tomas.
Sure. That will reduce a parameter in hdcp_init.

--Ram



if (is_hdcp2_supported())
  intel_hdcp2_init(connector);

They are both defied in intel_hdcp.c.

Thanks
Tomas



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

RE: [PATCH v10 26/40] misc/mei/hdcp: Verify Receiver Cert and prepare km

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 26/40] misc/mei/hdcp: Verify Receiver Cert and prepare km
>
>Requests for verification for receiver certification and also the preparation 
>for
>next AKE auth message with km.
>
>On Success ME FW validate the HDCP2.2 receivers certificate and do the
>revocation check on the receiver ID. AKE_Stored_Km will be prepared if the
>receiver is already paired, else AKE_No_Stored_Km will be prepared.
>
>Here AKE_Stored_Km and AKE_No_Stored_Km are HDCP2.2 protocol msgs.
>
>v2: Rebased.
>v3:
>  cldev is passed as first parameter [Tomas]
>  Redundant comments and cast are removed [Tomas]
>v4:
>  %zd is used for ssize_t [Alexander]
>  %s/return -1/return -EIO [Alexander]
>v5: Rebased.
>v6:
>  Collected the Rb-ed by.
>  Rebasing.
>v7:
>  Adjust to the new mei interface.
>  Fix for Kdoc.
>v8:
>  K-Doc Addition. [Tomas]
>  memcpy for const length.
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

Latest set look ok. You can keep the RB.

>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 81
>+++-
> 1 file changed, 80 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 534d29c8ee86..24665fff640d 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -90,11 +90,90 @@ mei_initiate_hdcp2_session(struct device *dev, struct
>hdcp_port_data *data,
>   return 0;
> }
>
>+/**
>+ * mei_verify_receiver_cert_prepare_km() - Verify the Receiver
>+Certificate
>+ * AKE_Send_Cert and prepare AKE_Stored_Km/AKE_No_Stored_Km
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ * @rx_cert: AKE_Send_Cert for verification
>+ * @km_stored: Pairing status flag output
>+ * @ek_pub_km: AKE_Stored_Km/AKE_No_Stored_Km output msg
>+ * @msg_sz : size of AKE_X_Km output msg
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int
>+mei_verify_receiver_cert_prepare_km(struct device *dev,
>+  struct hdcp_port_data *data,
>+  struct hdcp2_ake_send_cert *rx_cert,
>+  bool *km_stored,
>+  struct hdcp2_ake_no_stored_km
>*ek_pub_km,
>+  size_t *msg_sz)
>+{
>+  struct wired_cmd_verify_receiver_cert_in verify_rxcert_in = { { 0 } };
>+  struct wired_cmd_verify_receiver_cert_out verify_rxcert_out = { { 0 } };
>+  struct mei_cl_device *cldev;
>+  ssize_t byte;
>+
>+  if (!dev || !data || !rx_cert || !km_stored || !ek_pub_km || !msg_sz)
>+  return -EINVAL;
>+
>+  cldev = to_mei_cl_device(dev);
>+
>+  verify_rxcert_in.header.api_version = HDCP_API_VERSION;
>+  verify_rxcert_in.header.command_id = WIRED_VERIFY_RECEIVER_CERT;
>+  verify_rxcert_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+  verify_rxcert_in.header.buffer_len =
>+
>   WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
>+
>+  verify_rxcert_in.port.integrated_port_type = data->port_type;
>+  verify_rxcert_in.port.physical_port =
>+(u8)GET_MEI_DDI_INDEX(data->port);
>+
>+  verify_rxcert_in.cert_rx = rx_cert->cert_rx;
>+  memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
>+  memcpy(verify_rxcert_in.rx_caps, rx_cert->rx_caps,
>+HDCP_2_2_RXCAPS_LEN);
>+
>+  byte = mei_cldev_send(cldev, (u8 *)_rxcert_in,
>+sizeof(verify_rxcert_in));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_send failed: %zd\n", byte);
>+  return byte;
>+  }
>+
>+  byte = mei_cldev_recv(cldev, (u8 *)_rxcert_out,
>+sizeof(verify_rxcert_out));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_recv failed: %zd\n", byte);
>+  return byte;
>+  }
>+
>+  if (verify_rxcert_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+  dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
>+  WIRED_VERIFY_RECEIVER_CERT,
>+  verify_rxcert_out.header.status);
>+  return -EIO;
>+  }
>+
>+  *km_stored = verify_rxcert_out.km_stored;
>+  if (verify_rxcert_out.km_stored) {
>+  ek_pub_km->msg_id = HDCP_2_2_AKE_STORED_KM;
>+  *msg_sz = sizeof(struct hdcp2_ake_stored_km);
>+  } else {
>+  ek_pub_km->msg_id = HDCP_2_2_AKE_NO_STORED_KM;
>+  *msg_sz = sizeof(struct hdcp2_ake_no_stored_km);
>+  }
>+
>+  memcpy(ek_pub_km->e_kpub_km, _rxcert_out.ekm_buff,
>+ sizeof(verify_rxcert_out.ekm_buff));
>+
>+  return 0;
>+}
>+
> static __attribute__((unused))
> struct i915_hdcp_component_ops mei_hdcp_ops = {
>

RE: [PATCH v10 25/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 25/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
>
>Request ME FW to start the HDCP2.2 session for an intel port.
>Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends to
>ME FW.
>
>On Success, ME FW will start a HDCP2.2 session for the port and provides the
>content for HDCP2.2 AKE_Init message.
>
>v2: Rebased.
>v3:
>  cldev is add as a separate parameter [Tomas]
>  Redundant comment and typecast are removed [Tomas]
>v4:
>  %zd is used for size [Alexander]
>  %s/return -1/return -EIO [Alexander]
>  Spellings in commit msg is fixed [Uma]
>v5: Rebased.
>v6:
>  Collected the rb-ed by.
>  Realigning the patches in the series.
>v7:
>  Adjust to the new mei interface.
>  Fix for kdoc.
>v8:
>  K-Doc Addition.
>  memcpy for const length.
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

Latest set look ok. You can keep the RB.

>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 82
>
> drivers/misc/mei/hdcp/mei_hdcp.h | 28 ++
> 2 files changed, 110 insertions(+)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index ca5010ad7dd7..534d29c8ee86 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -23,6 +23,88 @@
> #include 
> #include 
> #include 
>+#include 
>+#include 
>+#include 
>+
>+#include "mei_hdcp.h"
>+
>+/**
>+ * mei_initiate_hdcp2_session() - Initiate a Wired HDCP2.2 Tx Session
>+in ME FW
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ * @ake_data: AKE_Init msg output.
>+ *
>+ * Return:  0 on Success, <0 on Failure.
>+ */
>+static int
>+mei_initiate_hdcp2_session(struct device *dev, struct hdcp_port_data *data,
>+ struct hdcp2_ake_init *ake_data)
>+{
>+  struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
>+  struct wired_cmd_initiate_hdcp2_session_out
>+  session_init_out = { { 0 } };
>+  struct mei_cl_device *cldev;
>+  ssize_t byte;
>+
>+  if (!dev || !data || !ake_data)
>+  return -EINVAL;
>+
>+  cldev = to_mei_cl_device(dev);
>+
>+  session_init_in.header.api_version = HDCP_API_VERSION;
>+  session_init_in.header.command_id =
>WIRED_INITIATE_HDCP2_SESSION;
>+  session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+  session_init_in.header.buffer_len =
>+
>   WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
>+
>+  session_init_in.port.integrated_port_type = data->port_type;
>+  session_init_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data-
>>port);
>+  session_init_in.protocol = data->protocol;
>+
>+  byte = mei_cldev_send(cldev, (u8 *)_init_in,
>+sizeof(session_init_in));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  byte = mei_cldev_recv(cldev, (u8 *)_init_out,
>+sizeof(session_init_out));
>+  if (byte < 0) {
>+  dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
>+  return byte;
>+  }
>+
>+  if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+  dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
>+  WIRED_INITIATE_HDCP2_SESSION,
>+  session_init_out.header.status);
>+  return -EIO;
>+  }
>+
>+  ake_data->msg_id = HDCP_2_2_AKE_INIT;
>+  ake_data->tx_caps = session_init_out.tx_caps;
>+  memcpy(ake_data->r_tx, session_init_out.r_tx, HDCP_2_2_RTX_LEN);
>+
>+  return 0;
>+}
>+
>+static __attribute__((unused))
>+struct i915_hdcp_component_ops mei_hdcp_ops = {
>+  .owner = THIS_MODULE,
>+  .initiate_hdcp2_session = mei_initiate_hdcp2_session,
>+  .verify_receiver_cert_prepare_km = NULL,
>+  .verify_hprime = NULL,
>+  .store_pairing_info = NULL,
>+  .initiate_locality_check = NULL,
>+  .verify_lprime = NULL,
>+  .get_session_key = NULL,
>+  .repeater_check_flow_prepare_ack = NULL,
>+  .verify_mprime = NULL,
>+  .enable_hdcp_authentication = NULL,
>+  .close_hdcp_session = NULL,
>+};
>
> static int mei_hdcp_probe(struct mei_cl_device *cldev,
> const struct mei_cl_device_id *id) diff --git
>a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
>index 582a7e27ae29..f831db3cbd54 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.h
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
>@@ -363,4 +363,32 @@ struct wired_cmd_repeater_auth_stream_req_out {
>   struct hdcp_port_id port;
> } __packed;
>
>+enum mei_hdcp_ddi {
>+  

RE: [PATCH v10 19/40] drm/i915: Add HDCP2.2 support for DP connectors

[Winkler, Tomas]

> -Original Message-
> From: C, Ramalingam
> Sent: Thursday, January 31, 2019 09:00
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
> Uma 
> Cc: C, Ramalingam 
> Subject: [PATCH v10 19/40] drm/i915: Add HDCP2.2 support for DP connectors
> 
> On DP connector init, intel_hdcp_init is passed with a flag for hdcp2.2 
> support
> based on the platform capability.
> 
> v2:
>   Rebased.
> v3:
>   Collected the reviewed-by received.
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4e36df266ab3..88c889770517 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -7301,7 +7301,7 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> 
>   if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
>   int ret = intel_hdcp_init(intel_connector,
> _dp_hdcp_shim,
> -   false);
> +   is_hdcp2_supported(dev_priv));
intel_hdcp_init is always called with is_hdcp2_supported() both for DP and 
HDMI, so you can just remove the argument it's redundant. 


Thanks
Tomas

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

RE: [PATCH v10 24/40] misc/mei/hdcp: Define ME FW interface for HDCP2.2

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 24/40] misc/mei/hdcp: Define ME FW interface for HDCP2.2
>
>Defines the HDCP specific ME FW interfaces such as Request CMDs, payload
>structure for CMDs and their response status codes.
>
>This patch defines payload size(Excluding the Header)for each WIRED
>HDCP2.2 CMDs.
>
>v2: Rebased.
>v3:
>  Extra comments are removed.
>v4:
>  %s/\/\*\*/\/\*
>v5:
>  Extra lines are removed.
>v6:
>  Remove redundant text from the License header
>  %s/LPRIME_HALF/V_PRIME_HALF
>  %s/uintxx_t/uxx
>v7:
>  Extra taps removed.
>
>Signed-off-by: Ramalingam C 

Looks ok to me.
Reviewed-by: Uma Shankar 

>---
> drivers/misc/mei/hdcp/mei_hdcp.h | 366
>+++
> 1 file changed, 366 insertions(+)
> create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h
>b/drivers/misc/mei/hdcp/mei_hdcp.h
>new file mode 100644
>index ..582a7e27ae29
>--- /dev/null
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
>@@ -0,0 +1,366 @@
>+/* SPDX-License-Identifier: (GPL-2.0+) */
>+/*
>+ * Copyright © 2017-2018 Intel Corporation
>+ *
>+ * Authors:
>+ * Ramalingam C   */
>+
>+#ifndef __MEI_HDCP_H__
>+#define __MEI_HDCP_H__
>+
>+#include 
>+
>+/* me_hdcp_status: Enumeration of all HDCP Status Codes */ enum
>+me_hdcp_status {
>+  ME_HDCP_STATUS_SUCCESS  = 0x,
>+
>+  /* WiDi Generic Status Codes */
>+  ME_HDCP_STATUS_INTERNAL_ERROR   = 0x1000,
>+  ME_HDCP_STATUS_UNKNOWN_ERROR= 0x1001,
>+  ME_HDCP_STATUS_INCORRECT_API_VERSION= 0x1002,
>+  ME_HDCP_STATUS_INVALID_FUNCTION = 0x1003,
>+  ME_HDCP_STATUS_INVALID_BUFFER_LENGTH= 0x1004,
>+  ME_HDCP_STATUS_INVALID_PARAMS   = 0x1005,
>+  ME_HDCP_STATUS_AUTHENTICATION_FAILED= 0x1006,
>+
>+  /* WiDi Status Codes */
>+  ME_HDCP_INVALID_SESSION_STATE   = 0x6000,
>+  ME_HDCP_SRM_FRAGMENT_UNEXPECTED = 0x6001,
>+  ME_HDCP_SRM_INVALID_LENGTH  = 0x6002,
>+  ME_HDCP_SRM_FRAGMENT_OFFSET_INVALID = 0x6003,
>+  ME_HDCP_SRM_VERIFICATION_FAILED = 0x6004,
>+  ME_HDCP_SRM_VERSION_TOO_OLD = 0x6005,
>+  ME_HDCP_RX_CERT_VERIFICATION_FAILED = 0x6006,
>+  ME_HDCP_RX_REVOKED  = 0x6007,
>+  ME_HDCP_H_VERIFICATION_FAILED   = 0x6008,
>+  ME_HDCP_REPEATER_CHECK_UNEXPECTED   = 0x6009,
>+  ME_HDCP_TOPOLOGY_MAX_EXCEEDED   = 0x600A,
>+  ME_HDCP_V_VERIFICATION_FAILED   = 0x600B,
>+  ME_HDCP_L_VERIFICATION_FAILED   = 0x600C,
>+  ME_HDCP_STREAM_KEY_ALLOC_FAILED = 0x600D,
>+  ME_HDCP_BASE_KEY_RESET_FAILED   = 0x600E,
>+  ME_HDCP_NONCE_GENERATION_FAILED = 0x600F,
>+  ME_HDCP_STATUS_INVALID_E_KEY_STATE  = 0x6010,
>+  ME_HDCP_STATUS_INVALID_CS_ICV   = 0x6011,
>+  ME_HDCP_STATUS_INVALID_KB_KEY_STATE = 0x6012,
>+  ME_HDCP_STATUS_INVALID_PAVP_MODE_ICV= 0x6013,
>+  ME_HDCP_STATUS_INVALID_PAVP_MODE= 0x6014,
>+  ME_HDCP_STATUS_LC_MAX_ATTEMPTS  = 0x6015,
>+
>+  /* New status for HDCP 2.1 */
>+  ME_HDCP_STATUS_MISMATCH_IN_M= 0x6016,
>+
>+  /* New status code for HDCP 2.2 Rx */
>+  ME_HDCP_STATUS_RX_PROV_NOT_ALLOWED  = 0x6017,
>+  ME_HDCP_STATUS_RX_PROV_WRONG_SUBJECT= 0x6018,
>+  ME_HDCP_RX_NEEDS_PROVISIONING   = 0x6019,
>+  ME_HDCP_BKSV_ICV_AUTH_FAILED= 0x6020,
>+  ME_HDCP_STATUS_INVALID_STREAM_ID= 0x6021,
>+  ME_HDCP_STATUS_CHAIN_NOT_INITIALIZED= 0x6022,
>+  ME_HDCP_FAIL_NOT_EXPECTED   = 0x6023,
>+  ME_HDCP_FAIL_HDCP_OFF   = 0x6024,
>+  ME_HDCP_FAIL_INVALID_PAVP_MEMORY_MODE   = 0x6025,
>+  ME_HDCP_FAIL_AES_ECB_FAILURE= 0x6026,
>+  ME_HDCP_FEATURE_NOT_SUPPORTED   = 0x6027,
>+  ME_HDCP_DMA_READ_ERROR  = 0x6028,
>+  ME_HDCP_DMA_WRITE_ERROR = 0x6029,
>+  ME_HDCP_FAIL_INVALID_PACKET_SIZE= 0x6030,
>+  ME_HDCP_H264_PARSING_ERROR  = 0x6031,
>+  ME_HDCP_HDCP2_ERRATA_VIDEO_VIOLATION= 0x6032,
>+  ME_HDCP_HDCP2_ERRATA_AUDIO_VIOLATION= 0x6033,
>+  ME_HDCP_TX_ACTIVE_ERROR = 0x6034,
>+  ME_HDCP_MODE_CHANGE_ERROR   = 0x6035,
>+  ME_HDCP_STREAM_TYPE_ERROR   = 0x6036,
>+  ME_HDCP_STREAM_MANAGE_NOT_POSSIBLE  = 0x6037,
>+
>+  ME_HDCP_STATUS_PORT_INVALID_COMMAND = 0x6038,
>+  ME_HDCP_STATUS_UNSUPPORTED_PROTOCOL = 0x6039,
>+  ME_HDCP_STATUS_INVALID_PORT_INDEX   = 0x603a,
>+  ME_HDCP_STATUS_TX_AUTH_NEEDED   = 0x603b,
>+  ME_HDCP_STATUS_NOT_INTEGRATED_PORT   

RE: [PATCH v10 20/40] drm/i915: Add HDCP2.2 support for HDMI connectors

[Winkler, Tomas]

> 
> On HDMI connector init, intel_hdcp_init is passed with a flag for hdcp2.2
> support based on the platform capability.
> 
> v2:
>   Rebased.
> v3:
>   Collected the reviewed-by received.
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 3b4fe7048af9..2c4bf6d0c39f 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -2621,7 +2621,8 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> 
>   if (is_hdcp_supported(dev_priv, port)) {
>   int ret = intel_hdcp_init(intel_connector,
> -   _hdmi_hdcp_shim, false);
> +  _hdmi_hdcp_shim,
> +  is_hdcp2_supported(dev_priv));

intel_hdcp_init is always called with is_hdcp2_supported() both for DP and 
HDMI, so you can just remove the argument it's redundant. 

if (is_hdcp2_supported())
 intel_hdcp2_init(connector);

They are both defied in intel_hdcp.c.

Thanks
Tomas

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

RE: [PATCH v10 17/40] drm/i915: Implement the HDCP2.2 support for HDMI

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 17/40] drm/i915: Implement the HDCP2.2 support for HDMI
>
>Implements the HDMI adaptation specific HDCP2.2 operations.
>
>Basically these are DDC read and write for authenticating through
>HDCP2.2 messages.
>
>v2: Rebased.
>v3:
>  No more special handling of Gmbus burst read for AKE_SEND_CERT.
>  Style fixed with few naming. [Uma]
>  %s/PARING/PAIRING
>v4:
>  msg_sz is initialized at definition.
>  Lookup table is defined for HDMI HDCP2.2 msgs [Daniel].
>v5: Rebased.
>v6:
>  Make a function as inline [Uma]
>  %s/uintxx_t/uxx
>v7:
>  Errors due to sinks are reported as DEBUG logs.
>  Adjust to the new mei interface.
>v8:
>  ARRAY_SIZE for the # of array members [Jon & Daniel].
>  hdcp adaptation is added as a const in the hdcp_shim [Daniel]
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

Latest set looks ok. You can keep my RB.

>---
> drivers/gpu/drm/i915/intel_hdmi.c | 189
>++
> 1 file changed, 189 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>b/drivers/gpu/drm/i915/intel_hdmi.c
>index ab376a31cdab..3b4fe7048af9 100644
>--- a/drivers/gpu/drm/i915/intel_hdmi.c
>+++ b/drivers/gpu/drm/i915/intel_hdmi.c
>@@ -1129,6 +1129,190 @@ bool intel_hdmi_hdcp_check_link(struct
>intel_digital_port *intel_dig_port)
>   return true;
> }
>
>+static struct hdcp2_hdmi_msg_data {
>+  u8 msg_id;
>+  u32 timeout;
>+  u32 timeout2;
>+  } hdcp2_msg_data[] = {
>+  {HDCP_2_2_AKE_INIT, 0, 0},
>+  {HDCP_2_2_AKE_SEND_CERT, HDCP_2_2_CERT_TIMEOUT_MS,
>0},
>+  {HDCP_2_2_AKE_NO_STORED_KM, 0, 0},
>+  {HDCP_2_2_AKE_STORED_KM, 0, 0},
>+  {HDCP_2_2_AKE_SEND_HPRIME,
>HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
>+
>   HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
>+  {HDCP_2_2_AKE_SEND_PAIRING_INFO,
>HDCP_2_2_PAIRING_TIMEOUT_MS,
>+  0},
>+  {HDCP_2_2_LC_INIT, 0, 0},
>+  {HDCP_2_2_LC_SEND_LPRIME,
>HDCP_2_2_HDMI_LPRIME_TIMEOUT_MS, 0},
>+  {HDCP_2_2_SKE_SEND_EKS, 0, 0},
>+  {HDCP_2_2_REP_SEND_RECVID_LIST,
>+  HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
>+  {HDCP_2_2_REP_SEND_ACK, 0, 0},
>+  {HDCP_2_2_REP_STREAM_MANAGE, 0, 0},
>+  {HDCP_2_2_REP_STREAM_READY,
>HDCP_2_2_STREAM_READY_TIMEOUT_MS,
>+  0},
>+  };
>+
>+static
>+int intel_hdmi_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
>+  uint8_t *rx_status)
>+{
>+  return intel_hdmi_hdcp_read(intel_dig_port,
>+  HDCP_2_2_HDMI_REG_RXSTATUS_OFFSET,
>+  rx_status,
>+  HDCP_2_2_HDMI_RXSTATUS_LEN);
>+}
>+
>+static int get_hdcp2_msg_timeout(u8 msg_id, bool is_paired) {
>+  int i;
>+
>+  for (i = 0; i < ARRAY_SIZE(hdcp2_msg_data); i++)
>+  if (hdcp2_msg_data[i].msg_id == msg_id &&
>+  (msg_id != HDCP_2_2_AKE_SEND_HPRIME || is_paired))
>+  return hdcp2_msg_data[i].timeout;
>+  else if (hdcp2_msg_data[i].msg_id == msg_id)
>+  return hdcp2_msg_data[i].timeout2;
>+
>+  return -EINVAL;
>+}
>+
>+static inline
>+int hdcp2_detect_msg_availability(struct intel_digital_port 
>*intel_digital_port,
>+u8 msg_id, bool *msg_ready,
>+ssize_t *msg_sz)
>+{
>+  u8 rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
>+  int ret;
>+
>+  ret = intel_hdmi_hdcp2_read_rx_status(intel_digital_port, rx_status);
>+  if (ret < 0) {
>+  DRM_DEBUG_KMS("rx_status read failed. Err %d\n", ret);
>+  return ret;
>+  }
>+
>+  *msg_sz = ((HDCP_2_2_HDMI_RXSTATUS_MSG_SZ_HI(rx_status[1]) << 8)
>|
>+rx_status[0]);
>+
>+  if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST)
>+  *msg_ready =
>(HDCP_2_2_HDMI_RXSTATUS_READY(rx_status[1]) &&
>+   *msg_sz);
>+  else
>+  *msg_ready = *msg_sz;
>+
>+  return 0;
>+}
>+
>+static ssize_t
>+intel_hdmi_hdcp2_wait_for_msg(struct intel_digital_port *intel_dig_port,
>+u8 msg_id, bool paired)
>+{
>+  bool msg_ready = false;
>+  int timeout, ret;
>+  ssize_t msg_sz = 0;
>+
>+  timeout = get_hdcp2_msg_timeout(msg_id, paired);
>+  if (timeout < 0)
>+  return timeout;
>+
>+  ret = __wait_for(ret = hdcp2_detect_msg_availability(intel_dig_port,
>+   msg_id,
>_ready,
>+   _sz),
>+   

RE: [PATCH v10 16/40] drm/i915: Implement the HDCP2.2 support for DP

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 16/40] drm/i915: Implement the HDCP2.2 support for DP
>
>Implements the DP adaptation specific HDCP2.2 functions.
>
>These functions perform the DPCD read and write for communicating the
>HDCP2.2 auth message back and forth.
>
>v2:
>  wait for cp_irq is merged with this patch. Rebased.
>v3:
>  wait_queue is used for wait for cp_irq [Chris Wilson]
>v4:
>  Style fixed.
>  %s/PARING/PAIRING
>  Few style fixes [Uma]
>v5:
>  Lookup table for DP HDCP2.2 msg details [Daniel].
>  Extra lines are removed.
>v6: Rebased.
>v7:
>  Fixed some regression introduced at v5. [Ankit]
>  Macro HDCP_2_2_RX_CAPS_VERSION_VAL is reused [Uma]
>  Converted a function to inline [Uma]
>  %s/uintxx_t/uxx
>v8:
>  Error due to the sinks are reported as DEBUG logs.
>  Adjust to the new mei interface.
>v9:
>  ARRAY_SIZE for no of array members [Jon & Daniel]
>  return of the wait_for_cp_irq is made as void [Daniel]
>  Wait for HDCP2.2 msg is done based on polling the reg bit than
>CP_IRQ based. [Daniel]
>  hdcp adaptation is added as a const in the hdcp_shim [Daniel]
>v10:
>  config_stream_type is redefined [Daniel]
>  DP Errata specific defines are moved into intel_dp.c.
>
>Signed-off-by: Ramalingam C 
>Signed-off-by: Ankit K Nautiyal 
>Reviewed-by: Uma Shankar 

Latest set looks ok. You can keep my RB.

>---
> drivers/gpu/drm/i915/intel_dp.c | 333
>
> 1 file changed, 333 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>index 9ce05819fc11..b13c41220ce0 100644
>--- a/drivers/gpu/drm/i915/intel_dp.c
>+++ b/drivers/gpu/drm/i915/intel_dp.c
>@@ -5843,6 +5843,333 @@ int intel_dp_hdcp_capable(struct intel_digital_port
>*intel_dig_port,
>   return 0;
> }
>
>+struct hdcp2_dp_errata_stream_type {
>+  u8  msg_id;
>+  u8  stream_type;
>+} __packed;
>+
>+static struct hdcp2_dp_msg_data {
>+  u8 msg_id;
>+  u32 offset;
>+  bool msg_detectable;
>+  u32 timeout;
>+  u32 timeout2; /* Added for non_paired situation */
>+  } hdcp2_msg_data[] = {
>+  {HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false,
>0, 0},
>+  {HDCP_2_2_AKE_SEND_CERT,
>DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
>+  false, HDCP_2_2_CERT_TIMEOUT_MS, 0},
>+  {HDCP_2_2_AKE_NO_STORED_KM,
>DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
>+  false, 0, 0},
>+  {HDCP_2_2_AKE_STORED_KM,
>DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
>+  false, 0, 0},
>+  {HDCP_2_2_AKE_SEND_HPRIME,
>DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
>+  true,
>HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
>+
>   HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
>+  {HDCP_2_2_AKE_SEND_PAIRING_INFO,
>+
>   DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, true,
>+  HDCP_2_2_PAIRING_TIMEOUT_MS, 0},
>+  {HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0,
>0},
>+  {HDCP_2_2_LC_SEND_LPRIME,
>DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
>+  false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0},
>+  {HDCP_2_2_SKE_SEND_EKS,
>DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, false,
>+  0, 0},
>+  {HDCP_2_2_REP_SEND_RECVID_LIST,
>+
>   DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
>+  HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
>+  {HDCP_2_2_REP_SEND_ACK,
>DP_HDCP_2_2_REP_SEND_ACK_OFFSET, false,
>+  0, 0},
>+  {HDCP_2_2_REP_STREAM_MANAGE,
>+
>   DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
>+  0, 0},
>+  {HDCP_2_2_REP_STREAM_READY,
>DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
>+  false,
>HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0},
>+/* local define to shovel this through the write_2_2 interface */
>+#define HDCP_2_2_ERRATA_DP_STREAM_TYPE50
>+  {HDCP_2_2_ERRATA_DP_STREAM_TYPE,
>+  DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET,
>false,
>+  0, 0},
>+  };
>+
>+static inline
>+int intel_dp_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
>+u8 *rx_status)
>+{
>+  ssize_t ret;
>+
>+  ret = drm_dp_dpcd_read(_dig_port->dp.aux,
>+ DP_HDCP_2_2_REG_RXSTATUS_OFFSET, rx_status,
>+ HDCP_2_2_DP_RXSTATUS_LEN);
>+  if (ret != HDCP_2_2_DP_RXSTATUS_LEN) {
>+  DRM_DEBUG_KMS("Read bstatus from DP/AUX failed (%zd)\n",
>ret);
>+  return ret >= 0 ? -EIO : ret;
>+  }
>+
>+  return 0;
>+}
>+

Re: [PATCH 2/2] components: multiple components for a device

[Daniel Vetter]

On Thu, Jan 31, 2019 at 03:46:40PM +0100, Daniel Vetter wrote:
> Component framework is extended to support multiple components for
> a struct device. These will be matched with different masters based on
> its sub component value.
> 
> We are introducing this, as I915 needs two different components
> with different subcomponent value, which will be matched to two
> different component masters(Audio and HDCP) based on the subcomponent
> values.
> 
> v2: Add documenation.
> 
> Signed-off-by: Daniel Vetter  (v1 code)
> Signed-off-by: Ramalingam C  (v1 commit message)
> Cc: Ramalingam C 
> Cc: Greg Kroah-Hartman 
> Cc: Russell King 
> Cc: Rafael J. Wysocki 
> Cc: Jaroslav Kysela 
> Cc: Takashi Iwai 
> Cc: Rodrigo Vivi 
> Cc: Jani Nikula 
> Signed-off-by: Daniel Vetter 

Hi Greg,

Now that there's nice documentation on everything, any comments on these
two patches?

Thanks, Daniel

> ---
>  drivers/base/component.c  | 159 +-
>  include/linux/component.h |  10 ++-
>  2 files changed, 130 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index e5b04bce8544..eb7915fc5278 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -48,6 +48,7 @@ struct component;
>  struct component_match_array {
>   void *data;
>   int (*compare)(struct device *, void *);
> + int (*compare_typed)(struct device *, int, void *);
>   void (*release)(struct device *, void *);
>   struct component *component;
>   bool duplicate;
> @@ -75,6 +76,7 @@ struct component {
>   bool bound;
>  
>   const struct component_ops *ops;
> + int subcomponent;
>   struct device *dev;
>  };
>  
> @@ -159,7 +161,7 @@ static struct master *__master_find(struct device *dev,
>  }
>  
>  static struct component *find_component(struct master *master,
> - int (*compare)(struct device *, void *), void *compare_data)
> + struct component_match_array *mc)
>  {
>   struct component *c;
>  
> @@ -167,8 +169,13 @@ static struct component *find_component(struct master 
> *master,
>   if (c->master && c->master != master)
>   continue;
>  
> - if (compare(c->dev, compare_data))
> + if (mc->compare_typed) {
> + if (mc->compare_typed(c->dev, c->subcomponent,
> +   mc->data))
> + return c;
> + } else if (mc->compare(c->dev, mc->data)) {
>   return c;
> + }
>   }
>  
>   return NULL;
> @@ -193,7 +200,7 @@ static int find_components(struct master *master)
>   if (match->compare[i].component)
>   continue;
>  
> - c = find_component(master, mc->compare, mc->data);
> + c = find_component(master, mc);
>   if (!c) {
>   ret = -ENXIO;
>   break;
> @@ -328,29 +335,12 @@ static int component_match_realloc(struct device *dev,
>   return 0;
>  }
>  
> -/**
> - * component_match_add_release - add a compent match with release callback
> - * @master: device with the aggregate driver
> - * @matchptr: pointer to the list of component matches
> - * @release: release function for @compare_data
> - * @compare: compare function to match against all components
> - * @compare_data: opaque pointer passed to the @compare function
> - *
> - * This adds a new component match to the list stored in @matchptr, which the
> - * @master aggregate driver needs to function. @matchptr must be initialized 
> to
> - * NULL before adding the first match.
> - *
> - * The allocated match list in @matchptr is automatically released using devm
> - * actions. At that point @release will be called, to free any references 
> held
> - * by @compare_data, e.g. when @compare_data is a _node that must be
> - * released with of_node_put().
> - *
> - * See also component_match_add().
> - */
> -void component_match_add_release(struct device *master,
> +static void __component_match_add(struct device *master,
>   struct component_match **matchptr,
>   void (*release)(struct device *, void *),
> - int (*compare)(struct device *, void *), void *compare_data)
> + int (*compare)(struct device *, void *),
> + int (*compare_typed)(struct device *, int, void *),
> + void *compare_data)
>  {
>   struct component_match *match = *matchptr;
>  
> @@ -382,13 +372,69 @@ void component_match_add_release(struct device *master,
>   }
>  
>   match->compare[match->num].compare = compare;
> + match->compare[match->num].compare_typed = compare_typed;
>   match->compare[match->num].release = release;
>   match->compare[match->num].data = compare_data;
>   match->compare[match->num].component = NULL;
>   match->num++;
>  }
> +
> +/**
> + * component_match_add_release - add a compent match with release callback
> + * @master: 

Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel

[Daniel Vetter]

On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding 
> > > >  wrote:
> > > > >
> > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > eDP panels usually have EDID EEPROM, so there's no need to define 
> > > > > > panel
> > > > > > width/height or any modes/timings in dts. But this panel still may 
> > > > > > have
> > > > > > regulator and/or backlight.
> > > > > >
> > > > > > Signed-off-by: Vasily Khoruzhick 
> > > > > > ---
> > > > > >  .../devicetree/bindings/display/panel/panel-edp.txt| 7 
> > > > > > +++
> > > > > >  1 file changed, 7 insertions(+)
> > > > > >  create mode 100644 
> > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > >
> > > > > Please don't try to make panels look more generic than they really 
> > > > > are.
> > > > > You're going to have to provide a compatible string for your device 
> > > > > that
> > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > extra information that is panel specific, but you don't know that now.
> > > > > We have in the past thought that we didn't need things like prepare
> > > > > delay, but then we ran into situations where we did need them.
> > > > >
> > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > is faulty on some device.
> > > > 
> > > > Pinebook used several 768p panels that have slightly different timings
> > > > and recent batch uses 1080p panel.
> > > > 
> > > > What panel descriptor should I use as fallback?
> > > 
> > > You don't use panel descriptors as fallback. The simple-panel driver
> > > will bind to a panel device and use the corresponding descriptor. If
> > > your device tree contains the correct information, the descriptor is
> > > correct for the panel you have.
> > > 
> > > In other words you need to ensure that you have the correct panel in
> > > device tree for the board that you're using. This is exactly the same
> > > thing as for other devices.
> > > 
> > > One way to to this is to have separate device trees for each variant
> > > of the board that you want to support. Another variant may be to have
> > > a common device tree and then have some early firmware update the DTB
> > > with the correct panel information.
> > 
> > This would defeat the point of edp, which is to standardize the mess of
> > panels (at least somewhat) and avoid having to change the DT/ACPI
> > tables/firmware for every board you ship. Also, we do have DP quirking
> > infrastructure already (using the OUI), I think if there's something that
> > doesn't work then we should quirk it there.
> 
> The problem is that while the attempt may have been to standardize, it
> failed. It doesn't take into account any of the details such as timing
> between things like powering up the display and enabling the backlight
> or similar. I don't know how you'd want to "quirk" those kinds of
> requirements because they are highly panel specific.

Hm right, we get these from some firmware tables (and mix them with the
spec one, since some of the firmware values are nonsense). I don't even
know whether we can read the timings over dp aux somehow (you can power up
the panel with some pessimistic values to figure those out, and you only
need dp aux to work, which is much simpler than the entire panel).

> > What does make sense though imo is if we try not to stuff the edp panel
> > into panel-simple, because it's anything like a simple dumb panel. There's
> > also some integration awkwardness since with this panel you need to do dp
> > aux/i2c transactions to get at the information (edid alone isn't good
> > enough for edp), and I'm not sure how exactly that's supposed to be
> > instantiated. Maybe a special function to instantiate an edp panel, which
> > takes both a DT node and the dp_aux controller would be much better,
> > instead of trying to auto-match against a DT compatible string and load a
> > panel driver which is almost all fake.
> > 
> > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > can get hold of the dp_aux channel it needs.
> 
> We already do that. drm_dp_aux registers as an I2C adapter that can be
> used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> use that on some platforms.
> 
> Also note that simple-panel already supports getting video timings from
> EDID. If a DDC link is present in DT, the driver will load the modes
> from EDID and use them.

Could we 

Re: [PATCH] drm/rockchip: Use drm_fbdev_generic_setup()

[Noralf Trønnes]

Den 04.02.2019 16.01, skrev Rob Herring:
> On Sat, Feb 2, 2019 at 12:22 PM Noralf Trønnes  wrote:
>> Den 02.02.2019 18.07, skrev Rob Herring:
>>> Other than using a rockchip_gem_object directly, the Rockchip fbdev
>>> setup has nothing special and can be converted to use the generic fbdev
>>> emulation instead.
> 
> [...]
> 
>>> -static int rockchip_drm_fbdev_create(struct drm_fb_helper *helper,
>>> -  struct drm_fb_helper_surface_size *sizes)
>>> -{
>>> - struct rockchip_drm_private *private = to_drm_private(helper);
>>> - struct drm_mode_fb_cmd2 mode_cmd = { 0 };
>>> - struct drm_device *dev = helper->dev;
>>> - struct rockchip_gem_object *rk_obj;
>>> - struct drm_framebuffer *fb;
>>> - unsigned int bytes_per_pixel;
>>> - unsigned long offset;
>>> - struct fb_info *fbi;
>>> - size_t size;
>>> - int ret;
>>> -
>>> - bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
>>> -
>>> - mode_cmd.width = sizes->surface_width;
>>> - mode_cmd.height = sizes->surface_height;
>>> - mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel;
>>> - mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
>>> - sizes->surface_depth);
>>> -
>>> - size = mode_cmd.pitches[0] * mode_cmd.height;
>>> -
>>> - rk_obj = rockchip_gem_create_object(dev, size, true);
>>
>> I don't think the generic emulation in it's current form will work for
>> rockchip. rockchip treats fbdev buffers and dumb buffers differently. If
>> it uses DMA buffers, then the dumb buffer can't get a virtual address.
> 
> Yes, you are right. I tested the iommu case.
> 
>> From rockchip_gem_alloc_dma():
>>
>> if (!alloc_kmap)
>> rk_obj->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
>>
>> From rockchip_gem_prime_vmap():
>>
>> if (rk_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
>> return NULL;
>>
>> Maybe it's possible to vmap a buffer created using dma_alloc_attrs()
>> after the allocation?
> 
> It should be possible I think as that is what
> drm_gem_cma_prime_import_sg_table_vmap() does. One problem though is
> you may already have a mapping because DMA_ATTR_NO_KERNEL_MAPPING is
> just a suggestion (only 32-bit ARM implements) and there's not a way
> to tell if you got a mapping or not. Maybe it's not all that important
> if there are 2 mappings because I think only fbcon needs a kernel
> mapping.
> 
> My follow-up to this was going to be converting Rockchip to use CMA
> and the shmem helpers. So I was already wondering about what to do
> with DMA_ATTR_NO_KERNEL_MAPPING. There's several drivers not using CMA
> just to set DMA_ATTR_NO_KERNEL_MAPPING. So it would be good to come up
> with a solution here.
> 

Here's part of a discussion concerning the mediatek driver (couldn't
find it in the dri-devel archives):

Re: [PATCH] drm/mediatek: Add MTK Framebuffer-Device (mt7623)

> On Fri, 2019-01-11 at 17:07 +0100, Noralf Trønnes wrote:
...
> > The problem here is that this driver doesn't map a virtual address for
> > its buffers:
> > mtk_gem->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
> >
> > Probably because of limited virtual address space.
> > rockchip is in the same situation.
> >
> > I'm aware of this shortcoming of the generic emulation, but I don't see
> > how it can be solved without using somekind of flag attached to the dumb
> > buffer creation request.
>
> The virtual address space is limited so we do not map it by default. I
> also see the shortcoming of the generic emulation, so I would refer to
> rockchip to implement this mapping.
>
> Regards,
> CK

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

[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering

[bugzilla-daemon]

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

--- Comment #14 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
FreeSync not working on WINE is a Mesa issue I believe.

I don't think the backend WINE goes through is DRI3 which is required to use
the present extension / support page-flipping through X to DRM.

The flickering I'm not quite sure about. I don't think I've observed it
happening lately in amd-staging-drm-next on Raven or Vega when running any of
the Unigine benchmarks at varying settings (dipping below and into the VRR
range).

Do you mind booting with drm.debug=4 and posting a dmesg log when you're
running the Unigine Valley benchmark? It would also help to know what desktop
environment/compositor you're using.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 1/2] xf86drm: fallback to MODALIAS for OF less platform devices

[Emil Velikov]

On Fri, 1 Feb 2019 at 14:15, Lucas Stach  wrote:
>
> Hi Emil,
>

> > > For reference with this patch drmdevice and other drmDevice API users 
> > > list:
> > >  - VGEM, needs "drm/vgem: Fix vgem_init to get drm device available."
> > > - in v5.0 only :'-(
> > >  - etnaviv, after "drm/etnaviv: remove the need for a gpu-subsystem DT
> > > node" landed in v4.17/18
> > >
> >
> > Christian can you please test that this patches brings etnaviv back to the 
> > list?
> > Above is a reasonable assumption, yet assumption never the less.
>
> I can confirm that with this patch applied
> loader_open_render_node("etnaviv") works as intended.
>
Amazing, thank you Lucas.
Pushed to master.

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

Re: [Intel-gfx] [PATCH 2/6] drm/drv: Prepare to remove drm_dev_unplug()

[Daniel Vetter]

On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
> 
> Signed-off-by: Noralf Trønnes 
> ---
> 
> Maybe s/unplugged/unregistered/ ?
> 
> I looked at drm_device->registered, but using that would mean that
> drm_dev_is_unplugged() would return before drm_device is registered.
> And given that its current purpose is to prevent race against connector
> registration, I stayed away from it.

Yeah I think we need to keep the registered state separate from unplugged.
Iirc this exact scenario is what we discussed when you revamped the
unplug infrastructure.

> 
> Noralf.
> 
> 
>  drivers/gpu/drm/drm_drv.c | 27 +++
>  include/drm/drm_drv.h | 10 --
>  2 files changed, 19 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 05bbc2b622fc..e0941200edc6 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -366,15 +366,6 @@ EXPORT_SYMBOL(drm_dev_exit);
>   */
>  void drm_dev_unplug(struct drm_device *dev)
>  {
> - /*
> -  * After synchronizing any critical read section is guaranteed to see
> -  * the new value of ->unplugged, and any critical section which might
> -  * still have seen the old value of ->unplugged is guaranteed to have
> -  * finished.
> -  */
> - dev->unplugged = true;
> - synchronize_srcu(_unplug_srcu);
> -
>   drm_dev_unregister(dev);
>   drm_dev_put(dev);
>  }
> @@ -832,11 +823,14 @@ EXPORT_SYMBOL(drm_dev_register);
>   * drm_dev_register() but does not deallocate the device. The caller must 
> call
>   * drm_dev_put() to drop their final reference.
>   *
> - * A special form of unregistering for hotpluggable devices is 
> drm_dev_unplug(),
> - * which can be called while there are still open users of @dev.
> + * This function can be called while there are still open users of @dev as 
> long
> + * as the driver protects its device resources using drm_dev_enter() and
> + * drm_dev_exit().
>   *
>   * This should be called first in the device teardown code to make sure
> - * userspace can't access the device instance any more.
> + * userspace can't access the device instance any more. Drivers that support
> + * device unplug will probably want to call drm_atomic_helper_shutdown() 
> first

Read once more with a bit more coffee, spotted this:

s/first/afterwards/ - shutting down the hw before we've taken it away from
userspace is kinda the wrong way round. It should be the inverse of driver
load, which is 1) allocate structures 2) prep hw 3) register driver with
the world (simplified ofc).

> + * in order to disable the hardware on regular driver module unload.
>   */
>  void drm_dev_unregister(struct drm_device *dev)
>  {
> @@ -845,6 +839,15 @@ void drm_dev_unregister(struct drm_device *dev)
>   if (drm_core_check_feature(dev, DRIVER_LEGACY))
>   drm_lastclose(dev);
>  
> + /*
> +  * After synchronizing any critical read section is guaranteed to see
> +  * the new value of ->unplugged, and any critical section which might
> +  * still have seen the old value of ->unplugged is guaranteed to have
> +  * finished.
> +  */
> + dev->unplugged = true;
> + synchronize_srcu(_unplug_srcu);
> +
>   dev->registered = false;
>  
>   drm_client_dev_unregister(dev);
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index ca46a45a9cce..c50696c82a42 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -736,13 +736,11 @@ void drm_dev_unplug(struct drm_device *dev);
>   * drm_dev_is_unplugged - is a DRM device unplugged
>   * @dev: DRM device
>   *
> - * This function can be called to check whether a hotpluggable is unplugged.
> - * Unplugging itself is singalled through drm_dev_unplug(). If a device is
> - * unplugged, these two functions guarantee that any store before calling
> - * drm_dev_unplug() is visible to callers of this function after it completes
> + * This function can be called to check whether @dev is unregistered. This 
> can
> + * be used to detect that the underlying parent device is gone.

I think it'd be good to keep the first part, and just update the reference
to drm_dev_unregister. So:

 * This function can be called to check whether a hotpluggable is unplugged.
 * Unplugging itself is singalled through drm_dev_unregister(). If a device is
 * unplugged, these two functions guarantee that any store before calling
 * drm_dev_unregister() is visible to callers of this function after it
 * completes.

I think your version shrugs a few important details under the rug. With
those nits addressed:

Reviewed-by: Daniel Vetter 

Cheers, Daniel

>   *
> - * WARNING: This function fundamentally races against drm_dev_unplug(). It is
> - * recommended that drivers instead use the 

[Bug 109539] System freezing

[bugzilla-daemon]

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

--- Comment #1 from Nicholas Kazlauskas  ---
The freezing doesn't seem to be necessarily caused by by something in amdgpu
from a glance at your log.

There are some DC warnings/errors that describe what you're seeing with your
monitor not waking from sleep however.

Please post a full dmesg log from system boot and an xorg log if you're using
X. It may also help to know what window manager you're using when you see this
issue occur.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v10 38/40] drm/i915: Fix KBL HDCP2.2 encrypt status signalling

[C, Ramalingam]

daniel,

Could you please review this patch too.? Already Updated this as per 
your previous review comment.


--Ram

On 1/31/2019 12:29 PM, Ramalingam C wrote:

Implement the required WA sequence for KBL to fix the
incorrect positioning of the window of oppurtunity and enc_en
signalling.

v2:
   WA is moved into the toggle_signalling [Daniel]

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_hdmi.c | 42 +++
  1 file changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 2c4bf6d0c39f..ae20288f7bbf 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1083,10 +1083,44 @@ int intel_hdmi_hdcp_read_v_prime_part(struct 
intel_digital_port *intel_dig_port,
return ret;
  }
  
+static int kbl_repositioning_enc_en_signal(struct intel_connector *connector)

+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct drm_crtc *crtc = connector->base.state->crtc;
+   struct intel_crtc *intel_crtc = container_of(crtc,
+struct intel_crtc, base);
+   u32 scanline;
+   int ret;
+
+   for (;;) {
+   scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
+   if (scanline > 100 && scanline < 200)
+   break;
+   usleep_range(25, 50);
+   }
+
+   ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, false);
+   if (ret) {
+   DRM_ERROR("Disable HDCP signalling failed (%d)\n", ret);
+   return ret;
+   }
+   ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, true);
+   if (ret) {
+   DRM_ERROR("Enable HDCP signalling failed (%d)\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
  static
  int intel_hdmi_hdcp_toggle_signalling(struct intel_digital_port 
*intel_dig_port,
  bool enable)
  {
+   struct intel_hdmi *hdmi = _dig_port->hdmi;
+   struct intel_connector *connector = hdmi->attached_connector;
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
int ret;
  
  	if (!enable)

@@ -1098,6 +1132,14 @@ int intel_hdmi_hdcp_toggle_signalling(struct 
intel_digital_port *intel_dig_port,
  enable ? "Enable" : "Disable", ret);
return ret;
}
+
+   /*
+* WA: To fix incorrect positioning of the window of
+* opportunity and enc_en signalling in KABYLAKE.
+*/
+   if (IS_KABYLAKE(dev_priv) && enable)
+   return kbl_repositioning_enc_en_signal(connector);
+
return 0;
  }
  


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

[Bug 108037] Turning monitors off and on again makes the kernel panic and system freeze

[bugzilla-daemon]

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

--- Comment #12 from Öyvind Saether  ---
Created attachment 143286
  --> https://bugs.freedesktop.org/attachment.cgi?id=143286=edit
Kernel 5.0.0-rc5 still has this problem

[27295.165873] Call Trace:  
[27295.165917]  ? dc_validate_stream+0x5d/0x90 [amdgpu] 
[27295.165921]  ? radix_tree_delete_item+0x69/0xc0
[27295.165958]  dc_stream_release+0x28/0x50 [amdgpu]
[27295.165997]  dc_resource_state_destruct+0x4d/0x70 [amdgpu]
[27295.166035]  dc_state_free+0x15/0x20 [amdgpu]
[27295.166076]  dm_atomic_destroy_state+0x1c/0x30 [amdgpu]
[27295.166089]  drm_atomic_state_default_clear+0x201/0x280 [drm]
[27295.166099]  __drm_atomic_state_free+0x13/0x50 [drm]
[27295.166105]  drm_atomic_helper_set_config+0x5a/0x90 [drm_kms_helper]
[27295.166115]  drm_mode_setcrtc+0x191/0x670 [drm]
[27295.166148]  ? amdgpu_cs_wait_ioctl+0x92/0x160 [amdgpu]
[27295.166157]  ? drm_mode_getcrtc+0x180/0x180 [drm]
[27295.166165]  drm_ioctl_kernel+0xa9/0xf0 [drm]
[27295.166174]  drm_ioctl+0x207/0x3c0 [drm]
[27295.166183]  ? drm_mode_getcrtc+0x180/0x180 [drm]
[27295.166213]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[27295.166216]  do_vfs_ioctl+0xa5/0x620
[27295.166218]  ksys_ioctl+0x60/0x90
[27295.166219]  __x64_sys_ioctl+0x16/0x20
[27295.166221]  do_syscall_64+0x55/0x150
[27295.166224]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[27295.166226] RIP: 0033:0x7f78fac8909b

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property

[Ville Syrjälä]

On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
> > Create a new connector property to program colorspace to sink
> > devices. Modern sink devices support more than 1 type of
> > colorspace like 601, 709, BT2020 etc. This helps to switch
> > based on content type which is to be displayed. The decision
> > lies with compositors as to in which scenarios, a particular
> > colorspace will be picked.
> > 
> > This will be helpful mostly to switch to higher gamut colorspaces
> > like BT2020 when the media content is encoded as BT2020. Thereby
> > giving a good visual experience to users.
> > 
> > The expectation from userspace is that it should parse the EDID
> > and get supported colorspaces. Use this property and switch to the
> > one supported. Sink supported colorspaces should be retrieved by
> > userspace from EDID and driver will not explicitly expose them.
> > 
> > Basically the expectation from userspace is:
> >  - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> >colorspace
> >  - Set this new property to let the sink know what it
> >converted the CRTC output to.
> > 
> > v2: Addressed Maarten and Ville's review comments. Enhanced
> > the colorspace enum to incorporate both HDMI and DP supported
> > colorspaces. Also, added a default option for colorspace.
> > 
> > v3: Removed Adobe references from enum definitions as per
> > Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
> > Default to an unset state where driver will assign the colorspace
> > is not chosen by user, suggested by Ville and Maarten. Addressed
> > other misc review comments from Maarten. Split the changes to
> > have separate colorspace property for DP and HDMI.
> > 
> > v4: Addressed Chris and Ville's review comments, and created a
> > common colorspace property for DP and HDMI, filtered the list
> > based on the colorspaces supported by the respective protocol
> > standard.
> > 
> > v5: Made the property creation helper accept enum list based on
> > platform capabilties as suggested by Shashank. Consolidated HDMI
> > and DP property creation in the common helper.
> > 
> > v6: Addressed Shashank's review comments.
> > 
> > v7: Added defines instead of enum in uapi as per Brian Starkey's
> > suggestion in order to go with string matching at userspace. Updated
> > the commit message to add more details as well kernel docs.
> > 
> > v8: Addressed Maarten's review comments.
> > 
> > v9: Removed macro defines from uapi as per Brian Starkey and Daniel
> > Stone's comments and moved to drm include file. Moved back to older
> > design with exposing all HDMI colorspaces to userspace since infoframe
> > capability is there even on legacy platforms, as per Ville's review
> > comments.
> > 
> > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
> > 
> > Signed-off-by: Uma Shankar 
> > Acked-by: Jani Nikula 
> > Reviewed-by: Shashank Sharma 
> > Reviewed-by: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/drm_atomic_uapi.c |  4 +++
> >  drivers/gpu/drm/drm_connector.c   | 75 
> > +++
> >  include/drm/drm_connector.h   | 46 
> >  3 files changed, 125 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 9a1f41a..9b5d44f 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct 
> > drm_connector *connector,
> > return -EINVAL;
> > }
> > state->content_protection = val;
> > +   } else if (property == connector->colorspace_property) {
> > +   state->colorspace = val;
> > } else if (property == config->writeback_fb_id_property) {
> > struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
> > val);
> > int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
> > @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct 
> > drm_connector *connector,
> > *val = state->picture_aspect_ratio;
> > } else if (property == config->content_type_property) {
> > *val = state->content_type;
> > +   } else if (property == connector->colorspace_property) {
> > +   *val = state->colorspace;
> > } else if (property == connector->scaling_mode_property) {
> > *val = state->scaling_mode;
> > } else if (property == connector->content_protection_property) {
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index 8475396..ed10dd9 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -826,6 +826,30 @@ int drm_display_info_set_bus_formats(struct 
> > drm_display_info *info,
> >  };
> >  DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> >  
> > 

Re: [PATCH v10 02/40] i915/snd_hdac: I915 subcomponent for the snd_hdac

[Takashi Iwai]

On Mon, 04 Feb 2019 16:00:18 +0100,
Daniel Vetter wrote:
> 
> On Thu, Jan 31, 2019 at 12:29:18PM +0530, Ramalingam C wrote:
> > From: Daniel Vetter 
> > 
> > Since we need multiple components for I915 for different purposes
> > (Audio & Mei_hdcp), we adopt the subcomponents methodology introduced
> > by the previous patch (mentioned below).
> > 
> > Author: Daniel Vetter 
> > Date:   Mon Jan 28 17:08:20 2019 +0530
> > 
> > components: multiple components for a device
> > 
> > Signed-off-by: Daniel Vetter 
> > Signed-off-by: Ramalingam C 
> > cc: Greg Kroah-Hartman 
> > cc: Russell King 
> > cc: Rafael J. Wysocki 
> > cc: Jaroslav Kysela 
> > cc: Takashi Iwai 
> > cc: Rodrigo Vivi 
> > cc: Jani Nikula 
> 
> Takashi, can you pls take a look and ack for merging through drm-intel? We
> can also do a topic branch in case this conflicts with something on the
> audio side.

I'm fine with the change as long as others agree with this API
extension.

Reviewed-by: Takashi Iwai 


thanks,

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

Re: [PATCH] intel: Add more PCI Device IDs for Coffee Lake and Ice Lake.

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 02/02/2019 08:07, Rodrigo Vivi wrote:

Align with kernel commits:

5e0f5a58b167 ("drm/i915/cfl: Adding another PCI Device ID.")
03ca3cf8e9aa ("drm/i915/icl: Adding few more device IDs for Ice Lake")

Cc: José Roberto de Souza 
Cc: Kenneth Graunke 
Cc: Anuj Phogat 
Signed-off-by: Rodrigo Vivi 
---
  include/pci_ids/i965_pci_ids.h | 5 +
  1 file changed, 5 insertions(+)

diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index 7201562d82..b91abd7a3f 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_ids.h
@@ -171,6 +171,7 @@ CHIPSET(0x3185, glk_2x6, "Intel(R) UHD Graphics 600 (Geminilake 
2x6)")
  CHIPSET(0x3E90, cfl_gt1, "Intel(R) UHD Graphics 610 (Coffeelake 2x6 GT1)")
  CHIPSET(0x3E93, cfl_gt1, "Intel(R) UHD Graphics 610 (Coffeelake 2x6 GT1)")
  CHIPSET(0x3E99, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
+CHIPSET(0x3E9C, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
  CHIPSET(0x3E91, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
  CHIPSET(0x3E92, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
  CHIPSET(0x3E96, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
@@ -203,6 +204,10 @@ CHIPSET(0x5A54, cnl_5x8, "Intel(R) HD Graphics (Cannonlake 5x8 
GT2)")
  CHIPSET(0x8A50, icl_8x8, "Intel(R) HD Graphics (Ice Lake 8x8 GT2)")
  CHIPSET(0x8A51, icl_8x8, "Intel(R) HD Graphics (Ice Lake 8x8 GT2)")
  CHIPSET(0x8A52, icl_8x8, "Intel(R) HD Graphics (Ice Lake 8x8 GT2)")
+CHIPSET(0x8A56, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
+CHIPSET(0x8A57, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
+CHIPSET(0x8A58, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
+CHIPSET(0x8A59, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
  CHIPSET(0x8A5A, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
  CHIPSET(0x8A5B, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
  CHIPSET(0x8A5C, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")



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

Re: [PATCH] drm/rockchip: Use drm_fbdev_generic_setup()

[Rob Herring]

On Sat, Feb 2, 2019 at 12:22 PM Noralf Trønnes  wrote:
> Den 02.02.2019 18.07, skrev Rob Herring:
> > Other than using a rockchip_gem_object directly, the Rockchip fbdev
> > setup has nothing special and can be converted to use the generic fbdev
> > emulation instead.

[...]

> > -static int rockchip_drm_fbdev_create(struct drm_fb_helper *helper,
> > -  struct drm_fb_helper_surface_size *sizes)
> > -{
> > - struct rockchip_drm_private *private = to_drm_private(helper);
> > - struct drm_mode_fb_cmd2 mode_cmd = { 0 };
> > - struct drm_device *dev = helper->dev;
> > - struct rockchip_gem_object *rk_obj;
> > - struct drm_framebuffer *fb;
> > - unsigned int bytes_per_pixel;
> > - unsigned long offset;
> > - struct fb_info *fbi;
> > - size_t size;
> > - int ret;
> > -
> > - bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
> > -
> > - mode_cmd.width = sizes->surface_width;
> > - mode_cmd.height = sizes->surface_height;
> > - mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel;
> > - mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
> > - sizes->surface_depth);
> > -
> > - size = mode_cmd.pitches[0] * mode_cmd.height;
> > -
> > - rk_obj = rockchip_gem_create_object(dev, size, true);
>
> I don't think the generic emulation in it's current form will work for
> rockchip. rockchip treats fbdev buffers and dumb buffers differently. If
> it uses DMA buffers, then the dumb buffer can't get a virtual address.

Yes, you are right. I tested the iommu case.

> From rockchip_gem_alloc_dma():
>
> if (!alloc_kmap)
> rk_obj->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
>
> From rockchip_gem_prime_vmap():
>
> if (rk_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> return NULL;
>
> Maybe it's possible to vmap a buffer created using dma_alloc_attrs()
> after the allocation?

It should be possible I think as that is what
drm_gem_cma_prime_import_sg_table_vmap() does. One problem though is
you may already have a mapping because DMA_ATTR_NO_KERNEL_MAPPING is
just a suggestion (only 32-bit ARM implements) and there's not a way
to tell if you got a mapping or not. Maybe it's not all that important
if there are 2 mappings because I think only fbcon needs a kernel
mapping.

My follow-up to this was going to be converting Rockchip to use CMA
and the shmem helpers. So I was already wondering about what to do
with DMA_ATTR_NO_KERNEL_MAPPING. There's several drivers not using CMA
just to set DMA_ATTR_NO_KERNEL_MAPPING. So it would be good to come up
with a solution here.

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

Re: [PATCH v10 02/40] i915/snd_hdac: I915 subcomponent for the snd_hdac

[Daniel Vetter]

On Thu, Jan 31, 2019 at 12:29:18PM +0530, Ramalingam C wrote:
> From: Daniel Vetter 
> 
> Since we need multiple components for I915 for different purposes
> (Audio & Mei_hdcp), we adopt the subcomponents methodology introduced
> by the previous patch (mentioned below).
> 
>   Author: Daniel Vetter 
>   Date:   Mon Jan 28 17:08:20 2019 +0530
> 
>   components: multiple components for a device
> 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Ramalingam C 
> cc: Greg Kroah-Hartman 
> cc: Russell King 
> cc: Rafael J. Wysocki 
> cc: Jaroslav Kysela 
> cc: Takashi Iwai 
> cc: Rodrigo Vivi 
> cc: Jani Nikula 

Takashi, can you pls take a look and ack for merging through drm-intel? We
can also do a topic branch in case this conflicts with something on the
audio side.

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/intel_audio.c | 4 +++-
>  include/drm/i915_component.h   | 4 
>  include/sound/hda_component.h  | 5 +++--
>  sound/hda/hdac_component.c | 4 ++--
>  sound/hda/hdac_i915.c  | 6 --
>  5 files changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index de26cd0a5497..5104c6bbd66f 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -984,7 +984,9 @@ void i915_audio_component_init(struct drm_i915_private 
> *dev_priv)
>  {
>   int ret;
>  
> - ret = component_add(dev_priv->drm.dev, _audio_component_bind_ops);
> + ret = component_add_typed(dev_priv->drm.dev,
> +   _audio_component_bind_ops,
> +   I915_COMPONENT_AUDIO);
>   if (ret < 0) {
>   DRM_ERROR("failed to add audio component (%d)\n", ret);
>   /* continue with reduced functionality */
> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> index fca22d463e1b..72fbb037f9b3 100644
> --- a/include/drm/i915_component.h
> +++ b/include/drm/i915_component.h
> @@ -26,6 +26,10 @@
>  
>  #include "drm_audio_component.h"
>  
> +enum i915_component_type {
> + I915_COMPONENT_AUDIO = 1,
> +};
> +
>  /* MAX_PORT is the number of port
>   * It must be sync with I915_MAX_PORTS defined i915_drv.h
>   */
> diff --git a/include/sound/hda_component.h b/include/sound/hda_component.h
> index 2ec31b358950..d4804c72d959 100644
> --- a/include/sound/hda_component.h
> +++ b/include/sound/hda_component.h
> @@ -20,7 +20,7 @@ int snd_hdac_acomp_get_eld(struct hdac_device *codec, 
> hda_nid_t nid, int dev_id,
>  bool *audio_enabled, char *buffer, int max_bytes);
>  int snd_hdac_acomp_init(struct hdac_bus *bus,
>   const struct drm_audio_component_audio_ops *aops,
> - int (*match_master)(struct device *, void *),
> + int (*match_master)(struct device *, int, void *),
>   size_t extra_size);
>  int snd_hdac_acomp_exit(struct hdac_bus *bus);
>  int snd_hdac_acomp_register_notifier(struct hdac_bus *bus,
> @@ -47,7 +47,8 @@ static inline int snd_hdac_acomp_get_eld(struct hdac_device 
> *codec, hda_nid_t ni
>  }
>  static inline int snd_hdac_acomp_init(struct hdac_bus *bus,
> const struct 
> drm_audio_component_audio_ops *aops,
> -   int (*match_master)(struct device *, void 
> *),
> +   int (*match_master)(struct device *,
> +   int, void *),
> size_t extra_size)
>  {
>   return -ENODEV;
> diff --git a/sound/hda/hdac_component.c b/sound/hda/hdac_component.c
> index a6d37b9d6413..5c95933e739a 100644
> --- a/sound/hda/hdac_component.c
> +++ b/sound/hda/hdac_component.c
> @@ -269,7 +269,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_acomp_register_notifier);
>   */
>  int snd_hdac_acomp_init(struct hdac_bus *bus,
>   const struct drm_audio_component_audio_ops *aops,
> - int (*match_master)(struct device *, void *),
> + int (*match_master)(struct device *, int, void *),
>   size_t extra_size)
>  {
>   struct component_match *match = NULL;
> @@ -288,7 +288,7 @@ int snd_hdac_acomp_init(struct hdac_bus *bus,
>   bus->audio_component = acomp;
>   devres_add(dev, acomp);
>  
> - component_match_add(dev, , match_master, bus);
> + component_match_add_typed(dev, , match_master, bus);
>   ret = component_master_add_with_match(dev, _component_master_ops,
> match);
>   if (ret < 0)
> diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> index 617ff1aa818f..7aee090e3d27 100644
> --- a/sound/hda/hdac_i915.c
> +++ b/sound/hda/hdac_i915.c
> @@ -82,9 +82,11 @@ void snd_hdac_i915_set_bclk(struct hdac_bus *bus)
>  }
>  EXPORT_SYMBOL_GPL(snd_hdac_i915_set_bclk);
>  
> -static int 

Re: [PATCH v10 12/40] drm: HDCP2.2 link check period

[C, Ramalingam]

On 2/4/2019 7:54 PM, Shankar, Uma wrote:



-Original Message-
From: C, Ramalingam
Sent: Thursday, January 31, 2019 12:29 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
Uma 
Cc: C, Ramalingam 
Subject: [PATCH v10 12/40] drm: HDCP2.2 link check period

Time period for HDCP2.2 link check.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 

Not sure if we need a separate patch for this. Could be merged where check_link 
is
introduced for hdcp2.2.

If there is a valid reasoning, no hard objection and it looks ok in general. So
drm level change is convenient to have in separate patch to get approval 
from dri-devel.


--Ram


Reviewed-by: Uma Shankar 


---
include/drm/drm_hdcp.h | 1 +
1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index
7260b31af276..d4e98b11b4aa 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -13,6 +13,7 @@

/* Period of hdcp checks (to ensure we're still authenticated) */
#define DRM_HDCP_CHECK_PERIOD_MS(128 * 16)
+#define DRM_HDCP2_CHECK_PERIOD_MS  500

/* Shared lengths/masks between HDMI/DVI/DisplayPort */
#define DRM_HDCP_AN_LEN 8
--
2.7.4


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

Re: [PATCH v10 07/40] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking

[C, Ramalingam]

On 2/4/2019 7:39 PM, Shankar, Uma wrote:



-Original Message-
From: C, Ramalingam
Sent: Thursday, January 31, 2019 12:29 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
Uma 
Cc: C, Ramalingam 
Subject: [PATCH v10 07/40] drm/i915: hdcp1.4 CP_IRQ handling and SW
encryption tracking

"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
This SW tracking is used to determine the need for real hdcp1.4 disable and
hdcp_check_link upon CP_IRQ.

On CP_IRQ we filter the CP_IRQ related to the states like Link failure and
reauthentication req etc and handle them in hdcp_check_link.
CP_IRQ corresponding to the authentication msg availability are ignored.

WARN_ON is added for the abrupt stop of HDCP encryption of a port.

v2:
  bool is used in struct for the cleaner coding. [Daniel]
  check_link work_fn is scheduled for cp_irq handling [Daniel]

Signed-off-by: Ramalingam C 
---
drivers/gpu/drm/i915/intel_dp.c   |  2 +-
drivers/gpu/drm/i915/intel_drv.h  |  5 ++-  drivers/gpu/drm/i915/intel_hdcp.c |
73 ---
3 files changed, 58 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 815ee68efa2f..9ce05819fc11 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4776,7 +4776,7 @@ static void intel_dp_check_service_irq(struct intel_dp
*intel_dp)
intel_dp_handle_test_request(intel_dp);

if (val & DP_CP_IRQ)
-   intel_hdcp_check_link(intel_dp->attached_connector);
+   intel_hdcp_handle_cp_irq(intel_dp->attached_connector);

if (val & DP_SINK_SPECIFIC_IRQ)
DRM_DEBUG_DRIVER("Sink specific irq unhandled\n"); diff --git
a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 63e009286d5f..13a41e8cf4ff 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -399,6 +399,9 @@ struct intel_hdcp {
struct delayed_work check_work;
struct work_struct prop_work;

+   /* HDCP1.4 Encryption status */
+   bool hdcp_encrypted;
+
/* HDCP2.2 related definitions */
/* Flag indicates whether this connector supports HDCP2.2 or not. */
bool hdcp2_supported;
@@ -2073,10 +2076,10 @@ int intel_hdcp_init(struct intel_connector
*connector,
bool hdcp2_supported);
int intel_hdcp_enable(struct intel_connector *connector);  int
intel_hdcp_disable(struct intel_connector *connector); -int
intel_hdcp_check_link(struct intel_connector *connector);  bool
is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);  bool
intel_hdcp_capable(struct intel_connector *connector);  bool
is_hdcp2_supported(struct drm_i915_private *dev_priv);
+void intel_hdcp_handle_cp_irq(struct intel_connector *connector);

/* intel_psr.c */
#define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index e0bb5f32ba90..c1b057f1501b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -74,6 +74,16 @@ bool intel_hdcp_capable(struct intel_connector
*connector)
return capable;
}

+static inline bool intel_hdcp_in_use(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   enum port port = connector->encoder->port;
+   u32 reg;
+
+   reg = I915_READ(PORT_HDCP_STATUS(port));
+   return reg & HDCP_STATUS_ENC;
+}
+
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)  { @@ -
668,6 +678,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
  connector->base.name, connector->base.base.id);

+   hdcp->hdcp_encrypted = false;
I915_WRITE(PORT_HDCP_CONF(port), 0);
if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
@@ -713,8 +724,10 @@ static int _intel_hdcp_enable(struct intel_connector
*connector)
/* Incase of authentication failures, HDCP spec expects reauth. */
for (i = 0; i < tries; i++) {
ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp-

shim);

-   if (!ret)
+   if (!ret) {
+   hdcp->hdcp_encrypted = true;
return 0;
+   }

DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);

@@ -741,16 +754,17 @@ int intel_hdcp_check_link(struct intel_connector
*connector)
enum port port = intel_dig_port->base.port;
int ret = 0;

-   if (!hdcp->shim)
-   return -ENOENT;
-
mutex_lock(>mutex);

RE: [PATCH v10 15/40] drm: removing the DP Errata msg and its msg id

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 15/40] drm: removing the DP Errata msg and its msg id
>
>Since DP ERRATA message is not defined at spec, those structure definition is
>removed from drm_hdcp.h

I believe we still want to have it but inside the driver isn't it ?, would be 
good to
add a comment on that.

With that fixed.
Reviewed-by: Uma Shankar 
>
>Signed-off-by: Ramalingam C 
>Suggested-by: Daniel Vetter 


>---
> include/drm/drm_hdcp.h | 6 --
> 1 file changed, 6 deletions(-)
>
>diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index
>d4e98b11b4aa..f243408ecf26 100644
>--- a/include/drm/drm_hdcp.h
>+++ b/include/drm/drm_hdcp.h
>@@ -69,7 +69,6 @@
> #define HDCP_2_2_REP_SEND_ACK 15
> #define HDCP_2_2_REP_STREAM_MANAGE16
> #define HDCP_2_2_REP_STREAM_READY 17
>-#define HDCP_2_2_ERRATA_DP_STREAM_TYPE50
>
> #define HDCP_2_2_RTX_LEN  8
> #define HDCP_2_2_RRX_LEN  8
>@@ -220,11 +219,6 @@ struct hdcp2_rep_stream_ready {
>   u8  m_prime[HDCP_2_2_MPRIME_LEN];
> } __packed;
>
>-struct hdcp2_dp_errata_stream_type {
>-  u8  msg_id;
>-  u8  stream_type;
>-} __packed;
>-
> /* HDCP2.2 TIMEOUTs in mSec */
> #define HDCP_2_2_CERT_TIMEOUT_MS  100
> #define HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS  1000
>--
>2.7.4

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

RE: [PATCH v10 14/40] drm/i915: Handle HDCP2.2 downstream topology change

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 14/40] drm/i915: Handle HDCP2.2 downstream topology
>change
>
>When repeater notifies a downstream topology change, this patch
>reauthenticate the repeater alone without disabling the hdcp encryption. If 
>that
>fails then complete reauthentication is executed.
>
>v2:
>  Rebased.
>v3:
>  Typo in commit msg is fixed [Uma]
>v4:
>  Rebased as part of patch reordering.
>  Minor style fixes.
>v5:
>  Rebased.
>v6:
>  Rebased.
>v7:
>  Errors due to sinks are reported as DEBUG logs.
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

The latest version is ok. You can keep the RB.

>---
> drivers/gpu/drm/i915/intel_hdcp.c | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 3feff921a547..7ff29fb0aa2f 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -1617,8 +1617,24 @@ static int intel_hdcp2_check_link(struct
>intel_connector *connector)
>   goto out;
>   }
>
>-  DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
>-connector->base.name, connector->base.base.id);
>+  if (ret == HDCP_TOPOLOGY_CHANGE) {
>+  if (hdcp->value ==
>DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
>+  goto out;
>+
>+  DRM_DEBUG_KMS("HDCP2.2 Downstream topology change\n");
>+  ret = hdcp2_authenticate_repeater_topology(connector);
>+  if (!ret) {
>+  hdcp->value =
>DRM_MODE_CONTENT_PROTECTION_ENABLED;
>+  schedule_work(>prop_work);
>+  goto out;
>+  }
>+  DRM_DEBUG_KMS("[%s:%d] Repeater topology auth
>failed.(%d)\n",
>+connector->base.name, connector->base.base.id,
>+ret);
>+  } else {
>+  DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying
>auth\n",
>+connector->base.name, connector->base.base.id);
>+  }
>
>   ret = _intel_hdcp2_disable(connector);
>   if (ret) {
>--
>2.7.4

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

RE: [PATCH v10 13/40] drm/i915: Implement HDCP2.2 link integrity check

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:29 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 13/40] drm/i915: Implement HDCP2.2 link integrity check
>
>Implements the link integrity check once in 500mSec.
>
>Once encryption is enabled, an ongoing Link Integrity Check is performed by the
>HDCP Receiver to check that cipher synchronization is maintained between the
>HDCP Transmitter and the HDCP Receiver.
>
>On the detection of synchronization lost, the HDCP Receiver must assert the
>corresponding bits of the RxStatus register. The Transmitter polls the RxStatus
>register and it may initiate re-authentication.
>
>v2:
>  Rebased.
>v3:
>  enum check_link_response is used check the link status [Uma]
>v4:
>  Rebased as part of patch reordering.
>v5:
>  Required members of intel_hdcp is defined [Sean Paul]
>v6:
>  hdcp2_check_link is cancelled at required places.
>v7:
>  Rebased for the component i/f changes.
>  Errors due to the sinks are reported as DEBUG logs.
>v8:
>  hdcp_check_work is used for both hdcp1 and hdcp2 check_link [Daniel]
>  hdcp2.2 encryption status check is put under WARN_ON [Daniel]
>  drm_hdcp.h changes are moved into separate patch [Daniel]
>v9:
>  enum check_link_status is defined at intel_drv.h [Daniel]
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Uma Shankar 

The latest version also looks ok. You can keep my RB.

>---
> drivers/gpu/drm/i915/intel_drv.h  | 10 +  
> drivers/gpu/drm/i915/intel_hdcp.c
>| 88 ---
> 2 files changed, 93 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>b/drivers/gpu/drm/i915/intel_drv.h
>index e6792304520a..747fe7361287 100644
>--- a/drivers/gpu/drm/i915/intel_drv.h
>+++ b/drivers/gpu/drm/i915/intel_drv.h
>@@ -314,6 +314,13 @@ struct intel_panel {
>
> struct intel_digital_port;
>
>+enum check_link_response {
>+  HDCP_LINK_PROTECTED = 0,
>+  HDCP_TOPOLOGY_CHANGE,
>+  HDCP_LINK_INTEGRITY_FAILURE,
>+  HDCP_REAUTH_REQUEST
>+};
>+
> /*
>  * This structure serves as a translation layer between the generic HDCP code
>  * and the bus-specific code. What that means is that HDCP over HDMI differs
>@@ -409,6 +416,9 @@ struct intel_hdcp_shim {
>*/
>   int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
> bool is_repeater, u8 type);
>+
>+  /* HDCP2.2 Link Integrity Check */
>+  int (*check_2_2_link)(struct intel_digital_port *intel_dig_port);
> };
>
> struct intel_hdcp {
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 3b8d3a4b5e6e..3feff921a547 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -102,6 +102,16 @@ static inline bool intel_hdcp_in_use(struct
>intel_connector *connector)
>   return reg & HDCP_STATUS_ENC;
> }
>
>+static inline bool intel_hdcp2_in_use(struct intel_connector
>+*connector) {
>+  struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+  enum port port = connector->encoder->port;
>+  u32 reg;
>+
>+  reg = I915_READ(HDCP2_STATUS_DDI(port));
>+  return reg & LINK_ENCRYPTION_STATUS;
>+}
>+
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
>   const struct intel_hdcp_shim *shim)  { @@ -
>1571,6 +1581,69 @@ static int _intel_hdcp2_disable(struct intel_connector
>*connector)
>   return ret;
> }
>
>+/* Implements the Link Integrity Check for HDCP2.2 */ static int
>+intel_hdcp2_check_link(struct intel_connector *connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  enum port port = connector->encoder->port;
>+  int ret = 0;
>+
>+  mutex_lock(>mutex);
>+
>+  /* hdcp2_check_link is expected only when HDCP2.2 is Enabled */
>+  if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED ||
>+  !hdcp->hdcp2_encrypted) {
>+  ret = -EINVAL;
>+  goto out;
>+  }
>+
>+  if (WARN_ON(!intel_hdcp2_in_use(connector))) {
>+  DRM_ERROR("HDCP2.2 link stopped the encryption, %x\n",
>+I915_READ(HDCP2_STATUS_DDI(port)));
>+  ret = -ENXIO;
>+  hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
>+  schedule_work(>prop_work);
>+  goto out;
>+  }
>+
>+  ret = hdcp->shim->check_2_2_link(intel_dig_port);
>+  if (ret == HDCP_LINK_PROTECTED) {
>+  if (hdcp->value !=
>DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
>+  hdcp->value =
>DRM_MODE_CONTENT_PROTECTION_ENABLED;
>+  schedule_work(>prop_work);
>+  }
>+ 

RE: [PATCH v10 12/40] drm: HDCP2.2 link check period

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:29 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 12/40] drm: HDCP2.2 link check period
>
>Time period for HDCP2.2 link check.
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Daniel Vetter 

Not sure if we need a separate patch for this. Could be merged where check_link 
is
introduced for hdcp2.2.

If there is a valid reasoning, no hard objection and it looks ok in general. So

Reviewed-by: Uma Shankar 

>---
> include/drm/drm_hdcp.h | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index
>7260b31af276..d4e98b11b4aa 100644
>--- a/include/drm/drm_hdcp.h
>+++ b/include/drm/drm_hdcp.h
>@@ -13,6 +13,7 @@
>
> /* Period of hdcp checks (to ensure we're still authenticated) */
> #define DRM_HDCP_CHECK_PERIOD_MS  (128 * 16)
>+#define DRM_HDCP2_CHECK_PERIOD_MS 500
>
> /* Shared lengths/masks between HDMI/DVI/DisplayPort */
> #define DRM_HDCP_AN_LEN   8
>--
>2.7.4

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

RE: [PATCH v10 11/40] drm/i915: Implement HDCP2.2 repeater authentication

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:29 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 11/40] drm/i915: Implement HDCP2.2 repeater
>authentication
>
>Implements the HDCP2.2 repeaters authentication steps such as verifying the
>downstream topology and sending stream management information.
>
>v2: Rebased.
>v3:
>  -EINVAL is returned for topology error and rollover scenario.
>  Endianness conversion func from drm_hdcp.h is used [Uma]
>v4:
>  Rebased as part of patches reordering.
>  Defined the mei service functions [Daniel]
>v5:
>  Redefined the mei service functions as per comp redesign.
>v6:
>  %s/uintxx_t/uxx
>  Check for comp_master is removed.
>v7:
>  Adjust to the new mei interface.
>  style issue fixed.
>v8:
>  drm_hdcp.h change is moved into separate patch [Daniel]
>v9:
>  %s/__swab16/cpu_to_be16. [Tomas]
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Daniel Vetter 

Looks ok to me.
Reviewed-by: Uma Shankar 

>---
> drivers/gpu/drm/i915/intel_hdcp.c | 125
>+-
> 1 file changed, 123 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 1c81e17dc6c4..3b8d3a4b5e6e 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -1032,7 +1032,7 @@ static int hdcp2_prepare_skey(struct intel_connector
>*connector,
>   return ret;
> }
>
>-static __attribute__((unused)) int
>+static int
> hdcp2_verify_rep_topology_prepare_ack(struct intel_connector *connector,
> struct hdcp2_rep_send_receiverid_list
>   *rep_topology,
>@@ -1061,7 +1061,7 @@ hdcp2_verify_rep_topology_prepare_ack(struct
>intel_connector *connector,
>   return ret;
> }
>
>-static __attribute__((unused)) int
>+static int
> hdcp2_verify_mprime(struct intel_connector *connector,
>   struct hdcp2_rep_stream_ready *stream_ready)  { @@ -
>1270,6 +1270,119 @@ static int hdcp2_session_key_exchange(struct
>intel_connector *connector)
>   return 0;
> }
>
>+static
>+int hdcp2_propagate_stream_management_info(struct intel_connector
>+*connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  union {
>+  struct hdcp2_rep_stream_manage stream_manage;
>+  struct hdcp2_rep_stream_ready stream_ready;
>+  } msgs;
>+  const struct intel_hdcp_shim *shim = hdcp->shim;
>+  int ret;
>+
>+  /* Prepare RepeaterAuth_Stream_Manage msg */
>+  msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
>+  drm_hdcp2_u32_to_seq_num(msgs.stream_manage.seq_num_m,
>+hdcp->seq_num_m);
>+
>+  /* K no of streams is fixed as 1. Stored as big-endian. */
>+  msgs.stream_manage.k = cpu_to_be16(1);
>+
>+  /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
>+  msgs.stream_manage.streams[0].stream_id = 0;
>+  msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
>+
>+  /* Send it to Repeater */
>+  ret = shim->write_2_2_msg(intel_dig_port, _manage,
>+sizeof(msgs.stream_manage));
>+  if (ret < 0)
>+  return ret;
>+
>+  ret = shim->read_2_2_msg(intel_dig_port,
>HDCP_2_2_REP_STREAM_READY,
>+   _ready,
>sizeof(msgs.stream_ready));
>+  if (ret < 0)
>+  return ret;
>+
>+  hdcp->port_data.seq_num_m = hdcp->seq_num_m;
>+  hdcp->port_data.streams[0].stream_type = hdcp->content_type;
>+
>+  ret = hdcp2_verify_mprime(connector, _ready);
>+  if (ret < 0)
>+  return ret;
>+
>+  hdcp->seq_num_m++;
>+
>+  if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
>+  DRM_DEBUG_KMS("seq_num_m roll over.\n");
>+  return -1;
>+  }
>+
>+  return 0;
>+}
>+
>+static
>+int hdcp2_authenticate_repeater_topology(struct intel_connector
>+*connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  union {
>+  struct hdcp2_rep_send_receiverid_list recvid_list;
>+  struct hdcp2_rep_send_ack rep_ack;
>+  } msgs;
>+  const struct intel_hdcp_shim *shim = hdcp->shim;
>+  u8 *rx_info;
>+  u32 seq_num_v;
>+  int ret;
>+
>+  ret = shim->read_2_2_msg(intel_dig_port,
>HDCP_2_2_REP_SEND_RECVID_LIST,
>+   _list, sizeof(msgs.recvid_list));
>+  if (ret < 0)
>+  return ret;
>+
>+  rx_info = msgs.recvid_list.rx_info;
>+
>+  if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
>+  HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
>+  DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
>+ 

RE: [PATCH v10 10/40] drm: helper functions for hdcp2 seq_num to from u32

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:29 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 10/40] drm: helper functions for hdcp2 seq_num to from u32
>
>Library functions for endianness are aligned for 16/32/64 bits.
>But hdcp sequence numbers are 24bits(big endian).
>So for their conversion to and from u32 helper functions are developed.
>
>v2:
>  Comment is updated. [Daniel]
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Daniel Vetter 

Looks ok to me.
Reviewed-by: Uma Shankar 

>---
> include/drm/drm_hdcp.h | 18 ++
> 1 file changed, 18 insertions(+)
>
>diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index
>d6dfef8cff6a..7260b31af276 100644
>--- a/include/drm/drm_hdcp.h
>+++ b/include/drm/drm_hdcp.h
>@@ -252,4 +252,22 @@ struct hdcp2_dp_errata_stream_type {
> #define HDCP_2_2_HDMI_RXSTATUS_READY(x)   ((x) & BIT(2))
> #define HDCP_2_2_HDMI_RXSTATUS_REAUTH_REQ(x)  ((x) & BIT(3))
>
>+/*
>+ * Helper functions to convert 24bit big endian hdcp sequence number to
>+ * host format and back
>+ */
>+static inline
>+u32 drm_hdcp2_seq_num_to_u32(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN]) {
>+  return (u32)(seq_num[2] | seq_num[1] << 8 | seq_num[0] << 16); }
>+
>+static inline
>+void drm_hdcp2_u32_to_seq_num(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN],
>u32
>+val) {
>+  seq_num[0] = val >> 16;
>+  seq_num[1] = val >> 8;
>+  seq_num[2] = val;
>+}
>+
> #endif
>--
>2.7.4

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

Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected

[Maxime Ripard]

Hi,

On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
> Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> Validate the clock rate") prevents some panel and bridges from working with
> sun4i driver.
> 
> Unfortunately, dotclock frequency for some modes are not achievable on
> sunxi hardware, and there's a slight deviation in rate returned by
> clk_round_rate(), so they fail this check.
> 
> Experiments show that panels and bridges work fine with this slight
> deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
> fine.
> 
> This patch adds a 1% tolerence to the dot clock check when bridge is
> connected.
> 
> Signed-off-by: Vasily Khoruzhick 

I'm not sure we want to make exceptions for all the hardware
combination we face, but we should go for something more generic (and
easier to maintain instead).

IIRC, from the previous discussion, HDMI had a tolerancy requirement
in the standard. Do you know if there's such a thing for eDP? That
would solve the issue for all the eDP displays at once.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v10 09/40] drm/i915: Implement HDCP2.2 receiver authentication

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:29 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 09/40] drm/i915: Implement HDCP2.2 receiver
>authentication
>
>Implements HDCP2.2 authentication for hdcp2.2 receivers, with following steps:
>   Authentication and Key exchange (AKE).
>   Locality Check (LC).
>   Session Key Exchange(SKE).
>   DP Errata for stream type configuration for receivers.
>
>At AKE, the HDCP Receiver’s public key certificate is verified by the HDCP
>Transmitter. A Master Key k m is exchanged.
>
>At LC, the HDCP Transmitter enforces locality on the content by requiring that 
>the
>Round Trip Time (RTT) between a pair of messages is not more than 20 ms.
>
>At SKE, The HDCP Transmitter exchanges Session Key ks with the HDCP Receiver.
>
>In DP HDCP2.2 encryption and decryption logics use the stream type as one of 
>the
>parameter. So Before enabling the Encryption DP HDCP2.2 receiver needs to be
>communicated with stream type. This is added to spec as ERRATA.
>
>This generic implementation is complete only with the hdcp2 specific functions
>defined at hdcp_shim.
>
>v2: Rebased.
>v3:
>  %s/PARING/PAIRING
>  Coding style fixing [Uma]
>v4:
>  Rebased as part of patch reordering.
>  Defined the functions for mei services. [Daniel]
>v5:
>  Redefined the mei service functions as per comp redesign.
>  Required intel_hdcp members are defined [Sean Paul]
>v6:
>  Typo of cipher is Fixed [Uma]
>  %s/uintxx_t/uxx
>  Check for comp_master is removed.
>v7:
>  Adjust to the new interface.
>  Avoid using bool structure members. [Tomas]
>v8: Rebased.
>v9:
>  bool is used in struct intel_hdcp [Daniel]
>  config_stream_type is redesigned [Daniel]
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Daniel Vetter 

Looks ok to me.
Reviewed-by: Uma Shankar 

>---
> drivers/gpu/drm/i915/intel_drv.h  |  34 +++
>drivers/gpu/drm/i915/intel_hdcp.c | 197
>+++---
> 2 files changed, 216 insertions(+), 15 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>b/drivers/gpu/drm/i915/intel_drv.h
>index 31c7a4577ca9..e6792304520a 100644
>--- a/drivers/gpu/drm/i915/intel_drv.h
>+++ b/drivers/gpu/drm/i915/intel_drv.h
>@@ -393,6 +393,22 @@ struct intel_hdcp_shim {
>   /* Detects whether Panel is HDCP2.2 capable */
>   int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
>   bool *capable);
>+
>+  /* Write HDCP2.2 messages */
>+  int (*write_2_2_msg)(struct intel_digital_port *intel_dig_port,
>+   void *buf, size_t size);
>+
>+  /* Read HDCP2.2 messages */
>+  int (*read_2_2_msg)(struct intel_digital_port *intel_dig_port,
>+  u8 msg_id, void *buf, size_t size);
>+
>+  /*
>+   * Implementation of DP HDCP2.2 Errata for the communication of
>stream
>+   * type to Receivers. In DP HDCP2.2 Stream type is one of the input to
>+   * the HDCP2.2 Cipher for En/De-Cryption. Not applicable for HDMI.
>+   */
>+  int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
>+bool is_repeater, u8 type);
> };
>
> struct intel_hdcp {
>@@ -420,6 +436,24 @@ struct intel_hdcp {
>*/
>   u8 content_type;
>   struct hdcp_port_data port_data;
>+
>+  bool is_paired;
>+  bool is_repeater;
>+
>+  /*
>+   * Count of ReceiverID_List received. Initialized to 0 at AKE_INIT.
>+   * Incremented after processing the RepeaterAuth_Send_ReceiverID_List.
>+   * When it rolls over re-auth has to be triggered.
>+   */
>+  u32 seq_num_v;
>+
>+  /*
>+   * Count of RepeaterAuth_Stream_Manage msg propagated.
>+   * Initialized to 0 on AKE_INIT. Incremented after every successful
>+   * transmission of RepeaterAuth_Stream_Manage message. When it rolls
>+   * over re-Auth has to be triggered.
>+   */
>+  u32 seq_num_m;
> };
>
> struct intel_connector {
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index fbf8b7893bfa..1c81e17dc6c4 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -17,6 +17,7 @@
>
> #define KEY_LOAD_TRIES5
> #define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS  50
>+#define HDCP2_LC_RETRY_CNT3
>
> static
> bool intel_hdcp_is_ksv_valid(u8 *ksv)
>@@ -853,7 +854,7 @@ bool is_hdcp_supported(struct drm_i915_private
>*dev_priv, enum port port)
>   return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;  }
>
>-static __attribute__((unused)) int
>+static int
> hdcp2_prepare_ake_init(struct intel_connector *connector,
>  struct hdcp2_ake_init *ake_data)  { @@ -878,7 +879,7 @@
>hdcp2_prepare_ake_init(struct intel_connector *connector,
>   return ret;
> }
>
>-static 

RE: [PATCH v10 08/40] drm/i915: Enable and Disable of HDCP2.2

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Thursday, January 31, 2019 12:29 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Subject: [PATCH v10 08/40] drm/i915: Enable and Disable of HDCP2.2
>
>Considering that HDCP2.2 is more secure than HDCP1.4, When a setup supports
>HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
>
>When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is enabled.
>
>This change implements a sequence of enabling and disabling of
>HDCP2.2 authentication and HDCP2.2 port encryption.
>
>v2:
>  Included few optimization suggestions [Chris Wilson]
>  Commit message is updated as per the rebased version.
>  intel_wait_for_register is used instead of wait_for. [Chris Wilson]
>v3:
>  Extra comment added and Style issue fixed [Uma]
>v4:
>  Rebased as part of patch reordering.
>  HDCP2 encryption status is tracked.
>  HW state check is moved into WARN_ON [Daniel]
>v5:
>  Redefined the mei service functions as per comp redesign.
>  Merged patches related to hdcp2.2 enabling and disabling [Sean Paul].
>  Required shim functionality is defined [Sean Paul]
>v6:
>  Return values are handles [Uma]
>  Realigned the code.
>  Check for comp_master is removed.
>v7:
>  HDCP2.2 is attempted only if mei interface is up.
>  Adjust to the new interface
>  Avoid bool usage in struct [Tomas]
>v8:
>  mei_binded status check is removed.
>  %s/hdcp2_in_use/hdcp2_encrypted
>v9:
>  bool is used in struct intel_hdcp. [Daniel]
>
>Signed-off-by: Ramalingam C 
>Reviewed-by: Daniel Vetter 
>---
> drivers/gpu/drm/i915/intel_drv.h  |   7 ++
> drivers/gpu/drm/i915/intel_hdcp.c | 202
>+++---
> 2 files changed, 195 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>b/drivers/gpu/drm/i915/intel_drv.h
>index 13a41e8cf4ff..31c7a4577ca9 100644
>--- a/drivers/gpu/drm/i915/intel_drv.h
>+++ b/drivers/gpu/drm/i915/intel_drv.h
>@@ -389,6 +389,10 @@ struct intel_hdcp_shim {
>
>   /* HDCP adaptation(DP/HDMI) required on the port */
>   enum hdcp_wired_protocol protocol;
>+
>+  /* Detects whether Panel is HDCP2.2 capable */

Make Panel as Sink.

>+  int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
>+  bool *capable);
> };
>
> struct intel_hdcp {
>@@ -406,6 +410,9 @@ struct intel_hdcp {
>   /* Flag indicates whether this connector supports HDCP2.2 or not. */
>   bool hdcp2_supported;
>
>+  /* HDCP2.2 Encryption status */
>+  bool hdcp2_encrypted;
>+
>   /*
>* Content Stream Type defined by content owner. TYPE0(0x0) content
>can
>* flow in the link protected by HDCP2.2 or HDCP1.4, where as
>TYPE1(0x1) diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index c1b057f1501b..fbf8b7893bfa 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -74,6 +74,23 @@ bool intel_hdcp_capable(struct intel_connector
>*connector)
>   return capable;
> }
>
>+/* Is HDCP2.2 capable on Platform and Sink */ static bool
>+intel_hdcp2_capable(struct intel_connector *connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  bool capable = false;
>+
>+  /* I915 support for HDCP2.2 */
>+  if (!hdcp->hdcp2_supported)
>+  return false;
>+
>+  /* Sink's capability for HDCP2.2 */
>+  hdcp->shim->hdcp_2_2_capable(intel_dig_port, );
>+
>+  return capable;
>+}
>+
> static inline bool intel_hdcp_in_use(struct intel_connector *connector)  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev); @@
>-1094,8 +,7 @@ int hdcp2_authenticate_port(struct intel_connector
>*connector)
>   return ret;
> }
>
>-static __attribute__((unused))
>-int hdcp2_close_mei_session(struct intel_connector *connector)
>+static int hdcp2_close_mei_session(struct intel_connector *connector)
> {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   struct i915_hdcp_comp_master *comp;
>@@ -1116,12 +1132,157 @@ int hdcp2_close_mei_session(struct
>intel_connector *connector)
>   return ret;
> }
>
>-static __attribute__((unused))
>-int hdcp2_deauthenticate_port(struct intel_connector *connector)
>+static int hdcp2_deauthenticate_port(struct intel_connector *connector)
> {
>   return hdcp2_close_mei_session(connector);
> }
>
>+static int hdcp2_authenticate_sink(struct intel_connector *connector) {
>+  DRM_ERROR("Sink authentication is done in subsequent patches\n");
>+
>+  return -EINVAL;
>+}
>+
>+static int hdcp2_enable_encryption(struct intel_connector *connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct drm_i915_private *dev_priv = 

[Bug 109545] intel_gt(dev_id) function returns wrong gt size on some device IDs

[bugzilla-daemon]

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

Lionel Landwerlin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Lionel Landwerlin  ---
There is proposed fix for this issue, feel free to pick it up and revive the
discussion on the mailing list.

*** This bug has been marked as a duplicate of bug 101740 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v10 07/40] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking

[Shankar, Uma]

>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:29 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma 
>Cc: C, Ramalingam 
>Subject: [PATCH v10 07/40] drm/i915: hdcp1.4 CP_IRQ handling and SW
>encryption tracking
>
>"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
>This SW tracking is used to determine the need for real hdcp1.4 disable and
>hdcp_check_link upon CP_IRQ.
>
>On CP_IRQ we filter the CP_IRQ related to the states like Link failure and
>reauthentication req etc and handle them in hdcp_check_link.
>CP_IRQ corresponding to the authentication msg availability are ignored.
>
>WARN_ON is added for the abrupt stop of HDCP encryption of a port.
>
>v2:
>  bool is used in struct for the cleaner coding. [Daniel]
>  check_link work_fn is scheduled for cp_irq handling [Daniel]
>
>Signed-off-by: Ramalingam C 
>---
> drivers/gpu/drm/i915/intel_dp.c   |  2 +-
> drivers/gpu/drm/i915/intel_drv.h  |  5 ++-  drivers/gpu/drm/i915/intel_hdcp.c 
> |
>73 ---
> 3 files changed, 58 insertions(+), 22 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>index 815ee68efa2f..9ce05819fc11 100644
>--- a/drivers/gpu/drm/i915/intel_dp.c
>+++ b/drivers/gpu/drm/i915/intel_dp.c
>@@ -4776,7 +4776,7 @@ static void intel_dp_check_service_irq(struct intel_dp
>*intel_dp)
>   intel_dp_handle_test_request(intel_dp);
>
>   if (val & DP_CP_IRQ)
>-  intel_hdcp_check_link(intel_dp->attached_connector);
>+  intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
>
>   if (val & DP_SINK_SPECIFIC_IRQ)
>   DRM_DEBUG_DRIVER("Sink specific irq unhandled\n"); diff --git
>a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
>index 63e009286d5f..13a41e8cf4ff 100644
>--- a/drivers/gpu/drm/i915/intel_drv.h
>+++ b/drivers/gpu/drm/i915/intel_drv.h
>@@ -399,6 +399,9 @@ struct intel_hdcp {
>   struct delayed_work check_work;
>   struct work_struct prop_work;
>
>+  /* HDCP1.4 Encryption status */
>+  bool hdcp_encrypted;
>+
>   /* HDCP2.2 related definitions */
>   /* Flag indicates whether this connector supports HDCP2.2 or not. */
>   bool hdcp2_supported;
>@@ -2073,10 +2076,10 @@ int intel_hdcp_init(struct intel_connector
>*connector,
>   bool hdcp2_supported);
> int intel_hdcp_enable(struct intel_connector *connector);  int
>intel_hdcp_disable(struct intel_connector *connector); -int
>intel_hdcp_check_link(struct intel_connector *connector);  bool
>is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);  bool
>intel_hdcp_capable(struct intel_connector *connector);  bool
>is_hdcp2_supported(struct drm_i915_private *dev_priv);
>+void intel_hdcp_handle_cp_irq(struct intel_connector *connector);
>
> /* intel_psr.c */
> #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index e0bb5f32ba90..c1b057f1501b 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -74,6 +74,16 @@ bool intel_hdcp_capable(struct intel_connector
>*connector)
>   return capable;
> }
>
>+static inline bool intel_hdcp_in_use(struct intel_connector *connector)
>+{
>+  struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+  enum port port = connector->encoder->port;
>+  u32 reg;
>+
>+  reg = I915_READ(PORT_HDCP_STATUS(port));
>+  return reg & HDCP_STATUS_ENC;
>+}
>+
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
>   const struct intel_hdcp_shim *shim)  { @@ -
>668,6 +678,7 @@ static int _intel_hdcp_disable(struct intel_connector
>*connector)
>   DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
> connector->base.name, connector->base.base.id);
>
>+  hdcp->hdcp_encrypted = false;
>   I915_WRITE(PORT_HDCP_CONF(port), 0);
>   if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
>   ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
>@@ -713,8 +724,10 @@ static int _intel_hdcp_enable(struct intel_connector
>*connector)
>   /* Incase of authentication failures, HDCP spec expects reauth. */
>   for (i = 0; i < tries; i++) {
>   ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp-
>>shim);
>-  if (!ret)
>+  if (!ret) {
>+  hdcp->hdcp_encrypted = true;
>   return 0;
>+  }
>
>   DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
>
>@@ -741,16 +754,17 @@ int intel_hdcp_check_link(struct intel_connector
>*connector)
>   enum port port = intel_dig_port->base.port;
>   int ret = 0;
>
>-  if (!hdcp->shim)
>-

[Bug 109545] intel_gt(dev_id) function returns wrong gt size on some device IDs

[bugzilla-daemon]

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

andrey.or...@intel.com changed:

   What|Removed |Added

   Priority|medium  |high

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109545] intel_gt(dev_id) function returns wrong gt size on some device IDs

[bugzilla-daemon]

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

Bug ID: 109545
   Summary: intel_gt(dev_id) function returns wrong gt size on
some device IDs
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: critical
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: andrey.or...@intel.com

I've built "perf" test tool from the intel_gpu_tools and started it on two
systems:

SKL-GT4(0x193B):

root@nnt-sklnuc-andreyor:/msdk/intel-gpu-tools/installed_build/libexec/igt-gpu-tools#
./perf
IGT-Version: 1.23-gcb6610f5 (x86_64) (Linux: 4.19.5 x86_64)
Starting subtest: i915-ref-count
init_sys_info function
SKYLAKE intel_gt(devid) = 3
Subtest i915-ref-count: SUCCESS (0,083s)

CFL-GT2(0x3E91):

root@nnt-cfl03:/msdk/WORKER/exec_dir# ./perf
IGT-Version: 1.23-gcb6610f5 (x86_64) (Linux: 4.19.5 x86_64)
Starting subtest: i915-ref-count
init_sys_info function
COFFEELAKE intel_gt(devid) = 9
Test requirement not met in function test_i915_ref_count, file perf.c:4053:
Test requirement: init_sys_info()
Subtest i915-ref-count: SKIP (0.000s)

So, on CFL-GT2(device_id = 0x3E91): intel_gt(devid) = 9.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel