[PATCH 01/20] drm/doc: Fix more kerneldoc/sphinx warnings

2016-08-11 Thread Markus Heiser

Am 11.08.2016 um 10:23 schrieb Jani Nikula :

> On Thu, 11 Aug 2016, Jani Nikula  wrote:
>> On Tue, 09 Aug 2016, Daniel Vetter  wrote:
>>> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
>>> b/drivers/gpu/drm/i915/intel_audio.c
>>> index d32f586f9c05..85389cdd0bec 100644
>>> --- a/drivers/gpu/drm/i915/intel_audio.c
>>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>>> @@ -51,10 +51,10 @@
>>>  * related registers. (The notable exception is the power management, not
>>>  * covered here.)
>>>  *
>>> - * The struct i915_audio_component is used to interact between the graphics
>>> - * and audio drivers. The struct i915_audio_component_ops *ops in it is
>>> + * The struct _audio_component is used to interact between the 
>>> graphics
>>> + * and audio drivers. The struct _audio_component_ops @ops in it is
>> 
>> Please prefer " foo" over "struct ". The former makes the
>> struct be part of the link text.
> 
> Mmmh, the kernel-doc highlighting code should probably learn about "
> foo" spread to two lines.

my 2cent thoughts: the kernel-doc syntax is weak and ambiguous. This
remains mainly in tagging only with a start-tag or only with a end-tag 
e.g:

* sectioning:   "Return:" --> end-tag just ":"
* fields:   "@arg1:"  --> better
* highlight/ref: start tag [@%$&] / no end tag

the most ambiguous is highlighting, known quirks [1]. I tried 
to improve it in the kernel-doc parser, but haven't found
any good or better reg-expressions yet.

We had this already and I won't restart the discussion, just
to remember: In my POC I tried to handle this quirks by distinguish
*vintage* from *modern* markup and in my first attempt I dropped the
kernel-doc highlight markups from the *modern* syntax.

My conclusion is, conceptional we should not try to extend the wacky
kernel-doc syntax supporting e.g. multi-line markup constructs, 
particularly if there is a reST markup available.

We should only improve the kernel-doc reg-expressions e.g. not to have
*fails-match* for highlighting on common things like a e-mail addresses.

[1] http://www.spinics.net/lists/linux-media/msg103145.html

-- Markus --
> 
> BR,
> Jani.
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



[PATCH 1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"

2016-08-11 Thread Paul E. McKenney
On Thu, Aug 11, 2016 at 12:38:59PM +0200, Daniel Vetter wrote:
> On Thu, Aug 11, 2016 at 11:50:21AM +0200, Johannes Berg wrote:
> > From: Johannes Berg 
> > 
> > This reverts commit fa7d81bb3c269a2ee38b6e4d569d9eb8be1a78ad.
> > 
> > As Peter explained:
> >   [...] lockless_dereference() is _stronger_ than READ_ONCE(), not weaker.
> > 
> >   [...]
> > 
> >   Also, clue is in the name: 'dereference', you don't actually dereference
> >   the pointer here, only load it.
> > 
> > My next patch breaks compile on this, because it assumes you want to
> > deference and thus also need the struct type visible (which it isn't
> > here), so revert it.
> > 
> > Cc: Peter Zijlstra 
> > Signed-off-by: Johannes Berg 
> 
> Reviewed-by: Daniel Vetter 
> 
> And ack-by: me for merging through whatever tree this makes sense for.
> -Daniel

Initial testing says that the change below must precede the change
to the definition of lockless_dereference(), so the two should go
together.

If my upcoming testing of the two changes together pans out, I will
give you a Tested-by -- I am guessing that you don't want to wait
until the next merge window for these changes.

Thanx, Paul

> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index ce54e985d91b..0a06f9120b5a 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -464,7 +464,7 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper 
> > *fb_helper)
> >  
> > /* Sometimes user space wants everything disabled, so don't steal the
> >  * display if there's a master. */
> > -   if (lockless_dereference(dev->master))
> > +   if (READ_ONCE(dev->master))
> > return false;
> >  
> > drm_for_each_crtc(crtc, dev) {
> > -- 
> > 2.8.1
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> 



[PATCH 01/20] drm/doc: Fix more kerneldoc/sphinx warnings

2016-08-11 Thread Jani Nikula
On Thu, 11 Aug 2016, Jani Nikula  wrote:
> On Tue, 09 Aug 2016, Daniel Vetter  wrote:
>> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
>> b/drivers/gpu/drm/i915/intel_audio.c
>> index d32f586f9c05..85389cdd0bec 100644
>> --- a/drivers/gpu/drm/i915/intel_audio.c
>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>> @@ -51,10 +51,10 @@
>>   * related registers. (The notable exception is the power management, not
>>   * covered here.)
>>   *
>> - * The struct i915_audio_component is used to interact between the graphics
>> - * and audio drivers. The struct i915_audio_component_ops *ops in it is
>> + * The struct _audio_component is used to interact between the graphics
>> + * and audio drivers. The struct _audio_component_ops @ops in it is
>
> Please prefer " foo" over "struct ". The former makes the
> struct be part of the link text.

Mmmh, the kernel-doc highlighting code should probably learn about "
foo" spread to two lines.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH 01/20] drm/doc: Fix more kerneldoc/sphinx warnings

2016-08-11 Thread Ville Syrjälä
On Thu, Aug 11, 2016 at 11:15:13AM +0300, Jani Nikula wrote:
> On Tue, 09 Aug 2016, Daniel Vetter  wrote:
> > These are the leftovers I could only track down using keep_warnings =
> > True. For some of them we might want to update our style guide on how
> > to reference structures and constants, not sure ...
> >
> > Cc: Markus Heiser 
> > Cc: Jonathan Corbet 
> > Cc: linux-doc at vger.kernel.org
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_crtc.c  |  4 ++--
> >  drivers/gpu/drm/drm_fb_helper.c |  2 +-
> >  drivers/gpu/drm/drm_irq.c   |  8 +++
> >  drivers/gpu/drm/drm_simple_kms_helper.c |  2 +-
> >  drivers/gpu/drm/i915/i915_vgpu.c| 42 
> > -
> >  drivers/gpu/drm/i915/intel_audio.c  |  6 ++---
> >  drivers/gpu/drm/i915/intel_guc_fwif.h   |  5 ++--
> >  include/drm/drm_crtc.h  |  8 +++
> >  include/drm/drm_gem.h   |  4 ++--
> >  9 files changed, 41 insertions(+), 40 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 3d03eb1e3b63..ad38a8a31898 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -1272,7 +1272,7 @@ static unsigned int drm_num_planes(struct drm_device 
> > *dev)
> >   * @plane: plane object to init
> >   * @possible_crtcs: bitmask of possible CRTCs
> >   * @funcs: callbacks for the new plane
> > - * @formats: array of supported formats (%DRM_FORMAT_*)
> > + * @formats: array of supported formats (DRM_FORMAT\_\*)
> 
> Future idea: If we turned DRM_FORMAT_* into an enum instead of a
> plethora of macros, we could reference the enum here. Not to mention the
> code being self-documenting too.

DRM_FORMAT_* is uapi, so can't change it.

-- 
Ville Syrjälä
Intel OTC


[PATCH v7 1/5] drm: Read DP branch device HW revision

2016-08-11 Thread Ville Syrjälä
On Thu, Aug 11, 2016 at 11:14:43AM +0300, Mika Kahola wrote:
> On Thu, 2016-08-11 at 10:10 +0300, Ville Syrjälä wrote:
> > On Mon, Aug 08, 2016 at 04:00:26PM +0300, Mika Kahola wrote:
> > > HW revision is mandatory field for DisplayPort branch
> > > devices. This is defined in DPCD register field 0x509.
> > 
> > But what do we want to do with it? Me, I don't see a point in parsing a
> > bunch of stuff from the DPCD unless there's a real use case for it.
> > /dev/drm_dp_aux will provide all the debug aid we need if we need to
> > check random pieces of data from the DPCD, so even exposing this sort
> > of stuff via debugfs is IMO pretty pointless.
> > 
> > If there's a good reason for a debug print, then I think we could parse
> > something and dump it out so that it's always in the dmesg. But so far
> > I'm not aware of any bug that would have required to deal with different
> > hw revisions of things and whatnot.
> > 
> Digging up the HW and SW revisions are just for debugging purposes. My
> idea here was that it would be handy if this information would be
> available if we face a problem let's say with VGA dongle for example. It
> is true that at the moment we don't have a single bug that would require
> HW/SW revision information but maybe in the future we have one.
> 
> So, if we don't want to have this stuff in drm_dp_helpers and/or debugfs
> I could make a change and print this info on dmesg when DP branch device
> is plugged in.

Perhaps. We do print out the OUI as well, so there is some precedent.

> 
> Cheers,
> Mika
> 
> > > 
> > > v2: move drm_dp_ds_revision structure to be part of
> > > drm_dp_link structure (Daniel)
> > > 
> > > Signed-off-by: Mika Kahola 
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c  | 27 +++
> > >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> > >  include/drm/drm_dp_helper.h  |  9 +
> > >  3 files changed, 37 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 75b2873..5fecdc1 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -514,6 +514,33 @@ int drm_dp_downstream_max_bpc(const u8 
> > > dpcd[DP_RECEIVER_CAP_SIZE],
> > >  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
> > >  
> > >  /**
> > > + * drm_dp_downstream_hw_rev() - read DP branch device HW revision
> > > + * @aux: DisplayPort AUX channel
> > > + *
> > > + * Returns 0 on succes or negative error code on failure
> > > + */
> > > +int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > > +  struct drm_dp_aux *aux, struct drm_dp_link *link)
> > > +{
> > > + uint8_t tmp;
> > > + int err;
> > > +
> > > + if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
> > > + return -EINVAL;
> > > +
> > > + err = drm_dp_dpcd_read(aux, DP_BRANCH_HW_REV, , 1);
> > > +
> > > + if (err < 0)
> > > + return err;
> > > +
> > > + link->ds_hw_rev.major = (tmp & 0xf0) >> 4;
> > > + link->ds_hw_rev.minor = tmp & 0xf;
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(drm_dp_downstream_hw_rev);
> > > +
> > > +/**
> > >   * drm_dp_downstream_id() - identify branch device
> > >   * @aux: DisplayPort AUX channel
> > >   *
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index e74d851..a6eccf5 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -865,6 +865,7 @@ struct intel_dp {
> > >   uint8_t num_sink_rates;
> > >   int sink_rates[DP_MAX_SUPPORTED_RATES];
> > >   struct drm_dp_aux aux;
> > > + struct drm_dp_link link;
> > >   uint8_t train_set[4];
> > >   int panel_power_up_delay;
> > >   int panel_power_down_delay;
> > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > > index 8e1fe58..1127948 100644
> > > --- a/include/drm/drm_dp_helper.h
> > > +++ b/include/drm/drm_dp_helper.h
> > > @@ -446,6 +446,7 @@
> > >  #define DP_SINK_OUI  0x400
> > >  #define DP_BRANCH_OUI0x500
> > >  #define DP_BRANCH_ID0x503
> > > +#define DP_BRANCH_HW_REV0x509
> > >  
> > >  #define DP_SET_POWER0x600
> > >  # define DP_SET_POWER_D00x1
> > > @@ -803,11 +804,17 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux 
> > > *aux,
> > >   */
> > >  #define DP_LINK_CAP_ENHANCED_FRAMING (1 << 0)
> > >  
> > > +struct drm_dp_ds_revision {
> > > + int major;
> > > + int minor;
> > > +};
> > > +
> > >  struct drm_dp_link {
> > >   unsigned char revision;
> > >   unsigned int rate;
> > >   unsigned int num_lanes;
> > >   unsigned long capabilities;
> > > + struct drm_dp_ds_revision ds_hw_rev;
> > >  };
> > >  
> > >  int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
> > > @@ -819,6 +826,8 @@ int drm_dp_downstream_max_clock(const u8 
> > > 

[PATCH REBASED v10 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

2016-08-11 Thread Maarten Lankhorst
Op 10-08-16 om 16:27 schreef Lyude:
> Since the watermark calculations for Skylake are still broken, we're apt
> to hitting underruns very easily under multi-monitor configurations.
> While it would be lovely if this was fixed, it's not. Another problem
> that's been coming from this however, is the mysterious issue of
> underruns causing full system hangs. An easy way to reproduce this with
> a skylake system:
>
> - Get a laptop with a skylake GPU, and hook up two external monitors to
>   it
> - Move the cursor from the built-in LCD to one of the external displays
>   as quickly as you can
> - You'll get a few pipe underruns, and eventually the entire system will
>   just freeze.
>
> After doing a lot of investigation and reading through the bspec, I
> found the existence of the SAGV, which is responsible for adjusting the
> system agent voltage and clock frequencies depending on how much power
> we need. According to the bspec:
>
> "The display engine access to system memory is blocked during the
>  adjustment time. SAGV defaults to enabled. Software must use the
>  GT-driver pcode mailbox to disable SAGV when the display engine is not
>  able to tolerate the blocking time."
>
> The rest of the bspec goes on to explain that software can simply leave
> the SAGV enabled, and disable it when we use interlaced pipes/have more
> then one pipe active.
>
> Sure enough, with this patchset the system hangs resulting from pipe
> underruns on Skylake have completely vanished on my T460s. Additionally,
> the bspec mentions turning off the SAGV   with more then one pipe enabled
> as a workaround for display underruns. While this patch doesn't entirely
> fix that, it looks like it does improve the situation a little bit so
> it's likely this is going to be required to make watermarks on Skylake
> fully functional.
>
> Changes since v9:
>  - Only enable/disable sagv on Skylake
> Changes since v8:
>  - Add intel_state->modeset guard to the conditional for
>skl_enable_sagv()
> Changes since v7:
>  - Remove GEN9_SAGV_LOW_FREQ, replace with GEN9_SAGV_IS_ENABLED (that's
>all we use it for anyway)
>  - Use GEN9_SAGV_IS_ENABLED instead of 0x1 for clarification
>  - Fix a styling error that snuck past me
> Changes since v6:
>  - Protect skl_enable_sagv() with intel_state->modeset conditional in
>intel_atomic_commit_tail()
> Changes since v5:
>  - Don't use is_power_of_2. Makes things confusing
>  - Don't use the old state to figure out whether or not to
>enable/disable the sagv, use the new one
>  - Split the loop in skl_disable_sagv into it's own function
>  - Move skl_sagv_enable/disable() calls into intel_atomic_commit_tail()
> Changes since v4:
>  - Use is_power_of_2 against active_crtcs to check whether we have > 1
>pipe enabled
>  - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
>enabled
>  - Call skl_sagv_enable/disable() from pre/post-plane updates
> Changes since v3:
>  - Use time_before() to compare timeout to jiffies
> Changes since v2:
>  - Really apply minor style nitpicks to patch this time
> Changes since v1:
>  - Added comments about this probably being one of the requirements to
>fixing Skylake's watermark issues
>  - Minor style nitpicks from Matt Roper
>  - Disable these functions on Broxton, since it doesn't have an SAGV
>
> Reviewed-by: Matt Roper 
> Reviewed-by: Maarten Lankhorst 
> Signed-off-by: Lyude 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Cc: stable at vger.kernel.org
>
> squash! drm/i915/skl: Add support for the SAGV, fix underrun hangs
>
> squash! drm/i915/skl: Add support for the SAGV, fix underrun hangs
>
> Signed-off-by: Lyude 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   2 +
>  drivers/gpu/drm/i915/i915_reg.h  |   4 ++
>  drivers/gpu/drm/i915/intel_display.c |  12 
>  drivers/gpu/drm/i915/intel_drv.h |   2 +
>  drivers/gpu/drm/i915/intel_pm.c  | 112 
> +++
>  5 files changed, 132 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7f2754a..fa3c9f9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1944,6 +1944,8 @@ struct drm_i915_private {
>   struct i915_suspend_saved_registers regfile;
>   struct vlv_s0ix_state vlv_s0ix_state;
>  
> + bool skl_sagv_enabled;
> +
>   struct {
>   /*
>* Raw watermark latency values:
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index da82744..6c3947f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7143,6 +7143,10 @@ enum {
>  #define   HSW_PCODE_DE_WRITE_FREQ_REQ0x17
>  #define   DISPLAY_IPS_CONTROL0x19
>  #defineHSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL  0x1A
> +#define   GEN9_PCODE_SAGV_CONTROL0x21
> +#define GEN9_SAGV_DISABLE0x0
> +#define 

[PATCH 5/5] drm/imx: add exclusive fence to plane state

2016-08-11 Thread Lucas Stach
This allows the atomic helper to wait on them, instead of open-coding
the same in the imx-drm driver.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 63 +-
 1 file changed, 28 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 66b3556f7b79..2d3f32f1b13b 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -152,50 +152,43 @@ static void imx_drm_output_poll_changed(struct drm_device 
*drm)
drm_fbdev_cma_hotplug_event(imxdrm->fbhelper);
 }

+static int imx_drm_atomic_commit(struct drm_device *dev,
+struct drm_atomic_state *state,
+bool nonblock)
+{
+   struct drm_plane_state *plane_state;
+   struct drm_plane *plane;
+   struct dma_buf *dma_buf;
+   int i;
+
+   /*
+* If the plane fb has an dma-buf attached, fish out the exclusive
+* fence for the atomic helper to wait on.
+*/
+   for_each_plane_in_state(state, plane, plane_state, i) {
+   if ((plane->state->fb != plane_state->fb) && plane_state->fb) {
+   dma_buf = drm_fb_cma_get_gem_obj(plane_state->fb,
+0)->base.dma_buf;
+   if (!dma_buf)
+   continue;
+   plane_state->fence =
+   reservation_object_get_excl_rcu(dma_buf->resv);
+   }
+   }
+
+   return drm_atomic_helper_commit(dev, state, nonblock);
+}
+
 static const struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
.output_poll_changed = imx_drm_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
-   .atomic_commit = drm_atomic_helper_commit,
+   .atomic_commit = imx_drm_atomic_commit,
 };

 static void imx_drm_atomic_commit_tail(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
-   struct drm_plane_state *plane_state;
-   struct drm_gem_cma_object *cma_obj;
-   struct fence *excl;
-   unsigned shared_count;
-   struct fence **shared;
-   unsigned int i, j;
-   int ret;
-
-   /* Wait for fences. */
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   plane_state = crtc->primary->state;
-   if (plane_state->fb) {
-   cma_obj = drm_fb_cma_get_gem_obj(plane_state->fb, 0);
-   if (cma_obj->base.dma_buf) {
-   ret = reservation_object_get_fences_rcu(
-   cma_obj->base.dma_buf->resv, ,
-   _count, );
-   if (unlikely(ret))
-   DRM_ERROR("failed to get fences "
- "for buffer\n");
-
-   if (excl) {
-   fence_wait(excl, false);
-   fence_put(excl);
-   }
-   for (j = 0; j < shared_count; i++) {
-   fence_wait(shared[j], false);
-   fence_put(shared[j]);
-   }
-   }
-   }
-   }

drm_atomic_helper_commit_modeset_disables(dev, state);

-- 
2.8.1



[PATCH 4/5] drm/imx: fold ipu_plane_disable into ipu_disable_plane

2016-08-11 Thread Lucas Stach
ipu_disable_plane is the only left caller of ipu_plane_disable.
Having those 2 similar named functions is confusing and superfluous,
so fold them into 1.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 6cc809e1ca55..a6247f57541d 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -213,8 +213,12 @@ static void ipu_plane_enable(struct ipu_plane *ipu_plane)
ipu_dp_enable_channel(ipu_plane->dp);
 }

-static void ipu_plane_disable(struct ipu_plane *ipu_plane)
+static int ipu_disable_plane(struct drm_plane *plane)
 {
+   struct ipu_plane *ipu_plane = to_ipu_plane(plane);
+
+   DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
+
ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);

if (ipu_plane->dp)
@@ -223,15 +227,6 @@ static void ipu_plane_disable(struct ipu_plane *ipu_plane)
ipu_dmfc_disable_channel(ipu_plane->dmfc);
if (ipu_plane->dp)
ipu_dp_disable(ipu_plane->ipu);
-}
-
-static int ipu_disable_plane(struct drm_plane *plane)
-{
-   struct ipu_plane *ipu_plane = to_ipu_plane(plane);
-
-   DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
-
-   ipu_plane_disable(ipu_plane);

return 0;
 }
-- 
2.8.1



[PATCH 3/5] drm/imx: don't destroy mode objects manually on driver unbind

2016-08-11 Thread Lucas Stach
Instead let drm_mode_config_cleanup() do the work when taking down
the master device. This requires all cleanup functions to be
properly hooked up to the mode object .destroy callback.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/bridge/dw-hdmi.c   | 3 ---
 drivers/gpu/drm/imx/imx-drm-core.c | 4 ++--
 drivers/gpu/drm/imx/imx-ldb.c  | 6 --
 drivers/gpu/drm/imx/imx-tve.c  | 3 ---
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 9 ++---
 drivers/gpu/drm/imx/parallel-display.c | 3 ---
 6 files changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 77ab47341658..56f3d86a4be6 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1812,9 +1812,6 @@ void dw_hdmi_unbind(struct device *dev, struct device 
*master, void *data)
/* Disable all interrupts */
hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);

-   hdmi->connector.funcs->destroy(>connector);
-   hdmi->encoder->funcs->destroy(hdmi->encoder);
-
clk_disable_unprepare(hdmi->iahb_clk);
clk_disable_unprepare(hdmi->isfr_clk);
i2c_put_adapter(hdmi->ddc);
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index c0d06a0f6825..66b3556f7b79 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -468,11 +468,11 @@ static void imx_drm_unbind(struct device *dev)
if (imxdrm->fbhelper)
drm_fbdev_cma_fini(imxdrm->fbhelper);

+   drm_mode_config_cleanup(drm);
+
component_unbind_all(drm->dev, drm);
dev_set_drvdata(dev, NULL);

-   drm_mode_config_cleanup(drm);
-
drm_dev_unref(drm);
 }

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index b03919ed60ba..1c091dd97688 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -716,12 +716,6 @@ static void imx_ldb_unbind(struct device *dev, struct 
device *master,
for (i = 0; i < 2; i++) {
struct imx_ldb_channel *channel = _ldb->channel[i];

-   if (!channel->connector.funcs)
-   continue;
-
-   channel->connector.funcs->destroy(>connector);
-   channel->encoder.funcs->destroy(>encoder);
-
kfree(channel->edid);
i2c_put_adapter(channel->ddc);
}
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 5e875944ffa2..8fc088843e55 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -685,9 +685,6 @@ static void imx_tve_unbind(struct device *dev, struct 
device *master,
 {
struct imx_tve *tve = dev_get_drvdata(dev);

-   tve->connector.funcs->destroy(>connector);
-   tve->encoder.funcs->destroy(>encoder);
-
if (!IS_ERR(tve->dac_reg))
regulator_disable(tve->dac_reg);
 }
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 08e188bc10fc..a2a239fe0dba 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -121,9 +121,14 @@ static void imx_drm_crtc_destroy_state(struct drm_crtc 
*crtc,
kfree(to_imx_crtc_state(state));
 }

+static void imx_drm_crtc_destroy(struct drm_crtc *crtc)
+{
+   imx_drm_remove_crtc(to_ipu_crtc(crtc)->imx_crtc);
+}
+
 static const struct drm_crtc_funcs ipu_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
-   .destroy = drm_crtc_cleanup,
+   .destroy = imx_drm_crtc_destroy,
.page_flip = drm_atomic_helper_page_flip,
.reset = imx_drm_crtc_reset,
.atomic_duplicate_state = imx_drm_crtc_duplicate_state,
@@ -410,8 +415,6 @@ static void ipu_drm_unbind(struct device *dev, struct 
device *master,
 {
struct ipu_crtc *ipu_crtc = dev_get_drvdata(dev);

-   imx_drm_remove_crtc(ipu_crtc->imx_crtc);
-
ipu_put_resources(ipu_crtc);
if (ipu_crtc->plane[1])
ipu_plane_put_resources(ipu_crtc->plane[1]);
diff --git a/drivers/gpu/drm/imx/parallel-display.c 
b/drivers/gpu/drm/imx/parallel-display.c
index 1dad297b01fd..d6010d09ade0 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -289,9 +289,6 @@ static void imx_pd_unbind(struct device *dev, struct device 
*master,
 {
struct imx_parallel_display *imxpd = dev_get_drvdata(dev);

-   imxpd->encoder.funcs->destroy(>encoder);
-   imxpd->connector.funcs->destroy(>connector);
-
kfree(imxpd->edid);
 }

-- 
2.8.1



[PATCH 2/5] drm/imx: drop deprecated load/unload drm_driver ops

2016-08-11 Thread Lucas Stach
Drop the load/unload driver ops, as they are deprecated because of their
inherent races, with devices being visible to userspace before they are
fully initialized.

Move this code into the driver bind/unbind routines bracketed by the
proper drm_dev_alloc/register and drm_dev_unregister/unref calls.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 240 +
 1 file changed, 112 insertions(+), 128 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 9f7dafce3a4c..c0d06a0f6825 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -71,25 +71,6 @@ static void imx_drm_driver_lastclose(struct drm_device *drm)
drm_fbdev_cma_restore_mode(imxdrm->fbhelper);
 }

-static int imx_drm_driver_unload(struct drm_device *drm)
-{
-   struct imx_drm_device *imxdrm = drm->dev_private;
-
-   drm_kms_helper_poll_fini(drm);
-
-   if (imxdrm->fbhelper)
-   drm_fbdev_cma_fini(imxdrm->fbhelper);
-
-   component_unbind_all(drm->dev, drm);
-
-   drm_vblank_cleanup(drm);
-   drm_mode_config_cleanup(drm);
-
-   platform_set_drvdata(drm->platformdev, NULL);
-
-   return 0;
-}
-
 int imx_drm_crtc_vblank_get(struct imx_drm_crtc *imx_drm_crtc)
 {
return drm_crtc_vblank_get(imx_drm_crtc->crtc);
@@ -234,111 +215,6 @@ static struct drm_mode_config_helper_funcs 
imx_drm_mode_config_helpers = {
 };

 /*
- * Main DRM initialisation. This binds, initialises and registers
- * with DRM the subcomponents of the driver.
- */
-static int imx_drm_driver_load(struct drm_device *drm, unsigned long flags)
-{
-   struct imx_drm_device *imxdrm;
-   struct drm_connector *connector;
-   int ret;
-
-   imxdrm = devm_kzalloc(drm->dev, sizeof(*imxdrm), GFP_KERNEL);
-   if (!imxdrm)
-   return -ENOMEM;
-
-   imxdrm->drm = drm;
-
-   drm->dev_private = imxdrm;
-
-   /*
-* enable drm irq mode.
-* - with irq_enabled = true, we can use the vblank feature.
-*
-* P.S. note that we wouldn't use drm irq handler but
-*  just specific driver own one instead because
-*  drm framework supports only one irq handler and
-*  drivers can well take care of their interrupts
-*/
-   drm->irq_enabled = true;
-
-   /*
-* set max width and height as default value(4096x4096).
-* this value would be used to check framebuffer size limitation
-* at drm_mode_addfb().
-*/
-   drm->mode_config.min_width = 64;
-   drm->mode_config.min_height = 64;
-   drm->mode_config.max_width = 4096;
-   drm->mode_config.max_height = 4096;
-   drm->mode_config.funcs = _drm_mode_config_funcs;
-   drm->mode_config.helper_private = _drm_mode_config_helpers;
-
-   drm_mode_config_init(drm);
-
-   ret = drm_vblank_init(drm, MAX_CRTC);
-   if (ret)
-   goto err_kms;
-
-   platform_set_drvdata(drm->platformdev, drm);
-
-   /* Now try and bind all our sub-components */
-   ret = component_bind_all(drm->dev, drm);
-   if (ret)
-   goto err_vblank;
-
-   /*
-* All components are now added, we can publish the connector sysfs
-* entries to userspace.  This will generate hotplug events and so
-* userspace will expect to be able to access DRM at this point.
-*/
-   list_for_each_entry(connector, >mode_config.connector_list, head) {
-   ret = drm_connector_register(connector);
-   if (ret) {
-   dev_err(drm->dev,
-   "[CONNECTOR:%d:%s] drm_connector_register 
failed: %d\n",
-   connector->base.id,
-   connector->name, ret);
-   goto err_unbind;
-   }
-   }
-
-   drm_mode_config_reset(drm);
-
-   /*
-* All components are now initialised, so setup the fb helper.
-* The fb helper takes copies of key hardware information, so the
-* crtcs/connectors/encoders must not change after this point.
-*/
-#if IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION)
-   if (legacyfb_depth != 16 && legacyfb_depth != 32) {
-   dev_warn(drm->dev, "Invalid legacyfb_depth.  Defaulting to 
16bpp\n");
-   legacyfb_depth = 16;
-   }
-   imxdrm->fbhelper = drm_fbdev_cma_init(drm, legacyfb_depth,
-   drm->mode_config.num_crtc, MAX_CRTC);
-   if (IS_ERR(imxdrm->fbhelper)) {
-   ret = PTR_ERR(imxdrm->fbhelper);
-   imxdrm->fbhelper = NULL;
-   goto err_unbind;
-   }
-#endif
-
-   drm_kms_helper_poll_init(drm);
-
-   return 0;
-
-err_unbind:
-   component_unbind_all(drm->dev, drm);
-err_vblank:
-   drm_vblank_cleanup(drm);
-err_kms:
-   drm_mode_config_cleanup(drm);
-
- 

[PATCH 1/5] drm/imx: don't call disable_plane in plane destroy path

2016-08-11 Thread Lucas Stach
When the destroy path is called the plane should already be
disabled. If not, this is a core bug and should not be worked
around in the driver.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 4ad67d015ec7..6cc809e1ca55 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -242,7 +242,6 @@ static void ipu_plane_destroy(struct drm_plane *plane)

DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);

-   ipu_disable_plane(plane);
drm_plane_cleanup(plane);
kfree(ipu_plane);
 }
-- 
2.8.1



[PATCH 01/20] drm/doc: Fix more kerneldoc/sphinx warnings

2016-08-11 Thread Jani Nikula
On Tue, 09 Aug 2016, Daniel Vetter  wrote:
> These are the leftovers I could only track down using keep_warnings =
> True. For some of them we might want to update our style guide on how
> to reference structures and constants, not sure ...
>
> Cc: Markus Heiser 
> Cc: Jonathan Corbet 
> Cc: linux-doc at vger.kernel.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_crtc.c  |  4 ++--
>  drivers/gpu/drm/drm_fb_helper.c |  2 +-
>  drivers/gpu/drm/drm_irq.c   |  8 +++
>  drivers/gpu/drm/drm_simple_kms_helper.c |  2 +-
>  drivers/gpu/drm/i915/i915_vgpu.c| 42 
> -
>  drivers/gpu/drm/i915/intel_audio.c  |  6 ++---
>  drivers/gpu/drm/i915/intel_guc_fwif.h   |  5 ++--
>  include/drm/drm_crtc.h  |  8 +++
>  include/drm/drm_gem.h   |  4 ++--
>  9 files changed, 41 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 3d03eb1e3b63..ad38a8a31898 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1272,7 +1272,7 @@ static unsigned int drm_num_planes(struct drm_device 
> *dev)
>   * @plane: plane object to init
>   * @possible_crtcs: bitmask of possible CRTCs
>   * @funcs: callbacks for the new plane
> - * @formats: array of supported formats (%DRM_FORMAT_*)
> + * @formats: array of supported formats (DRM_FORMAT\_\*)

Future idea: If we turned DRM_FORMAT_* into an enum instead of a
plethora of macros, we could reference the enum here. Not to mention the
code being self-documenting too.

>   * @format_count: number of elements in @formats
>   * @type: type of plane (overlay, primary, cursor)
>   * @name: printf style format string for the plane name, or NULL for default 
> name
> @@ -1387,7 +1387,7 @@ static void drm_plane_unregister_all(struct drm_device 
> *dev)
>   * @plane: plane object to init
>   * @possible_crtcs: bitmask of possible CRTCs
>   * @funcs: callbacks for the new plane
> - * @formats: array of supported formats (%DRM_FORMAT_*)
> + * @formats: array of supported formats (DRM_FORMAT\_\*)
>   * @format_count: number of elements in @formats
>   * @is_primary: plane type (primary vs overlay)
>   *
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index ce54e985d91b..95f405e04f5f 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2194,7 +2194,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
>   * @fb_helper: the drm_fb_helper
>   *
>   * Scan the connectors attached to the fb_helper and try to put together a
> - * setup after *notification of a change in output configuration.
> + * setup after notification of a change in output configuration.
>   *
>   * Called at runtime, takes the mode config locks to be able to check/change 
> the
>   * modeset configuration. Must be run from process context (which usually 
> means
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 9bdce1cb6c5c..10611a936059 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -713,10 +713,10 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
>   * Negative value on error, failure or if not supported in current
>   * video mode:
>   *
> - * -EINVAL   - Invalid CRTC.
> - * -EAGAIN   - Temporary unavailable, e.g., called before initial modeset.
> - * -ENOTSUPP - Function not supported in current display mode.
> - * -EIO  - Failed, e.g., due to failed scanout position query.
> + * -EINVALInvalid CRTC.
> + * -EAGAINTemporary unavailable, e.g., called before initial modeset.
> + * -ENOTSUPP  Function not supported in current display mode.
> + * -EIO   Failed, e.g., due to failed scanout position query.
>   *
>   * Returns or'ed positive status flags on success:
>   *
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 0db36d27e90b..4e1de31f072b 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -152,7 +152,7 @@ static const struct drm_plane_funcs 
> drm_simple_kms_plane_funcs = {
>   * @dev: DRM device
>   * @pipe: simple display pipe object to initialize
>   * @funcs: callbacks for the display pipe (optional)
> - * @formats: array of supported formats (%DRM_FORMAT_*)
> + * @formats: array of supported formats (DRM_FORMAT\_\*)
>   * @format_count: number of elements in @formats
>   * @connector: connector to attach and register
>   *
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c 
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 142bac976919..ca2e91259948 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -156,27 +156,27 @@ static int vgt_balloon_space(struct drm_mm *mm,
>   * host point of view, the graphic address space is partitioned by multiple
>   * vGPUs in different VMs. ::
>   *
> - *vGPU1 view 

[PATCH v7 1/5] drm: Read DP branch device HW revision

2016-08-11 Thread Mika Kahola
On Thu, 2016-08-11 at 10:10 +0300, Ville Syrjälä wrote:
> On Mon, Aug 08, 2016 at 04:00:26PM +0300, Mika Kahola wrote:
> > HW revision is mandatory field for DisplayPort branch
> > devices. This is defined in DPCD register field 0x509.
> 
> But what do we want to do with it? Me, I don't see a point in parsing a
> bunch of stuff from the DPCD unless there's a real use case for it.
> /dev/drm_dp_aux will provide all the debug aid we need if we need to
> check random pieces of data from the DPCD, so even exposing this sort
> of stuff via debugfs is IMO pretty pointless.
> 
> If there's a good reason for a debug print, then I think we could parse
> something and dump it out so that it's always in the dmesg. But so far
> I'm not aware of any bug that would have required to deal with different
> hw revisions of things and whatnot.
> 
Digging up the HW and SW revisions are just for debugging purposes. My
idea here was that it would be handy if this information would be
available if we face a problem let's say with VGA dongle for example. It
is true that at the moment we don't have a single bug that would require
HW/SW revision information but maybe in the future we have one.

So, if we don't want to have this stuff in drm_dp_helpers and/or debugfs
I could make a change and print this info on dmesg when DP branch device
is plugged in.

Cheers,
Mika

> > 
> > v2: move drm_dp_ds_revision structure to be part of
> > drm_dp_link structure (Daniel)
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c  | 27 +++
> >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> >  include/drm/drm_dp_helper.h  |  9 +
> >  3 files changed, 37 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 75b2873..5fecdc1 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -514,6 +514,33 @@ int drm_dp_downstream_max_bpc(const u8 
> > dpcd[DP_RECEIVER_CAP_SIZE],
> >  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
> >  
> >  /**
> > + * drm_dp_downstream_hw_rev() - read DP branch device HW revision
> > + * @aux: DisplayPort AUX channel
> > + *
> > + * Returns 0 on succes or negative error code on failure
> > + */
> > +int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > +struct drm_dp_aux *aux, struct drm_dp_link *link)
> > +{
> > +   uint8_t tmp;
> > +   int err;
> > +
> > +   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
> > +   return -EINVAL;
> > +
> > +   err = drm_dp_dpcd_read(aux, DP_BRANCH_HW_REV, , 1);
> > +
> > +   if (err < 0)
> > +   return err;
> > +
> > +   link->ds_hw_rev.major = (tmp & 0xf0) >> 4;
> > +   link->ds_hw_rev.minor = tmp & 0xf;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_dp_downstream_hw_rev);
> > +
> > +/**
> >   * drm_dp_downstream_id() - identify branch device
> >   * @aux: DisplayPort AUX channel
> >   *
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index e74d851..a6eccf5 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -865,6 +865,7 @@ struct intel_dp {
> > uint8_t num_sink_rates;
> > int sink_rates[DP_MAX_SUPPORTED_RATES];
> > struct drm_dp_aux aux;
> > +   struct drm_dp_link link;
> > uint8_t train_set[4];
> > int panel_power_up_delay;
> > int panel_power_down_delay;
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 8e1fe58..1127948 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -446,6 +446,7 @@
> >  #define DP_SINK_OUI0x400
> >  #define DP_BRANCH_OUI  0x500
> >  #define DP_BRANCH_ID0x503
> > +#define DP_BRANCH_HW_REV0x509
> >  
> >  #define DP_SET_POWER0x600
> >  # define DP_SET_POWER_D00x1
> > @@ -803,11 +804,17 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux 
> > *aux,
> >   */
> >  #define DP_LINK_CAP_ENHANCED_FRAMING (1 << 0)
> >  
> > +struct drm_dp_ds_revision {
> > +   int major;
> > +   int minor;
> > +};
> > +
> >  struct drm_dp_link {
> > unsigned char revision;
> > unsigned int rate;
> > unsigned int num_lanes;
> > unsigned long capabilities;
> > +   struct drm_dp_ds_revision ds_hw_rev;
> >  };
> >  
> >  int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
> > @@ -819,6 +826,8 @@ int drm_dp_downstream_max_clock(const u8 
> > dpcd[DP_RECEIVER_CAP_SIZE],
> >  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> >   const u8 port_cap[4]);
> >  int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
> > +int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > +struct drm_dp_aux *aux, struct 

[PATCH v4.5 3/4] drm/mediatek: Add gamma correction.

2016-08-11 Thread Philipp Zabel
>From 2f3f4dda747c0619594d13996e65598ab675c60c Mon Sep 17 00:00:00 2001
From: Bibby Hsieh 
Date: Thu, 28 Jul 2016 10:22:54 +0800
Subject: [PATCH] drm/mediatek: Add gamma correction.

Add gamma set function to correct brightness values.
It applies arbitrary mapping curve to compensate the
incorrect transfer function of the panel.

Signed-off-by: Bibby Hsieh 
Signed-off-by: Philipp Zabel 
---
I have applied this patch with one change from v4:
 - Use drm_crtc_enable_color_mgmt instead of drm_crtc_helper_enable_color_mgmt
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  7 ++-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h |  1 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 31 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 10 ++
 4 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 24aa3ba..e3ac280 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -409,6 +409,9 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
}
if (pending_planes)
mtk_crtc->pending_planes = true;
+   if (crtc->state->color_mgmt_changed)
+   for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
+   mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
 }

 static const struct drm_crtc_funcs mtk_crtc_funcs = {
@@ -418,6 +421,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
.reset  = mtk_drm_crtc_reset,
.atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
.atomic_destroy_state   = mtk_drm_crtc_destroy_state,
+   .gamma_set  = drm_atomic_helper_legacy_gamma_set,
 };

 static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
@@ -568,7 +572,8 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
_crtc->planes[1].base, pipe);
if (ret < 0)
goto unprepare;
-
+   drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
+   drm_crtc_enable_color_mgmt(_crtc->base, 0, false, MTK_LUT_SIZE);
priv->crtc[pipe] = _crtc->base;
priv->num_pipes++;

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index 81e5566..d332564 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
@@ -19,6 +19,7 @@
 #include "mtk_drm_plane.h"

 #define OVL_LAYER_NR   4
+#define MTK_LUT_SIZE   512

 int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe);
 void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int pipe);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index ba895c8..42cd587 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -24,6 +24,7 @@
 #include "mtk_drm_drv.h"
 #include "mtk_drm_plane.h"
 #include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_crtc.h"

 #define DISP_OD_EN 0x
 #define DISP_OD_INTEN  0x0008
@@ -42,7 +43,11 @@
 #define DISP_AAL_SIZE  0x0030

 #define DISP_GAMMA_EN  0x
+#define DISP_GAMMA_CFG 0x0020
 #define DISP_GAMMA_SIZE0x0030
+#define DISP_GAMMA_LUT 0x0700
+
+#define LUT_10BIT_MASK 0x03ff

 #defineOD_RELAY_MODE   BIT(0)

@@ -54,6 +59,7 @@
 #define AAL_EN BIT(0)

 #define GAMMA_EN   BIT(0)
+#define GAMMA_LUT_EN   BIT(1)

 static void mtk_color_config(struct mtk_ddp_comp *comp, unsigned int w,
 unsigned int h, unsigned int vrefresh)
@@ -118,13 +124,38 @@ static void mtk_gamma_stop(struct mtk_ddp_comp *comp)
writel_relaxed(0x0, comp->regs  + DISP_GAMMA_EN);
 }

+static void mtk_gamma_set(struct mtk_ddp_comp *comp,
+ struct drm_crtc_state *state)
+{
+   unsigned int i, reg;
+   struct drm_color_lut *lut;
+   void __iomem *lut_base;
+   u32 word;
+
+   if (state->gamma_lut) {
+   reg = readl(comp->regs + DISP_GAMMA_CFG);
+   reg = reg | GAMMA_LUT_EN;
+   writel(reg, comp->regs + DISP_GAMMA_CFG);
+   lut_base = comp->regs + DISP_GAMMA_LUT;
+   lut = (struct drm_color_lut *)state->gamma_lut->data;
+   for (i = 0; i < MTK_LUT_SIZE; i++) {
+   word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
+   (((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
+   ((lut[i].blue >> 6) & LUT_10BIT_MASK);
+   writel(word, (lut_base + i * 4));
+   }
+   }
+}
+
 static const struct 

[PATCH v2 0/7] drm/mediatek: cleaning up and refine

2016-08-11 Thread Philipp Zabel
Am Donnerstag, den 11.08.2016, 10:51 +0200 schrieb Daniel Vetter:
> On Thu, Aug 11, 2016 at 09:33:26AM +0200, Philipp Zabel wrote:
> > Am Donnerstag, den 04.08.2016, 10:59 +0800 schrieb Bibby Hsieh:
> > > These patches based on 4.7-rc1 to clean up unused function
> > > & variable and use drm core function instead.
> > > 
> > > The following patches are needed to cleanly apply on top of v4.7-rc1:
> > >  - https://patchwork.kernel.org/patch/8044001/
> > >(drm: Deal with rotation in drm_plane_helper_check_update())
> > >  - https://patchwork.kernel.org/patch/9248373/
> > >(drm: Warn about negative sizes when calculating scale factor)
> > >  - https://patchwork.kernel.org/patch/9248371/
> > >(drm: Store clipped src/dst coordinatee in drm_plane_state)
> > >  - https://patchwork.kernel.org/patch/9248363/
> > >(drm/plane-helper: Add drm_plane_helper_check_state())
> > >  - https://patchwork.kernel.org/patch/9248361/
> > >(drm/mediatek: Use drm_plane_helper_check_state())
> > > 
> > > Bibby Hsieh (2):
> > >   drm/mediatek: Use drm_atomic destroy_state helpers
> > >   drm/mediatek: Fix mtk_atomic_complete for runtime_pm
> > > 
> > > Daniel Kurtz (5):
> > >   drm/mediatek: Remove mtk_drm_crtc_check_flush
> > >   drm/mediatek: plane: Remove plane zpos/index
> > >   drm/mediatek: Remove mtk_drm_plane
> > 
> > I have picked up patches 1-5, but not patches 6-7:
> > 
> > >   drm/mediatek: plane: Merge mtk_plane_enable into
> > > mtk_plane_atomic_update
> > >   drm/mediatek: plane: Use FB's format's cpp to compute x offset
> > 
> > These two don't apply. Could you please rebase them onto
> > git.pengutronix.de/git/pza/linux.git mediatek-drm/next
>
> Note that I think most of them are already in drm-misc, and that branch is
> non-rebasing.
> -Daniel

Thanks. Please disregard then, I'll drop the already applied patches and
rebase onto drm-misc if necessary.

regards
Philipp



[PATCH v4 3/4] drm/mediatek: Add gamma correction.

2016-08-11 Thread Ville Syrjälä
On Thu, Aug 11, 2016 at 09:51:16AM +0200, Philipp Zabel wrote:
> Am Donnerstag, den 11.08.2016, 10:44 +0300 schrieb Ville Syrjälä:
> > On Thu, Aug 11, 2016 at 09:32:59AM +0200, Philipp Zabel wrote:
> > > Am Donnerstag, den 28.07.2016, 10:22 +0800 schrieb Bibby Hsieh:
> > > > Add gamma set function to correct brightness values.
> > > > It applies arbitrary mapping curve to compensate the
> > > > incorrect transfer function of the panel.
> > > > 
> > > > Signed-off-by: Bibby Hsieh 
> > > > ---
> > > >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 ++-
> > > >  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   31 
> > > > +++
> > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   10 +
> > > >  4 files changed, 49 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> > > > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > index 24aa3ba..cbb460a5 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > @@ -409,6 +409,9 @@ static void mtk_drm_crtc_atomic_flush(struct 
> > > > drm_crtc *crtc,
> > > > }
> > > > if (pending_planes)
> > > > mtk_crtc->pending_planes = true;
> > > > +   if (crtc->state->color_mgmt_changed)
> > > > +   for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > > > +   mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], 
> > > > crtc->state);
> > > >  }
> > > >  
> > > >  static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > > > @@ -418,6 +421,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = 
> > > > {
> > > > .reset  = mtk_drm_crtc_reset,
> > > > .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > > > .atomic_destroy_state   = mtk_drm_crtc_destroy_state,
> > > > +   .gamma_set  = drm_atomic_helper_legacy_gamma_set,
> > > >  };
> > > >  
> > > >  static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > > > @@ -568,7 +572,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > > > _crtc->planes[1].base, pipe);
> > > > if (ret < 0)
> > > > goto unprepare;
> > > > -
> > > > +   drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
> > > > +   drm_helper_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
> > > > + MTK_LUT_SIZE);
> > > 
> > > I have applied all four patches and rebased onto v4.8-rc1, replacing
> > > drm_helper_crtc_enable_color_mgmt with:
> > > 
> > >   drm_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
> > >  true, MTK_LUT_SIZE);
> > 
> > BTW that looks wrong (already in the original). AFAICS the patch just
> > handled the gamma_lut, not the degamma_lut, so telling you have both
> > is not right.
> 
> Thanks, so should that be
>drm_crtc_enable_color_mgmt(_crtc->base, 0, false,
>   MTK_LUT_SIZE);
> instead, since we only handle gamma?

Hmm. Yeah, that looks correct since you didn't seem to have "ctm" either.

-- 
Ville Syrjälä
Intel OTC


drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference

2016-08-11 Thread Paul E. McKenney
On Thu, Aug 11, 2016 at 11:44:08AM +0200, Peter Zijlstra wrote:
> On Wed, Jun 22, 2016 at 08:46:12AM +0100, Chris Wilson wrote:
> > We are only documenting that the read is outside of the lock, and do not
> > require strict ordering on the operation. In this case the more relaxed
> > lockless_dereference() will suffice.
> 
> No, no, no... This is 'broken'. lockless_dereference() is _stronger_
> than READ_ONCE(), not weaker.
> 
> lockless_dereference() is a wrapper around smp_read_barrier_depends()
> and is used to form read dependencies. There is no read dependency here,
> therefore using lockless_dereference() is entirely pointless.
> 
> Look at the definition of lockless_dereference(), it does a READ_ONCE()
> and then smp_read_barrier_depends().
> 
> Also, clue is in the name: 'dereference', you don't actually dereference
> the pointer here, only load it.

What Peter said!

If you are just checking the value of an RCU-protected pointer,
that is, one on which you would use rcu_dereference() rather than
lockless_dereference(), rcu_access_pointer() does the job of READ_ONCE()
while keeping sparse happy.

Thanx, Paul

> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -464,7 +464,7 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper 
> > *fb_helper)
> >  
> > /* Sometimes user space wants everything disabled, so don't steal the
> >  * display if there's a master. */
> > -   if (READ_ONCE(dev->master))
> > +   if (lockless_dereference(dev->master))
> > return false;
> >  
> > drm_for_each_crtc(crtc, dev) {
> 



[PATCH v2 6/6] dma-buf/sw_sync: de-stage SW_SYNC

2016-08-11 Thread Eric Engestrom
On Mon, Aug 08, 2016 at 06:24:22PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> SW_SYNC allows to run tests on the sync_file framework via debugfs on
> 
> /sync/sw_sync
> 
> Opening and closing the file triggers creation and release of a sync
> timeline. To create fences on this timeline the SW_SYNC_IOC_CREATE_FENCE
> ioctl should be used. To increment the timeline value use SW_SYNC_IOC_INC.
> 
> Also it exports Sync information on
> 
> /sync/info
> 
> Signed-off-by: Gustavo Padovan 

Reviewed-by: Eric Engestrom 

> ---
>  drivers/dma-buf/Kconfig  |  13 ++
>  drivers/dma-buf/Makefile |   1 +
>  drivers/dma-buf/sw_sync.c| 349 
> +++
>  drivers/dma-buf/sync_debug.c | 230 +++
>  drivers/dma-buf/sync_debug.h |  69 +++
>  drivers/dma-buf/sync_trace.h |  32 
>  drivers/staging/android/Kconfig  |  13 --
>  drivers/staging/android/Makefile |   1 -
>  drivers/staging/android/sw_sync.c| 349 
> ---
>  drivers/staging/android/sync_debug.c | 230 ---
>  drivers/staging/android/sync_debug.h |  69 ---
>  drivers/staging/android/sync_trace.h |  32 
>  12 files changed, 694 insertions(+), 694 deletions(-)
>  create mode 100644 drivers/dma-buf/sw_sync.c
>  create mode 100644 drivers/dma-buf/sync_debug.c
>  create mode 100644 drivers/dma-buf/sync_debug.h
>  create mode 100644 drivers/dma-buf/sync_trace.h
>  delete mode 100644 drivers/staging/android/sw_sync.c
>  delete mode 100644 drivers/staging/android/sync_debug.c
>  delete mode 100644 drivers/staging/android/sync_debug.h
>  delete mode 100644 drivers/staging/android/sync_trace.h
> 

[snip]


[PATCH v7 4/5] drm: Update bits per component for display info

2016-08-11 Thread Daniel Vetter
On Thu, Aug 11, 2016 at 10:22:27AM +0300, Ville Syrjälä wrote:
> On Mon, Aug 08, 2016 at 04:00:29PM +0300, Mika Kahola wrote:
> > DisplayPort branch device may define max supported bits per
> > component. Update display info based on this value if bpc
> > is defined.
> > 
> > v2: cleanup to match the drm_dp_helper.c patches introduced
> > earlier in this series
> > v3: Fill bpc for connector's display info in separate
> > drm_dp_helper function (Daniel)
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 24 
> >  drivers/gpu/drm/i915/intel_dp.c |  3 +++
> >  include/drm/drm_dp_helper.h |  4 
> >  3 files changed, 31 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 1f36016..a2c46ed 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -514,6 +514,30 @@ int drm_dp_downstream_max_bpc(const u8 
> > dpcd[DP_RECEIVER_CAP_SIZE],
> >  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
> >  
> >  /**
> > + * drm_dp_downstream_update_max_bpc() - extract branch device max
> > + *  bits per component and update
> > + *  connector max bpc
> > + * @dpcd: DisplayPort configuration data
> > + * @port_cap: port capabilities
> > + * @connector: Connector info
> > + * Returns current max bpc on success
> > + */
> > +int drm_dp_downstream_update_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > +const u8 port_cap[4],
> > +struct drm_connector *connector)
> > +{
> > +   if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT) {
> > +   int bpc = drm_dp_downstream_max_bpc(dpcd, port_cap);
> > +
> > +   if (bpc > 0)
> > +   connector->display_info.bpc = bpc;
> > +   }
> > +
> > +   return connector->display_info.bpc;
> > +}
> > +EXPORT_SYMBOL(drm_dp_downstream_update_max_bpc);
> > +
> > +/**
> >   * drm_dp_downstream_hw_rev() - read DP branch device HW revision
> >   * @aux: DisplayPort AUX channel
> >   *
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index e990c8b..763e2f5 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3985,6 +3985,9 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> > uint8_t *dpcd = intel_dp->dpcd;
> > uint8_t type;
> >  
> > +   drm_dp_downstream_update_max_bpc(dpcd, intel_dp->downstream_ports,
> > +_dp->attached_connector->base);
> > +
> 
> And it will be promptly overwritten by the EDID parser. Like I said
> before, touching display_info from elsewhere is a bad idea right now.
> We need to lay out some real rules on how the EDID parser vs. DP
> helpers must be called if we are to share that information between
> the two.
> 
> For now, I would just utilize the DP helper in the compute_config
> to limit the bpc.

I think we need one dp helper which does _all_ the sink detection, and in
the right order. Edid reading dpcd decoding, all that. And then stuff is
all into relevant structures like display_info, but also some new (or well
I think we have parts of it already) dp_sink struct. Otherwise this will
stay fragile, especially once other drivers start using it.
-Daniel

> 
> > if (!intel_dp_get_dpcd(intel_dp))
> > return connector_status_disconnected;
> >  
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 45366aa..5491a9b 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -26,6 +26,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  /*
> >   * Unless otherwise noted, all values are from the DP 1.1a spec.  Note that
> > @@ -827,6 +828,9 @@ int drm_dp_downstream_max_clock(const u8 
> > dpcd[DP_RECEIVER_CAP_SIZE],
> > const u8 port_cap[4]);
> >  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> >   const u8 port_cap[4]);
> > +int drm_dp_downstream_update_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > +const u8 port_cap[4],
> > +struct drm_connector *connector);
> >  int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
> >  int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> >  struct drm_dp_aux *aux, struct drm_dp_link *link);
> > -- 
> > 1.9.1
> 
> -- 
> Ville Syrjälä
> Intel OTC

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


[PATCH v2 0/7] drm/mediatek: cleaning up and refine

2016-08-11 Thread Daniel Vetter
On Thu, Aug 11, 2016 at 09:33:26AM +0200, Philipp Zabel wrote:
> Am Donnerstag, den 04.08.2016, 10:59 +0800 schrieb Bibby Hsieh:
> > These patches based on 4.7-rc1 to clean up unused function
> > & variable and use drm core function instead.
> > 
> > The following patches are needed to cleanly apply on top of v4.7-rc1:
> >  - https://patchwork.kernel.org/patch/8044001/
> >(drm: Deal with rotation in drm_plane_helper_check_update())
> >  - https://patchwork.kernel.org/patch/9248373/
> >(drm: Warn about negative sizes when calculating scale factor)
> >  - https://patchwork.kernel.org/patch/9248371/
> >(drm: Store clipped src/dst coordinatee in drm_plane_state)
> >  - https://patchwork.kernel.org/patch/9248363/
> >(drm/plane-helper: Add drm_plane_helper_check_state())
> >  - https://patchwork.kernel.org/patch/9248361/
> >(drm/mediatek: Use drm_plane_helper_check_state())
> > 
> > Bibby Hsieh (2):
> >   drm/mediatek: Use drm_atomic destroy_state helpers
> >   drm/mediatek: Fix mtk_atomic_complete for runtime_pm
> > 
> > Daniel Kurtz (5):
> >   drm/mediatek: Remove mtk_drm_crtc_check_flush
> >   drm/mediatek: plane: Remove plane zpos/index
> >   drm/mediatek: Remove mtk_drm_plane
> 
> I have picked up patches 1-5, but not patches 6-7:
> 
> >   drm/mediatek: plane: Merge mtk_plane_enable into
> > mtk_plane_atomic_update
> >   drm/mediatek: plane: Use FB's format's cpp to compute x offset
> 
> These two don't apply. Could you please rebase them onto
> git.pengutronix.de/git/pza/linux.git mediatek-drm/next

Note that I think most of them are already in drm-misc, and that branch is
non-rebasing.
-Daniel

> 
> regards
> Philipp
> 

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


[PATCH v4 3/4] drm/mediatek: Add gamma correction.

2016-08-11 Thread Daniel Vetter
On Thu, Aug 11, 2016 at 11:02:27AM +0300, Ville Syrjälä wrote:
> On Thu, Aug 11, 2016 at 09:51:16AM +0200, Philipp Zabel wrote:
> > Am Donnerstag, den 11.08.2016, 10:44 +0300 schrieb Ville Syrjälä:
> > > On Thu, Aug 11, 2016 at 09:32:59AM +0200, Philipp Zabel wrote:
> > > > Am Donnerstag, den 28.07.2016, 10:22 +0800 schrieb Bibby Hsieh:
> > > > > Add gamma set function to correct brightness values.
> > > > > It applies arbitrary mapping curve to compensate the
> > > > > incorrect transfer function of the panel.
> > > > > 
> > > > > Signed-off-by: Bibby Hsieh 
> > > > > ---
> > > > >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 ++-
> > > > >  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> > > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   31 
> > > > > +++
> > > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   10 +
> > > > >  4 files changed, 49 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> > > > > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > > index 24aa3ba..cbb460a5 100644
> > > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > > @@ -409,6 +409,9 @@ static void mtk_drm_crtc_atomic_flush(struct 
> > > > > drm_crtc *crtc,
> > > > >   }
> > > > >   if (pending_planes)
> > > > >   mtk_crtc->pending_planes = true;
> > > > > + if (crtc->state->color_mgmt_changed)
> > > > > + for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > > > > + mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], 
> > > > > crtc->state);
> > > > >  }
> > > > >  
> > > > >  static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > > > > @@ -418,6 +421,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs 
> > > > > = {
> > > > >   .reset  = mtk_drm_crtc_reset,
> > > > >   .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > > > >   .atomic_destroy_state   = mtk_drm_crtc_destroy_state,
> > > > > + .gamma_set  = drm_atomic_helper_legacy_gamma_set,
> > > > >  };
> > > > >  
> > > > >  static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > > > > @@ -568,7 +572,9 @@ int mtk_drm_crtc_create(struct drm_device 
> > > > > *drm_dev,
> > > > >   _crtc->planes[1].base, pipe);
> > > > >   if (ret < 0)
> > > > >   goto unprepare;
> > > > > -
> > > > > + drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
> > > > > + drm_helper_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
> > > > > +   MTK_LUT_SIZE);
> > > > 
> > > > I have applied all four patches and rebased onto v4.8-rc1, replacing
> > > > drm_helper_crtc_enable_color_mgmt with:
> > > > 
> > > > drm_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
> > > >true, MTK_LUT_SIZE);
> > > 
> > > BTW that looks wrong (already in the original). AFAICS the patch just
> > > handled the gamma_lut, not the degamma_lut, so telling you have both
> > > is not right.
> > 
> > Thanks, so should that be
> >drm_crtc_enable_color_mgmt(_crtc->base, 0, false,
> >   MTK_LUT_SIZE);
> > instead, since we only handle gamma?
> 
> Hmm. Yeah, that looks correct since you didn't seem to have "ctm" either.

Yup, that's how this is meant to be used.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[Intel-gfx] [PATCH v2 05/15] drm/atmel-hlcdc: Use per-plane rotation property

2016-08-11 Thread Daniel Vetter
On Wed, Aug 10, 2016 at 06:38:39PM +0200, Boris Brezillon wrote:
> On Wed, 10 Aug 2016 16:04:37 +0200
> Daniel Vetter  wrote:
> 
> > On Wed, Aug 10, 2016 at 01:52:45PM +0200, Boris Brezillon wrote:
> > > On Wed, 10 Aug 2016 14:41:52 +0300
> > > Ville Syrjälä  wrote:
> > >   
> > > > On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote:  
> > > > > On Wed, 10 Aug 2016 12:09:41 +0300
> > > > > Ville Syrjälä  wrote:
> > > > > 
> > > > > > On Wed, Aug 10, 2016 at 10:35:22AM +0200, Boris Brezillon wrote:
> > > > > > > Hi Ville,
> > > > > > > 
> > > > > > > On Fri, 22 Jul 2016 18:47:01 +0300
> > > > > > > ville.syrjala at linux.intel.com wrote:
> > > > > > >   
> > > > > > > > From: Ville Syrjälä 
> > > > > > > > 
> > > > > > > > The global mode_config.rotation_property is going away, switch 
> > > > > > > > over to
> > > > > > > > per-plane rotation_property.
> > > > > > > > 
> > > > > > > > v2: Propagate error upwards (Boris)
> > > > > > > > 
> > > > > > > > Cc: Boris Brezillon 
> > > > > > > > Signed-off-by: Ville Syrjälä  > > > > > > > linux.intel.com>
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 37 
> > > > > > > > +
> > > > > > > >  1 file changed, 20 insertions(+), 17 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> > > > > > > > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > > > > > > > index f3350c80704d..ee9bd7a938c3 100644
> > > > > > > > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > > > > > > > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > > > > > > > @@ -883,9 +883,9 @@ static int 
> > > > > > > > atmel_hlcdc_plane_atomic_get_property(struct drm_plane *p,
> > > > > > > > return 0;
> > > > > > > >  }
> > > > > > > >  
> > > > > > > > -static void atmel_hlcdc_plane_init_properties(struct 
> > > > > > > > atmel_hlcdc_plane *plane,
> > > > > > > > -   const struct 
> > > > > > > > atmel_hlcdc_layer_desc *desc,
> > > > > > > > -   struct 
> > > > > > > > atmel_hlcdc_plane_properties *props)
> > > > > > > > +static int atmel_hlcdc_plane_init_properties(struct 
> > > > > > > > atmel_hlcdc_plane *plane,
> > > > > > > > +const struct 
> > > > > > > > atmel_hlcdc_layer_desc *desc,
> > > > > > > > +struct 
> > > > > > > > atmel_hlcdc_plane_properties *props)
> > > > > > > >  {
> > > > > > > > struct regmap *regmap = plane->layer.hlcdc->regmap;
> > > > > > > >  
> > > > > > > > @@ -902,10 +902,18 @@ static void 
> > > > > > > > atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane 
> > > > > > > > *plane,
> > > > > > > > ATMEL_HLCDC_LAYER_GA_MASK);
> > > > > > > > }
> > > > > > > >  
> > > > > > > > -   if (desc->layout.xstride && desc->layout.pstride)
> > > > > > > > -   drm_object_attach_property(>base.base,
> > > > > > > > -   
> > > > > > > > plane->base.dev->mode_config.rotation_property,
> > > > > > > > -   BIT(DRM_ROTATE_0));
> > > > > > > > +   if (desc->layout.xstride && desc->layout.pstride) {
> > > > > > > > +   int ret;
> > > > > > > > +
> > > > > > > > +   ret = 
> > > > > > > > drm_plane_create_rotation_property(>base,
> > > > > > > > +
> > > > > > > > BIT(DRM_ROTATE_0),
> > > > > > > > +
> > > > > > > > BIT(DRM_ROTATE_0) |
> > > > > > > > +
> > > > > > > > BIT(DRM_ROTATE_90) |
> > > > > > > > +
> > > > > > > > BIT(DRM_ROTATE_180) |
> > > > > > > > +
> > > > > > > > BIT(DRM_ROTATE_270));
> > > > > > > > +   if (ret)
> > > > > > > > +   return ret;
> > > > > > > > +   }
> > > > > > > >  
> > > > > > > > if (desc->layout.csc) {
> > > > > > > > /*
> > > > > > > > @@ -925,6 +933,8 @@ static void 
> > > > > > > > atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane 
> > > > > > > > *plane,
> > > > > > > >  
> > > > > > > > ATMEL_HLCDC_LAYER_CSC_CFG(>layer, 2),
> > > > > > > >  0x40040890);
> > > > > > > > }
> > > > > > > > +
> > > > > > > > +   return 0;
> > > > > > > >  }
> > > > > > > >  
> > > > > > > >  static struct drm_plane_helper_funcs 
> > > > > > > > atmel_hlcdc_layer_plane_helper_funcs = {
> > > > > > > > @@ -1036,7 +1046,9 @@ atmel_hlcdc_plane_create(struct 
> > > > > > > > drm_device *dev,
> > > > > > > >  
> > > > > > > > _hlcdc_layer_plane_helper_funcs);
> > > > > > > 

[PATCH v4 3/4] drm/mediatek: Add gamma correction.

2016-08-11 Thread Ville Syrjälä
On Thu, Aug 11, 2016 at 09:32:59AM +0200, Philipp Zabel wrote:
> Am Donnerstag, den 28.07.2016, 10:22 +0800 schrieb Bibby Hsieh:
> > Add gamma set function to correct brightness values.
> > It applies arbitrary mapping curve to compensate the
> > incorrect transfer function of the panel.
> > 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 ++-
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   31 
> > +++
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   10 +
> >  4 files changed, 49 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 24aa3ba..cbb460a5 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -409,6 +409,9 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
> > *crtc,
> > }
> > if (pending_planes)
> > mtk_crtc->pending_planes = true;
> > +   if (crtc->state->color_mgmt_changed)
> > +   for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > +   mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
> >  }
> >  
> >  static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > @@ -418,6 +421,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > .reset  = mtk_drm_crtc_reset,
> > .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > .atomic_destroy_state   = mtk_drm_crtc_destroy_state,
> > +   .gamma_set  = drm_atomic_helper_legacy_gamma_set,
> >  };
> >  
> >  static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > @@ -568,7 +572,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > _crtc->planes[1].base, pipe);
> > if (ret < 0)
> > goto unprepare;
> > -
> > +   drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
> > +   drm_helper_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
> > + MTK_LUT_SIZE);
> 
> I have applied all four patches and rebased onto v4.8-rc1, replacing
> drm_helper_crtc_enable_color_mgmt with:
> 
>   drm_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
>  true, MTK_LUT_SIZE);

BTW that looks wrong (already in the original). AFAICS the patch just
handled the gamma_lut, not the degamma_lut, so telling you have both
is not right.

> 
> (See https://patchwork.kernel.org/patch/9160987/)
> 
> regards
> Philipp
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC


[PATCH v2 5/6] staging/android: add Doc for SW_SYNC ioctl interface

2016-08-11 Thread Eric Engestrom
On Mon, Aug 08, 2016 at 06:24:21PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> This interface is hidden from kernel headers and it is intended for use
> only for testing. So testers would have to add the ioctl information
> internally. This is to prevent misuse of this feature.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/staging/android/sw_sync.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/staging/android/sw_sync.c 
> b/drivers/staging/android/sw_sync.c
> index 43491b6..2ac5608 100644
> --- a/drivers/staging/android/sw_sync.c
> +++ b/drivers/staging/android/sw_sync.c
> @@ -25,6 +25,36 @@
>  #define CREATE_TRACE_POINTS
>  #include "sync_trace.h"
>  
> +/*
> + * SW SYNC validation framework
> + *
> + * A sync object driver that uses a 32bit counter to coordinate
> + * synchronization.  Useful when there is no hardware primitive backing
> + * the synchronization.
> + *
> + * To start the framework just open:
> + *
> + * /sync/sw_sync
> + *
> + * That will create a sync timeline, all fences created under this timeline
> + * file descriptor will belong to the this timeline.
> + *
> + * The 'sw_sync' file can be opened many times as to create different
> + * timelines.
> + *
> + * Fences can be created with SW_SYNC_IOC_CREATE_FENCE ioctl with struct
> + * sw_sync_ioctl_create_fence as parameter.
> + *
> + * To increment the timeline counter SW_SYNC_IOC_INC ioctl should be used
> + * with the increment as u32. This will update the last signaled value
> + * from the timeline and signal any fence that has seqno, smaller of equal
> + * it.

This last paragraph could use some love: comma before "SW_SYNC_IOC_INC",
"that has seqno smaller or equal to it."

> + *
> + * struct sw_sync_ioctl_create_fence
> + * @value:   the seqno to initiate the fence with

s/initiate/initialise/

With these fixed,
Reviewed-by: Eric Engestrom 

> + * @name:the name of the new sync point
> + * @fence:   return the fd of the new sync_file with the created fence
> + */
>  struct sw_sync_create_fence_data {
>   __u32   value;
>   charname[32];
> @@ -35,6 +65,7 @@ struct sw_sync_create_fence_data {
>  
>  #define SW_SYNC_IOC_CREATE_FENCE _IOWR(SW_SYNC_IOC_MAGIC, 0,\
>   struct sw_sync_create_fence_data)
> +
>  #define SW_SYNC_IOC_INC  _IOW(SW_SYNC_IOC_MAGIC, 1, 
> __u32)
>  
>  static const struct fence_ops timeline_fence_ops;
> -- 
> 2.5.5


[PATCH v2 4/6] staging/android: prepare sw_sync files for de-staging

2016-08-11 Thread Eric Engestrom
On Mon, Aug 08, 2016 at 06:24:20PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> remove file paths in the comments and add short description about each
> file.
> 
> v2: remove file paths instead of just change them.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/staging/android/sw_sync.c| 2 +-
>  drivers/staging/android/sync_debug.c | 2 +-
>  drivers/staging/android/sync_debug.h | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/android/sw_sync.c 
> b/drivers/staging/android/sw_sync.c
> index 745597b..43491b6 100644
> --- a/drivers/staging/android/sw_sync.c
> +++ b/drivers/staging/android/sw_sync.c
> @@ -1,5 +1,5 @@
>  /*
> - * drivers/dma-buf/sw_sync.c
> + * Sync File validation framework
>   *
>   * Copyright (C) 2012 Google, Inc.
>   *
> diff --git a/drivers/staging/android/sync_debug.c 
> b/drivers/staging/android/sync_debug.c
> index 4c5a855..fab9520 100644
> --- a/drivers/staging/android/sync_debug.c
> +++ b/drivers/staging/android/sync_debug.c
> @@ -1,5 +1,5 @@
>  /*
> - * drivers/base/sync.c
> + * Sync File validation framework and debug information
>   *
>   * Copyright (C) 2012 Google, Inc.
>   *
> diff --git a/drivers/staging/android/sync_debug.h 
> b/drivers/staging/android/sync_debug.h
> index 5b82cf8..ee3c27b 100644
> --- a/drivers/staging/android/sync_debug.h
> +++ b/drivers/staging/android/sync_debug.h
> @@ -1,5 +1,5 @@
>  /*
> - * include/linux/sync.h
> + * Sync File validation framework

"and debug information"

With that added,
Reviewed-by: Eric Engestrom 

>   *
>   * Copyright (C) 2012 Google, Inc.
>   *
> -- 
> 2.5.5


[PATCH v2 3/6] staging/android: move trace/sync.h to sync_trace.h

2016-08-11 Thread Eric Engestrom
On Mon, Aug 08, 2016 at 06:24:19PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> The common behaviour for trace headers is to have them in the same folder
> they are used, instead of creating a special trace/ directory.
> 
> Signed-off-by: Gustavo Padovan 

Reviewed-by: Eric Engestrom 

> ---
>  drivers/staging/android/sw_sync.c|  2 +-
>  drivers/staging/android/sync_trace.h | 32 
>  drivers/staging/android/trace/sync.h | 32 
>  3 files changed, 33 insertions(+), 33 deletions(-)
>  create mode 100644 drivers/staging/android/sync_trace.h
>  delete mode 100644 drivers/staging/android/trace/sync.h
> 
> diff --git a/drivers/staging/android/sw_sync.c 
> b/drivers/staging/android/sw_sync.c
> index ad0bb1a..745597b 100644
> --- a/drivers/staging/android/sw_sync.c
> +++ b/drivers/staging/android/sw_sync.c
> @@ -23,7 +23,7 @@
>  #include "sync_debug.h"
>  
>  #define CREATE_TRACE_POINTS
> -#include "trace/sync.h"
> +#include "sync_trace.h"
>  
>  struct sw_sync_create_fence_data {
>   __u32   value;
> diff --git a/drivers/staging/android/sync_trace.h 
> b/drivers/staging/android/sync_trace.h
> new file mode 100644
> index 000..ea485f7
> --- /dev/null
> +++ b/drivers/staging/android/sync_trace.h
> @@ -0,0 +1,32 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_INCLUDE_PATH ../../drivers/staging/android
> +#define TRACE_SYSTEM sync_trace
> +
> +#if !defined(_TRACE_SYNC_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_SYNC_H
> +
> +#include "sync_debug.h"
> +#include 
> +
> +TRACE_EVENT(sync_timeline,
> + TP_PROTO(struct sync_timeline *timeline),
> +
> + TP_ARGS(timeline),
> +
> + TP_STRUCT__entry(
> + __string(name, timeline->name)
> + __field(u32, value)
> + ),
> +
> + TP_fast_assign(
> + __assign_str(name, timeline->name);
> + __entry->value = timeline->value;
> + ),
> +
> + TP_printk("name=%s value=%d", __get_str(name), __entry->value)
> +);
> +
> +#endif /* if !defined(_TRACE_SYNC_H) || defined(TRACE_HEADER_MULTI_READ) */
> +
> +/* This part must be outside protection */
> +#include 
> diff --git a/drivers/staging/android/trace/sync.h 
> b/drivers/staging/android/trace/sync.h
> deleted file mode 100644
> index 6b5ce96..000
> --- a/drivers/staging/android/trace/sync.h
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -#undef TRACE_SYSTEM
> -#define TRACE_INCLUDE_PATH ../../drivers/staging/android/trace
> -#define TRACE_SYSTEM sync
> -
> -#if !defined(_TRACE_SYNC_H) || defined(TRACE_HEADER_MULTI_READ)
> -#define _TRACE_SYNC_H
> -
> -#include "../sync_debug.h"
> -#include 
> -
> -TRACE_EVENT(sync_timeline,
> - TP_PROTO(struct sync_timeline *timeline),
> -
> - TP_ARGS(timeline),
> -
> - TP_STRUCT__entry(
> - __string(name, timeline->name)
> - __field(u32, value)
> - ),
> -
> - TP_fast_assign(
> - __assign_str(name, timeline->name);
> - __entry->value = timeline->value;
> - ),
> -
> - TP_printk("name=%s value=%d", __get_str(name), __entry->value)
> -);
> -
> -#endif /* if !defined(_TRACE_SYNC_H) || defined(TRACE_HEADER_MULTI_READ) */
> -
> -/* This part must be outside protection */
> -#include 
> -- 
> 2.5.5


[PATCH v2 0/6] de-stage SW_SYNC validation frawework

2016-08-11 Thread Eric Engestrom
On Mon, Aug 08, 2016 at 06:24:16PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Hi Greg,
> 
> This is the last step in the Sync Framwork de-stage task. It de-stage
> the SW_SYNC validation framework and the sync_debug info debugfs file.
> 
> The first 2 patches are clean up and improvements and the rest is preparation
> to de-stage and then finally the actual de-stage.
> 
> v2: 
>  - add documentation about the SW_SYNC ioctl API (comments from Pavel Machek)
>  - remove for now patch to add sync_pt name to debugfs
> 
> Please review,
> 
> Gustavo
> 
> ---
> Gustavo Padovan (6):
>   staging/android: remove doc from sw_sync
>   staging/android: do not let userspace trigger WARN_ON
>   staging/android: move trace/sync.h to sync_trace.h
>   staging/android: prepare sw_sync files for de-staging
>   staging/android: add Doc for SW_SYNC ioctl interface
>   dma-buf/sw_sync: de-stage SW_SYNC
> 
>  drivers/dma-buf/Kconfig  |  13 ++
>  drivers/dma-buf/Makefile |   1 +
>  drivers/dma-buf/sw_sync.c| 349 
> +++
>  drivers/dma-buf/sync_debug.c | 230 +++
>  drivers/dma-buf/sync_debug.h |  69 +++
>  drivers/dma-buf/sync_trace.h |  32 
>  drivers/staging/android/Kconfig  |  13 --
>  drivers/staging/android/Makefile |   1 -
>  drivers/staging/android/sw_sync.c| 344 --
>  drivers/staging/android/sync_debug.c | 230 ---
>  drivers/staging/android/sync_debug.h |  84 -
>  drivers/staging/android/trace/sync.h |  32 
>  12 files changed, 694 insertions(+), 704 deletions(-)

>  create mode 100644 drivers/dma-buf/sw_sync.c
>  create mode 100644 drivers/dma-buf/sync_debug.c
>  create mode 100644 drivers/dma-buf/sync_debug.h
>  create mode 100644 drivers/dma-buf/sync_trace.h
>  delete mode 100644 drivers/staging/android/sw_sync.c
>  delete mode 100644 drivers/staging/android/sync_debug.c
>  delete mode 100644 drivers/staging/android/sync_debug.h
>  delete mode 100644 drivers/staging/android/trace/sync.h

When you send your next revision, could you use `git format-patch -M`?
A good 95% of the lines in these patches aren't actually modified, just
moved around, which makes it much harder to spot the actual changes :)

Cheers,
  Eric

> 
> -- 
> 2.5.5


[PATCH v7 4/5] drm: Update bits per component for display info

2016-08-11 Thread Ville Syrjälä
On Mon, Aug 08, 2016 at 04:00:29PM +0300, Mika Kahola wrote:
> DisplayPort branch device may define max supported bits per
> component. Update display info based on this value if bpc
> is defined.
> 
> v2: cleanup to match the drm_dp_helper.c patches introduced
> earlier in this series
> v3: Fill bpc for connector's display info in separate
> drm_dp_helper function (Daniel)
> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 24 
>  drivers/gpu/drm/i915/intel_dp.c |  3 +++
>  include/drm/drm_dp_helper.h |  4 
>  3 files changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 1f36016..a2c46ed 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -514,6 +514,30 @@ int drm_dp_downstream_max_bpc(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE],
>  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
>  
>  /**
> + * drm_dp_downstream_update_max_bpc() - extract branch device max
> + *  bits per component and update
> + *  connector max bpc
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + * @connector: Connector info
> + * Returns current max bpc on success
> + */
> +int drm_dp_downstream_update_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +  const u8 port_cap[4],
> +  struct drm_connector *connector)
> +{
> + if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT) {
> + int bpc = drm_dp_downstream_max_bpc(dpcd, port_cap);
> +
> + if (bpc > 0)
> + connector->display_info.bpc = bpc;
> + }
> +
> + return connector->display_info.bpc;
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_update_max_bpc);
> +
> +/**
>   * drm_dp_downstream_hw_rev() - read DP branch device HW revision
>   * @aux: DisplayPort AUX channel
>   *
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e990c8b..763e2f5 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3985,6 +3985,9 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
>   uint8_t *dpcd = intel_dp->dpcd;
>   uint8_t type;
>  
> + drm_dp_downstream_update_max_bpc(dpcd, intel_dp->downstream_ports,
> +  _dp->attached_connector->base);
> +

And it will be promptly overwritten by the EDID parser. Like I said
before, touching display_info from elsewhere is a bad idea right now.
We need to lay out some real rules on how the EDID parser vs. DP
helpers must be called if we are to share that information between
the two.

For now, I would just utilize the DP helper in the compute_config
to limit the bpc.

>   if (!intel_dp_get_dpcd(intel_dp))
>   return connector_status_disconnected;
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 45366aa..5491a9b 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Unless otherwise noted, all values are from the DP 1.1a spec.  Note that
> @@ -827,6 +828,9 @@ int drm_dp_downstream_max_clock(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE],
>   const u8 port_cap[4]);
>  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> const u8 port_cap[4]);
> +int drm_dp_downstream_update_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +  const u8 port_cap[4],
> +  struct drm_connector *connector);
>  int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
>  int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>struct drm_dp_aux *aux, struct drm_dp_link *link);
> -- 
> 1.9.1

-- 
Ville Syrjälä
Intel OTC


[PATCH v7 1/5] drm: Read DP branch device HW revision

2016-08-11 Thread Jim Bride
On Thu, Aug 11, 2016 at 11:22:15AM +0300, Ville Syrjälä wrote:
> On Thu, Aug 11, 2016 at 11:14:43AM +0300, Mika Kahola wrote:
> > On Thu, 2016-08-11 at 10:10 +0300, Ville Syrjälä wrote:
> > > On Mon, Aug 08, 2016 at 04:00:26PM +0300, Mika Kahola wrote:
> > > > HW revision is mandatory field for DisplayPort branch
> > > > devices. This is defined in DPCD register field 0x509.
> > > 
> > > But what do we want to do with it? Me, I don't see a point in parsing a
> > > bunch of stuff from the DPCD unless there's a real use case for it.
> > > /dev/drm_dp_aux will provide all the debug aid we need if we need to
> > > check random pieces of data from the DPCD, so even exposing this sort
> > > of stuff via debugfs is IMO pretty pointless.
> > > 
> > > If there's a good reason for a debug print, then I think we could parse
> > > something and dump it out so that it's always in the dmesg. But so far
> > > I'm not aware of any bug that would have required to deal with different
> > > hw revisions of things and whatnot.
> > > 
> > Digging up the HW and SW revisions are just for debugging purposes. My
> > idea here was that it would be handy if this information would be
> > available if we face a problem let's say with VGA dongle for example. It
> > is true that at the moment we don't have a single bug that would require
> > HW/SW revision information but maybe in the future we have one.
> > 
> > So, if we don't want to have this stuff in drm_dp_helpers and/or debugfs
> > I could make a change and print this info on dmesg when DP branch device
> > is plugged in.
> 
> Perhaps. We do print out the OUI as well, so there is some precedent.

Even if we don't dump stuff out to dmesg, I'd like to see this information
in the mst_info debugfs file or someplace similar.  As has been pointed out,
having this information available in the event that we need to work with a
vendor on a problem would be a help.

Jim


> 
> > 
> > Cheers,
> > Mika
> > 
> > > > 
> > > > v2: move drm_dp_ds_revision structure to be part of
> > > > drm_dp_link structure (Daniel)
> > > > 
> > > > Signed-off-by: Mika Kahola 
> > > > ---
> > > >  drivers/gpu/drm/drm_dp_helper.c  | 27 +++
> > > >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> > > >  include/drm/drm_dp_helper.h  |  9 +
> > > >  3 files changed, 37 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > index 75b2873..5fecdc1 100644
> > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > @@ -514,6 +514,33 @@ int drm_dp_downstream_max_bpc(const u8 
> > > > dpcd[DP_RECEIVER_CAP_SIZE],
> > > >  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
> > > >  
> > > >  /**
> > > > + * drm_dp_downstream_hw_rev() - read DP branch device HW revision
> > > > + * @aux: DisplayPort AUX channel
> > > > + *
> > > > + * Returns 0 on succes or negative error code on failure
> > > > + */
> > > > +int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > > > +struct drm_dp_aux *aux, struct drm_dp_link 
> > > > *link)
> > > > +{
> > > > +   uint8_t tmp;
> > > > +   int err;
> > > > +
> > > > +   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & 
> > > > DP_DWN_STRM_PORT_PRESENT))
> > > > +   return -EINVAL;
> > > > +
> > > > +   err = drm_dp_dpcd_read(aux, DP_BRANCH_HW_REV, , 1);
> > > > +
> > > > +   if (err < 0)
> > > > +   return err;
> > > > +
> > > > +   link->ds_hw_rev.major = (tmp & 0xf0) >> 4;
> > > > +   link->ds_hw_rev.minor = tmp & 0xf;
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(drm_dp_downstream_hw_rev);
> > > > +
> > > > +/**
> > > >   * drm_dp_downstream_id() - identify branch device
> > > >   * @aux: DisplayPort AUX channel
> > > >   *
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index e74d851..a6eccf5 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -865,6 +865,7 @@ struct intel_dp {
> > > > uint8_t num_sink_rates;
> > > > int sink_rates[DP_MAX_SUPPORTED_RATES];
> > > > struct drm_dp_aux aux;
> > > > +   struct drm_dp_link link;
> > > > uint8_t train_set[4];
> > > > int panel_power_up_delay;
> > > > int panel_power_down_delay;
> > > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > > > index 8e1fe58..1127948 100644
> > > > --- a/include/drm/drm_dp_helper.h
> > > > +++ b/include/drm/drm_dp_helper.h
> > > > @@ -446,6 +446,7 @@
> > > >  #define DP_SINK_OUI0x400
> > > >  #define DP_BRANCH_OUI  0x500
> > > >  #define DP_BRANCH_ID0x503
> > > > +#define DP_BRANCH_HW_REV0x509
> > > >  
> > > >  #define DP_SET_POWER0x600
> > > >  # define 

[PATCH v7 3/5] drm/i915: Check pixel rate for DP to VGA dongle

2016-08-11 Thread Ville Syrjälä
On Mon, Aug 08, 2016 at 04:00:28PM +0300, Mika Kahola wrote:
> Filter out a mode that exceeds the max pixel rate setting
> for DP to VGA dongle. This is defined in DPCD register 0x81
> if detailed cap info i.e. info field is 4 bytes long and
> it is available for DP downstream port.
> 
> The register defines the pixel rate divided by 8 in MP/s.
> 
> v2: DPCD read outs and computation moved to drm (Ville, Daniel)
> v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
> function (Daniel)
> v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville)
> v5: Use of intel_dp->downstream_ports to read out port capabilities.
> Code restructuring (Ville)
> v6: Move DP branch device check to drm_dp_helper.c (Daniel)
> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 25 -
>  1 file changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 21b04c3..e990c8b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -190,6 +190,26 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
>   return (max_link_clock * max_lanes * 8) / 10;
>  }
>  
> +static int
> +intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp, int dotclk)
> +{

I would just

{
int max_dotclk = dev_priv->max_dotclk_freq;

ds_max_dotclk = ...;
if (ds_dotclk != 0)
max_dotclk = min(max_dotclk, ds_max_dotclk);

return max_dotclk;
}

> + int ds_dotclk;
> + int type;
> +
> + ds_dotclk = drm_dp_downstream_max_clock(intel_dp->dpcd,
> + intel_dp->downstream_ports);
> +
> + if (ds_dotclk == 0)
> + return dotclk;
> +
> + type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
> + 
> + if (type != DP_DS_PORT_TYPE_VGA)
> + return dotclk;

Why isn't drm_dp_downstream_max_clock() handling all of it already?
Why are we even checking for !=VGA?

> +
> + return min(dotclk, ds_dotclk);
> +}
> +
>  static enum drm_mode_status
>  intel_dp_mode_valid(struct drm_connector *connector,
>   struct drm_display_mode *mode)
> @@ -199,7 +219,10 @@ intel_dp_mode_valid(struct drm_connector *connector,
>   struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
>   int target_clock = mode->clock;
>   int max_rate, mode_rate, max_lanes, max_link_clock;
> - int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> + int max_dotclk;
> +
> + max_dotclk = intel_dp_downstream_max_dotclock(intel_dp,
> +   
> to_i915(connector->dev)->max_dotclk_freq);
>  
>   if (is_edp(intel_dp) && fixed_mode) {
>   if (mode->hdisplay > fixed_mode->hdisplay)
> -- 
> 1.9.1

-- 
Ville Syrjälä
Intel OTC


[PATCH v7 1/5] drm: Read DP branch device HW revision

2016-08-11 Thread Ville Syrjälä
On Mon, Aug 08, 2016 at 04:00:26PM +0300, Mika Kahola wrote:
> HW revision is mandatory field for DisplayPort branch
> devices. This is defined in DPCD register field 0x509.

But what do we want to do with it? Me, I don't see a point in parsing a
bunch of stuff from the DPCD unless there's a real use case for it.
/dev/drm_dp_aux will provide all the debug aid we need if we need to
check random pieces of data from the DPCD, so even exposing this sort
of stuff via debugfs is IMO pretty pointless.

If there's a good reason for a debug print, then I think we could parse
something and dump it out so that it's always in the dmesg. But so far
I'm not aware of any bug that would have required to deal with different
hw revisions of things and whatnot.

> 
> v2: move drm_dp_ds_revision structure to be part of
> drm_dp_link structure (Daniel)
> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/drm_dp_helper.c  | 27 +++
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  include/drm/drm_dp_helper.h  |  9 +
>  3 files changed, 37 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 75b2873..5fecdc1 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -514,6 +514,33 @@ int drm_dp_downstream_max_bpc(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE],
>  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
>  
>  /**
> + * drm_dp_downstream_hw_rev() - read DP branch device HW revision
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns 0 on succes or negative error code on failure
> + */
> +int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +  struct drm_dp_aux *aux, struct drm_dp_link *link)
> +{
> + uint8_t tmp;
> + int err;
> +
> + if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
> + return -EINVAL;
> +
> + err = drm_dp_dpcd_read(aux, DP_BRANCH_HW_REV, , 1);
> +
> + if (err < 0)
> + return err;
> +
> + link->ds_hw_rev.major = (tmp & 0xf0) >> 4;
> + link->ds_hw_rev.minor = tmp & 0xf;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_hw_rev);
> +
> +/**
>   * drm_dp_downstream_id() - identify branch device
>   * @aux: DisplayPort AUX channel
>   *
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index e74d851..a6eccf5 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -865,6 +865,7 @@ struct intel_dp {
>   uint8_t num_sink_rates;
>   int sink_rates[DP_MAX_SUPPORTED_RATES];
>   struct drm_dp_aux aux;
> + struct drm_dp_link link;
>   uint8_t train_set[4];
>   int panel_power_up_delay;
>   int panel_power_down_delay;
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8e1fe58..1127948 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -446,6 +446,7 @@
>  #define DP_SINK_OUI  0x400
>  #define DP_BRANCH_OUI0x500
>  #define DP_BRANCH_ID0x503
> +#define DP_BRANCH_HW_REV0x509
>  
>  #define DP_SET_POWER0x600
>  # define DP_SET_POWER_D00x1
> @@ -803,11 +804,17 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
>   */
>  #define DP_LINK_CAP_ENHANCED_FRAMING (1 << 0)
>  
> +struct drm_dp_ds_revision {
> + int major;
> + int minor;
> +};
> +
>  struct drm_dp_link {
>   unsigned char revision;
>   unsigned int rate;
>   unsigned int num_lanes;
>   unsigned long capabilities;
> + struct drm_dp_ds_revision ds_hw_rev;
>  };
>  
>  int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
> @@ -819,6 +826,8 @@ int drm_dp_downstream_max_clock(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE],
>  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> const u8 port_cap[4]);
>  int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
> +int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +  struct drm_dp_aux *aux, struct drm_dp_link *link);
>  
>  void drm_dp_aux_init(struct drm_dp_aux *aux);
>  int drm_dp_aux_register(struct drm_dp_aux *aux);
> -- 
> 1.9.1

-- 
Ville Syrjälä
Intel OTC


[PATCH v4 3/4] drm/mediatek: Add gamma correction.

2016-08-11 Thread Philipp Zabel
Am Donnerstag, den 11.08.2016, 10:44 +0300 schrieb Ville Syrjälä:
> On Thu, Aug 11, 2016 at 09:32:59AM +0200, Philipp Zabel wrote:
> > Am Donnerstag, den 28.07.2016, 10:22 +0800 schrieb Bibby Hsieh:
> > > Add gamma set function to correct brightness values.
> > > It applies arbitrary mapping curve to compensate the
> > > incorrect transfer function of the panel.
> > > 
> > > Signed-off-by: Bibby Hsieh 
> > > ---
> > >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 ++-
> > >  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   31 
> > > +++
> > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   10 +
> > >  4 files changed, 49 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> > > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > index 24aa3ba..cbb460a5 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > @@ -409,6 +409,9 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
> > > *crtc,
> > >   }
> > >   if (pending_planes)
> > >   mtk_crtc->pending_planes = true;
> > > + if (crtc->state->color_mgmt_changed)
> > > + for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > > + mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
> > >  }
> > >  
> > >  static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > > @@ -418,6 +421,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > >   .reset  = mtk_drm_crtc_reset,
> > >   .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > >   .atomic_destroy_state   = mtk_drm_crtc_destroy_state,
> > > + .gamma_set  = drm_atomic_helper_legacy_gamma_set,
> > >  };
> > >  
> > >  static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > > @@ -568,7 +572,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > >   _crtc->planes[1].base, pipe);
> > >   if (ret < 0)
> > >   goto unprepare;
> > > -
> > > + drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
> > > + drm_helper_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
> > > +   MTK_LUT_SIZE);
> > 
> > I have applied all four patches and rebased onto v4.8-rc1, replacing
> > drm_helper_crtc_enable_color_mgmt with:
> > 
> > drm_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
> >true, MTK_LUT_SIZE);
> 
> BTW that looks wrong (already in the original). AFAICS the patch just
> handled the gamma_lut, not the degamma_lut, so telling you have both
> is not right.

Thanks, so should that be
   drm_crtc_enable_color_mgmt(_crtc->base, 0, false,
  MTK_LUT_SIZE);
instead, since we only handle gamma?

regards
Philipp



[RESEND Patch 2/4] gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle

2016-08-11 Thread Peter Chen


>On 15/07/16 06:17, Peter Chen wrote:
>> of_node_put needs to be called when the device node which is got from
>> of_parse_phandle has finished using.
>>
>> Cc: Tomi Valkeinen 
>> Signed-off-by: Peter Chen 
>> ---
>>  drivers/gpu/drm/omapdrm/dss/dss-of.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> b/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> index dfd4e96..e256d87 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> @@ -125,15 +125,16 @@ u32 dss_of_port_get_port_number(struct
>> device_node *port)
>>
>>  static struct device_node *omapdss_of_get_remote_port(const struct
>> device_node *node)  {
>> -struct device_node *np;
>> +struct device_node *np, *np_parent;
>>
>>  np = of_parse_phandle(node, "remote-endpoint", 0);
>>  if (!np)
>>  return NULL;
>>
>> -np = of_get_next_parent(np);
>> +np_parent = of_get_next_parent(np);
>> +of_node_put(np);
>>
>> -return np;
>> +return np_parent;
>>  }
>
>The doc for of_get_next_parent() says:
>
>"This is like of_get_parent() except that it drops the refcount on the passed 
>node,
>making it suitable for iterating".
>

It is my careless, thanks for pointing it.

Peter


[PATCH v2 0/7] drm/mediatek: cleaning up and refine

2016-08-11 Thread Philipp Zabel
Am Donnerstag, den 04.08.2016, 10:59 +0800 schrieb Bibby Hsieh:
> These patches based on 4.7-rc1 to clean up unused function
> & variable and use drm core function instead.
> 
> The following patches are needed to cleanly apply on top of v4.7-rc1:
>  - https://patchwork.kernel.org/patch/8044001/
>(drm: Deal with rotation in drm_plane_helper_check_update())
>  - https://patchwork.kernel.org/patch/9248373/
>(drm: Warn about negative sizes when calculating scale factor)
>  - https://patchwork.kernel.org/patch/9248371/
>(drm: Store clipped src/dst coordinatee in drm_plane_state)
>  - https://patchwork.kernel.org/patch/9248363/
>(drm/plane-helper: Add drm_plane_helper_check_state())
>  - https://patchwork.kernel.org/patch/9248361/
>(drm/mediatek: Use drm_plane_helper_check_state())
> 
> Bibby Hsieh (2):
>   drm/mediatek: Use drm_atomic destroy_state helpers
>   drm/mediatek: Fix mtk_atomic_complete for runtime_pm
> 
> Daniel Kurtz (5):
>   drm/mediatek: Remove mtk_drm_crtc_check_flush
>   drm/mediatek: plane: Remove plane zpos/index
>   drm/mediatek: Remove mtk_drm_plane

I have picked up patches 1-5, but not patches 6-7:

>   drm/mediatek: plane: Merge mtk_plane_enable into
> mtk_plane_atomic_update
>   drm/mediatek: plane: Use FB's format's cpp to compute x offset

These two don't apply. Could you please rebase them onto
git.pengutronix.de/git/pza/linux.git mediatek-drm/next

regards
Philipp



[PATCH v4 3/4] drm/mediatek: Add gamma correction.

2016-08-11 Thread Philipp Zabel
Am Donnerstag, den 28.07.2016, 10:22 +0800 schrieb Bibby Hsieh:
> Add gamma set function to correct brightness values.
> It applies arbitrary mapping curve to compensate the
> incorrect transfer function of the panel.
> 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 ++-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   31 
> +++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   10 +
>  4 files changed, 49 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 24aa3ba..cbb460a5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -409,6 +409,9 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
> *crtc,
>   }
>   if (pending_planes)
>   mtk_crtc->pending_planes = true;
> + if (crtc->state->color_mgmt_changed)
> + for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> + mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
>  }
>  
>  static const struct drm_crtc_funcs mtk_crtc_funcs = {
> @@ -418,6 +421,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
>   .reset  = mtk_drm_crtc_reset,
>   .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
>   .atomic_destroy_state   = mtk_drm_crtc_destroy_state,
> + .gamma_set  = drm_atomic_helper_legacy_gamma_set,
>  };
>  
>  static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> @@ -568,7 +572,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
>   _crtc->planes[1].base, pipe);
>   if (ret < 0)
>   goto unprepare;
> -
> + drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
> + drm_helper_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
> +   MTK_LUT_SIZE);

I have applied all four patches and rebased onto v4.8-rc1, replacing
drm_helper_crtc_enable_color_mgmt with:

drm_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
   true, MTK_LUT_SIZE);

(See https://patchwork.kernel.org/patch/9160987/)

regards
Philipp



[PATCH] drm/bridge: dw-hdmi: fix hdmi display lost

2016-08-11 Thread Russell King - ARM Linux
On Thu, Aug 11, 2016 at 03:54:03PM +0800, Mark Yao wrote:
> hdmi->disabled maybe not match to the real hardware status.
> 
> ->dw_hdmi_bridge_enable()
>   hdmi->disabled = false;
> -->dw_hdmi_update_power()
>if (hdmi->rxsense)
>force = DRM_FORCE_ON;
>else
>force = DRM_FORCE_OFF;
> 
> hdmi->rxsense maybe false on bridge enable path, then hdmi->disabled
> is false, but actually hardware is power off, they are not match.

... which is correct.  If rxsense is false, it means there is nothing
plugged in, so we don't power the hardware up until something _is_
plugged in.

When something is plugged in, we get the HPD and RXSENSE events, which
will cause dw_hdmi_update_power() to be called.

hdmi->disabled is merely a bit mask of things that would cause us to
want to avoid powering the hardware up when rxsense becomes true.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


[PATCH v3 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K

2016-08-11 Thread Philipp Zabel
Am Donnerstag, den 04.08.2016, 10:38 +0800 schrieb Bibby Hsieh:
> From: Junzhi Zhao 
> 
> Pixel clock should be 297MHz when resolution is 4K.
> 
> Signed-off-by: Junzhi Zhao 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_dpi.c |8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index d05ca79..a90af59 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -438,10 +438,14 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>   }
>  
>   pix_rate = 1000UL * mode->clock;
> - if (mode->clock <= 74000)
> + if (mode->clock <= 27000)
> + factor = 16 * 3;
> + else if (mode->clock <= 74250)
>   factor = 8 * 3;
> - else
> + else if (mode->clock <= 167000)
>   factor = 4 * 3;
> + else
> + factor = 2 * 3;
>   pll_rate = pix_rate * factor;
>  
>   dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n",

Could you add a comment why this also changes the 74 MHz limit to 74.25
MHz and that adds a factor 16*3 for clocks <= 27 MHz ?

regards
Philipp



[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

2016-08-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #118 from pc.jago1337 at gmail.com ---
Using radeon, the microcode 'fix' doesn't fix the problem for me. Perhaps there
are multiple bugs, and not just the one?

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


答复: Re: [RESEND PATCH] drm/gma500: Fix comments in gtt.c

2016-08-11 Thread jiang.bi...@zte.com.cn


Daniel Vetter  wrote on 2016/08/10 17:22:14:

> Daniel Vetter 
> From:  Daniel Vetter 
> 2016/08/10 17:22
>
> To: jiang.biao2 at zte.com.cn,
>
> Re: [RESEND PATCH] drm/gma500: Fix comments in gtt.c
>
> On Wed, Aug 10, 2016 at 04:52:53PM +0800, jiang.biao2 at zte.com.cn wrote:
> >
> >
> > Daniel Vetter  wrote on 2016/08/10 16:35:29:
> >
> > > Daniel Vetter 
> > > From: Daniel Vetter 
> > >
> > > 2016/08/10 16:35
> > >
> > >
> > > jiang.biao2 at zte.com.cn,
> > >
> > >
> > > Re: [RESEND PATCH] drm/gma500: Fix comments in gtt.c
> > >
> > > On Wed, Aug 10, 2016 at 11:35:14AM +0800, jiang.biao2 at zte.com.cn wrote:
> > > >
> > > > Fix some comment faults in gtt.c.
> > > >
> > > > Signed-off-by: Jiang Biao 
> > >
> > > Sending the same patch 3 times in just one hour doesn't help - people
> > > sometimes sleep, or are busy. Please let at least a few days pass until
> > > you ping (with a reply) or resend.
> > >
> > > Thanks, Daniel
> > >
> > I'm so sorry about the interruption.
> > The mail server of my company corrupted the format of first two patchs,
> > and I have to resend it with correct format, after I corrected the
> > configuration of the mail server. The format of the last one should be
> > right.
> > I'm fresh to this mailing list, next time should be right.
> > Thanks a lot.
>
> Ah now worries. In such a case simply add a small comment to your resend
> patches why you're resending. You can add such comments to the commit
> message at the and after a line with just --- git will then cut it away.
> E.g.
>
> ... commmit message ...
>
> Signed-off-by: Daniel Vetter 
> ---
> This here is an additional comment which will not get applied to the real
> git log.
>
> Making sure that the patch isn't corrupted is definitely appreciated!
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Actually, as newcomer, I didn't exactly know how to resend a patch in this
case. Thank you very much for your guidance, that's very helpful for me.

What I want is just to make my contribution, hope to communicate with you
more often.

Next time will be better. Thanks again.



[PATCH 0/9] v4.8 build regressions

2016-08-11 Thread Philipp Zabel
Am Mittwoch, den 10.08.2016, 23:54 +0200 schrieb Arnd Bergmann:
> This is a set of patches to address build warnings and errors that have
> come up in linux-4.8 but that worked fine in v4.7. I've added the
> tinyconfig warning patch in there as well, which is not a regression
> but is something that shows up in the kernelci.org build bots.
> The other patches address issues that either came up in kernelci.org
> or in my randconfig test setup.
> 
> I have three more fixes queued up in arm-soc/fixes that I plan
> to send as a pull request for -rc2 along with the other bugfixes.
> 
> All patches have been posted before, but for some reason or another
> failed to make it into the merge window. I have updated the ones
> that were waiting for a new version from me now, the others are
> sent without modifications.
> 
> Hopefully we can get them all merged into v4.8. Please pick up
> patches from the middle of the series if appropriate.
> 
>   Arnd
> 
> Arnd Bergmann (7):
>   kconfig: tinyconfig: provide whole choice blocks to avoid warnings
>   dsa: mv88e6xxx: hide unused functions
>   drm/mediatek: add COMMON_CLK dependency
>   drm/mediatek: add CONFIG_OF dependency
>   drm/mediatek: add ARM_SMCCC dependency

I have picked up the three drm/mediatek patches.

regards
Philipp

>   clocksource: kona: fix get_counter error handling
>   8250/fintek: rename IRQ_MODE macro
> 
> Geert Uytterhoeven (1):
>   test/hash: Fix warning in two-dimensional array init
> 
> George Spelvin (1):
>   test/hash: Fix warning in preprocessor symbol evaluation
> 
>  arch/x86/configs/tiny.config  |  2 ++
>  drivers/clocksource/bcm_kona_timer.c  | 16 ++--
>  drivers/gpu/drm/mediatek/Kconfig  |  3 +++
>  drivers/net/dsa/mv88e6xxx/chip.c  |  2 ++
>  drivers/tty/serial/8250/8250_fintek.c |  4 ++--
>  kernel/configs/tiny.config|  8 
>  lib/test_hash.c   |  8 
>  7 files changed, 31 insertions(+), 12 deletions(-)




[RFC 0/4] doc: dma-buf: sphinx conversion and cleanup

2016-08-11 Thread Jonathan Corbet
On Thu, 11 Aug 2016 16:17:56 +0530
Sumit Semwal  wrote:

> Convert dma-buf documentation over to sphinx; also cleanup to
> address sphinx warnings.
> 
> While at that, convert dma-buf-sharing.txt as well, and make it the
> dma-buf API guide.

Thanks for working to improve the documentation!  I do have a few overall
comments...

 - The two comment fixes are a separate thing that should go straight to
   the dma-buf maintainer, who is ...  ... evidently somebody
   familiar to you :)  I assume you'll merge those two directly?

 - It looks like you create a new RST document but leave the old one in
   place.  Having two copies of the document around can only lead to
   confusion, so I think the old one should go.

 - I really wonder if we want to start carving pieces out of
   device-drivers.tmpl in this way.  I guess I would rather see the
   conversion of that book and the better integration of the other docs
   *into* it.  One of the goals of this whole thing is to unify our
   documentation, not to reinforce the silos.

Does that make sense?

Thanks,

jon


[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

2016-08-11 Thread Inki Dae
Hi Shuah,

2016년 08월 11일 02:30에 Shuah Khan 이(가) 쓴 글:
> Fix exynos_drm_gem_create_ioctl() attempts to allocate non-contiguous GEM
> memory without IOMMU. In this case, there is no point in attempting to

DRM gem can be used for Non-DRM drivers such as GPU, V4L2 based Multimedia 
device and other DMA devices.
Even though IOMMU support is disabled, other framework based DMA drivers can 
use IOMMU - i.e., GPU driver -
and they can use non-contiguous GEM buffer through UMM. (DMABUF) 

So GEM allocation type is not dependent on IOMMU.

Thanks,
Inki Dae

> allocate non-contiguous memory, only to return error during the next step
> from exynos_drm_framebuffer_init() which leads to display manager failing
> to start.
> 
> Check if non-contiguous GEM memory is requested without IOMMU. If so,
> allocate contiguous GEM memory to help display manager start.
> 
> Signed-off-by: Shuah Khan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 4c4cb0e..4719116 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -266,6 +266,20 @@ int exynos_drm_gem_create_ioctl(struct drm_device *dev, 
> void *data,
>   struct exynos_drm_gem *exynos_gem;
>   int ret;
>  
> + /*
> +  * Check if non-contiguous GEM memory is requested without IOMMU.
> +  * If so, allocate contiguous GEM memory.
> +  *
> +  * There is no point in attempting to allocate non-contiguous memory,
> +  * only to return error from exynos_drm_framebuffer_init() which leads
> +  * to display manager failing to start.
> + */
> + if (!is_drm_iommu_supported(dev) &&
> + (args->flags & EXYNOS_BO_NONCONTIG)) {
> + args->flags &= ~EXYNOS_BO_NONCONTIG;
> + args->flags |= EXYNOS_BO_CONTIG;
> + }
> +
>   exynos_gem = exynos_drm_gem_create(dev, args->flags, args->size);
>   if (IS_ERR(exynos_gem))
>   return PTR_ERR(exynos_gem);
> 


[PATCH 1/1] Revert "gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle"

2016-08-11 Thread Sean Paul
On Thu, Aug 11, 2016 at 5:44 AM, Peter Chen  wrote:
> This reverts commit 2ab9f5879162499e1c4e48613287e3f59e593c4f.
>
> The of_get_next_parent will drop refcount on the passed node, so the reverted
> patch is wrong, thanks for Tomi Valkeinen points it.
>

Indeed it is. Tomi, are you going to pick this up in your tree, or
would you like it to go through -misc?

Reviewed-by: Sean Paul 


> Cc: Tomi Valkeinen 
> Signed-off-by: Peter Chen 
> ---
>  drivers/gpu/drm/omapdrm/dss/dss-of.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
> b/drivers/gpu/drm/omapdrm/dss/dss-of.c
> index e256d87..dfd4e96 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
> @@ -125,16 +125,15 @@ u32 dss_of_port_get_port_number(struct device_node 
> *port)
>
>  static struct device_node *omapdss_of_get_remote_port(const struct 
> device_node *node)
>  {
> -   struct device_node *np, *np_parent;
> +   struct device_node *np;
>
> np = of_parse_phandle(node, "remote-endpoint", 0);
> if (!np)
> return NULL;
>
> -   np_parent = of_get_next_parent(np);
> -   of_node_put(np);
> +   np = of_get_next_parent(np);
>
> -   return np_parent;
> +   return np;
>  }
>
>  struct device_node *
> --
> 1.9.1
>


[Bug 93649] [radeonsi] Graphics lockup while playing tf2

2016-08-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93649

Matthew Dawson  changed:

   What|Removed |Added

 Status|NEEDINFO|REOPENED

--- Comment #21 from Matthew Dawson  ---
I can confirm lastest git head (50b49d242d702e4728329cc59f87d929963e7c53) still
causes lockups, though they seem to come much faster.

Also seems to have a regression regarding lighting, I'll see about bisecting
that in a separate report.

LLVM: 3.8.0
DRM: 2.43.0
Linux: 4.6.3-gentoo

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


[v10 PATCH 0/5] Rockchip Type-C and DisplayPort driver

2016-08-11 Thread Chris Zhong
Hi Chanwoo

On 08/10/2016 08:37 AM, Chanwoo Choi wrote:
> Hi Chris,
>
> On 2016년 08월 10일 08:32, Chris Zhong wrote:
>> Hi all
>>
>> This series patch is for rockchip Type-C phy and DisplayPort controller
>> driver.
>>
>> The USB Type-C PHY is designed to support the USB3 and DP applications.
>> The PHY basically has two main components: USB3 and DisplyPort. USB3
>> operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2
>> data rates. The Type-C cable orientation detection and Power Delivery
>> (PD) is accomplished using a PD PHY or a exernal PD chip.
>>
>> The DP controller is compliant with DisplayPort Specification,
>> Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
>> There is a uCPU in DP controller, it need a firmware to work, please
>> put the firmware file[0] to /lib/firmware/rockchip/dptx.bin. The uCPU
>> in charge of aux communication and link training, the host use mailbox
>> to communicate with the ucpu.
>>
>> The DP contoller has register a notification with extcon API, to get the
>> alt mode from PD, the PD driver need call the devm_extcon_dev_allocate
>> to create a extcon device and use extcon_set_state to notify DP
>> controller. And call extcon_set_cable_property to set orientation.
>>
>> About the DP audio, cdn-dp registered 2 DAIs: 0 is I2S, 1 is SPDIF.
>> We can reference them in simple-card.
>>
>> This series is based on Mark Yao's branch[1] and Chanwoo Choi's
>> extcon-next branch[2], and the clk patch[3].
>>
>> I test this patches on the rk3399-evb board, with a fusb302 driver,
>> this branch has no rk3399.dtsi, so the patch about dts is not included
>> in this series.
>>
>> >From V9, the Type-C PHY is split into two PHYs: DP and USB3. The PHY
>> will be init, no matter which PHY be power_on. The DP module will
>> enter A2 mode (standby mode) after phy_init, if DP PHY is powered on,
>> the DP module will enter to A0 mode(running mode). Then if DP PHY is
>> powered off, DP module will back to A2 mode. If everything is
>> un-plugged, phy will be deinit.
>>
>> [0]
>> https://patchwork.kernel.org/patch/9249693/
>> [1]
>> https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2016-05-23
>> [2]
>> https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-test
>> - extcon: Add the extcon_type to gather each connector into five category
>> - extcon: Add the support for extcon property according to extcon type
>> - extcon: Add the support for the capability of each property
>> - extcon: Rename the extcon_set/get_state() to maintain the function naming
>> pattern
>> - extcon: Add the synchronization extcon APIs to support the notification
>> - extcon: Add EXTCON_DISP_DP and the property for USB Type-C
> The extcon patches are merged on extcon-next branch.
> So, you can check them on both extcon git and linux-next git repo.
Oh, did not notice these extcon patches has landed.
I will remove this section, if next version DP is required.
> [snip]
>
> Regards,
> Chanwoo Choi
>
>
>
>




[PATCH 5/9] drm/mediatek: add ARM_SMCCC dependency

2016-08-11 Thread Arnd Bergmann
ARM SMCCC is only set for ARMv7 and ARMv8 CPUs, but we currently
allow the driver to be build for older architecture levels as
well, which results in a link failure:

drivers/gpu/built-in.o: In function `mtk_hdmi_hw_make_reg_writable':
:(.text+0x1e737c): undefined reference to `arm_smccc_smc'

This adds a Kconfig dependency. The patch applies on my two
previous fixes that are not yet applied, so please apply all
three to get randconfig builds to work correctly.

Signed-off-by: Arnd Bergmann 
Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
Reviewed-by: Matthias Brugger 
---
Sent first on June 27 when it first broke in linux-next.
Two other dependencies were already missing, so I'm sending
all three patches again now.
---
 drivers/gpu/drm/mediatek/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index 96ebf8bb6024..294de4549922 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -3,6 +3,7 @@ config DRM_MEDIATEK
depends on DRM
depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST)
depends on COMMON_CLK
+   depends on HAVE_ARM_SMCCC
depends on OF
select DRM_GEM_CMA_HELPER
select DRM_KMS_HELPER
-- 
2.9.0



[PATCH 4/9] drm/mediatek: add CONFIG_OF dependency

2016-08-11 Thread Arnd Bergmann
The mediatek DRM driver can be configured for compile testing with
CONFIG_OF disabled, but then fails to link:

drivers/gpu/built-in.o: In function `mtk_drm_bind':
analogix_dp_reg.c:(.text+0x52888): undefined reference to 
`of_find_device_by_node'
analogix_dp_reg.c:(.text+0x52930): undefined reference to 
`of_find_device_by_node'

This adds an explicit Kconfig dependency.

Signed-off-by: Arnd Bergmann 
Link: https://patchwork.kernel.org/patch/9120871/
---
I originally sent this on May 18 when the driver was newly added,
but my fix never made it.
---
 drivers/gpu/drm/mediatek/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index 5c2163737691..96ebf8bb6024 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -3,6 +3,7 @@ config DRM_MEDIATEK
depends on DRM
depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST)
depends on COMMON_CLK
+   depends on OF
select DRM_GEM_CMA_HELPER
select DRM_KMS_HELPER
select DRM_MIPI_DSI
-- 
2.9.0



[PATCH 3/9] drm/mediatek: add COMMON_CLK dependency

2016-08-11 Thread Arnd Bergmann
On kernel builds without COMMON_CLK, the newly added mediatek drm
driver fails to build:

drivers/gpu/drm/mediatek/mtk_mipi_tx.c:130:16: error: field 'pll_hw' has 
incomplete type
  struct clk_hw pll_hw;
^~
In file included from ../include/linux/clk.h:16:0,
 from ../drivers/gpu/drm/mediatek/mtk_mipi_tx.c:14:
drivers/gpu/drm/mediatek/mtk_mipi_tx.c: In function 'mtk_mipi_tx_from_clk_hw':
include/linux/kernel.h:831:48: error: initialization from incompatible pointer 
type [-Werror=incompatible-pointer-types]
  const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
/drivers/gpu/drm/mediatek/mtk_mipi_tx.c:136:9: note: in expansion of macro 
'container_of'
  return container_of(hw, struct mtk_mipi_tx, pll_hw);
 ^~~~
drivers/gpu/drm/mediatek/mtk_mipi_tx.c: At top level:
drivers/gpu/drm/mediatek/mtk_mipi_tx.c:302:21: error: variable 
'mtk_mipi_tx_pll_ops' has initializer but incomplete type
 static const struct clk_ops mtk_mipi_tx_pll_ops = {

This adds the required Kconfig dependency.

Signed-off-by: Arnd Bergmann 
Acked-by: Philipp Zabel 
Link: https://patchwork.kernel.org/patch/9069061/
---
I originally sent this on May 11 2016 after the driver was added with this
bug, but my fix never made it in.
---
 drivers/gpu/drm/mediatek/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index 23ac8041c562..5c2163737691 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -2,6 +2,7 @@ config DRM_MEDIATEK
tristate "DRM Support for Mediatek SoCs"
depends on DRM
depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST)
+   depends on COMMON_CLK
select DRM_GEM_CMA_HELPER
select DRM_KMS_HELPER
select DRM_MIPI_DSI
-- 
2.9.0



[PATCH 0/9] v4.8 build regressions

2016-08-11 Thread Arnd Bergmann
This is a set of patches to address build warnings and errors that have
come up in linux-4.8 but that worked fine in v4.7. I've added the
tinyconfig warning patch in there as well, which is not a regression
but is something that shows up in the kernelci.org build bots.
The other patches address issues that either came up in kernelci.org
or in my randconfig test setup.

I have three more fixes queued up in arm-soc/fixes that I plan
to send as a pull request for -rc2 along with the other bugfixes.

All patches have been posted before, but for some reason or another
failed to make it into the merge window. I have updated the ones
that were waiting for a new version from me now, the others are
sent without modifications.

Hopefully we can get them all merged into v4.8. Please pick up
patches from the middle of the series if appropriate.

Arnd

Arnd Bergmann (7):
  kconfig: tinyconfig: provide whole choice blocks to avoid warnings
  dsa: mv88e6xxx: hide unused functions
  drm/mediatek: add COMMON_CLK dependency
  drm/mediatek: add CONFIG_OF dependency
  drm/mediatek: add ARM_SMCCC dependency
  clocksource: kona: fix get_counter error handling
  8250/fintek: rename IRQ_MODE macro

Geert Uytterhoeven (1):
  test/hash: Fix warning in two-dimensional array init

George Spelvin (1):
  test/hash: Fix warning in preprocessor symbol evaluation

 arch/x86/configs/tiny.config  |  2 ++
 drivers/clocksource/bcm_kona_timer.c  | 16 ++--
 drivers/gpu/drm/mediatek/Kconfig  |  3 +++
 drivers/net/dsa/mv88e6xxx/chip.c  |  2 ++
 drivers/tty/serial/8250/8250_fintek.c |  4 ++--
 kernel/configs/tiny.config|  8 
 lib/test_hash.c   |  8 
 7 files changed, 31 insertions(+), 12 deletions(-)

-- 
2.9.0

Cc: Andrew Lunn 
Cc: Andrew Morton 
Cc: Daniel Lezcano 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: Geert Uytterhoeven 
Cc: George Spelvin 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Ji-Ze Hong (Peter Hong) 
Cc: Josh Triplett 
Cc: kernel-build-reports at lists.linaro.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: Masahiro Yamada 
Cc: Matthias Brugger 
Cc: netdev at vger.kernel.org
Cc: Philipp Zabel 
Cc: Ricardo Ribalda Delgado 
Cc: Thomas Gleixner 
Cc: Vivien Didelot 
Cc: x86 at kernel.org


<    1   2