date:20151012

[PATCH] drm/exynos: fix spelling errors

2015-10-12 Thread Inki Dae

Hi, Ingi.

Merged. Thanks for your first patch to drm world. :)
This patch isn't trivial so will go to next.

Thanks,
Inki Dae


2015ë 10ì 02ì¼ 17:59ì Ingi Kim ì´(ê°) ì´ ê¸:
> This patch fixes spelling errors in drm fimc/gsc
> inavild -> invaild
> 
> Signed-off-by: Ingi Kim 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16 
>   drivers/gpu/drm/exynos/exynos_drm_gsc.c  | 12 ++--
>   2 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 2a65235..5d00f86 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -466,7 +466,7 @@ static int fimc_src_set_fmt_order(struct fimc_context 
> *ctx, u32 fmt)
>   EXYNOS_MSCTRL_C_INT_IN_2PLANE);
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid source yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid source yuv order 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -513,7 +513,7 @@ static int fimc_src_set_fmt(struct device *dev, u32 fmt)
>   cfg |= EXYNOS_MSCTRL_INFORMAT_YCBCR420;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid source format 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid source format 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -578,7 +578,7 @@ static int fimc_src_set_transf(struct device *dev,
>   cfg1 &= ~EXYNOS_MSCTRL_FLIP_Y_MIRROR;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
>   return -EINVAL;
>   }
>   
> @@ -701,7 +701,7 @@ static int fimc_src_set_addr(struct device *dev,
>   property->prop_id, buf_id, buf_type);
>   
>   if (buf_id > FIMC_MAX_SRC) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->dev, "invalid buf_id %d.\n", buf_id);
>   return -ENOMEM;
>   }
>   
> @@ -812,7 +812,7 @@ static int fimc_dst_set_fmt_order(struct fimc_context 
> *ctx, u32 fmt)
>   cfg |= EXYNOS_CIOCTRL_YCBCR_2PLANE;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid target yuv order 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -865,7 +865,7 @@ static int fimc_dst_set_fmt(struct device *dev, u32 fmt)
>   cfg |= EXYNOS_CITRGFMT_OUTFORMAT_YCBCR420;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid target format 0x%x.\n",
> + dev_err(ippdrv->dev, "invalid target format 0x%x.\n",
>   fmt);
>   return -EINVAL;
>   }
> @@ -929,7 +929,7 @@ static int fimc_dst_set_transf(struct device *dev,
>   cfg &= ~EXYNOS_CITRGFMT_FLIP_Y_MIRROR;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
>   return -EINVAL;
>   }
>   
> @@ -1160,7 +1160,7 @@ static int fimc_dst_set_addr(struct device *dev,
>   property->prop_id, buf_id, buf_type);
>   
>   if (buf_id > FIMC_MAX_DST) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->dev, "invalid buf_id %d.\n", buf_id);
>   return -ENOMEM;
>   }
>   
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 808a0a0..11b87d2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -543,7 +543,7 @@ static int gsc_src_set_fmt(struct device *dev, u32 fmt)
>   GSC_IN_YUV420_2P);
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid target yuv order 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -595,7 +595,7 @@ static int gsc_src_set_transf(struct device *dev,
>   cfg &= ~GSC_IN_ROT_YFLIP;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
>   return -EINVAL;
>   }
>   
> @@ -721,7 +721,7 @@ static int gsc_src_set_addr(struct device *dev,
>   property->prop_id, buf_id, buf_type);
>   
>   if (buf_id > GSC_MAX_SRC) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> +

[PATCH 00/16] drm/exynos/hdmi: refactoring/cleanup patches

2015-10-12 Thread Inki Dae

Hi Andrzej,

For all patches, merged excepting patch 2 which cleans up dt binding
document.

Thanks,
Inki Dae

2015ë 09ì 25ì¼ 21:48ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Hi,
> 
> This is another set of cleanup/improvement patches for HDMI.
> 
> The patchset is based on exynos-drm-next.
> It was tested on Universal and Odroid U3.
> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (15):
>drm/exynos/hdmi: remove support for deprecated compatible
>dt-bindings: remove deprecated compatible string from exynos-hdmi
>drm/exynos/hdmi: use mappings for registers with IP dependent address
>drm/exynos/hdmi: move PLL stabilization check code to separate
>  function
>drm/exynos/hdmi: simplify HDMI-PHY power sequence
>drm/exynos/hdmi: replace all writeb with writel
>drm/exynos/hdmi: fix removal order
>drm/exynos/hdmi: use optional regulator_get for hdmi-en
>drm/exynos/hdmi: use constant size array for regulators
>drm/exynos/hdmi: simplify clock re-parenting
>drm/exynos/hdmi: convert to gpiod API
>drm/exynos/hdmi: remove deprecated hdmi_resources structure
>drm/exynos/hdmi: convert container_of macro to inline function
>drm/exynos/hdmi: improve HDMI/ACR related code
>drm/exynos/hdmi: remove unused field
> 
> Tomasz Stanislawski (1):
>drm: exynos: mixer: fix using usleep() in atomic context
> 
>   .../devicetree/bindings/video/exynos_hdmi.txt  |   7 +-
>   drivers/gpu/drm/exynos/exynos_hdmi.c   | 491 
> +++--
>   drivers/gpu/drm/exynos/exynos_mixer.c  |   2 +-
>   drivers/gpu/drm/exynos/regs-hdmi.h |  33 +-
>   4 files changed, 189 insertions(+), 344 deletions(-)
>

[PATCH 07/10] drm/exynos: add pm_runtime to FIMD

2015-10-12 Thread Inki Dae

Also ping~~

2015ë 09ì 19ì¼ 12:53ì Inki Dae ì´(ê°) ì´ ê¸:
> On 2015ë 09ì 05ì¼ 05:15, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> Let pm_runtime handle the enabling/disabling of the device with proper
>> refcnt instead of rely on specific flags to track the enabled state.
>>
>> Signed-off-by: Gustavo Padovan 
>> ---
>>   drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  1 -
>>   drivers/gpu/drm/exynos/exynos7_drm_decon.c|  1 -
>>   drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 91 
>> +++
>>   3 files changed, 37 insertions(+), 56 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> index 79b2b22..838a9c1 100644
>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> @@ -478,7 +478,6 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
>>  .commit = decon_commit,
>>  .enable_vblank  = decon_enable_vblank,
>>  .disable_vblank = decon_disable_vblank,
>> -.commit = decon_commit,
>
> Above wouldn't be related to this patch.
>
>>  .atomic_begin   = decon_atomic_begin,
>>  .update_plane   = decon_update_plane,
>>  .disable_plane  = decon_disable_plane,
>> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
>> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> index f3826dc..e4646e2 100644
>> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> @@ -637,7 +637,6 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = 
>> {
>>  .enable = decon_enable,
>>  .disable = decon_disable,
>>  .mode_fixup = decon_mode_fixup,
>> -.commit = decon_commit,
>
> Ditto.
>
> Thanks,
> Inki Dae
>
>>  .enable_vblank = decon_enable_vblank,
>>  .disable_vblank = decon_disable_vblank,
>>  .wait_for_vblank = decon_wait_for_vblank,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 0bbe537..0f17ae0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -160,7 +160,6 @@ struct fimd_context {
>>  u32 vidout_con;
>>  u32 i80ifcon;
>>  booli80_if;
>> -boolsuspended;
>>  int pipe;
>>  wait_queue_head_t   wait_vsync_queue;
>>  atomic_twait_vsync_event;
>> @@ -209,9 +208,6 @@ static int fimd_enable_vblank(struct exynos_drm_crtc 
>> *crtc)
>>  struct fimd_context *ctx = crtc->ctx;
>>  u32 val;
>>
>> -if (ctx->suspended)
>> -return -EPERM;
>> -
>>  if (!test_and_set_bit(0, >irq_flags)) {
>>  val = readl(ctx->regs + VIDINTCON0);
>>
>> @@ -241,9 +237,6 @@ static void fimd_disable_vblank(struct exynos_drm_crtc 
>> *crtc)
>>  struct fimd_context *ctx = crtc->ctx;
>>  u32 val;
>>
>> -if (ctx->suspended)
>> -return;
>> -
>>  if (test_and_clear_bit(0, >irq_flags)) {
>>  val = readl(ctx->regs + VIDINTCON0);
>>
>> @@ -264,9 +257,6 @@ static void fimd_wait_for_vblank(struct exynos_drm_crtc 
>> *crtc)
>>   {
>>  struct fimd_context *ctx = crtc->ctx;
>>
>> -if (ctx->suspended)
>> -return;
>> -
>>  atomic_set(>wait_vsync_event, 1);
>>
>>  /*
>> @@ -339,14 +329,12 @@ static void fimd_clear_channels(struct exynos_drm_crtc 
>> *crtc)
>>  int pipe = ctx->pipe;
>>
>>  /* ensure that vblank interrupt won't be reported to core */
>> -ctx->suspended = false;
>>  ctx->pipe = -1;
>>
>>  fimd_enable_vblank(ctx->crtc);
>>  fimd_wait_for_vblank(ctx->crtc);
>>  fimd_disable_vblank(ctx->crtc);
>>
>> -ctx->suspended = true;
>>  ctx->pipe = pipe;
>>  }
>>
>> @@ -394,9 +382,6 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
>>  void *timing_base = ctx->regs + driver_data->timing_base;
>>  u32 val, clkdiv;
>>
>> -if (ctx->suspended)
>> -return;
>> -
>>  /* nothing to do if we haven't set the mode yet */
>>  if (mode->htotal == 0 || mode->vtotal == 0)
>>  return;
>> @@ -630,9 +615,6 @@ static void fimd_atomic_begin(struct exynos_drm_crtc 
>> *crtc,
>>   {
>>  struct fimd_context *ctx = crtc->ctx;
>>
>> -if (ctx->suspended)
>> -return;
>> -
>>  fimd_shadow_protect_win(ctx, plane->zpos, true);
>>   }
>>
>> @@ -641,9 +623,6 @@ static void fimd_atomic_flush(struct exynos_drm_crtc 
>> *crtc,
>>   {
>>  struct fimd_context *ctx = crtc->ctx;
>>
>> -if (ctx->suspended)
>> -return;
>> -
>>  fimd_shadow_protect_win(ctx, plane->zpos, false);
>>   }
>>
>> @@ -659,9 +638,6 @@ static void

[PATCH 08/10] drm/exynos: Enable DP clock directly from FIMD

2015-10-12 Thread Inki Dae

Gustavo, please ping~~~

2015ë 09ì 19ì¼ 12:51ì Inki Dae ì´(ê°) ì´ ê¸:
> Hi Gustavo,
>
> On 2015ë 09ì 05ì¼ 05:15, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> Instead of having a .clock_enable callback enable the dp clock directly
>> from FIMD.
>>
>> Signed-off-by: Gustavo Padovan 
>> ---
>>   drivers/gpu/drm/exynos/exynos_dp_core.c  | 13 ---
>>   drivers/gpu/drm/exynos/exynos_drm_drv.h  |  5 
>>   drivers/gpu/drm/exynos/exynos_drm_fimd.c | 39 
>> +---
>>   3 files changed, 21 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 6794982..aa11d18 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -37,11 +37,6 @@
>>   #define ctx_from_connector(c)  container_of(c, struct 
>> exynos_dp_device, \
>>  connector)
>>
>> -static inline struct exynos_drm_crtc *dp_to_crtc(struct exynos_dp_device 
>> *dp)
>> -{
>> -return to_exynos_crtc(dp->encoder.crtc);
>> -}
>> -
>>   static inline struct exynos_dp_device *encoder_to_dp(
>>  struct drm_encoder *e)
>>   {
>> @@ -1068,7 +1063,6 @@ static void exynos_dp_mode_set(struct drm_encoder 
>> *encoder,
>>   static void exynos_dp_enable(struct drm_encoder *encoder)
>>   {
>>  struct exynos_dp_device *dp = encoder_to_dp(encoder);
>> -struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
>>
>>  pm_runtime_get_sync(dp->dev);
>>
>> @@ -1079,9 +1073,6 @@ static void exynos_dp_enable(struct drm_encoder 
>> *encoder)
>>  }
>>  }
>>
>> -if (crtc->ops->clock_enable)
>> -crtc->ops->clock_enable(dp_to_crtc(dp), true);
>> -
>>  phy_power_on(dp->phy);
>>  exynos_dp_init_dp(dp);
>>  enable_irq(dp->irq);
>> @@ -1091,7 +1082,6 @@ static void exynos_dp_enable(struct drm_encoder 
>> *encoder)
>>   static void exynos_dp_disable(struct drm_encoder *encoder)
>>   {
>>  struct exynos_dp_device *dp = encoder_to_dp(encoder);
>> -struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
>>
>>  if (dp->panel) {
>>  if (drm_panel_disable(dp->panel)) {
>> @@ -1104,9 +1094,6 @@ static void exynos_dp_disable(struct drm_encoder 
>> *encoder)
>>  flush_work(>hotplug_work);
>>  phy_power_off(dp->phy);
>>
>> -if (crtc->ops->clock_enable)
>> -crtc->ops->clock_enable(dp_to_crtc(dp), false);
>> -
>>  if (dp->panel) {
>>  if (drm_panel_unprepare(dp->panel))
>>  DRM_ERROR("failed to turnoff the panel\n");
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 5f1a4d6..ee60619 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -96,10 +96,6 @@ struct exynos_drm_plane {
>>* @disable_plane: disable hardware specific overlay.
>>* @te_handler: trigger to transfer video image at the tearing effect
>>* synchronization signal if there is a page flip request.
>> - * @clock_enable: optional function enabling/disabling display domain clock,
>> - *  called from exynos-dp driver before powering up (with
>> - *  'enable' argument as true) and after powering down (with
>> - *  'enable' as false).
>>*/
>>   struct exynos_drm_crtc;
>>   struct exynos_drm_crtc_ops {
>> @@ -120,7 +116,6 @@ struct exynos_drm_crtc_ops {
>>  void (*atomic_flush)(struct exynos_drm_crtc *crtc,
>>struct exynos_drm_plane *plane);
>>  void (*te_handler)(struct exynos_drm_crtc *crtc);
>> -void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable);
>>   };
>>
>>   /*
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 0f17ae0..3cf2b80 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -573,6 +573,23 @@ static void fimd_win_set_colkey(struct fimd_context 
>> *ctx, unsigned int win)
>>  writel(keycon1, ctx->regs + WKEYCON1_BASE(win));
>>   }
>>
>> +static void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bool enable)
>> +{
>> +struct fimd_context *ctx = crtc->ctx;
>> +u32 val;
>> +
>> +/*
>> + * Only Exynos 5250, 5260, 5410 and 542x requires enabling DP/MIE
>> + * clock. On these SoCs the bootloader may enable it but any
>> + * power domain off/on will reset it to disable state.
>> + */
>> +if (ctx->driver_data != _fimd_driver_data)
>> +return;
>> +
>> +val = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
>> +writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
>> +}
>> +
>>   /**
>>* shadow_protect_win() - disable updating values from shadow registers at 
>> vsync
>>*
>> @@ -735,6 +752,8 @@ static void fimd_enable(struct exynos_drm_crtc *crtc)
>>  if

[PATCH 2/2] drm/exynos: add cursor plane support

2015-10-12 Thread Inki Dae


Merged.

Thanks,
Inki Dae

2015ë 09ì 05ì¼ 07:05ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan 
> 
> Set one of the planes for each crtc driver as a cursor plane enabled
> window managers to fully work on exynos.
> 
> Signed-off-by: Gustavo Padovan 
> 
> ---
> v2: use the top window for cursor on each crtc
> ---
>   drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  4 ++--
>   drivers/gpu/drm/exynos/exynos7_drm_decon.c|  4 ++--
>   drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  4 ++--
>   drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 +++
>   drivers/gpu/drm/exynos/exynos_drm_plane.h |  2 ++
>   drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  4 ++--
>   drivers/gpu/drm/exynos/exynos_mixer.c |  4 ++--
>   7 files changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 2f393b1..4b8dd7c 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -24,6 +24,7 @@
>   #include "exynos_drm_iommu.h"
>   
>   #define WINDOWS_NR  3
> +#define CURSOR_WIN   2
>   #define MIN_FB_WIDTH_FOR_16WORD_BURST   128
>   
>   struct decon_context {
> @@ -450,8 +451,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   ctx->pipe = priv->pipe++;
>   
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> + type = exynos_plane_get_type(zpos, CURSOR_WIN);
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
>   1 << ctx->pipe, type, decon_formats,
>   ARRAY_SIZE(decon_formats), zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 7a6c069..aa0ae79 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -41,6 +41,7 @@
>   #define MIN_FB_WIDTH_FOR_16WORD_BURST 128
>   
>   #define WINDOWS_NR  2
> +#define CURSOR_WIN   1
>   
>   struct decon_context {
>   struct device   *dev;
> @@ -630,8 +631,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   }
>   
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> + type = exynos_plane_get_type(zpos, CURSOR_WIN);
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
>   1 << ctx->pipe, type, decon_formats,
>   ARRAY_SIZE(decon_formats), zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 7776768..caa5255 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -88,6 +88,7 @@
>   
>   /* FIMD has totally five hardware windows. */
>   #define WINDOWS_NR  5
> +#define CURSOR_WIN   4
>   
>   struct fimd_driver_data {
>   unsigned int timing_base;
> @@ -909,8 +910,7 @@ static int fimd_bind(struct device *dev, struct device 
> *master, void *data)
>   ctx->pipe = priv->pipe++;
>   
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> + type = exynos_plane_get_type(zpos, CURSOR_WIN);
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
>   1 << ctx->pipe, type, fimd_formats,
>   ARRAY_SIZE(fimd_formats), zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 7148224..80b2151 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -208,6 +208,17 @@ static void exynos_plane_attach_zpos_property(struct 
> drm_plane *plane,
>   drm_object_attach_property(>base, prop, zpos);
>   }
>   
> +enum drm_plane_type exynos_plane_get_type(unsigned int zpos,
> +   unsigned int cursor_win)
> +{
> + if (zpos == DEFAULT_WIN)
> + return DRM_PLANE_TYPE_PRIMARY;
> + else if (zpos == cursor_win)
> + return DRM_PLANE_TYPE_CURSOR;
> + else
> + return DRM_PLANE_TYPE_OVERLAY;
> +}
> +
>   int exynos_plane_init(struct drm_device *dev,
> struct exynos_drm_plane *exynos_plane,
> unsigned long possible_crtcs, enum drm_plane_type type,
> diff --git

[PATCH 1/2] drm/exynos: add global macro for the default primary plane

2015-10-12 Thread Inki Dae

Hi Gustavo,

Merged.

Thanks,
Inki Dae

2015ë 09ì 05ì¼ 07:05ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan 
> 
> Define DEFAULT_WIN as zero to help set the primary plane on all CRTCs.
> Some CRTCs were defining a variable to store the default window, but that
> is not necessary as the default (primary) window is always the window zero.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>   drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++
>   drivers/gpu/drm/exynos/exynos7_drm_decon.c| 5 ++---
>   drivers/gpu/drm/exynos/exynos_drm_drv.h   | 2 ++
>   drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 5 ++---
>   drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 6 ++
>   drivers/gpu/drm/exynos/exynos_mixer.c | 7 +++
>   6 files changed, 13 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 988df06..2f393b1 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -33,7 +33,6 @@ struct decon_context {
>   struct exynos_drm_plane planes[WINDOWS_NR];
>   void __iomem*addr;
>   struct clk  *clks[6];
> - unsigned intdefault_win;
>   unsigned long   irq_flags;
>   int pipe;
>   
> @@ -451,7 +450,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   ctx->pipe = priv->pipe++;
>   
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> + type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
>   DRM_PLANE_TYPE_OVERLAY;
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
>   1 << ctx->pipe, type, decon_formats,
> @@ -460,7 +459,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   return ret;
>   }
>   
> - exynos_plane = >planes[ctx->default_win];
> + exynos_plane = >planes[DEFAULT_WIN];
>   ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
>   ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
>   _crtc_ops, ctx);
> @@ -557,7 +556,6 @@ static int exynos5433_decon_probe(struct platform_device 
> *pdev)
>   if (!ctx)
>   return -ENOMEM;
>   
> - ctx->default_win = 0;
>   ctx->dev = dev;
>   if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
>   ctx->i80_if = true;
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 0776f38..7a6c069 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -52,7 +52,6 @@ struct decon_context {
>   struct clk  *eclk;
>   struct clk  *vclk;
>   void __iomem*regs;
> - unsigned intdefault_win;
>   unsigned long   irq_flags;
>   booli80_if;
>   int pipe;
> @@ -631,7 +630,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   }
>   
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> + type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
>   DRM_PLANE_TYPE_OVERLAY;
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
>   1 << ctx->pipe, type, decon_formats,
> @@ -640,7 +639,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   return ret;
>   }
>   
> - exynos_plane = >planes[ctx->default_win];
> + exynos_plane = >planes[DEFAULT_WIN];
>   ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
>  ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
>  _crtc_ops, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 5cb9bc3..058abd1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -22,6 +22,8 @@
>   #define MAX_PLANE   5
>   #define MAX_FB_BUFFER   4
>   
> +#define DEFAULT_WIN  0
> +
>   #define to_exynos_crtc(x)   container_of(x, struct exynos_drm_crtc, base)
>   #define to_exynos_plane(x)  container_of(x, struct exynos_drm_plane, base)
>   
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index dc36e63..7776768 100644
> ---

[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2

2015-10-12 Thread bugzilla-dae...@freedesktop.org

ast_dri.so
No symbol table info available.
#11 0xb7004b40 in ?? () from /usr/lib/xorg/modules/dri/swrast_dri.so
No symbol table info available.
#12 0x08049fdb in ?? ()
No symbol table info available.
#13 0x080496ca in ?? ()
No symbol table info available.
#14 0xb7baf497 in __libc_start_main () from /usr/lib/libc.so.6
No symbol table info available.
#15 0x08049d0a in ?? ()
No symbol table info available.


what is your opinion about these new infos ?

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

[Intel-gfx] [PATCH 09/20] i915: switch from acpi_os_ioremap to memremap

2015-10-12 Thread Williams, Dan J

On Mon, 2015-10-12 at 09:01 +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 06:16:25PM -0400, Dan Williams wrote:
> > i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
> > map it with memremap rather than the implied cache setting of
> > acpi_os_ioremap().
> > 
> > Cc: Daniel Vetter 
> > Cc: Jani Nikula 
> > Cc: intel-gfx at lists.freedesktop.org
> > Cc: David Airlie 
> > Cc: dri-devel at lists.freedesktop.org
> > Signed-off-by: Dan Williams 
> 
> Assuming you've run sparse over this to make sure you've caught them all,
> and with the nit below addressed this is
> 
> Reviewed-by: Daniel Vetter 

Indeed, re-running sparse again found a few conversions of ioread* I
missed as well as moving the force casting out of validate_vbt() to
find_vbt().

> Feel free to pull v2 into whatever tree you think it's suitable for (but
> you can also resend and I'll pick it up).

Please pick up v2 below.

> 
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> > b/drivers/gpu/drm/i915/intel_panel.c
> > index e2ab3f6ed022..c8444d5f549f 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -387,7 +387,7 @@ intel_panel_detect(struct drm_device *dev)
> >  
> > /* Assume that the BIOS does not lie through the OpRegion... */
> > if (!i915.panel_ignore_lid && dev_priv->opregion.lid_state) {
> > -   return ioread32(dev_priv->opregion.lid_state) & 0x1 ?
> > +   return *(dev_priv->opregion.lid_state) & 0x1 ?
> 
> () are redundant now here.

Yup, fixed.

8<
Subject: i915: switch from acpi_os_ioremap to memremap

From: Dan Williams 

i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
map it with memremap rather than the implied cache setting of
acpi_os_ioremap().

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx at lists.freedesktop.org
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dan Williams 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |2 -
 drivers/gpu/drm/i915/i915_drv.h   |   12 ++---
 drivers/gpu/drm/i915/intel_bios.c |   25 +-
 drivers/gpu/drm/i915/intel_opregion.c |   83 -
 drivers/gpu/drm/i915/intel_panel.c|2 -
 5 files changed, 62 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e3ec9049081f..15989cc16e92 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1849,7 +1849,7 @@ static int i915_opregion(struct seq_file *m, void *unused)
goto out;

if (opregion->header) {
-   memcpy_fromio(data, opregion->header, OPREGION_SIZE);
+   memcpy(data, opregion->header, OPREGION_SIZE);
seq_write(m, data, OPREGION_SIZE);
}

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e1db8de52851..d8684634a31d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -444,14 +444,14 @@ struct opregion_swsci;
 struct opregion_asle;

 struct intel_opregion {
-   struct opregion_header __iomem *header;
-   struct opregion_acpi __iomem *acpi;
-   struct opregion_swsci __iomem *swsci;
+   struct opregion_header *header;
+   struct opregion_acpi *acpi;
+   struct opregion_swsci *swsci;
u32 swsci_gbda_sub_functions;
u32 swsci_sbcb_sub_functions;
-   struct opregion_asle __iomem *asle;
-   void __iomem *vbt;
-   u32 __iomem *lid_state;
+   struct opregion_asle *asle;
+   void *vbt;
+   u32 *lid_state;
struct work_struct asle_work;
 };
 #define OPREGION_SIZE(8*1024)
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index c19e669ffe50..f6762a5faee8 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1231,20 +1231,13 @@ static const struct dmi_system_id 
intel_no_opregion_vbt[] = {
{ }
 };

-static const struct bdb_header *validate_vbt(const void __iomem *_base,
+static const struct bdb_header *validate_vbt(const void *base,
 size_t size,
-const void __iomem *_vbt,
+const void *_vbt,
 const char *source)
 {
-   /*
-* This is the one place where we explicitly discard the address space
-* (__iomem) of the BIOS/VBT. (And this will cause a sparse complaint.)
-* From now on everything is based on 'base', and treated as regular
-* memory.
-*/
-   const void *base = (const void *) _base;
-   size_t offset = _vbt - _base;
-   const struct vbt_header *vbt = base + offset;
+   size_t offset = _vbt - base;
+   const struct vbt_header *vbt = _vbt;
const struct bdb_header *bdb;

[PATCH v6 10/17] phy: Add driver for rockchip Display Port PHY

2015-10-12 Thread Kishon Vijay Abraham I

Hi,

On Saturday 10 October 2015 09:25 PM, Yakir Yang wrote:
> This phy driver would control the Rockchip DisplayPort module
> phy clock and phy power, it is relate to analogix_dp-rockchip
> dp driver. If you want DP works rightly on rockchip platform,
> then you should select both of them.

Add phy driver for the Rockchip DisplayPort PHY module. This is required
to get DisplayPort working in Rockchip SoCs.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v6: None
> Changes in v5:
> - Remove "reg" DT property, cause driver could poweron/poweroff phy via
>   the exist "grf" syscon already. And rename the example DT node from
>   "edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
> - Add deivce_node at the front of driver, update phy_ops type from "static
>   struct" to "static const struct". And correct the input paramters of
>   devm_phy_create() interfaces. (Heiko)
> 
> Changes in v4:
> - Add commit message, and remove the redundant rockchip_dp_phy_init()
>   function, move those code to probe() method. And remove driver .owner
>   number. (Kishon)
> 
> Changes in v3:
> - Suggest, add rockchip dp phy driver, collect the phy clocks and
>   power control. (Heiko)
> 
> Changes in v2: None
> 
>  drivers/phy/Kconfig   |   7 ++
>  drivers/phy/Makefile  |   1 +
>  drivers/phy/phy-rockchip-dp.c | 151 
> ++
>  3 files changed, 159 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-dp.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 47da573..8f2bc4f 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
>   help
> Enable this to support the Rockchip USB 2.0 PHY.
>  
> +config PHY_ROCKCHIP_DP
> + tristate "Rockchip Display Port PHY Driver"
> + depends on ARCH_ROCKCHIP && OF
> + select GENERIC_PHY
> + help
> +   Enable this to support the Rockchip Display Port PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
>   tristate "ST SPEAR1310-MIPHY driver"
>   select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a5b18c1..e281f35 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)  += 
> phy-s5pv210-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)  += phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)  += phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..3a2ac120
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,151 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GRF_SOC_CON12   0x0274
> +#define GRF_EDP_REF_CLK_SEL_INTERBIT(4)
> +#define GRF_EDP_PHY_SIDDQ_WRITE_EN  BIT(21)
> +#define GRF_EDP_PHY_SIDDQ_ON0
> +#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
> +
> +struct rockchip_dp_phy {
> + struct device  *dev;
> + struct regmap  *grf;
> + struct clk *phy_24m;
> +};
> +
> +static int rockchip_set_phy_state(struct phy *phy, bool enable)
> +{
> + struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
> + int ret;
> +
> + if (enable) {
> + ret = clk_prepare_enable(dp->phy_24m);
> + if (ret < 0) {
> + dev_err(dp->dev, "Can't enable clock 24m %d\n", ret);
> + return ret;
> + }
> +
> + ret = regmap_write(dp->grf, GRF_SOC_CON12,
> +GRF_EDP_PHY_SIDDQ_WRITE_EN |
> +GRF_EDP_PHY_SIDDQ_ON);
> + } else {
> + clk_disable_unprepare(dp->phy_24m);

should clk_disable come after regmap_write? It'll be symmetric to enable?
> + ret = regmap_write(dp->grf, GRF_SOC_CON12,
> +GRF_EDP_PHY_SIDDQ_WRITE_EN |
> +GRF_EDP_PHY_SIDDQ_OFF);

Is this syscon register used only by Display Port PHY? Better to use
regmap_update API?

Thanks
Kishon

[Bug 91896] AMDGPU Fiji: only getting 1080i on DP

2015-10-12 Thread bugzilla-dae...@freedesktop.org

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #118841|0   |1
is obsolete||

--- Comment #18 from Alex Deucher  ---
Created attachment 118844
  --> https://bugs.freedesktop.org/attachment.cgi?id=118844=edit
possible fix

(In reply to Ernst SjÃ¶strand from comment #17)
> Works! There's another default value 54000 on line 676, but maybe that's
> needed for "current_dispclk"?

It shouldn't hurt anything, but lets just clean it up anyway.

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

v4.3-rc4: i915: ThinkPad Yoga 12: ERROR The master control interrupt lied (SDE)! [regression]

2015-10-12 Thread Jean-Christian de Rivaz

Le 12. 10. 15 09:06, Daniel Vetter a Ã©crit :
> Another regression for Jairo to track.
> -Daniel

I get the exact same dmesg too with the 4.3.0-rc5 on a i5-5250U NUC 
using HDMI. The rest is a standard Debian Jessie.

> On Sat, Oct 10, 2015 at 12:08:43PM -0700, Darren Hart wrote:
>> The Debian 3.16.0 kernel does not emit the error, but I have not attempted a
>> bisection.
>>
>> The warning was added by:
>> 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8)
>>   2014-06-18 (1 year, 4 months ago), Oscar Mateo 
>>
>> Follows: v3.15-rc8
>> Preceedes: 3.17-rc1
>>
>> This is not present in v3.16, so perhaps not present in the Debian kernel and
>> this is not a regression, but just reporting the condition as intended.
>>
>> Linux Version: v4.3-rc4
>> Platform: Lenovo ThinkPad Yoga 12
>> OS: Debian 8.2
>>
>> $ dmesg | grep -i drm
>> [   10.918367] [drm] Initialized drm 1.1.0 20060810
>> [   11.235005] [drm] Memory usable by graphics device = 4096M
>> [   11.235009] fb: switching to inteldrmfb from simple
>> [   11.235093] [drm] Replacing VGA console driver
>> [   11.241160] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [   11.241162] [drm] Driver supports precise vblank timestamp query.
>> [   11.256249] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: 
>> Can't calculate constants, dotclock = 0!
>> [   11.326946] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit 
>> banging on pin 5
>> [   11.344097] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on 
>> minor 0
>> [   11.344913] fbcon: inteldrmfb (fb0) is primary device
>> [   12.462509] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [   12.466498] i915 :00:02.0: fb0: inteldrmfb frame buffer device
>> [   12.794359] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [   13.869733] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [   13.869894] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [   13.870058] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [   22.656986] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [  257.506246] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [  257.506415] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [  257.506584] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [  257.506746] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [  278.722570] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [  278.722744] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [  278.722908] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [ 1857.776390] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [ 1857.776549] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [ 1857.776710] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>> [ 4057.592685] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
>> interrupt lied (SDE)!
>>
>> -- 
>> Darren Hart
>> Intel Open Source Technology Center

[PATCH v4 0/6] Enable gpu switching on the MacBook Pro

2015-10-12 Thread Lukas Wunner

Changes since v3:
  * Previously when switching the display, the DDC lines were switched
as well. But actually this is not necessary: If a GPU probes EDID,
DDC must be switched and locked to the GPU anyway, so why switch
DDC preemptively? Also, previously the DDC lines were switched back
to the previous owner on unlock. This is unnecessary for the same
reason. So I did away with all that and it simplifies the code
considerably. This works fine as long as anything accessing DDC
calls vga_switcheroo_lock_ddc() first. If something in the kernel
or a VM or in user space accesses DDC and omits locking it first,
things may go awry. (However, if locking is omitted, things could
go awry with the previous behaviour as well.) I'm curious if this
new behaviour provokes objections.
  * I now have conclusive evidence that only the pre-retina MacBook Pro
can switch DDC. The mux in the retina is incapable of that. So the
->switch_ddc callback is no longer advertised to vga_switcheroo
on retinas.


Also available on GitHub for easier reviewing:
https://github.com/l1k/linux/commits/mbp_switcheroo_v4


For those who haven't been following this series so far:

The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines and some models have no
VBIOS at all, so the inactive GPU cannot set up its LVDS output.

Extend vga_switcheroo to support switching only the DDC lines.
Introduce a drm_get_edid_switcheroo() helper which uses this feature.
Amend i915, nouveau and radeon to call it for LVDS connectors.

This only enables EDID probing on the pre-retina MBP (2008 - 2013),
and only under the condition that apple-gmux loads before the DRM
drivers. Later patches will address reprobing of the DRM drivers
if apple-gmux loads late.

The retina MBP (2012 - present) uses eDP and is apparently not
capable of switching AUX separately from the main link.
This will also be addressed in later patches.


Previous installments:
v1: http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html
v2: http://lists.freedesktop.org/archives/dri-devel/2015-August/088156.html
v3: http://lists.freedesktop.org/archives/dri-devel/2015-October/091741.html


Lukas Wunner (6):
  vga_switcheroo: Add support for switching only the DDC
  apple-gmux: Add switch_ddc support
  drm/edid: Switch DDC when reading the EDID
  drm/i915: Switch DDC when reading the EDID
  drm/nouveau: Switch DDC when reading the EDID
  drm/radeon: Switch DDC when reading the EDID

 drivers/gpu/drm/drm_edid.c  | 26 
 drivers/gpu/drm/i915/intel_lvds.c   |  3 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +-
 drivers/gpu/drm/radeon/radeon_connectors.c  |  4 ++
 drivers/gpu/vga/vga_switcheroo.c| 66 -
 drivers/platform/x86/apple-gmux.c   | 21 -
 include/drm/drm_crtc.h  |  2 +
 include/linux/vga_switcheroo.h  | 15 +--
 8 files changed, 141 insertions(+), 9 deletions(-)

-- 
1.8.5.2 (Apple Git-48)

[PATCH 20/22] drm/i915: BDW: Load degamma correction values

2015-10-12 Thread Rob Bradford

On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:
> I915 color manager registers pipe degamma correction as palette
> correction before CTM, DRM property.
> 
> This patch adds the no of coefficients(65) for degamma correction
> as "num_samples_before_ctm" parameter in device info structures,
> for BDW and higher platforms.

Did you copy and paste this from the CHV version? The only constant you
add for degamma here is 512?

Rob

> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>  drivers/gpu/drm/i915/i915_drv.c| 7 +++
>  drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index 4fa046f..ebf4910 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -303,6 +303,7 @@ static const struct intel_device_info
> intel_broadwell_d_info = {
>   .need_gfx_hws = 1, .has_hotplug = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
>   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
> + .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>   .has_llc = 1,
>   .has_ddi = 1,
>   .has_fpga_dbg = 1,
> @@ -316,6 +317,7 @@ static const struct intel_device_info
> intel_broadwell_m_info = {
>   .need_gfx_hws = 1, .has_hotplug = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
>   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
> + .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>   .has_llc = 1,
>   .has_ddi = 1,
>   .has_fpga_dbg = 1,
> @@ -329,6 +331,7 @@ static const struct intel_device_info
> intel_broadwell_gt3d_info = {
>   .need_gfx_hws = 1, .has_hotplug = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING
> | BSD2_RING,
>   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
> + .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>   .has_llc = 1,
>   .has_ddi = 1,
>   .has_fpga_dbg = 1,
> @@ -342,6 +345,7 @@ static const struct intel_device_info
> intel_broadwell_gt3m_info = {
>   .need_gfx_hws = 1, .has_hotplug = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING
> | BSD2_RING,
>   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
> + .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>   .has_llc = 1,
>   .has_ddi = 1,
>   .has_fpga_dbg = 1,
> @@ -368,6 +372,7 @@ static const struct intel_device_info
> intel_skylake_info = {
>   .need_gfx_hws = 1, .has_hotplug = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
>   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
> + .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>   .has_llc = 1,
>   .has_ddi = 1,
>   .has_fpga_dbg = 1,
> @@ -382,6 +387,7 @@ static const struct intel_device_info
> intel_skylake_gt3_info = {
>   .need_gfx_hws = 1, .has_hotplug = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING
> | BSD2_RING,
>   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
> + .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>   .has_llc = 1,
>   .has_ddi = 1,
>   .has_fpga_dbg = 1,
> @@ -396,6 +402,7 @@ static const struct intel_device_info
> intel_broxton_info = {
>   .need_gfx_hws = 1, .has_hotplug = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
>   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
> + .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>   .num_pipes = 3,
>   .has_ddi = 1,
>   .has_fpga_dbg = 1,
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
> b/drivers/gpu/drm/i915/intel_color_manager.h
> index 6c7cb08..e0c486e 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.h
> +++ b/drivers/gpu/drm/i915/intel_color_manager.h
> @@ -98,3 +98,6 @@
>  #define BDW_MAX_GAMMA ((1 << 24) - 1)
>  #define BDW_INDEX_AUTO_INCREMENT   (1 << 15)
>  #define BDW_INDEX_SPLIT_MODE   (1 << 31)
> +
> +/* Degamma on BDW */
> +#define BDW_DEGAMMA_MAX_VALS   512

[PATCH 19/22] drm/i915: BDW: Pipe level Gamma correction

2015-10-12 Thread Rob Bradford

On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:
> BDW/SKL/BXT platforms support various Gamma correction modes
> which are:
> 1. Legacy 8-bit mode
> 2. 10-bit Split Gamma mode
> 3. 12-bit mode
> 
> This patch does the following:
> 1. Adds the core function to program Gamma correction values
>for BDW/SKL/BXT platforms
> 2. Adds Gamma correction macros/defines
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h|  25 ++-
>  drivers/gpu/drm/i915/intel_color_manager.c | 248
> +
>  drivers/gpu/drm/i915/intel_color_manager.h |   6 +
>  3 files changed, 277 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 5825ab2..ed50f75 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5647,11 +5647,15 @@ enum skl_disp_power_wells {
>  /* legacy palette */
>  #define _LGC_PALETTE_A   0x4a000
>  #define _LGC_PALETTE_B   0x4a800
> -#define LGC_PALETTE(pipe, i) (_PIPE(pipe, _LGC_PALETTE_A,
> _LGC_PALETTE_B) + (i) * 4)
> +#define _LGC_PALETTE_C   0x4b000
> +#define LGC_PALETTE(pipe, i) (_PIPE3(pipe, _LGC_PALETTE_A,
> _LGC_PALETTE_B, \
> +  _LGC_PALETTE_C) + (i) * 4)
>  
>  #define _GAMMA_MODE_A0x4a480
>  #define _GAMMA_MODE_B0x4ac80
> -#define GAMMA_MODE(pipe) _PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
> +#define _GAMMA_MODE_C0x4b480
> +#define GAMMA_MODE(pipe) \
> + _PIPE3(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B, _GAMMA_MODE_C)
>  #define GAMMA_MODE_MODE_MASK (3 << 0)
>  #define GAMMA_MODE_MODE_8BIT (0 << 0)
>  #define GAMMA_MODE_MODE_10BIT(1 << 0)
> @@ -8062,6 +8066,23 @@ enum skl_disp_power_wells {
>  #define _PIPE_CSC_BASE(pipe) \
>   (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
>  
> +/* BDW gamma correction */
> +#define PAL_PREC_INDEX_A   0x4A400
> +#define PAL_PREC_INDEX_B   0x4AC00
> +#define PAL_PREC_INDEX_C   0x4B400
> +#define PAL_PREC_DATA_A0x4A404
> +#define PAL_PREC_DATA_B0x4AC04
> +#define PAL_PREC_DATA_C0x4B404
> +#define PAL_PREC_GCMAX_A 0x4A410
> +#define PAL_PREC_GCMAX_B 0x4AC10
> +#define PAL_PREC_GCMAX_C 0x4B410
> +
> +#define _PREC_PAL_INDEX(pipe) \
> + (_PIPE3(pipe, PAL_PREC_INDEX_A, PAL_PREC_INDEX_B,
> PAL_PREC_INDEX_C))
> +#define _PREC_PAL_DATA(pipe) \
> + (_PIPE3(pipe, PAL_PREC_DATA_A, PAL_PREC_DATA_B,
> PAL_PREC_DATA_C))
> +#define _PREC_PAL_GCMAX(pipe) \
> + (_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B,
> PAL_PREC_GCMAX_C))
>  
>  
>  #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index d5315b2..74f8fc3 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -26,6 +26,252 @@
>   */
>  
>  #include "intel_color_manager.h"
> +static void bdw_write_10bit_gamma_precision(struct drm_device *dev,
> + struct drm_r32g32b32 *correction_values, u32 pal_prec_data,
> + u32 no_of_coeff)
> +{
> + u16 blue_fract, green_fract, red_fract;
> + u32 word = 0;
> + u32 count = 0;
> + u32 blue, green, red;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + while (count < no_of_coeff) {
> +
> + blue = correction_values[count].b32;
> + green = correction_values[count].g32;
> + red = correction_values[count].r32;
> +
> + /*
> + * Maximum possible gamma correction value supported
> + * for BDW is 0x, so clip the values
> accordingly
> + */

I think you mean clamp not clip.

> + if (blue >= BDW_MAX_GAMMA)
> + blue = BDW_MAX_GAMMA;
> + if (green >= BDW_MAX_GAMMA)
> + green = BDW_MAX_GAMMA;
> + if (red >= BDW_MAX_GAMMA)
> + red = BDW_MAX_GAMMA;

So this handles the issue that was raised before that 1.0 in 8.24
should map to 1023.

> +
> + /*
> + * Gamma correction values are sent in 8.24 format
> + * with 8 int and 24 fraction bits. BDW 10 bit gamma
> + * unit expects correction registers to be programmed
> in
> + * 0.10 format, with 0 int and 16 fraction bits. So
> take
> + * MSB 10 bit values(bits 23-14) from the fraction
> part and
> + * prepare the correction registers.
> + */
> + blue_fract = GET_BITS(blue, 14, 10);
> + green_fract = GET_BITS(green, 14, 10);
> + red_fract = GET_BITS(red, 14, 10);
> +

I think this should round to the nearest rather than floor.

> +

[PATCH 21/22] drm/i915: BDW: Pipe level degamma correction

2015-10-12 Thread Rob Bradford

On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:
> BDW/SKL/BXT supports Degamma color correction feature, which
> linearizes the non-linearity due to gamma encoded color values.
> This will be applied before Color Transformation.
> 
> This patch does the following:
> 1. Adds the core function to program DeGamma correction values for
>BDW/SKL/BXT platform
> 2. Adds DeGamma correction macros/defines
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>  drivers/gpu/drm/i915/intel_color_manager.c | 59
> ++
>  1 file changed, 59 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index 74f8fc3..e659382 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -273,6 +273,63 @@ static int bdw_set_gamma(struct drm_device *dev,
> struct drm_property_blob *blob,
>   return 0;
>  }
>  
> +static int bdw_set_degamma(struct drm_device *dev,
> + struct drm_property_blob *blob, struct drm_crtc *crtc)
> +{
> + enum pipe pipe;
> + int num_samples, length;
> + u32 index, mode;
> + u32 pal_prec_index, pal_prec_data;
> + struct drm_palette *degamma_data;
> + struct drm_crtc_state *state = crtc->state;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_r32g32b32 *correction_values = NULL;
> +
> + if (WARN_ON(!blob))
> + return -EINVAL;
> +
> + degamma_data = (struct drm_palette *)blob->data;
> + pipe = to_intel_crtc(crtc)->pipe;
> + num_samples = degamma_data->num_samples;
> +
> + if (num_samples == GAMMA_DISABLE_VALS) {
> + /* Disable degamma on Pipe */
> + mode = I915_READ(GAMMA_MODE(pipe)) &
> ~GAMMA_MODE_MODE_MASK;
> + I915_WRITE(GAMMA_MODE(pipe), mode |
> GAMMA_MODE_MODE_8BIT);

When you turn off gamma you call bdw_reset_gamma() should you do the
same for degamma?

> +
> + state->palette_before_ctm_blob = NULL;
> + DRM_DEBUG_DRIVER("Disabling degamma on Pipe %c\n",
> + pipe_name(pipe));
> + return 0;
> + }
> +
> + if (num_samples != BDW_SPLITGAMMA_MAX_VALS) {
> + DRM_ERROR("Invalid number of samples\n");
> + return -EINVAL;
> + }
> +
> + length = num_samples * sizeof(struct drm_r32g32b32);

Uh, you calculate this length and don't use it anywhere? Was your
intention to check the blob length? And the length check should be in
the generic DRM code anyway...

I think it was suggested in the past that the number of samples could
be derived from the length of the data allowing the removal of the
struct member.

> + mode = I915_READ(GAMMA_MODE(pipe));

Move this closer to where you use it?

> + pal_prec_index = _PREC_PAL_INDEX(pipe);
> + pal_prec_data = _PREC_PAL_DATA(pipe);
> +
> + correction_values = (struct drm_r32g32b32 *)_data
> ->lut;

Why do you need this cast?

> + index = I915_READ(pal_prec_index);
> + index |= BDW_INDEX_AUTO_INCREMENT | BDW_INDEX_SPLIT_MODE;
> + I915_WRITE(pal_prec_index, index);
> +
> + bdw_write_10bit_gamma_precision(dev, correction_values,
> + pal_prec_data, BDW_SPLITGAMMA_MAX_VALS);
> +
> + /* Enable DeGamma on Pipe */
> + mode &= ~GAMMA_MODE_MODE_MASK;
> + I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_SPLIT);
> + DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",

Choose your capitalisation DeGamma or degamma. Pick one and use it
consistently to make it easier to grep through the code.

It also looks like you should check if the gamma mode is not something
other than split / off. Otherwise strange things could happen.
Similarly in the gamma code you shouldn't be able to program something
other than split if you have a degamma mode set.

> + pipe_name(pipe));
> +
> + return 0;
> +}
> +
>  static s16 chv_prepare_csc_coeff(s64 csc_value)
>  {
>   s32 csc_int_value;
> @@ -579,6 +636,8 @@ void intel_color_manager_crtc_commit(struct
> drm_device *dev,
>   /* Degamma correction */
>   if (IS_CHERRYVIEW(dev))
>   ret = chv_set_degamma(dev, blob, crtc);
> + else if (IS_BROADWELL(dev) || IS_GEN9(dev))
> + ret = bdw_set_degamma(dev, blob, crtc);
>  
>   if (ret)
>   DRM_ERROR("set degamma correction
> failed\n");

Rob

[PATCH v4 6/6] drm/radeon: Switch DDC when reading the EDID

2015-10-12 Thread Lukas Wunner

The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines.

Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS.
This allows us to retrieve the EDID if the outputs are currently
muxed to the integrated GPU by temporarily switching the panel's
DDC lines to the discrete GPU.

This only enables EDID probing on the pre-retina MBP (2008 - 2013).
The retina MBP (2012 - present) uses eDP and gmux is not capable
of switching AUX separately from the main link on these models.
This will be addressed in later patches.

List of pre-retina MBPs with dual GPUs, one of them AMD:
[MBP  8,2 2011  intel SNB + amd turks pre-retina  15"]
[MBP  8,3 2011  intel SNB + amd turks pre-retina  17"]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: William Brown 
[MBP  8,2 2011  intel SNB + amd turks pre-retina  15"]

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/radeon/radeon_connectors.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 5a2cafb..569f63c 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -344,6 +344,10 @@ static void radeon_connector_get_edid(struct drm_connector 
*connector)
else if (radeon_connector->ddc_bus)
radeon_connector->edid = 
drm_get_edid(_connector->base,
  
_connector->ddc_bus->adapter);
+   } else if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS &&
+  radeon_connector->ddc_bus) {
+   radeon_connector->edid = 
drm_get_edid_switcheroo(_connector->base,
+
_connector->ddc_bus->adapter);
} else if (radeon_connector->ddc_bus) {
radeon_connector->edid = drm_get_edid(_connector->base,
  
_connector->ddc_bus->adapter);
-- 
1.8.5.2 (Apple Git-48)

[PATCH v4 5/6] drm/nouveau: Switch DDC when reading the EDID

2015-10-12 Thread Lukas Wunner

The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines.

Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS.
This allows us to retrieve the EDID if the outputs are currently
muxed to the other GPU by temporarily switching the panel's DDC
lines. Likewise, ask vga_switcheroo to switch DDC before probing
LVDS connectors.

This only enables EDID probing on the pre-retina MBP (2008 - 2013).
The retina MBP (2012 - present) uses eDP and gmux is not capable
of switching AUX separately from the main link on these models.
This will be addressed in later patches.

List of pre-retina MBPs with dual GPUs, either or both Nvidia:
[MBP  5,1 2008  nvidia MCP79 + G96pre-retina  15"]
[MBP  5,2 2009  nvidia MCP79 + G96pre-retina  17"]
[MBP  5,3 2009  nvidia MCP79 + G96pre-retina  15"]
[MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina  15"]
[MBP  6,1 2010  intel ILK + nvidia GT216  pre-retina  17"]
[MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Lukas Wunner 
[MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 2e7cbe9..fb12c9e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -27,6 +27,7 @@
 #include 

 #include 
+#include 

 #include 
 #include 
@@ -148,7 +149,13 @@ nouveau_connector_ddc_detect(struct drm_connector 
*connector)
break;
} else
if (nv_encoder->i2c) {
-   if (nvkm_probe_i2c(nv_encoder->i2c, 0x50))
+   int ret;
+   if (nv_encoder->dcb->type == DCB_OUTPUT_LVDS)
+   vga_switcheroo_lock_ddc(dev->pdev);
+   ret = nvkm_probe_i2c(nv_encoder->i2c, 0x50);
+   if (nv_encoder->dcb->type == DCB_OUTPUT_LVDS)
+   vga_switcheroo_unlock_ddc();
+   if (ret)
break;
}
}
@@ -259,7 +266,9 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)

nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
-   nv_connector->edid = drm_get_edid(connector, i2c);
+   nv_connector->edid = nv_encoder->dcb->type == DCB_OUTPUT_LVDS ?
+drm_get_edid_switcheroo(connector, i2c) :
+drm_get_edid(connector, i2c);
drm_mode_connector_update_edid_property(connector,
nv_connector->edid);
if (!nv_connector->edid) {
-- 
1.8.5.2 (Apple Git-48)

[PATCH 8/9] drm/radeon: Fix kernel-doc copy/paste snafu

2015-10-12 Thread Lukas Wunner

Hi Alex,

On Mon, Oct 12, 2015 at 12:02:13PM -0400, Alex Deucher wrote:
> On Mon, Oct 12, 2015 at 5:44 AM, Lukas Wunner  wrote:
> > Introduced by f482a1419545 ("drm/radeon: document radeon_kms.c").
> >
> > Signed-off-by: Lukas Wunner 
> > ---
> >  drivers/gpu/drm/radeon/radeon_kms.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> > b/drivers/gpu/drm/radeon/radeon_kms.c
> > index 4e2780f..ee5cc14 100644
> > --- a/drivers/gpu/drm/radeon/radeon_kms.c
> > +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> > @@ -598,11 +598,11 @@ static int radeon_info_ioctl(struct drm_device *dev, 
> > void *data, struct drm_file
> >   * Outdated mess for old drm with Xorg being in charge (void function now).
> >   */
> >  /**
> > - * radeon_driver_firstopen_kms - drm callback for last close
> > + * radeon_driver_lastclose_kms - drm callback for last close
> 
> Already fixes as part of this patch:
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=8c70e1cda04b966b50ddfefafbd0ea376ed8edd5

Nice! I missed that because it's not yet in drm-next.


> Up to you if you want to respin the second hunk or not.

Not that important, so waived.

Thanks a lot!

Lukas


> >   *
> >   * @dev: drm dev pointer
> >   *
> > - * Switch vga switcheroo state after last close (all asics).
> > + * Switch vga_switcheroo state after last close (all asics).
> >   */
> >  void radeon_driver_lastclose_kms(struct drm_device *dev)
> >  {
> > --
> > 1.8.5.2 (Apple Git-48)
> >

[PATCH] drm/vmwgfx: switch from ioremap_cache to memremap

2015-10-12 Thread Dan Williams

Per commit 2e586a7e017a "drm/vmwgfx: Map the fifo as cached" the driver
expects the fifo registers to be cacheable.  In preparation for
deprecating ioremap_cache() convert its usage in vmwgfx to memremap().

Cc: David Airlie 
Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dan Williams 
---

 This is part of the tree-wide conversion of ioremap_cache() to
 memremap() targeted for v4.4 [1]

 As noted in that cover letter feel free to apply or ack.  These
 individual conversions can go in independently given the base memremap()
 implementation is already upstream in v4.3-rc1.

 This passes a clean run of sparse, but I have not tried to run the
 result.

 [1]: https://lkml.org/lkml/2015/10/9/699

 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |8 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h   |2 -
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |   23 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c  |  102 -
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c |9 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_irq.c   |8 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |   24 
 7 files changed, 84 insertions(+), 92 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 2c7a25c71af2..d6152cd7c634 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -752,8 +752,8 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
ttm_lock_set_kill(_priv->fbdev_master.lock, false, SIGTERM);
dev_priv->active_master = _priv->fbdev_master;

-   dev_priv->mmio_virt = ioremap_cache(dev_priv->mmio_start,
-   dev_priv->mmio_size);
+   dev_priv->mmio_virt = memremap(dev_priv->mmio_start,
+  dev_priv->mmio_size, MEMREMAP_WB);

if (unlikely(dev_priv->mmio_virt == NULL)) {
ret = -ENOMEM;
@@ -907,7 +907,7 @@ out_no_irq:
 out_no_device:
ttm_object_device_release(_priv->tdev);
 out_err4:
-   iounmap(dev_priv->mmio_virt);
+   memunmap(dev_priv->mmio_virt);
 out_err3:
vmw_ttm_global_release(dev_priv);
 out_err0:
@@ -958,7 +958,7 @@ static int vmw_driver_unload(struct drm_device *dev)
pci_release_regions(dev->pdev);

ttm_object_device_release(_priv->tdev);
-   iounmap(dev_priv->mmio_virt);
+   memunmap(dev_priv->mmio_virt);
if (dev_priv->ctx.staged_bindings)
vmw_binding_state_free(dev_priv->ctx.staged_bindings);
vmw_ttm_global_release(dev_priv);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index f19fd39b43e1..7ff1db23de80 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -375,7 +375,7 @@ struct vmw_private {
uint32_t stdu_max_height;
uint32_t initial_width;
uint32_t initial_height;
-   u32 __iomem *mmio_virt;
+   u32 *mmio_virt;
uint32_t capabilities;
uint32_t max_gmr_ids;
uint32_t max_gmr_pages;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 567ddede51d1..97f75adc080d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -141,9 +141,9 @@ static bool vmw_fence_enable_signaling(struct fence *f)

struct vmw_fence_manager *fman = fman_from_fence(fence);
struct vmw_private *dev_priv = fman->dev_priv;
+   u32 *fifo_mem = dev_priv->mmio_virt;
+   u32 seqno = *(fifo_mem + SVGA_FIFO_FENCE);

-   u32 __iomem *fifo_mem = dev_priv->mmio_virt;
-   u32 seqno = ioread32(fifo_mem + SVGA_FIFO_FENCE);
if (seqno - fence->base.seqno < VMW_FENCE_WRAP)
return false;

@@ -386,14 +386,14 @@ static bool vmw_fence_goal_new_locked(struct 
vmw_fence_manager *fman,
  u32 passed_seqno)
 {
u32 goal_seqno;
-   u32 __iomem *fifo_mem;
+   u32 *fifo_mem;
struct vmw_fence_obj *fence;

if (likely(!fman->seqno_valid))
return false;

fifo_mem = fman->dev_priv->mmio_virt;
-   goal_seqno = ioread32(fifo_mem + SVGA_FIFO_FENCE_GOAL);
+   goal_seqno = *(fifo_mem + SVGA_FIFO_FENCE_GOAL);
if (likely(passed_seqno - goal_seqno >= VMW_FENCE_WRAP))
return false;

@@ -401,8 +401,7 @@ static bool vmw_fence_goal_new_locked(struct 
vmw_fence_manager *fman,
list_for_each_entry(fence, >fence_list, head) {
if (!list_empty(>seq_passed_actions)) {
fman->seqno_valid = true;
-   iowrite32(fence->base.seqno,
- fifo_mem + SVGA_FIFO_FENCE_GOAL);
+   *(fifo_mem + SVGA_FIFO_FENCE_GOAL) = fence->base.seqno;
break;
}
}
@@ -430,18 +429,18 @@ static bool

[PATCH v4 4/6] drm/i915: Switch DDC when reading the EDID

2015-10-12 Thread Lukas Wunner

The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines and some models have no
VBIOS at all.

Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS.
This allows us to retrieve the EDID if the outputs are currently
muxed to the discrete GPU by temporarily switching the panel's DDC
lines to the integrated GPU.

This only enables EDID probing on the pre-retina MBP (2008 - 2013).
The retina MBP (2012 - present) uses eDP and gmux is not capable
of switching AUX separately from the main link on these models.
This will be addressed in later patches.

List of pre-retina MBPs with dual GPUs, one of them Intel:
[MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina  15"]
[MBP  6,1 2010  intel ILK + nvidia GT216  pre-retina  17"]
[MBP  8,2 2011  intel SNB + amd turks pre-retina  15"]
[MBP  8,3 2011  intel SNB + amd turks pre-retina  17"]
[MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: William Brown 
[MBP  8,2 2011  intel SNB + amd turks pre-retina  15"]
Tested-by: Lukas Wunner 
[MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/i915/intel_lvds.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 881b5d1..a84727f 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -1067,7 +1067,8 @@ void intel_lvds_init(struct drm_device *dev)
 * preferred mode is the right one.
 */
mutex_lock(>mode_config.mutex);
-   edid = drm_get_edid(connector, intel_gmbus_get_adapter(dev_priv, pin));
+   edid = drm_get_edid_switcheroo(connector,
+  intel_gmbus_get_adapter(dev_priv, pin));
if (edid) {
if (drm_add_edid_modes(connector, edid)) {
drm_mode_connector_update_edid_property(connector,
-- 
1.8.5.2 (Apple Git-48)

[PATCH v4 3/6] drm/edid: Switch DDC when reading the EDID

2015-10-12 Thread Lukas Wunner

Originally by Seth Forshee , 2012-10-04:
Some dual graphics machines support muxing the DDC separately from
the display, so make use of this functionality when reading the EDID
on the inactive GPU. Also serialize drm_get_edid() with a mutex to
avoid races on the DDC mux state.

Modified by Dave Airlie , 2012-12-22:
I can't figure out why I didn't like this, but I rewrote this [...]
to lock/unlock the ddc lines [...]. I think I'd prefer something
like that otherwise the interface got really ugly.

Modified by Lukas Wunner , 2015-09-11:
Move vga_switcheroo calls to a wrapper around drm_get_edid() which
drivers can call on muxed machines. This avoids other drivers having
to go through the vga_switcheroo motions even though they are never
used on a muxed platform.
(suggested by Thierry Reding )

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Lukas Wunner 
[MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]

Cc: Seth Forshee 
Cc: Dave Airlie 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/drm_edid.c | 26 ++
 include/drm/drm_crtc.h |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d5d2c03..f28385c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1389,6 +1390,31 @@ struct edid *drm_get_edid(struct drm_connector 
*connector,
 EXPORT_SYMBOL(drm_get_edid);

 /**
+ * drm_get_edid_switcheroo - get EDID data for a vga_switcheroo output
+ * @connector: connector we're probing
+ * @adapter: I2C adapter to use for DDC
+ *
+ * Wrapper around drm_get_edid() for laptops with dual GPUs using one set of
+ * outputs. The wrapper adds the requisite vga_switcheroo calls to temporarily
+ * switch DDC to the GPU which is retrieving EDID.
+ *
+ * Return: Pointer to valid EDID or NULL if we couldn't find any.
+ */
+struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
+struct i2c_adapter *adapter)
+{
+   struct pci_dev *pdev = connector->dev->pdev;
+   struct edid *edid;
+
+   vga_switcheroo_lock_ddc(pdev);
+   edid = drm_get_edid(connector, adapter);
+   vga_switcheroo_unlock_ddc();
+
+   return edid;
+}
+EXPORT_SYMBOL(drm_get_edid_switcheroo);
+
+/**
  * drm_edid_duplicate - duplicate an EDID and the extensions
  * @edid: EDID to duplicate
  *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 33ddedd..483f70c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1297,6 +1297,8 @@ extern void drm_property_destroy_user_blobs(struct 
drm_device *dev,
 extern bool drm_probe_ddc(struct i2c_adapter *adapter);
 extern struct edid *drm_get_edid(struct drm_connector *connector,
 struct i2c_adapter *adapter);
+extern struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
+   struct i2c_adapter *adapter);
 extern struct edid *drm_edid_duplicate(const struct edid *edid);
 extern int drm_add_edid_modes(struct drm_connector *connector, struct edid 
*edid);
 extern void drm_mode_config_init(struct drm_device *dev);
-- 
1.8.5.2 (Apple Git-48)

[PATCH v4 2/6] apple-gmux: Add switch_ddc support

2015-10-12 Thread Lukas Wunner

Originally by Seth Forshee , 2012-10-04:
The gmux allows muxing the DDC independently from the display, so
support this functionality. This will allow reading the EDID for the
inactive GPU, fixing issues with machines that either don't have a
VBT or have invalid mode data in the VBT.

Modified by Lukas Wunner , 2015-10-07:
Advertise ->switch_ddc handler callback only on the pre-retina
Macbook Pro. The retina uses eDP and its mux is incapable of
switching the AUX channel separately from the main link.
It's an NXP CBTL06142 (alternate parts: TI HD3SS212,
Pericom PPI3VDP12412).

Sources:
http://www.electronicproducts.com/-whatsinside_text-145.aspx

http://slideshare.net/jjwu6266/apple-2012-wwdc-apple-macbook-pro-with-retina-display

http://www.techrepublic.com/blog/cracking-open/teardown-shows-retina-macbook-pro-is-nearly-impossible-to-upgrade-difficult-to-work-on/

Datasheets:
http://www.nxp.com/documents/data_sheet/CBTL06141.pdf
http://www.ti.com/lit/ds/symlink/hd3ss212.pdf
https://www.pericom.com/assets/Datasheets/PI3VDP12412.pdf

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Lukas Wunner 
[MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]

Cc: Seth Forshee 
Signed-off-by: Lukas Wunner 
---
 drivers/platform/x86/apple-gmux.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index 0dec3f5..78997b7 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -276,11 +276,9 @@ static const struct backlight_ops gmux_bl_ops = {
 static int gmux_switchto(enum vga_switcheroo_client_id id)
 {
if (id == VGA_SWITCHEROO_IGD) {
-   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 2);
gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 2);
} else {
-   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 3);
gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 3);
}
@@ -288,6 +286,18 @@ static int gmux_switchto(enum vga_switcheroo_client_id id)
return 0;
 }

+static int gmux_switch_ddc(enum vga_switcheroo_client_id id)
+{
+   pr_debug("Switching gmux DDC to %d\n", id);
+
+   if (id == VGA_SWITCHEROO_IGD)
+   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
+   else
+   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
+
+   return 0;
+}
+
 static int gmux_set_discrete_state(struct apple_gmux_data *gmux_data,
   enum vga_switcheroo_state state)
 {
@@ -588,6 +598,13 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
gmux_data->gpe = -1;
}

+   /*
+* The gmux in pre-retina MacBook Pros can switch DDC separately
+* from the other pins of the outputs. It's distinguishable from
+* the gmux in retinas by being non-indexed.
+*/
+   if (!gmux_data->indexed)
+   gmux_handler.switch_ddc = gmux_switch_ddc;
if (vga_switcheroo_register_handler(_handler)) {
ret = -ENODEV;
goto err_register_handler;
-- 
1.8.5.2 (Apple Git-48)

[PATCH v4 1/6] vga_switcheroo: Add support for switching only the DDC

2015-10-12 Thread Lukas Wunner

Originally by Seth Forshee , 2012-10-04:
During graphics driver initialization it's useful to be able to mux
only the DDC to the inactive client in order to read the EDID. Add
a switch_ddc callback to allow capable handlers to provide this
functionality, and add vga_switcheroo_switch_ddc() to allow DRM
to mux only the DDC.

Modified by Dave Airlie , 2012-12-22:
I can't figure out why I didn't like this, but I rewrote this [...]
to lock/unlock the ddc lines [...]. I think I'd prefer something
like that otherwise the interface got really ugly.

Modified by Lukas Wunner , 2015-08-14:
Don't lock vgasr_mutex in _lock_ddc() / _unlock_ddc(), it can cause
deadlocks because (a) during switch (with vgasr_mutex already held),
GPU is woken and probes its outputs, tries to re-acquire vgasr_mutex
to lock DDC lines; (b) Likewise during switch, GPU is suspended and
calls cancel_delayed_work_sync() to stop output polling, if poll
task is running at this moment we may wait forever for it to finish.

Instead, lock ddc_lock when unregistering the handler because the
only reason why we'd want to lock vgasr_mutex in _lock_ddc() /
_unlock_ddc() is to block the handler from disappearing while DDC
lines are switched.

Don't switch DDC lines in stage2, it's pointless because if DDC is
accessed, _lock_ddc() needs to be called anyway. And for consistency
we'd also have to switch DDC on MIGD / MDIS commands and on runtime
suspend, needlessly inflating the code. For the same reason it's
unnecessary to switch DDC back to the previous owner on unlock.

v2.1: Overhaul locking, squash commits
(requested by Daniel Vetter )

v2.2: Readability improvements
(requested by Thierry Reding )

v2.3: Overhaul locking once more

v2.4: Retain semantics of ->switchto handler callback to switch all pins
(requested by Daniel Vetter )

v4:   Drop DDC switch in stage2, MIGD / MDIS and runtime suspend

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Lukas Wunner 
[MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]

Cc: Seth Forshee 
Cc: Dave Airlie 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/vga/vga_switcheroo.c | 66 +++-
 include/linux/vga_switcheroo.h   | 15 +++--
 2 files changed, 77 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index af0d372..757 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -73,9 +73,19 @@
  * there can thus be up to three clients: Two vga clients (GPUs) and one audio
  * client (on the discrete GPU). The code is mostly prepared to support
  * machines with more than two GPUs should they become available.
+ *
  * The GPU to which the outputs are currently switched is called the
  * active client in vga_switcheroo parlance. The GPU not in use is the
- * inactive client.
+ * inactive client. When the inactive client's DRM driver is loaded,
+ * it will be unable to probe the panel's EDID and hence depends on
+ * VBIOS to provide its display modes. If the VBIOS modes are bogus or
+ * if there is no VBIOS at all (which is common on the MacBook Pro),
+ * a client may alternatively request that the DDC lines are temporarily
+ * switched to it, provided that the handler supports this. Switching
+ * only the DDC lines and not the entire output avoids unnecessary
+ * flickering. On machines which are able to mux external connectors,
+ * VBIOS cannot know of attached displays so switching the DDC lines
+ * is the only option to retrieve the displays' EDID.
  */

 /**
@@ -125,6 +135,7 @@ static DEFINE_MUTEX(vgasr_mutex);
  * (counting only vga clients, not audio clients)
  * @clients: list of registered clients
  * @handler: registered handler
+ * @ddc_lock: protects access to DDC lines while they are temporarily switched
  *
  * vga_switcheroo private data. Currently only one vga_switcheroo instance
  * per system is supported.
@@ -141,6 +152,7 @@ struct vgasr_priv {
struct list_head clients;

struct vga_switcheroo_handler *handler;
+   struct mutex ddc_lock;
 };

 #define ID_BIT_AUDIO   0x100
@@ -155,6 +167,7 @@ static void vga_switcheroo_debugfs_fini(struct vgasr_priv 
*priv);
 /* only one switcheroo per system */
 static struct vgasr_priv vgasr_priv = {
.clients = LIST_HEAD_INIT(vgasr_priv.clients),
+   .ddc_lock = __MUTEX_INITIALIZER(vgasr_priv.ddc_lock),
 };

 static bool vga_switcheroo_ready(void)
@@ -221,12 +234,14 @@ EXPORT_SYMBOL(vga_switcheroo_register_handler);
 void vga_switcheroo_unregister_handler(void)
 {
mutex_lock(_mutex);
+   mutex_lock(_priv.ddc_lock);
vgasr_priv.handler = NULL;
if (vgasr_priv.active) {
pr_info("disabled\n");
vga_switcheroo_debugfs_fini(_priv);

[PATCH v6 10/17] phy: Add driver for rockchip Display Port PHY

2015-10-12 Thread Heiko Stübner

Am Montag, 12. Oktober 2015, 20:32:47 schrieb Kishon Vijay Abraham I:
> Hi,
> 
> On Saturday 10 October 2015 09:25 PM, Yakir Yang wrote:
> > This phy driver would control the Rockchip DisplayPort module
> > phy clock and phy power, it is relate to analogix_dp-rockchip
> > dp driver. If you want DP works rightly on rockchip platform,
> > then you should select both of them.
> 
> Add phy driver for the Rockchip DisplayPort PHY module. This is required
> to get DisplayPort working in Rockchip SoCs.
> 
> > Signed-off-by: Yakir Yang 
> > ---
> > Changes in v6: None
> > Changes in v5:
> > - Remove "reg" DT property, cause driver could poweron/poweroff phy via
> > 
> >   the exist "grf" syscon already. And rename the example DT node from
> >   "edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
> > 
> > - Add deivce_node at the front of driver, update phy_ops type from "static
> > 
> >   struct" to "static const struct". And correct the input paramters of
> >   devm_phy_create() interfaces. (Heiko)
> > 
> > Changes in v4:
> > - Add commit message, and remove the redundant rockchip_dp_phy_init()
> > 
> >   function, move those code to probe() method. And remove driver .owner
> >   number. (Kishon)
> > 
> > Changes in v3:
> > - Suggest, add rockchip dp phy driver, collect the phy clocks and
> > 
> >   power control. (Heiko)
> > 
> > Changes in v2: None
> > 
> >  drivers/phy/Kconfig   |   7 ++
> >  drivers/phy/Makefile  |   1 +
> >  drivers/phy/phy-rockchip-dp.c | 151
> >  ++ 3 files changed, 159
> >  insertions(+)
> >  create mode 100644 drivers/phy/phy-rockchip-dp.c
> > 
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index 47da573..8f2bc4f 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
> > 
> > help
> > 
> >   Enable this to support the Rockchip USB 2.0 PHY.
> > 
> > +config PHY_ROCKCHIP_DP
> > +   tristate "Rockchip Display Port PHY Driver"
> > +   depends on ARCH_ROCKCHIP && OF
> > +   select GENERIC_PHY
> > +   help
> > + Enable this to support the Rockchip Display Port PHY.
> > +
> > 
> >  config PHY_ST_SPEAR1310_MIPHY
> >  
> > tristate "ST SPEAR1310-MIPHY driver"
> > select GENERIC_PHY
> > 
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> > index a5b18c1..e281f35 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
> > phy-s5pv210-usb2.o> 
> >  obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
> >  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
> >  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> > 
> > +obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
> > 
> >  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
> >  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
> >  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
> > 
> > diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> > new file mode 100644
> > index 000..3a2ac120
> > --- /dev/null
> > +++ b/drivers/phy/phy-rockchip-dp.c
> > @@ -0,0 +1,151 @@
> > +/*
> > + * Rockchip DP PHY driver
> > + *
> > + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> > + * Author: Yakir Yang 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define GRF_SOC_CON12   0x0274
> > +#define GRF_EDP_REF_CLK_SEL_INTER  BIT(4)
> > +#define GRF_EDP_PHY_SIDDQ_WRITE_EN  BIT(21)
> > +#define GRF_EDP_PHY_SIDDQ_ON0
> > +#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
> > +
> > +struct rockchip_dp_phy {
> > +   struct device  *dev;
> > +   struct regmap  *grf;
> > +   struct clk *phy_24m;
> > +};
> > +
> > +static int rockchip_set_phy_state(struct phy *phy, bool enable)
> > +{
> > +   struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
> > +   int ret;
> > +
> > +   if (enable) {
> > +   ret = clk_prepare_enable(dp->phy_24m);
> > +   if (ret < 0) {
> > +   dev_err(dp->dev, "Can't enable clock 24m %d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   ret = regmap_write(dp->grf, GRF_SOC_CON12,
> > +  GRF_EDP_PHY_SIDDQ_WRITE_EN |
> > +  GRF_EDP_PHY_SIDDQ_ON);
> > +   } else {
> > +   clk_disable_unprepare(dp->phy_24m);
> 
> should clk_disable come after regmap_write? It'll be symmetric to enable?
> 
> > +   ret =

[PATCH 22/22] drm/i915: BDW: Pipe level CSC correction

2015-10-12 Thread Rob Bradford

On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:
> BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
> that needs to be programmed into respective CSC registers.
> 
> This patch does the following:
> 1. Adds the core function to program CSC correction values for
>BDW/SKL/BXT platform
> 2. Adds CSC correction macros/defines
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> Signed-off-by: Kumar, Kiran S 
> ---
>  drivers/gpu/drm/i915/i915_reg.h|   7 ++
>  drivers/gpu/drm/i915/intel_color_manager.c | 114
> -
>  drivers/gpu/drm/i915/intel_color_manager.h |  12 ++-
>  3 files changed, 129 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index ed50f75..0e9d252 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8085,4 +8085,11 @@ enum skl_disp_power_wells {
>   (_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B,
> PAL_PREC_GCMAX_C))
>  
>  
> +/* BDW CSC correction */
> +#define CSC_COEFF_A  0x49010
> +#define CSC_COEFF_B  0x49110
> +#define CSC_COEFF_C  0x49210
> +#define _PIPE_CSC_COEFF(pipe) \
> + (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
> +
>  #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index e659382..0a6c00c 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -330,11 +330,119 @@ static int bdw_set_degamma(struct drm_device
> *dev,
>   return 0;
>  }
>  
> -static s16 chv_prepare_csc_coeff(s64 csc_value)
> +static uint32_t bdw_prepare_csc_coeff(int64_t coeff)
> +{
> + uint32_t reg_val, ls_bit_pos, exponent_bits, sign_bit = 0;
> + int32_t mantissa;
> + uint64_t abs_coeff;
> +
> + coeff = min_t(int64_t, coeff, BDW_CSC_COEFF_MAX_VAL);
> + coeff = max_t(int64_t, coeff, BDW_CSC_COEFF_MIN_VAL);
> +
> + abs_coeff = abs(coeff);
> + if (abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 3)) {
> + /* abs_coeff < 0.125 */
> + exponent_bits = 3;
> + ls_bit_pos = 19;
> + } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 3) &&
> + abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 2)) {
> + /* abs_coeff >= 0.125 && val < 0.25 */
> + exponent_bits = 2;
> + ls_bit_pos = 20;
> + } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 2)
> + && abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 1)) {
> + /* abs_coeff >= 0.25 && val < 0.5 */
> + exponent_bits = 1;
> + ls_bit_pos = 21;
> + } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 1)
> + && abs_coeff < BDW_CSC_COEFF_UNITY_VAL) {
> + /* abs_coeff >= 0.5 && val < 1.0 */
> + exponent_bits = 0;
> + ls_bit_pos = 22;
> + } else if (abs_coeff >= BDW_CSC_COEFF_UNITY_VAL &&
> + abs_coeff < (BDW_CSC_COEFF_UNITY_VAL << 1)) {
> + /* abs_coeff >= 1.0 && val < 2.0 */
> + exponent_bits = 7;
> + ls_bit_pos = 23;
> + } else {
> + /* abs_coeff >= 2.0 && val < 4.0 */
> + exponent_bits = 6;
> + ls_bit_pos = 24;
> + }
> +
> + mantissa = GET_BITS_ROUNDOFF(abs_coeff, ls_bit_pos,
> CSC_MAX_VALS);

Is GET_BITS_ROUNDOFF safe for negative values?

> + if (coeff < 0) {
> + sign_bit = 1;
> + mantissa = -mantissa;
> + mantissa &= ((1 << CSC_MAX_VALS) - 1);

Oops. It looks like you are reusing the macro/define for the number of
coefficients for the size of the mantissa. Also you defined a macro for
this very purpose in your other patch.

> + }
> +
> + reg_val = 0;
> + SET_BITS(reg_val, exponent_bits, 12, 3);
> + SET_BITS(reg_val, mantissa, 3, 9);
> + SET_BITS(reg_val, sign_bit, 15, 1);
> + DRM_DEBUG_DRIVER("CSC: reg_val=0x%x\n", reg_val);

This debug message is superfluous as you can easily read register
values out with i-g-t.

> + return reg_val;
> +}
> +
> +int bdw_set_csc(struct drm_device *dev, struct drm_property_blob
> *blob,
> + struct drm_crtc *crtc)
> +{
> + enum pipe pipe;
> + enum plane plane;
> + int i, j, temp;
> + int word = 0;
> + u32 reg, plane_ctl, mode;
> + struct drm_ctm *csc_data;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + if (WARN_ON(!blob))
> + return -EINVAL;
> +
> + if (blob->length != sizeof(struct drm_ctm)) {
> + DRM_ERROR("Invalid length of data received\n");
> + return -EINVAL;
> + }
> +
> + csc_data = (struct drm_ctm *)blob->data;
> + pipe = to_intel_crtc(crtc)->pipe;
> + plane = to_intel_crtc(crtc)->plane;
> +
> + plane_ctl = I915_READ(PLANE_CTL(pipe,

As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]

2015-10-12 Thread Jani Nikula

On Fri, 09 Oct 2015, Doug Smythies  wrote:
> This started somewhere between Kernel 4.2 and 4.3-rc1,
> but I only noticed it a day ago.

Thanks for the report, please let's follow up at [1].

Thanks,
Jani.


[1] https://bugs.freedesktop.org/show_bug.cgi?id=92414


-- 
Jani Nikula, Intel Open Source Technology Center

radeonsi - crash with 7870 Tahiti - Bad Active CU detection?

2015-10-12 Thread Alex Deucher

On Thu, Oct 8, 2015 at 9:59 PM, Alexandre Biron
 wrote:
> Hi!
>
> I've never been able to run the open source drm driver on my 7870
> Tahiti card. The console kms works but it crashes as soon as X is
> started. There have been many mentions of it in bug reports, but none
> of the attempts at fixes worked.
> https://bugs.freedesktop.org/show_bug.cgi?id=71689 is currently open
> https://bugs.freedesktop.org/show_bug.cgi?id=60879 was about a few
> different issues, including this one, but none of the proposed fixes
> worked on my 7870
>
> I decided to debug this on my own, and though I am a total noob at
> driver development, I think I made some progress at understanding the
> issue.
>
> The 7870 Tahiti is a "harvested" chip, which means some CUs are
> disabled. 25% of them in this case.  The code handling this is in
> si.c, in the function is si_setup_spi(). The idea seems to be that a
> bit mask telling which CUs are truly available must be set in the
> SPI_STATIC_THREAD_MGMT_3 register. But the algorithm to build that
> mask seems fuzzy to me. It walks the bits of active_cu until it finds
> an active one, and stop there to build its make.
>
> data = RREG32(SPI_STATIC_THREAD_MGMT_3);
> active_cu = si_get_cu_enabled(rdev, cu_per_sh);
> mask = 1;
> for (k = 0; k < 16; k++) {
> mask <<= k;
> if (active_cu & mask) {
> data &= ~mask;
> WREG32(SPI_STATIC_THREAD_MGMT_3, data);
> break;
> }
> }
>
> However, from the little I understand that doesn't cover all cases,
> but only works if the disabled CUs are in the lower bits. For my card,
> the active_cu results are:
> Decimal - Binary
> 252 - 1100
> 252 - 1100
> 207 - 1100
> 252 - 1100
>
> As you can see the 3rd group has its disabled CUs straight in the
> middle of it, but the algorithm probably thinks that they are all good
> since the first bit is 1 and it stops right there. So I guess it tries
> to use bad CUs at runtime and fails miserably
> I tried to change the way the register data is computed by I just
> can't figure the logic of it (and I couldn't find much details in
> AMD's doc). Assuming it generates the right thing for active_cu ==
> 1100, I get data == 0111.
> So I have 2 disabled units, but only a single 0 in the mask?
> Pretending to have more disabled units, active_cu == , that
> generates data == 1011. Again, single 0. Is that right?
> What would be the bit pattern required for active_cu == 1100 ?
>
> I might be way off track in my investigation, so please enlighten me!

I don't think this register even needs to be programmed.  Can you try
skipping the call to si_setup_spi()?  The hw default values 0x
should be fine.  These registers are not for harvesting, but rather
for limiting the number of CUs uses by specific shader stages so even
if you program them wrong, the hw will do the right thing internally.

Alex

[PATCH 0/9] vga_switcheroo cleanup

2015-10-12 Thread Lukas Wunner

Hi Daniel,

as requested here's a resend of the 4 pending vga_switcheroo
cleanup patches (originally posted Sep 17), 2 of them now with
Reviewed-by tags.

On top, a new one for i915 and 4 new ones for Alex.

Also available on GitHub:
https://github.com/l1k/linux/commits/vga_switcheroo_cleanup

Thank you & best regards,

Lukas


Lukas Wunner (9):
  vga_switcheroo: Use enum vga_switcheroo_state instead of int
  vga_switcheroo: Use VGA_SWITCHEROO_UNKNOWN_ID instead of -1
  vga_switcheroo: Use enum vga_switcheroo_client_id instead of int
  ALSA: hda - Spell vga_switcheroo consistently
  drm/i915: Drop unnecessary #include 
  drm/radeon: Drop unnecessary #include 
  drm/amdgpu: Drop unnecessary #include 
  drm/radeon: Fix kernel-doc copy/paste snafu
  drm/amdgpu: Fix kernel-doc copy/paste snafu

 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c  |  4 ++--
 drivers/gpu/drm/i915/intel_acpi.c|  1 -
 drivers/gpu/drm/radeon/radeon_acpi.c |  1 -
 drivers/gpu/drm/radeon/radeon_asic.c |  1 -
 drivers/gpu/drm/radeon/radeon_bios.c |  1 -
 drivers/gpu/drm/radeon/radeon_kms.c  |  4 ++--
 drivers/gpu/vga/vga_switcheroo.c | 36 ++--
 include/linux/vga_switcheroo.h   | 14 -
 sound/pci/hda/hda_controller.h   |  2 +-
 sound/pci/hda/hda_intel.c| 12 +--
 sound/pci/hda/hda_intel.h|  2 +-
 13 files changed, 41 insertions(+), 39 deletions(-)

-- 
1.8.5.2 (Apple Git-48)

[PATCH v4 2/6] apple-gmux: Add switch_ddc support

2015-10-12 Thread Alex Deucher

On Mon, Oct 12, 2015 at 5:07 PM, Alex Deucher  wrote:
> On Fri, Aug 14, 2015 at 12:18 PM, Lukas Wunner  wrote:
>> Originally by Seth Forshee , 2012-10-04:
>> The gmux allows muxing the DDC independently from the display, so
>> support this functionality. This will allow reading the EDID for the
>> inactive GPU, fixing issues with machines that either don't have a
>> VBT or have invalid mode data in the VBT.
>>
>> Modified by Lukas Wunner , 2015-10-07:
>> Advertise ->switch_ddc handler callback only on the pre-retina
>> Macbook Pro. The retina uses eDP and its mux is incapable of
>> switching the AUX channel separately from the main link.
>> It's an NXP CBTL06142 (alternate parts: TI HD3SS212,
>> Pericom PPI3VDP12412).
>>
>> Sources:
>> http://www.electronicproducts.com/-whatsinside_text-145.aspx
>> 
>> http://slideshare.net/jjwu6266/apple-2012-wwdc-apple-macbook-pro-with-retina-display
>> 
>> http://www.techrepublic.com/blog/cracking-open/teardown-shows-retina-macbook-pro-is-nearly-impossible-to-upgrade-difficult-to-work-on/
>>
>> Datasheets:
>> http://www.nxp.com/documents/data_sheet/CBTL06141.pdf
>> http://www.ti.com/lit/ds/symlink/hd3ss212.pdf
>> https://www.pericom.com/assets/Datasheets/PI3VDP12412.pdf
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
>> Tested-by: Lukas Wunner 
>> [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
>>
>> Cc: Seth Forshee 
>> Signed-off-by: Lukas Wunner 
>> ---
>>  drivers/platform/x86/apple-gmux.c | 21 +++--
>>  1 file changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/platform/x86/apple-gmux.c 
>> b/drivers/platform/x86/apple-gmux.c
>> index 0dec3f5..78997b7 100644
>> --- a/drivers/platform/x86/apple-gmux.c
>> +++ b/drivers/platform/x86/apple-gmux.c
>> @@ -276,11 +276,9 @@ static const struct backlight_ops gmux_bl_ops = {
>>  static int gmux_switchto(enum vga_switcheroo_client_id id)
>>  {
>> if (id == VGA_SWITCHEROO_IGD) {
>> -   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
>> gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 2);
>> gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 2);
>> } else {
>> -   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
>> gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 3);
>> gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 3);
>> }
>
> Won't this hunk break manual switching until the later patches land?
> Seems like you might want to break this out as a separate patch later
> in the series.

Also. I'm not sure how the gmux works, but this might break ddc on
external displays that are muxed.

Alex

>
> Alex
>
>
>> @@ -288,6 +286,18 @@ static int gmux_switchto(enum vga_switcheroo_client_id 
>> id)
>> return 0;
>>  }
>>
>> +static int gmux_switch_ddc(enum vga_switcheroo_client_id id)
>> +{
>> +   pr_debug("Switching gmux DDC to %d\n", id);
>> +
>> +   if (id == VGA_SWITCHEROO_IGD)
>> +   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
>> +   else
>> +   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
>> +
>> +   return 0;
>> +}
>> +
>>  static int gmux_set_discrete_state(struct apple_gmux_data *gmux_data,
>>enum vga_switcheroo_state state)
>>  {
>> @@ -588,6 +598,13 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
>> pnp_device_id *id)
>> gmux_data->gpe = -1;
>> }
>>
>> +   /*
>> +* The gmux in pre-retina MacBook Pros can switch DDC separately
>> +* from the other pins of the outputs. It's distinguishable from
>> +* the gmux in retinas by being non-indexed.
>> +*/
>> +   if (!gmux_data->indexed)
>> +   gmux_handler.switch_ddc = gmux_switch_ddc;
>> if (vga_switcheroo_register_handler(_handler)) {
>> ret = -ENODEV;
>> goto err_register_handler;
>> --
>> 1.8.5.2 (Apple Git-48)
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 2/6] apple-gmux: Add switch_ddc support

2015-10-12 Thread Alex Deucher

On Fri, Aug 14, 2015 at 12:18 PM, Lukas Wunner  wrote:
> Originally by Seth Forshee , 2012-10-04:
> The gmux allows muxing the DDC independently from the display, so
> support this functionality. This will allow reading the EDID for the
> inactive GPU, fixing issues with machines that either don't have a
> VBT or have invalid mode data in the VBT.
>
> Modified by Lukas Wunner , 2015-10-07:
> Advertise ->switch_ddc handler callback only on the pre-retina
> Macbook Pro. The retina uses eDP and its mux is incapable of
> switching the AUX channel separately from the main link.
> It's an NXP CBTL06142 (alternate parts: TI HD3SS212,
> Pericom PPI3VDP12412).
>
> Sources:
> http://www.electronicproducts.com/-whatsinside_text-145.aspx
> 
> http://slideshare.net/jjwu6266/apple-2012-wwdc-apple-macbook-pro-with-retina-display
> 
> http://www.techrepublic.com/blog/cracking-open/teardown-shows-retina-macbook-pro-is-nearly-impossible-to-upgrade-difficult-to-work-on/
>
> Datasheets:
> http://www.nxp.com/documents/data_sheet/CBTL06141.pdf
> http://www.ti.com/lit/ds/symlink/hd3ss212.pdf
> https://www.pericom.com/assets/Datasheets/PI3VDP12412.pdf
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
> Tested-by: Lukas Wunner 
> [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
>
> Cc: Seth Forshee 
> Signed-off-by: Lukas Wunner 
> ---
>  drivers/platform/x86/apple-gmux.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/apple-gmux.c 
> b/drivers/platform/x86/apple-gmux.c
> index 0dec3f5..78997b7 100644
> --- a/drivers/platform/x86/apple-gmux.c
> +++ b/drivers/platform/x86/apple-gmux.c
> @@ -276,11 +276,9 @@ static const struct backlight_ops gmux_bl_ops = {
>  static int gmux_switchto(enum vga_switcheroo_client_id id)
>  {
> if (id == VGA_SWITCHEROO_IGD) {
> -   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
> gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 2);
> gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 2);
> } else {
> -   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
> gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 3);
> gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 3);
> }

Won't this hunk break manual switching until the later patches land?
Seems like you might want to break this out as a separate patch later
in the series.

Alex


> @@ -288,6 +286,18 @@ static int gmux_switchto(enum vga_switcheroo_client_id 
> id)
> return 0;
>  }
>
> +static int gmux_switch_ddc(enum vga_switcheroo_client_id id)
> +{
> +   pr_debug("Switching gmux DDC to %d\n", id);
> +
> +   if (id == VGA_SWITCHEROO_IGD)
> +   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
> +   else
> +   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
> +
> +   return 0;
> +}
> +
>  static int gmux_set_discrete_state(struct apple_gmux_data *gmux_data,
>enum vga_switcheroo_state state)
>  {
> @@ -588,6 +598,13 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
> pnp_device_id *id)
> gmux_data->gpe = -1;
> }
>
> +   /*
> +* The gmux in pre-retina MacBook Pros can switch DDC separately
> +* from the other pins of the outputs. It's distinguishable from
> +* the gmux in retinas by being non-indexed.
> +*/
> +   if (!gmux_data->indexed)
> +   gmux_handler.switch_ddc = gmux_switch_ddc;
> if (vga_switcheroo_register_handler(_handler)) {
> ret = -ENODEV;
> goto err_register_handler;
> --
> 1.8.5.2 (Apple Git-48)
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2

2015-10-12 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #26 from Barto  ---
(In reply to Barto from comment #25)
> to be sure I am currently trying to compile LLVM 3.7.0 with the classic way
> ( ./configure ) by reverting this patch in order to allow this :
> 
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150629/284970.html
> 
> and I will see if the bug is still here when libLLVM.so.3.7 is building with
> ./configure and not CMAKE

I tried : the bug is still here, even with an autoconf build,

so the bug is elsewhere, maybe in mesa source code ( bad initialization of llvm
3.7.0 lib ) , or in LLVM 3.7.0,

could be also in glibc 2.22-3 but I doubt,

here is a new backtrace of the tunnel program ( from mesa-demos ), here I use a
debug version of glibc 2.22-3 :

(gdb) thread apply all bt full

Thread 2 (Thread 0x7fffee4c6700 (LWP 11292)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1  0x722fe04a in ?? () from /usr/lib/xorg/modules/dri/r600_dri.so
No symbol table info available.
#2  0x722fd787 in ?? () from /usr/lib/xorg/modules/dri/r600_dri.so
No symbol table info available.
#3  0x73d74464 in start_thread (arg=0x7fffee4c6700) at
pthread_create.c:334
__res = 
pd = 0x7fffee4c6700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737191372544,
-3511726595263618993, 0, 140737488345551, 3, 
140737488348064, 3511694852238942287, 3511735595139276879},
mask_was_saved = 0}}, priv = {pad = {0x0, 
  0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype =
0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#4  0x7704d13d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.

Thread 1 (Thread 0x77f9a740 (LWP 11286)):
#0  0x7fffedaa55eb in ?? ()
No symbol table info available.
#1  0x0076a320 in ?? ()
No symbol table info available.
#2  0x7fffd630 in ?? ()
No symbol table info available.
#3  0x0007 in ?? ()
No symbol table info available.
---Type  to continue, or q  to quit---
#4  0x in ?? ()
No symbol table info available.

it would be interesting to put a breakpoint in mesa 11.0.3 source code, a
location where LLVM 3.7.0 functions are used or loaded, my purpose is to know
if the bug occurs before or after mesa tries to use LLVM functions, and if it's
a problem related to glibc or gcc libs, but I don't know where I should put
this breakpoint,

another test would be to create a simple program test, for example a simple
test.c program who loads LLVM 3.7.0 lib and try to run a simple LLVM function,
the idea is to check if LLVM 3.7.0 lib can be loaded and used without a crash

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

[Bug 91896] AMDGPU Fiji: only getting 1080i on DP

2015-10-12 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #17 from Ernst SjÃ¶strand  ---
Works! There's another default value 54000 on line 676, but maybe that's needed
for "current_dispclk"?

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

[PATCH v2 0/3] drm: fix i2c adapter device driver user counter

2015-10-12 Thread Vladimir Zapolskiy

David, Russell,

ping.

On 23.09.2015 00:46, Vladimir Zapolskiy wrote:
> of_find_i2c_adapter_by_node() call requires quite often missing
> put_device(), and i2c_put_adapter() releases a device locked by
> i2c_get_adapter() only.
> 
> Below is a common error reproduction scenario as a result of the
> misusage described above (this is run on iMX6 platform with
> HDMI and I2C bus drivers compiled as kernel modules for clearness):
> 
> root at mx6q:~# lsmod | grep i2c
> i2c_imx15348  0
> root at mx6q:~# lsmod | grep dw_hdmi_imx
> dw_hdmi_imx 3567  0
> dw_hdmi15850  1 dw_hdmi_imx
> imxdrm  8610  3 dw_hdmi_imx,imx_ipuv3_crtc,imx_ldb
> root at mx6q:~# rmmod dw_hdmi_imx
> root at mx6q:~# lsmod | grep i2c
> i2c_imx15348  -1
> 
>  ^
> 
> root at mx6q:~# rmmod i2c_imx
> rmmod: ERROR: Module i2c_imx is in use
> 
> To fix existing users of these interfaces use of_get_i2c_adapter_by_node()
> interface, which is similar to i2c_get_adapter() in sense that an I2C bus
> device driver found and locked by a user can be correctly unlocked by
> i2c_put_adapter() call.
> 
> Changes from v1 to v2:
> - none, this series is a straightforward bugfix, v1 was a blend of
>   I2C core changes, bugfixes and improvements
> 
> The change is based on dri/drm-next.
> 
> Vladimir Zapolskiy (3):
>   drm: dw_hdmi: use of_get_i2c_adapter_by_node interface
>   drm: tilcdc: use of_get_i2c_adapter_by_node interface
>   drm: tegra: use of_get_i2c_adapter_by_node interface
> 
>  drivers/gpu/drm/bridge/dw_hdmi.c   | 14 +-
>  drivers/gpu/drm/tegra/output.c | 23 ---
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |  6 ++
>  3 files changed, 23 insertions(+), 20 deletions(-)
> 

--
With best wishes,
Vladimir

[PATCH v2 1/3] drm: dw_hdmi: use of_get_i2c_adapter_by_node interface

2015-10-12 Thread Vladimir Zapolskiy

David, Russel,

ping.

On 23.09.2015 00:48, Vladimir Zapolskiy wrote:
> This change is needed to properly lock I2C bus driver, which serves DDC.
> 
> The change fixes an overflow over zero of I2C bus driver user counter:
> 
> root at mx6q:~# lsmod | grep i2c
> i2c_imx15348  0
> root at mx6q:~# lsmod | grep dw_hdmi_imx
> dw_hdmi_imx 3567  0
> dw_hdmi15850  1 dw_hdmi_imx
> imxdrm  8610  3 dw_hdmi_imx,imx_ipuv3_crtc,imx_ldb
> root at mx6q:~# rmmod dw_hdmi_imx
> root at mx6q:~# lsmod | grep i2c
> i2c_imx15348  -1
> 
>  ^
> 
> root at mx6q:~# rmmod i2c_imx
> rmmod: ERROR: Module i2c_imx is in use
> 
> Note that prior to this change put_device() coupled with
> of_find_i2c_adapter_by_node() was missing on error path of
> dw_hdmi_bind(), added i2c_put_adapter() there along with the change.
> 
> Signed-off-by: Vladimir Zapolskiy 
> Cc: Russell King 
> Cc: Philipp Zabel 
> Cc: Andy Yan 

--
With best wishes,
Vladimir

[PATCH v7 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

2015-10-12 Thread Krzysztof Kozlowski

On 12.10.2015 13:29, Yakir Yang wrote:
> Both hsync/vsync polarity and interlace mode can be parsed from
> drm display mode, and dynamic_range and ycbcr_coeff can be judge
> by the video code.
> 
> But presumably Exynos still relies on the DT properties, so take
> good use of mode_fixup() in to achieve the compatibility hacks.
> 
> Signed-off-by: Yakir Yang 
> ---
> *just add a note that this is v7 of only fifth patch.*
> 
> Changes in v7:
> - Back to use the of_property_read_bool() interfacs to provoid backward
>   compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
>   to avoid -EOVERFLOW error (Krzysztof)
> 
> Changes in v6: None
> Changes in v5:
> - Switch video timing type to "u32", so driver could use 
> "of_property_read_u32"
>   to get the backword timing values. Krzysztof suggest me that driver could 
> use
>   the "of_property_read_bool" to get backword timing values, but that 
> interfacs
>   would modify the original drm_display_mode timing directly (whether those
>   properties exists or not).
> 
> Changes in v4:
> - Provide backword compatibility with samsung. (Krzysztof)
> 
> Changes in v3:
> - Dynamic parse video timing info from struct drm_display_mode and
>   struct drm_display_info. (Thierry)
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 
> +
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   2 +-
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
>  3 files changed, 103 insertions(+), 61 deletions(-)
> 

Looks good and backward compatible to me:
Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

[PATCH 4/9] ALSA: hda - Spell vga_switcheroo consistently

2015-10-12 Thread Lukas Wunner

Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.

vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.

Signed-off-by: Lukas Wunner 
Reviewed-by: Takashi Iwai 
---
 sound/pci/hda/hda_controller.h |  2 +-
 sound/pci/hda/hda_intel.c  | 12 ++--
 sound/pci/hda/hda_intel.h  |  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/sound/pci/hda/hda_controller.h b/sound/pci/hda/hda_controller.h
index 314105c..7b635d6 100644
--- a/sound/pci/hda/hda_controller.h
+++ b/sound/pci/hda/hda_controller.h
@@ -153,7 +153,7 @@ struct azx {
unsigned int snoop:1;
unsigned int align_buffer_size:1;
unsigned int region_requested:1;
-   unsigned int disabled:1; /* disabled by VGA-switcher */
+   unsigned int disabled:1; /* disabled by vga_switcheroo */

 #ifdef CONFIG_SND_HDA_DSP_LOADER
struct azx_dev saved_azx_dev;
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index e819013..45233731 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -337,7 +337,7 @@ enum {
 AZX_DCAPS_4K_BDLE_BOUNDARY | AZX_DCAPS_SNOOP_OFF)

 /*
- * VGA-switcher support
+ * vga_switcheroo support
  */
 #ifdef SUPPORT_VGA_SWITCHEROO
 #define use_vga_switcheroo(chip)   ((chip)->use_vga_switcheroo)
@@ -1076,12 +1076,12 @@ static void azx_vs_set_state(struct pci_dev *pci,
}
}
} else {
-   dev_info(chip->card->dev, "%s via VGA-switcheroo\n",
+   dev_info(chip->card->dev, "%s via vga_switcheroo\n",
 disabled ? "Disabling" : "Enabling");
if (disabled) {
pm_runtime_put_sync_suspend(card->dev);
azx_suspend(card->dev);
-   /* when we get suspended by vga switcheroo we end up in 
D3cold,
+   /* when we get suspended by vga_switcheroo we end up in 
D3cold,
 * however we have no ACPI handle, so pci/acpi can't 
put us there,
 * put ourselves there */
pci->current_state = PCI_D3cold;
@@ -1121,7 +1121,7 @@ static void init_vga_switcheroo(struct azx *chip)
struct pci_dev *p = get_bound_vga(chip->pci);
if (p) {
dev_info(chip->card->dev,
-"Handle VGA-switcheroo audio client\n");
+"Handle vga_switcheroo audio client\n");
hda->use_vga_switcheroo = 1;
pci_dev_put(p);
}
@@ -1232,7 +1232,7 @@ static int azx_dev_free(struct snd_device *device)

 #ifdef SUPPORT_VGA_SWITCHEROO
 /*
- * Check of disabled HDMI controller by vga-switcheroo
+ * Check of disabled HDMI controller by vga_switcheroo
  */
 static struct pci_dev *get_bound_vga(struct pci_dev *pci)
 {
@@ -1917,7 +1917,7 @@ static int azx_probe(struct pci_dev *pci,

err = register_vga_switcheroo(chip);
if (err < 0) {
-   dev_err(card->dev, "Error registering VGA-switcheroo client\n");
+   dev_err(card->dev, "Error registering vga_switcheroo client\n");
goto out_free;
}

diff --git a/sound/pci/hda/hda_intel.h b/sound/pci/hda/hda_intel.h
index 354f0bb..ff0c4d6 100644
--- a/sound/pci/hda/hda_intel.h
+++ b/sound/pci/hda/hda_intel.h
@@ -35,7 +35,7 @@ struct hda_intel {
unsigned int irq_pending_warned:1;
unsigned int probe_continued:1;

-   /* VGA-switcheroo setup */
+   /* vga_switcheroo setup */
unsigned int use_vga_switcheroo:1;
unsigned int vga_switcheroo_registered:1;
unsigned int init_failed:1; /* delayed init failed */
-- 
1.8.5.2 (Apple Git-48)

[PATCH 3/9] vga_switcheroo: Use enum vga_switcheroo_client_id instead of int

2015-10-12 Thread Lukas Wunner

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/vga/vga_switcheroo.c | 17 ++---
 include/linux/vga_switcheroo.h   |  6 +++---
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 9896305..af0d372 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -102,7 +102,7 @@ struct vga_switcheroo_client {
struct fb_info *fb_info;
enum vga_switcheroo_state pwr_state;
const struct vga_switcheroo_client_ops *ops;
-   int id;
+   enum vga_switcheroo_client_id id;
bool active;
bool driver_power_control;
struct list_head list;
@@ -233,7 +233,8 @@ EXPORT_SYMBOL(vga_switcheroo_unregister_handler);

 static int register_client(struct pci_dev *pdev,
   const struct vga_switcheroo_client_ops *ops,
-  int id, bool active, bool driver_power_control)
+  enum vga_switcheroo_client_id id, bool active,
+  bool driver_power_control)
 {
struct vga_switcheroo_client *client;

@@ -288,7 +289,7 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
  * vga_switcheroo_register_audio_client - register audio client
  * @pdev: client pci device
  * @ops: client callbacks
- * @id: client identifier, see enum vga_switcheroo_client_id
+ * @id: client identifier
  *
  * Register audio client (audio device on a GPU). The power state of the
  * client is assumed to be ON.
@@ -297,7 +298,7 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
  */
 int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
 const struct vga_switcheroo_client_ops 
*ops,
-int id)
+enum vga_switcheroo_client_id id)
 {
return register_client(pdev, ops, id | ID_BIT_AUDIO, false, false);
 }
@@ -315,7 +316,8 @@ find_client_from_pci(struct list_head *head, struct pci_dev 
*pdev)
 }

 static struct vga_switcheroo_client *
-find_client_from_id(struct list_head *head, int client_id)
+find_client_from_id(struct list_head *head,
+   enum vga_switcheroo_client_id client_id)
 {
struct vga_switcheroo_client *client;

@@ -497,7 +499,8 @@ static int vga_switchoff(struct vga_switcheroo_client 
*client)
return 0;
 }

-static void set_audio_state(int id, enum vga_switcheroo_state state)
+static void set_audio_state(enum vga_switcheroo_client_id id,
+   enum vga_switcheroo_state state)
 {
struct vga_switcheroo_client *client;

@@ -584,7 +587,7 @@ vga_switcheroo_debugfs_write(struct file *filp, const char 
__user *ubuf,
int ret;
bool delay = false, can_switch;
bool just_mux = false;
-   int client_id = VGA_SWITCHEROO_UNKNOWN_ID;
+   enum vga_switcheroo_client_id client_id = VGA_SWITCHEROO_UNKNOWN_ID;
struct vga_switcheroo_client *client = NULL;

if (cnt > 63)
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index 88909a8..c557511 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -100,7 +100,7 @@ struct vga_switcheroo_handler {
int (*switchto)(enum vga_switcheroo_client_id id);
int (*power_state)(enum vga_switcheroo_client_id id,
   enum vga_switcheroo_state state);
-   int (*get_client_id)(struct pci_dev *pdev);
+   enum vga_switcheroo_client_id (*get_client_id)(struct pci_dev *pdev);
 };

 /**
@@ -132,7 +132,7 @@ int vga_switcheroo_register_client(struct pci_dev *dev,
   bool driver_power_control);
 int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
 const struct vga_switcheroo_client_ops 
*ops,
-int id);
+enum vga_switcheroo_client_id id);

 void vga_switcheroo_client_fb_set(struct pci_dev *dev,
  struct fb_info *info);
@@ -158,7 +158,7 @@ static inline void vga_switcheroo_client_fb_set(struct 
pci_dev *dev, struct fb_i
 static inline int vga_switcheroo_register_handler(struct 
vga_switcheroo_handler *handler) { return 0; }
 static inline int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
const struct vga_switcheroo_client_ops *ops,
-   int id) { return 0; }
+   enum vga_switcheroo_client_id id) { return 0; }
 static inline void vga_switcheroo_unregister_handler(void) {}
 static inline int vga_switcheroo_process_delayed_switch(void) { return 0; }
 static inline enum vga_switcheroo_state vga_switcheroo_get_client_state(struct 
pci_dev *dev) { return VGA_SWITCHEROO_ON; }
-- 
1.8.5.2 (Apple Git-48)

[PATCH 2/9] vga_switcheroo: Use VGA_SWITCHEROO_UNKNOWN_ID instead of -1

2015-10-12 Thread Lukas Wunner

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/vga/vga_switcheroo.c | 17 +
 include/linux/vga_switcheroo.h   |  4 
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index a7870d2..9896305 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -84,9 +84,9 @@
  * @fb_info: framebuffer to which console is remapped on switching
  * @pwr_state: current power state
  * @ops: client callbacks
- * @id: client identifier, see enum vga_switcheroo_client_id.
- * Determining the id requires the handler, so GPUs are initially
- * assigned -1 and later given their true id in vga_switcheroo_enable()
+ * @id: client identifier. Determining the id requires the handler,
+ * so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
+ * and later given their true id in vga_switcheroo_enable()
  * @active: whether the outputs are currently switched to this client
  * @driver_power_control: whether power state is controlled by the driver's
  * runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
@@ -145,7 +145,8 @@ struct vgasr_priv {

 #define ID_BIT_AUDIO   0x100
 #define client_is_audio(c) ((c)->id & ID_BIT_AUDIO)
-#define client_is_vga(c)   ((c)->id == -1 || !client_is_audio(c))
+#define client_is_vga(c)   ((c)->id == VGA_SWITCHEROO_UNKNOWN_ID || \
+!client_is_audio(c))
 #define client_id(c)   ((c)->id & ~ID_BIT_AUDIO)

 static int vga_switcheroo_debugfs_init(struct vgasr_priv *priv);
@@ -173,7 +174,7 @@ static void vga_switcheroo_enable(void)
vgasr_priv.handler->init();

list_for_each_entry(client, _priv.clients, list) {
-   if (client->id != -1)
+   if (client->id != VGA_SWITCHEROO_UNKNOWN_ID)
continue;
ret = vgasr_priv.handler->get_client_id(client->pdev);
if (ret < 0)
@@ -277,7 +278,7 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
   const struct vga_switcheroo_client_ops *ops,
   bool driver_power_control)
 {
-   return register_client(pdev, ops, -1,
+   return register_client(pdev, ops, VGA_SWITCHEROO_UNKNOWN_ID,
   pdev == vga_default_device(),
   driver_power_control);
 }
@@ -583,7 +584,7 @@ vga_switcheroo_debugfs_write(struct file *filp, const char 
__user *ubuf,
int ret;
bool delay = false, can_switch;
bool just_mux = false;
-   int client_id = -1;
+   int client_id = VGA_SWITCHEROO_UNKNOWN_ID;
struct vga_switcheroo_client *client = NULL;

if (cnt > 63)
@@ -652,7 +653,7 @@ vga_switcheroo_debugfs_write(struct file *filp, const char 
__user *ubuf,
client_id = VGA_SWITCHEROO_DIS;
}

-   if (client_id == -1)
+   if (client_id == VGA_SWITCHEROO_UNKNOWN_ID)
goto out;
client = find_client_from_id(_priv.clients, client_id);
if (!client)
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index e636617..88909a8 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -59,6 +59,9 @@ enum vga_switcheroo_state {

 /**
  * enum vga_switcheroo_client_id - client identifier
+ * @VGA_SWITCHEROO_UNKNOWN_ID: initial identifier assigned to vga clients.
+ * Determining the id requires the handler, so GPUs are given their
+ * true id in a delayed fashion in vga_switcheroo_enable()
  * @VGA_SWITCHEROO_IGD: integrated graphics device
  * @VGA_SWITCHEROO_DIS: discrete graphics device
  * @VGA_SWITCHEROO_MAX_CLIENTS: currently no more than two GPUs are supported
@@ -66,6 +69,7 @@ enum vga_switcheroo_state {
  * Client identifier. Audio clients use the same identifier & 0x100.
  */
 enum vga_switcheroo_client_id {
+   VGA_SWITCHEROO_UNKNOWN_ID = -1,
VGA_SWITCHEROO_IGD,
VGA_SWITCHEROO_DIS,
VGA_SWITCHEROO_MAX_CLIENTS,
-- 
1.8.5.2 (Apple Git-48)

[PATCH 1/9] vga_switcheroo: Use enum vga_switcheroo_state instead of int

2015-10-12 Thread Lukas Wunner

Signed-off-by: Lukas Wunner 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/vga/vga_switcheroo.c | 6 +++---
 include/linux/vga_switcheroo.h   | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 1acbe20..a7870d2 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -100,7 +100,7 @@
 struct vga_switcheroo_client {
struct pci_dev *pdev;
struct fb_info *fb_info;
-   int pwr_state;
+   enum vga_switcheroo_state pwr_state;
const struct vga_switcheroo_client_ops *ops;
int id;
bool active;
@@ -344,7 +344,7 @@ find_active_client(struct list_head *head)
  *
  * Return: Power state.
  */
-int vga_switcheroo_get_client_state(struct pci_dev *pdev)
+enum vga_switcheroo_state vga_switcheroo_get_client_state(struct pci_dev *pdev)
 {
struct vga_switcheroo_client *client;
enum vga_switcheroo_state ret;
@@ -496,7 +496,7 @@ static int vga_switchoff(struct vga_switcheroo_client 
*client)
return 0;
 }

-static void set_audio_state(int id, int state)
+static void set_audio_state(int id, enum vga_switcheroo_state state)
 {
struct vga_switcheroo_client *client;

diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index 3764991..e636617 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -138,7 +138,7 @@ void vga_switcheroo_unregister_handler(void);

 int vga_switcheroo_process_delayed_switch(void);

-int vga_switcheroo_get_client_state(struct pci_dev *dev);
+enum vga_switcheroo_state vga_switcheroo_get_client_state(struct pci_dev *dev);

 void vga_switcheroo_set_dynamic_switch(struct pci_dev *pdev, enum 
vga_switcheroo_state dynamic);

@@ -157,7 +157,7 @@ static inline int 
vga_switcheroo_register_audio_client(struct pci_dev *pdev,
int id) { return 0; }
 static inline void vga_switcheroo_unregister_handler(void) {}
 static inline int vga_switcheroo_process_delayed_switch(void) { return 0; }
-static inline int vga_switcheroo_get_client_state(struct pci_dev *dev) { 
return VGA_SWITCHEROO_ON; }
+static inline enum vga_switcheroo_state vga_switcheroo_get_client_state(struct 
pci_dev *dev) { return VGA_SWITCHEROO_ON; }

 static inline void vga_switcheroo_set_dynamic_switch(struct pci_dev *pdev, 
enum vga_switcheroo_state dynamic) {}

-- 
1.8.5.2 (Apple Git-48)

[PATCH v7 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

2015-10-12 Thread Yakir Yang



On 10/12/2015 02:54 PM, Krzysztof Kozlowski wrote:
> On 12.10.2015 13:29, Yakir Yang wrote:
>> Both hsync/vsync polarity and interlace mode can be parsed from
>> drm display mode, and dynamic_range and ycbcr_coeff can be judge
>> by the video code.
>>
>> But presumably Exynos still relies on the DT properties, so take
>> good use of mode_fixup() in to achieve the compatibility hacks.
>>
>> Signed-off-by: Yakir Yang 
>> ---
>> *just add a note that this is v7 of only fifth patch.*
>>
>> Changes in v7:
>> - Back to use the of_property_read_bool() interfacs to provoid backward
>>compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
>>to avoid -EOVERFLOW error (Krzysztof)
>>
>> Changes in v6: None
>> Changes in v5:
>> - Switch video timing type to "u32", so driver could use 
>> "of_property_read_u32"
>>to get the backword timing values. Krzysztof suggest me that driver could 
>> use
>>the "of_property_read_bool" to get backword timing values, but that 
>> interfacs
>>would modify the original drm_display_mode timing directly (whether those
>>properties exists or not).
>>
>> Changes in v4:
>> - Provide backword compatibility with samsung. (Krzysztof)
>>
>> Changes in v3:
>> - Dynamic parse video timing info from struct drm_display_mode and
>>struct drm_display_info. (Thierry)
>>
>> Changes in v2: None
>>
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 
>> +
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   2 +-
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
>>   3 files changed, 103 insertions(+), 61 deletions(-)
>>
> Looks good and backward compatible to me:
> Reviewed-by: Krzysztof Kozlowski 

Thanks,

- Yakir

> Best regards,
> Krzysztof
>
>
>
>

[PATCH RFC 0/5] Re: drm/doc: Rename docbook to gpu.tmpl

2015-10-12 Thread Lukas Wunner

This series shows what drm.tmpl would look like if renamed to gpu.tmpl
and amended by the vga_switcheroo documentation. The DocBook would thus
become the "Linux GPU Driver Developer's Guide", covering not only DRM
but also other components in drivers/gpu/.

There are two unsorted lists in the vga_switcheroo documentation which
for optimal rendering require markdown support. One may either apply
the series to drm-next (on top of the markdown patches), or to
drm-intel-nightly (which already has the markdown patches).

The series is also available on GitHub (the commits required for
markdown are apparent from this branch as it's based on drm-next):
https://github.com/l1k/linux/commits/gpu_docs

Best regards,

Lukas


Daniel Vetter (1):
  drm/doc: Rename docbook to gpu.tmpl

Lukas Wunner (4):
  drm/doc: Remove TODO about drm_vblank_pre/post_modeset()
  gpu/doc: Fix up remaining occurrences of old document title
  gpu/doc: Add vga_switcheroo documentation
  gpu/doc: Convert to markdown harder

 Documentation/DocBook/Makefile |4 +-
 Documentation/DocBook/drm.tmpl | 4191 ---
 Documentation/DocBook/gpu.tmpl | 4257 
 include/drm/drm_vma_manager.h  |2 +-
 4 files changed, 4260 insertions(+), 4194 deletions(-)
 delete mode 100644 Documentation/DocBook/drm.tmpl
 create mode 100644 Documentation/DocBook/gpu.tmpl

-- 
1.8.5.2 (Apple Git-48)

[PATCH v3 6/6] drm/radeon: Switch DDC when reading the EDID

2015-10-12 Thread Alex Deucher

On Thu, Oct 8, 2015 at 10:53 AM, Lukas Wunner  wrote:
> Hi Alex,
>
> On Wed, Oct 07, 2015 at 11:14:43PM -0400, Alex Deucher wrote:
>> On Sat, Sep 12, 2015 at 3:44 AM, Lukas Wunner  wrote:
>> > The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
>> > to switch the panel between its two GPUs. The panel mode in VBIOS
>> > is notoriously bogus on these machines.
>> >
>> > Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS.
>> > This allows us to retrieve the EDID if the outputs are currently
>> > muxed to the integrated GPU by temporarily switching the panel's
>> > DDC lines to the discrete GPU.
>> >
>> > This only enables EDID probing on the pre-retina MBP (2008 - 2013).
>> > The retina MBP (2012 - present) uses eDP and gmux is apparently not
>> > capable of switching AUX separately from the main link on these models.
>> > This will be addressed in later patches.
>> >
>> > List of pre-retina MBPs with dual GPUs, one of them AMD:
>> > [MBP  8,2 2011  intel SNB + amd turks pre-retina  15"]
>> > [MBP  8,3 2011  intel SNB + amd turks pre-retina  17"]
>> >
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
>> > Tested-by: William Brown 
>> > [MBP  8,2 2011  intel SNB + amd turks pre-retina  15"]
>> >
>> > Signed-off-by: Lukas Wunner 
>>
>> I'm not opposed to this series, but I have a few questions.
>>
>> 1.  Has any of this been tested on non-Apple hybrid laptops to make
>> sure nothing has regressed?  I think it would be good to verify that
>> since there are more of them in the wild.
>
> It hasn't been tested on such a machine because I don't have one and
> don't know anyone who has one.
>
> However I would be surprised if the series broke anything on non-Apple
> laptops since apple-gmux is the only handler declaring a ->switch_ddc
> callback. If that callback is not defined, the behaviour should be
> identical to just calling drm_get_edid().

Ah, I missed that part.  There is an ATPX method to switch ddc
separately from the encoder data path.  That could probably be hooked
up as well at some point if someone wants to test it.

>
> (With the only exception that EDID reads are serialized on LVDS connectors
> due to the locking in vga_switcheroo. And that should be irrelevant since
> laptops usually have only *one* LVDS panel.)
>
>
>> 2.  This only does the ddc switching for LVDS.  Newer systems almost
>> certainly use DP (either eDP or DP to LVDS bridges).  What about those
>> systems?
>
> As noted in the commit message above, the *retina* MacBook Pro uses eDP
> instead of LVDS and is not capable of switching AUX separately from the
> main link. I've gotten this to work by proxying the AUX communication
> via the currently active GPU, but the patches for this are still in a
> very experimental state. They will be submitted in a future series.
>
> The drivers will then be amended to call drm_get_edid_switcheroo()
> for eDP connectors, and drm_get_edid_switcheroo() will be amended
> by the proxying code.
>
> There will probably also be separate proxying-enabled helpers for
> drm_dp_dpcd_read() and _write() which the drivers need to call for
> eDP connectors (right now the proxying code is hacked directly into
> those two functions).


OK.

>
>
>> 3.  Most muxed hybrid laptops also mux external displays connectors as
>> well (VGA, DVI, HDMI, DP, etc.).  Do you have any plans to extend this
>> to those cases?
>
> As far as the MacBook Pro is concerned, only the earliest two generations
> support this (MacBookPro5 2008/09 with dual Nvidia GPUs and MacBookPro6
> 2010 with Intel/Nvidia). They have a single external switchable DP port.
>
> I was thinking about hardcoding the DMIs of these few laptops in the
> drivers and call drm_get_edid_switcheroo() for the DP port. But this
> is not a high priority item. I don't have a clear plan yet.
>

OK.

>
>> 4. Some desktop environments (GNOME IIRC, but possibly KDE as well)
>> rely on the fact that ddc doesn't work on one of the GPUs when it's
>> not selected.  They don't know how to deal with muxes and can't deal
>> with the same port showing up as connected on two GPUs.  I suspect
>> this patch set may break that.  radeon has always been able to report
>> the panel information on hybrid laptops even when the mux is not
>> switched since the info is also stored in the vbios.  At the behest of
>> those desktop environments there is actually code in the driver to not
>> report the edid for the unselected gpu on hybrid laptops even though
>> we could report it.  I suspect this patch may break that.
>
> I assume you're referring to:
> http://lists.freedesktop.org/archives/dri-devel/2014-November/072032.html
> https://bugzilla.opensuse.org/show_bug.cgi?id=904417
>
> After perusing the bug report at length I'm under the impression that
> it's not GNOME getting confused by two LVDS outputs, rather this seems
> like a runtime pm issue since radeon.runpm=0 seemed to fix it.
>
> Maybe gdm was triggering an ioctl() that

[PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-12 Thread Kamil Debski

Hi,

On 12 October 2015 at 14:39, Hans Verkuil  wrote:
> On 10/12/2015 02:33 PM, Kamil Debski wrote:
>> Hi,
>>
>> On 12 October 2015 at 12:50, Hans Verkuil  wrote:
>>> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
 On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
> +if (status & CEC_STATUS_TX_DONE) {
> +if (status & CEC_STATUS_TX_ERROR) {
> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
> +cec->tx = STATE_ERROR;
> +} else {
> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
> +cec->tx = STATE_DONE;
> +}
> +s5p_clr_pending_tx(cec);
> +}

 Your CEC implementation seems to be written around the idea that there
 are only two possible outcomes from a CEC message - "done" and "error",
 which get translated to:
>>>
>>> This code is for the Samsung exynos CEC implementation. Marek, is this all
>>> that the exynos CEC hardware returns?
>>
>> The possible status values that are implemented in the CEC framework
>> are following:
>>
>> +/* cec status field */
>> +#define CEC_TX_STATUS_OK   (0)
>> +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
>> +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
>> +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
>> +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
>> +#define CEC_RX_STATUS_READY(0)
>>
>> The only two ones I could match with the Exynos CEC module status bits are
>> CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.
>>
>> The status bits in Exynos HW are:
>> - Tx_Error
>> - Tx_Done
>> - Tx_Transferring
>> - Tx_Running
>> - Tx_Bytes_Transferred
>>
>> - Tx_Wait
>> - Tx_Sending_Status_Bit
>> - Tx_Sending_Hdr_Blk
>> - Tx_Sending_Data_Blk
>> - Tx_Latest_Initiator
>>
>> - Tx_Wait_SFT_Succ
>> - Tx_Wait_SFT_New
>> - Tx_Wait_SFT_Retran
>> - Tx_Retrans_Cnt
>> - Tx_ACK_Failed
>
> So are these all intermediate states? And every transfer always ends with 
> Tx_Done or
> Tx_Error state?

Yes, the Exynos CEC module has a pretty low level status indicator.

> It does look that way...
>
> Regards,
>
> Hans
>

Best wishes,
Kamil

[snip]

[Bug 91896] AMDGPU Fiji: only getting 1080i on DP

2015-10-12 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #16 from Alex Deucher  ---
Created attachment 118841
  --> https://bugs.freedesktop.org/attachment.cgi?id=118841=edit
possible fix

Does this patch fix the issue?

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

[PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-12 Thread Hans Verkuil

On 10/12/2015 02:33 PM, Kamil Debski wrote:
> Hi,
> 
> On 12 October 2015 at 12:50, Hans Verkuil  wrote:
>> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
>>> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
 +if (status & CEC_STATUS_TX_DONE) {
 +if (status & CEC_STATUS_TX_ERROR) {
 +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
 +cec->tx = STATE_ERROR;
 +} else {
 +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
 +cec->tx = STATE_DONE;
 +}
 +s5p_clr_pending_tx(cec);
 +}
>>>
>>> Your CEC implementation seems to be written around the idea that there
>>> are only two possible outcomes from a CEC message - "done" and "error",
>>> which get translated to:
>>
>> This code is for the Samsung exynos CEC implementation. Marek, is this all
>> that the exynos CEC hardware returns?
> 
> The possible status values that are implemented in the CEC framework
> are following:
> 
> +/* cec status field */
> +#define CEC_TX_STATUS_OK   (0)
> +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
> +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
> +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
> +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
> +#define CEC_RX_STATUS_READY(0)
> 
> The only two ones I could match with the Exynos CEC module status bits are
> CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.
> 
> The status bits in Exynos HW are:
> - Tx_Error
> - Tx_Done
> - Tx_Transferring
> - Tx_Running
> - Tx_Bytes_Transferred
> 
> - Tx_Wait
> - Tx_Sending_Status_Bit
> - Tx_Sending_Hdr_Blk
> - Tx_Sending_Data_Blk
> - Tx_Latest_Initiator
> 
> - Tx_Wait_SFT_Succ
> - Tx_Wait_SFT_New
> - Tx_Wait_SFT_Retran
> - Tx_Retrans_Cnt
> - Tx_ACK_Failed

So are these all intermediate states? And every transfer always ends with 
Tx_Done or
Tx_Error state?

It does look that way...

Regards,

Hans

> 
>>
>>>
 +case STATE_DONE:
 +cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
 +cec->tx = STATE_IDLE;
 +break;
 +case STATE_ERROR:
 +cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
 +cec->tx = STATE_IDLE;
>>>
>>> "okay" and "retry_timeout".  So, if we have an adapter which can report
>>> (eg) a NACK, we have to report it as the obscure "retry timeout" status?
>>> Why this obscure naming - why can't we have something that uses the
>>> terminology in the spec?
>>>
>>
>> Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC 
>> 7.1.
>> The assumption of the CEC framework is that this is done by the CEC adapter
>> driver, not by the framework. So if after repeated retransmissions there is
>> still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could
>> change this to _MAX_RETRIES_REACHED if you prefer.
>>
>> The CEC_TX_STATUS_ macros were based on what the adv drivers support (except
>> for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework).
>>
>> Regards,
>>
>> Hans
> 
> Best wishes,
> Kamil
>

bcm2835 (Raspberry Pi) KMS driver

2015-10-12 Thread Stephen Warren

On 10/11/2015 06:39 AM, Stefan Wahren wrote:
> Am 09.10.2015 um 23:27 schrieb Eric Anholt:
>> This is a respin of the Raspberry Pi KMS series.  Now that we've got a
>> real clock driver, I can actually set new video modes.  Also in this
>> version, most of the custom DT stuff from before is gone, thanks to
>> finding exynos's platform_driver component matching code (I have sent
>> separate patches to drivers/base to make helpers for doing it).
>>
>> https://github.com/anholt/linux/tree/vc4-kms-squash-2
>
> I want to point out that git format-patch could prepare a nice cover
> letter and usually the changelog should go there.

Well, I guess you could put it there, but that wouldn't remove the need 
to put the changelog in the individual patches too, so that reviewers 
don't have to switch back and forth between different messages just to 
find out what changed in each patch.

+1 on sending the cover letter using git format-patch/send-email 
thoughl; the threading here is a little odd.

[Intel-gfx] 4.2-rc4 kernel warnings on HSW laptop [regression]

2015-10-12 Thread Takashi Iwai

On Mon, 12 Oct 2015 14:29:19 +0200,
Takashi Iwai wrote:
> 
> > > Then a warning when I start powertop:
> > > 
> > >  WARNING: CPU: 1 PID: 1674 at drivers/gpu/drm/drm_atomic.c:889 
> > > drm_atomic_get_property+0x232/0x2b0 [drm]()
> > >  CPU: 1 PID: 1674 Comm: powertop Tainted: GW   
> > > 4.3.0-rc4-test+ #93
> > >  Hardware name: Hewlett-Packard HP ProBook 430 G1/1946, BIOS L73 Ver. 
> > > 08.05 2013/03/15
> > >   a005b289 880059173ca8 81346fa9 
> > >   880059173ce0 81063232 8800372bc028 8800373f3740
> > >   8800372bc000 880062ad37c0 0001 880059173cf0
> > >  Call Trace:
> > >   [] dump_stack+0x4b/0x72
> > >   [] warn_slowpath_common+0x82/0xc0
> > >   [] warn_slowpath_null+0x1a/0x20
> > >   [] drm_atomic_get_property+0x232/0x2b0 [drm]
> > >   [] drm_object_property_get_value+0x6c/0x70 [drm]
> > >   [] dpms_show+0x2f/0x70 [drm]
> > >   [] dev_attr_show+0x20/0x50
> > >   [] sysfs_kf_seq_show+0xbc/0x130
> > >   [] kernfs_seq_show+0x23/0x30
> > >   [] seq_read+0xca/0x360
> > >   [] kernfs_fop_read+0x10a/0x160
> > >   [] __vfs_read+0x28/0xd0
> > >   [] ? security_file_permission+0xa0/0xc0
> > >   [] ? rw_verify_area+0x4f/0xe0
> > >   [] vfs_read+0x83/0x130
> > >   [] SyS_read+0x46/0xa0
> > >   [] ? syscall_return_slowpath+0x50/0x130
> > >   [] entry_SYSCALL_64_fastpath+0x16/0x75
> > > 
> > > 
> > > Both don't look like serious issues, but not sexy to see at each time.
> > 
> > This should be fixed with
> > 
> > commit 621bd0f6982badd6483acb191eb7b6226a578328
> > Author: Daniel Vetter 
> > Date:   Tue Sep 29 09:56:53 2015 +0200
> > 
> > drm: Fix locking for sysfs dpms file
> > 
> > If not please scream.
> 
> OK, I'll give a shot.

This one was confirmed to work.  Feel free to my tested-by tag if you
can still add.
  Tested-by: Takashi Iwai 


thanks,

Takashi

[PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-12 Thread Kamil Debski

Hi,

On 12 October 2015 at 12:50, Hans Verkuil  wrote:
> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
>> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
>>> +if (status & CEC_STATUS_TX_DONE) {
>>> +if (status & CEC_STATUS_TX_ERROR) {
>>> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
>>> +cec->tx = STATE_ERROR;
>>> +} else {
>>> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
>>> +cec->tx = STATE_DONE;
>>> +}
>>> +s5p_clr_pending_tx(cec);
>>> +}
>>
>> Your CEC implementation seems to be written around the idea that there
>> are only two possible outcomes from a CEC message - "done" and "error",
>> which get translated to:
>
> This code is for the Samsung exynos CEC implementation. Marek, is this all
> that the exynos CEC hardware returns?

The possible status values that are implemented in the CEC framework
are following:

+/* cec status field */
+#define CEC_TX_STATUS_OK   (0)
+#define CEC_TX_STATUS_ARB_LOST (1 << 0)
+#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
+#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
+#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
+#define CEC_RX_STATUS_READY(0)

The only two ones I could match with the Exynos CEC module status bits are
CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.

The status bits in Exynos HW are:
- Tx_Error
- Tx_Done
- Tx_Transferring
- Tx_Running
- Tx_Bytes_Transferred

- Tx_Wait
- Tx_Sending_Status_Bit
- Tx_Sending_Hdr_Blk
- Tx_Sending_Data_Blk
- Tx_Latest_Initiator

- Tx_Wait_SFT_Succ
- Tx_Wait_SFT_New
- Tx_Wait_SFT_Retran
- Tx_Retrans_Cnt
- Tx_ACK_Failed

>
>>
>>> +case STATE_DONE:
>>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
>>> +cec->tx = STATE_IDLE;
>>> +break;
>>> +case STATE_ERROR:
>>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
>>> +cec->tx = STATE_IDLE;
>>
>> "okay" and "retry_timeout".  So, if we have an adapter which can report
>> (eg) a NACK, we have to report it as the obscure "retry timeout" status?
>> Why this obscure naming - why can't we have something that uses the
>> terminology in the spec?
>>
>
> Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC 
> 7.1.
> The assumption of the CEC framework is that this is done by the CEC adapter
> driver, not by the framework. So if after repeated retransmissions there is
> still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could
> change this to _MAX_RETRIES_REACHED if you prefer.
>
> The CEC_TX_STATUS_ macros were based on what the adv drivers support (except
> for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework).
>
> Regards,
>
> Hans

Best wishes,
Kamil

[Intel-gfx] 4.2-rc4 kernel warnings on HSW laptop [regression]

2015-10-12 Thread Takashi Iwai

On Mon, 12 Oct 2015 09:04:20 +0200,
Daniel Vetter wrote:
> 
> Another pile of regressions for Jairo to track ...
> 
> On Sat, Oct 10, 2015 at 11:46:29AM +0200, Takashi Iwai wrote:
> > Hi,
> > 
> > I noticed that a HSW laptop gets a few new warnings since 4.2-rc
> > kernels.  One error messages pops at each boot time:
> > 
> >  Console: switching to colour dummy device 80x25
> >  [drm] Replacing VGA console driver
> >  [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> >  [drm] Driver supports precise vblank timestamp query.
> >  vgaarb: device changed decodes: 
> > PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> >  [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't 
> > calculate constants, dotclock = 0!
> 
> There's patches for this one already, but I accidentally applied them for
> -next, not -fixes. They should land for -rc6.

Could you point commit ids?


> > Then a warning when I start powertop:
> > 
> >  WARNING: CPU: 1 PID: 1674 at drivers/gpu/drm/drm_atomic.c:889 
> > drm_atomic_get_property+0x232/0x2b0 [drm]()
> >  CPU: 1 PID: 1674 Comm: powertop Tainted: GW   4.3.0-rc4-test+ 
> > #93
> >  Hardware name: Hewlett-Packard HP ProBook 430 G1/1946, BIOS L73 Ver. 08.05 
> > 2013/03/15
> >   a005b289 880059173ca8 81346fa9 
> >   880059173ce0 81063232 8800372bc028 8800373f3740
> >   8800372bc000 880062ad37c0 0001 880059173cf0
> >  Call Trace:
> >   [] dump_stack+0x4b/0x72
> >   [] warn_slowpath_common+0x82/0xc0
> >   [] warn_slowpath_null+0x1a/0x20
> >   [] drm_atomic_get_property+0x232/0x2b0 [drm]
> >   [] drm_object_property_get_value+0x6c/0x70 [drm]
> >   [] dpms_show+0x2f/0x70 [drm]
> >   [] dev_attr_show+0x20/0x50
> >   [] sysfs_kf_seq_show+0xbc/0x130
> >   [] kernfs_seq_show+0x23/0x30
> >   [] seq_read+0xca/0x360
> >   [] kernfs_fop_read+0x10a/0x160
> >   [] __vfs_read+0x28/0xd0
> >   [] ? security_file_permission+0xa0/0xc0
> >   [] ? rw_verify_area+0x4f/0xe0
> >   [] vfs_read+0x83/0x130
> >   [] SyS_read+0x46/0xa0
> >   [] ? syscall_return_slowpath+0x50/0x130
> >   [] entry_SYSCALL_64_fastpath+0x16/0x75
> > 
> > 
> > Both don't look like serious issues, but not sexy to see at each time.
> 
> This should be fixed with
> 
> commit 621bd0f6982badd6483acb191eb7b6226a578328
> Author: Daniel Vetter 
> Date:   Tue Sep 29 09:56:53 2015 +0200
> 
> drm: Fix locking for sysfs dpms file
> 
> If not please scream.

OK, I'll give a shot.


thanks,

Takashi

[PATCH 2/2] Allocate objects in both video rams

2015-10-12 Thread Frediano Ziglio

If memory is not enough in the default BAR for a type try other BAR
this allow better memory usage and avoid memory allocation failure
if a BAR is quite small and other is quite unused.
---
 qxl/qxl_object.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/qxl/qxl_object.c b/qxl/qxl_object.c
index 5e1d789..220de9a 100644
--- a/qxl/qxl_object.c
+++ b/qxl/qxl_object.c
@@ -58,14 +58,17 @@ void qxl_ttm_placement_from_domain(struct qxl_bo *qbo, u32 
domain, bool pinned)

qbo->placement.placement = qbo->placements;
qbo->placement.busy_placement = qbo->placements;
-   if (domain == QXL_GEM_DOMAIN_VRAM)
+   if (domain == QXL_GEM_DOMAIN_VRAM) {
qbo->placements[c++].flags = TTM_PL_FLAG_CACHED | 
TTM_PL_FLAG_VRAM | pflag;
-   if (domain == QXL_GEM_DOMAIN_SURFACE)
qbo->placements[c++].flags = TTM_PL_FLAG_CACHED | 
TTM_PL_FLAG_PRIV0 | pflag;
-   if (domain == QXL_GEM_DOMAIN_CPU)
+   } else if (domain == QXL_GEM_DOMAIN_SURFACE) {
+   qbo->placements[c++].flags = TTM_PL_FLAG_CACHED | 
TTM_PL_FLAG_PRIV0 | pflag;
+   qbo->placements[c++].flags = TTM_PL_FLAG_CACHED | 
TTM_PL_FLAG_VRAM | pflag;
+   } else if (domain == QXL_GEM_DOMAIN_CPU) {
qbo->placements[c++].flags = TTM_PL_MASK_CACHING | 
TTM_PL_FLAG_SYSTEM | pflag;
-   if (!c)
+   } else {
qbo->placements[c++].flags = TTM_PL_MASK_CACHING | 
TTM_PL_FLAG_SYSTEM;
+   }
qbo->placement.num_placement = c;
qbo->placement.num_busy_placement = c;
for (i = 0; i < c; ++i) {
-- 
2.4.3

[PATCH 1/2] Change the way slot is detected

2015-10-12 Thread Frediano Ziglio

Instead of relaying on surface type use the actual placement.
This allow to have different placement for a single type of
surface.
---
 qxl/qxl_cmd.c | 2 +-
 qxl/qxl_drv.h | 9 -
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/qxl/qxl_cmd.c b/qxl/qxl_cmd.c
index fdc1833..3a1b055 100644
--- a/qxl/qxl_cmd.c
+++ b/qxl/qxl_cmd.c
@@ -511,7 +511,7 @@ int qxl_hw_surface_alloc(struct qxl_device *qdev,
cmd->u.surface_create.height = surf->surf.height;
cmd->u.surface_create.stride = surf->surf.stride;
if (new_mem) {
-   int slot_id = surf->type == QXL_GEM_DOMAIN_VRAM ? 
qdev->main_mem_slot : qdev->surfaces_mem_slot;
+   int slot_id = qxl_bo_get_slot_id(qdev, surf);
struct qxl_memslot *slot = &(qdev->mem_slots[slot_id]);

/* TODO - need to hold one of the locks to read tbo.offset */
diff --git a/qxl/qxl_drv.h b/qxl/qxl_drv.h
index 01a8694..60f0062 100644
--- a/qxl/qxl_drv.h
+++ b/qxl/qxl_drv.h
@@ -365,11 +365,18 @@ qxl_fb_virtual_address(struct qxl_device *qdev, unsigned 
long physical)
return 0;
 }

+static inline int
+qxl_bo_get_slot_id(struct qxl_device *qdev, struct qxl_bo *bo)
+{
+   return ((bo->tbo.cur_placement & TTM_PL_MASK_MEM) == TTM_PL_FLAG_VRAM) ?
+   qdev->main_mem_slot : qdev->surfaces_mem_slot;
+}
+
 static inline uint64_t
 qxl_bo_physical_address(struct qxl_device *qdev, struct qxl_bo *bo,
unsigned long offset)
 {
-   int slot_id = bo->type == QXL_GEM_DOMAIN_VRAM ? qdev->main_mem_slot : 
qdev->surfaces_mem_slot;
+   int slot_id = qxl_bo_get_slot_id(qdev, bo);
struct qxl_memslot *slot = &(qdev->mem_slots[slot_id]);

/* TODO - need to hold one of the locks to read tbo.offset */
-- 
2.4.3

[RFC PATCH 0/2] Try to smartly allocate memory on the two BARs

2015-10-12 Thread Frediano Ziglio

Currently a single type of surface is allocated in a specific BAR.
This also changes from userspace driver to the kernel one.
This way it could happen that allocation are failing even if there are
plenty of space in the other BAR.
For instance this can happen trying to change resolution as the old and
the new virtual screen is supposed to be contained in a single BAR.
The change allows allocation to occur in the BAR not being the default
for a surface type.

The patches prove to be really stable. I tested setting quite small BARs
(one or the oher) or changing default allocation BAR and continued working.
Setting large resolution is working fine while without these patches fails
for not so big BAR sizes.

Frediano Ziglio (2):
  Change the way slot is detected
  Allocate objects in both video rams

 qxl/qxl_cmd.c|  2 +-
 qxl/qxl_drv.h|  9 -
 qxl/qxl_object.c | 11 +++
 3 files changed, 16 insertions(+), 6 deletions(-)

-- 
2.4.3

[PATCH v3 7/7] ARM: bcm2835: Add VC4 to the device tree.

2015-10-12 Thread Eric Anholt

Stefan Wahren  writes:

> Am 09.10.2015 um 23:27 schrieb Eric Anholt:
>> VC4 is the GPU (display and 3D) present on the 2835.
>>
>> Signed-off-by: Eric Anholt 
>> ---
>>
>> v2: Sort by register address, mark HDMI as disabled by default in the
>>  SoC file and enable it from -rpi.
>>
>> v3: Add references to the pixel/HSM clocks for HDMI.  Rename
>>  compatibility strings and clean up node names.
>>
>>   arch/arm/boot/dts/bcm2835-rpi.dtsi |  4 
>>   arch/arm/boot/dts/bcm2835.dtsi | 42 
>> ++
>>   2 files changed, 46 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
>> b/arch/arm/boot/dts/bcm2835-rpi.dtsi
>> index 3572f03..dcaaee2 100644
>> --- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
>> +++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
>> @@ -56,6 +56,10 @@
>>  status = "okay";
>>   };
>>
>> + {
>> +status = "okay";
>> +};
>> +
>>{
>>  status = "okay";
>>  bus-width = <4>;
>> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
>> index 1e61eb7..21e354a9 100644
>> --- a/arch/arm/boot/dts/bcm2835.dtsi
>> +++ b/arch/arm/boot/dts/bcm2835.dtsi
>> @@ -1,4 +1,5 @@
>>   #include 
>> +#include 
>>   #include 
>>   #include "skeleton.dtsi"
>>
>> @@ -149,6 +150,18 @@
>>  status = "disabled";
>>  };
>>
>> +pixelvalve at 7e206000 {
>> +compatible = "brcm,bcm2835-pixelvalve0";
>> +reg = <0x7e206000 0x100>;
>> +interrupts = <2 13>; /* pwa2 */
>
> According to BCM2835-ARM-Peripherals this should be pwa0.
>
> Is it just a typo?
> What does pwa mean?

Just a typo.  I don't know what pwa means, either, it's just a string so
you can search for it in the docs.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151012/ec727731/attachment.sig>

bcm2835 (Raspberry Pi) KMS driver

2015-10-12 Thread Eric Anholt

Stephen Warren  writes:

> On 10/11/2015 06:39 AM, Stefan Wahren wrote:
>> Am 09.10.2015 um 23:27 schrieb Eric Anholt:
>>> This is a respin of the Raspberry Pi KMS series.  Now that we've got a
>>> real clock driver, I can actually set new video modes.  Also in this
>>> version, most of the custom DT stuff from before is gone, thanks to
>>> finding exynos's platform_driver component matching code (I have sent
>>> separate patches to drivers/base to make helpers for doing it).
>>>
>>> https://github.com/anholt/linux/tree/vc4-kms-squash-2
>>
>> I want to point out that git format-patch could prepare a nice cover
>> letter and usually the changelog should go there.
>
> Well, I guess you could put it there, but that wouldn't remove the need 
> to put the changelog in the individual patches too, so that reviewers 
> don't have to switch back and forth between different messages just to 
> find out what changed in each patch.
>
> +1 on sending the cover letter using git format-patch/send-email 
> thoughl; the threading here is a little odd.

I was using git send-email --compose.  I guess I'll play with
format-patch --cover-letter, but it seems odd that threading would be
any different between the two.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151012/1903f176/attachment.sig>

[PATCHv9 06/15] rc: Add HDMI CEC protocol handling

2015-10-12 Thread Hans Verkuil

On 10/06/2015 08:05 PM, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote:
>> From: Kamil Debski 
>>
>> Add handling of remote control events coming from the HDMI CEC bus.
>> This patch includes a new keymap that maps values found in the CEC
>> messages to the keys pressed and released. Also, a new protocol has
>> been added to the core.
>>
>> Signed-off-by: Kamil Debski 
>> Signed-off-by: Hans Verkuil 
> 
> (Added Mauro)
> 
> Hmm, how is rc-cec supposed to be loaded?

Is CONFIG_RC_MAP enabled in your config? Ran 'depmod -a'? (Sorry, I'm sure 
you've done
that, just checking...)

It's optional as I understand it, since you could configure the keytable from
userspace instead of using this module.

For the record (just tried it), it does load fine on my setup.

BTW, I am still on the fence whether using the kernel RC subsystem is the
right thing to do. There are a number of CEC RC commands that use extra 
parameters
that cannot be mapped to the RC API, so you still need to handle those manually.

I know Mauro would like to see this integration, but I am wondering whether it
really makes sense.

What is your opinion on this?

Perhaps I should split it off into a separate patch and keep it out from the 
initial
pull request once we're ready for that.

Regards,

Hans

> 
> At boot, I see:
> 
> [   16.577704] IR keymap rc-cec not found
> [   16.586675] Registered IR keymap rc-empty
> [   16.591668] input: RC for dw_hdmi as 
> /devices/soc0/soc/12.hdmi/rc/rc1/input3
> [   16.597769] rc1: RC for dw_hdmi as /devices/soc0/soc/12.hdmi/rc/rc1
> 
> Yet the rc-cec is a module in the filesystem, but it doesn't seem to
> be loaded automatically - even after the system has booted, the module
> hasn't been loaded.
> 
> It looks like it _should_ be loaded, but this plainly isn't working:
> 
> map = seek_rc_map(name);
> #ifdef MODULE
> if (!map) {
> int rc = request_module("%s", name);
> if (rc < 0) {
> printk(KERN_ERR "Couldn't load IR keymap %s\n", name);
> return NULL;
> }
> msleep(20); /* Give some time for IR to register */
> 
> map = seek_rc_map(name);
> }
> #endif
> if (!map) {
> printk(KERN_ERR "IR keymap %s not found\n", name);
> return NULL;
> }
> 
> Any ideas?
>

[PATCHv9 07/15] cec: add HDMI CEC framework

2015-10-12 Thread Hans Verkuil

On 10/06/2015 07:06 PM, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:44:36PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> The added HDMI CEC framework provides a generic kernel interface for
>> HDMI CEC devices.
>>
>> Signed-off-by: Hans Verkuil 
>> [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
>> [k.debski at samsung.com: Merged Update author commit by Hans Verkuil]
>> [k.debski at samsung.com: change kthread handling when setting logical
>> address]
>> [k.debski at samsung.com: code cleanup and fixes]
>> [k.debski at samsung.com: add missing CEC commands to match spec]
>> [k.debski at samsung.com: add RC framework support]
>> [k.debski at samsung.com: move and edit documentation]
>> [k.debski at samsung.com: add vendor id reporting]
>> [k.debski at samsung.com: add possibility to clear assigned logical
>> addresses]
>> [k.debski at samsung.com: documentation fixes, clenaup and expansion]
>> [k.debski at samsung.com: reorder of API structs and add reserved fields]
>> [k.debski at samsung.com: fix handling of events and fix 32/64bit timespec
>> problem]
>> [k.debski at samsung.com: add cec.h to include/uapi/linux/Kbuild]
>> [k.debski at samsung.com: add sequence number handling]
>> [k.debski at samsung.com: add passthrough mode]
>> [k.debski at samsung.com: fix CEC defines, add missing CEC 2.0 commands]
>> minor additions]
>> Signed-off-by: Kamil Debski 
>> Signed-off-by: Hans Verkuil 
> 
> I don't see much in the way of support for source devices in this:
> how do we handle hotplug of the sink, and how to do we configure the
> physical address?

The source device driver should call cec_enable(false) if the hotplug
goes down and cec_enable(true) when the EDID has been read and the physical
address has been retrieved and configured in the cec adapter.

This however assumes that the source driver is the one controlling the
CEC hardware. This is the case for the cobalt driver, but not apparently
for the exynos hardware. In that case userspace will have to handle this:
disable the CEC adapter when the hotplug disappears, set the physical address
and enable the CEC adapter when a new EDID is read.

Such drivers have the CEC_CAP_STATE and CEC_CAP_PHYS_ADDR caps set. I.e.
they expect that userspace does this.

This is also something that USB CEC dongles will do, although I don't have
a driver for that.

> Surely you aren't proposing that drivers should write directly to
> adap->phys_addr without calling some notification function that the
> physical address has changed?

Userspace is informed through CEC_EVENT_STATE_CHANGE when the adapter is
enabled/disabled. When the adapter is enabled and CEC_CAP_PHYS_ADDR is
not set (i.e. the kernel takes care of this), then calling CEC_ADAP_G_PHYS_ADDR
returns the new physical address.

> Please can you give some guidance on how a HDMI source bridge driver
> should deal with these issues.  Thanks.
> 

The cec.txt file will give more information about the kernel internals.
All I need is time (ha!) to update that file since the current version
is completely outdated (as mentioned in the cover letter).

Regards,

Hans

[PATCH v6 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

2015-10-12 Thread Krzysztof Kozlowski

On 12.10.2015 13:09, Yakir Yang wrote:
> 
> 
> On 10/12/2015 11:51 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 11:43, Yakir Yang wrote:
>>> On 10/12/2015 08:49 AM, Krzysztof Kozlowski wrote:
 On 12.10.2015 09:37, Yakir Yang wrote:
> Hi Krzysztof,
>
> On 10/10/2015 11:46 PM, Yakir Yang wrote:
>> Both hsync/vsync polarity and interlace mode can be parsed from
>> drm display mode, and dynamic_range and ycbcr_coeff can be judge
>> by the video code.
>>
>> But presumably Exynos still relies on the DT properties, so take
>> good use of mode_fixup() in to achieve the compatibility hacks.
>>
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v6: None
> +of_property_read_u32(dp_node, "hsync-active-high",
> + >h_sync_polarity);
> +of_property_read_u32(dp_node, "vsync-active-high",
> + >v_sync_polarity);
> +of_property_read_u32(dp_node, "interlaced",
> + >interlaced);
> +}
>
>
> Sorry, forget to fix your previous comment here, would
> remember to fix it to v7 version, wish v6 would collect
> more comment/reviewed/ack.  :)
 Right.

 You can send a v7 of only this patch.

 In the same time I would prefer not to chain-reply next version of
 entire patchset to cover letter of previous version. It confuses me
 because v6 appears UNDER v4 so I can't really find v6. I see v4 at the
 top of my email list.
>>> Okay, I wish this chain-reply would make people easy to find the
>>> previous comments, but actually it is little mess now. I would give
>>> up this way to send patchset  :)
>>>
 In the same time the patchset is quite big. Put the latest version
 (with
 this issue above fixed!) on some repo and link it in cover letter.
>>> Yeah, it's quite big now, I would like to back the patchset to previous
>>> format, like:
>>>
>>> ---> [PATCH v6 00/17] Cover letter
>>>|> [PATCH v6 01/17]
>>>|> [PATCH ..]
>>>|> [PATCH v6 05/17]
>>>   |> [PATCH v7 05/17]
>>>|> [PATCH ..]
>>>|> [PATCH v6 17/17]
>>>
>>> Is it right, and can resend the v6 to fix this chain-reply issue with
>>> RESEND flag ([PATCH RESEND v6 ...]) ?
>>>
>>> ---> [PATCH RESEND v6 00/17] Cover letter
>>>|> [PATCH RESEND v6 01/17]
>>>|> [PATCH ..]
>>>|> [PATCH RESEND v6 05/17]
>>>   |> [PATCH v7 05/17]
>>>|> [PATCH ..]
>>>|> [PATCH RESEND v6 17/17]
>>>
>> No, don't resend everything. I mean in this case with such big patchset
>> if you want to fix one patch just send one email [PATCH v7 05/17]
>> chained to proper id (cover letter or v6-05/17). Add a short note that
>> this is resend of only one patch from the set.
> 
> Oh, understand now, just keep this chain-reply no changes for now.
> 
> > [PATCH v4 00/16] Cover letter
>|> [PATCH v5 00/17] Covert letter
>|> [PATCH ..]
>|
>|> [PATCH v6 00/17] Covert letter
>|> [PATCH v6 01/17]
>|> [PATCH ..]
>|> [PATCH v6 17/17]
>|> [PATCH v7 05/17]

Yes, I think it is correct. Maybe just add a note (in patch changelog)
that this is v7 of only fifth patch.

Best regards,
Krzysztof

[PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-12 Thread Hans Verkuil

On 10/06/2015 01:11 AM, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
>> +cec->adap = cec_create_adapter(_cec_adap_ops, cec,
>> +CEC_NAME, CEC_CAP_STATE |
>> +CEC_CAP_PHYS_ADDR | CEC_CAP_LOG_ADDRS | CEC_CAP_IO |
>> +CEC_CAP_IS_SOURCE,
>> +0, THIS_MODULE, >dev);
>> +ret = PTR_ERR_OR_ZERO(cec->adap);
>> +if (ret)
>> +return ret;
>> +cec->adap->available_log_addrs = 1;
>> +
>> +platform_set_drvdata(pdev, cec);
>> +pm_runtime_enable(dev);
> 
> This is really not a good interface.
> 
> "cec_create_adapter" creates and registers the adapter, at which point it
> becomes available to userspace.  However, you haven't finished setting it
> up, so it's possible to nip in here and start using it before the setup
> has completed.  This needs fixing.
> 

Good point, I'll split off the registration part into a separate function.

Regards,

Hans

[PATCH v6 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

2015-10-12 Thread Krzysztof Kozlowski

On 12.10.2015 11:43, Yakir Yang wrote:
> 
> 
> On 10/12/2015 08:49 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 09:37, Yakir Yang wrote:
>>> Hi Krzysztof,
>>>
>>> On 10/10/2015 11:46 PM, Yakir Yang wrote:
 Both hsync/vsync polarity and interlace mode can be parsed from
 drm display mode, and dynamic_range and ycbcr_coeff can be judge
 by the video code.

 But presumably Exynos still relies on the DT properties, so take
 good use of mode_fixup() in to achieve the compatibility hacks.

 Signed-off-by: Yakir Yang 
 ---
 Changes in v6: None
>>> +of_property_read_u32(dp_node, "hsync-active-high",
>>> + >h_sync_polarity);
>>> +of_property_read_u32(dp_node, "vsync-active-high",
>>> + >v_sync_polarity);
>>> +of_property_read_u32(dp_node, "interlaced",
>>> + >interlaced);
>>> +}
>>>
>>>
>>> Sorry, forget to fix your previous comment here, would
>>> remember to fix it to v7 version, wish v6 would collect
>>> more comment/reviewed/ack.  :)
>> Right.
>>
>> You can send a v7 of only this patch.
>>
>> In the same time I would prefer not to chain-reply next version of
>> entire patchset to cover letter of previous version. It confuses me
>> because v6 appears UNDER v4 so I can't really find v6. I see v4 at the
>> top of my email list.
> 
> Okay, I wish this chain-reply would make people easy to find the
> previous comments, but actually it is little mess now. I would give
> up this way to send patchset  :)
> 
>> In the same time the patchset is quite big. Put the latest version (with
>> this issue above fixed!) on some repo and link it in cover letter.
> 
> Yeah, it's quite big now, I would like to back the patchset to previous
> format, like:
> 
> ---> [PATCH v6 00/17] Cover letter
>   |> [PATCH v6 01/17]
>   |> [PATCH ..]
>   |> [PATCH v6 05/17]
>  |> [PATCH v7 05/17]
>   |> [PATCH ..]
>   |> [PATCH v6 17/17]
> 
> Is it right, and can resend the v6 to fix this chain-reply issue with
> RESEND flag ([PATCH RESEND v6 ...]) ?
> 
> ---> [PATCH RESEND v6 00/17] Cover letter
>   |> [PATCH RESEND v6 01/17]
>   |> [PATCH ..]
>   |> [PATCH RESEND v6 05/17]
>  |> [PATCH v7 05/17]
>   |> [PATCH ..]
>   |> [PATCH RESEND v6 17/17]
> 

No, don't resend everything. I mean in this case with such big patchset
if you want to fix one patch just send one email [PATCH v7 05/17]
chained to proper id (cover letter or v6-05/17). Add a short note that
this is resend of only one patch from the set.

Of course you can just wait for some more comments and then send v7 of
everything.

Best regards,
Krzysztof

[PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-12 Thread Hans Verkuil

On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
>> +if (status & CEC_STATUS_TX_DONE) {
>> +if (status & CEC_STATUS_TX_ERROR) {
>> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
>> +cec->tx = STATE_ERROR;
>> +} else {
>> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
>> +cec->tx = STATE_DONE;
>> +}
>> +s5p_clr_pending_tx(cec);
>> +}
> 
> Your CEC implementation seems to be written around the idea that there
> are only two possible outcomes from a CEC message - "done" and "error",
> which get translated to:

This code is for the Samsung exynos CEC implementation. Marek, is this all
that the exynos CEC hardware returns?

> 
>> +case STATE_DONE:
>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
>> +cec->tx = STATE_IDLE;
>> +break;
>> +case STATE_ERROR:
>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
>> +cec->tx = STATE_IDLE;
> 
> "okay" and "retry_timeout".  So, if we have an adapter which can report
> (eg) a NACK, we have to report it as the obscure "retry timeout" status?
> Why this obscure naming - why can't we have something that uses the
> terminology in the spec?
> 

Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC 7.1.
The assumption of the CEC framework is that this is done by the CEC adapter
driver, not by the framework. So if after repeated retransmissions there is
still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could
change this to _MAX_RETRIES_REACHED if you prefer.

The CEC_TX_STATUS_ macros were based on what the adv drivers support (except
for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework).

Regards,

Hans

[PATCH v7 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

2015-10-12 Thread Yakir Yang

Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.

But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.

Signed-off-by: Yakir Yang 
---
*just add a note that this is v7 of only fifth patch.*

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)

Changes in v6: None
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).

Changes in v4:
- Provide backword compatibility with samsung. (Krzysztof)

Changes in v3:
- Dynamic parse video timing info from struct drm_display_mode and
  struct drm_display_info. (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   2 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
 3 files changed, 103 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 96afb67..6307060 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
return;
}

-   ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+   ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+dp->video_info.link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1030,6 +1030,85 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }

+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *orig_mode,
+   struct drm_display_mode *mode)
+{
+   struct analogix_dp_device *dp = bridge->driver_private;
+   struct drm_display_info *display_info = >connector->display_info;
+   struct video_info *video = >video_info;
+   struct device_node *dp_node = dp->dev->of_node;
+   int vic;
+
+   /* Input video interlaces & hsync pol & vsync pol */
+   video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+   video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+   video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+   /* Input video dynamic_range & colorimetry */
+   vic = drm_match_cea_mode(mode);
+   if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+   (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+   video->dynamic_range = CEA;
+   video->ycbcr_coeff = COLOR_YCBCR601;
+   } else if (vic) {
+   video->dynamic_range = CEA;
+   video->ycbcr_coeff = COLOR_YCBCR709;
+   } else {
+   video->dynamic_range = VESA;
+   video->ycbcr_coeff = COLOR_YCBCR709;
+   }
+
+   /* Input vide bpc and color_formats */
+   switch (display_info->bpc) {
+   case 12:
+   video->color_depth = COLOR_12;
+   break;
+   case 10:
+   video->color_depth = COLOR_10;
+   break;
+   case 8:
+   video->color_depth = COLOR_8;
+   break;
+   case 6:
+   video->color_depth = COLOR_6;
+   break;
+   default:
+   video->color_depth = COLOR_8;
+   break;
+   }
+   if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+   video->color_space = COLOR_YCBCR444;
+   else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+   video->color_space = COLOR_YCBCR422;
+   else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
+   video->color_space = COLOR_RGB;
+   else
+   video->color_space = COLOR_RGB;
+
+   /*
+* NOTE: those property parsing code is used for providing backward
+* compatibility for samsung platform.
+* Due to we used the "of_property_read_u32" interfaces, when this
+* property isn't present, the "video_info" can keep the original
+* values and wouldn't be modified.
+*/
+   of_property_read_u32(dp_node,

[PATCH 7/9] drm/amdgpu: Drop unnecessary #include

2015-10-12 Thread Alex Deucher

On Mon, Oct 12, 2015 at 5:54 AM, Lukas Wunner  wrote:
> This was added to two radeon files even though they don't use any
> vga_switcheroo symbols, the amdgpu fork inherited them:
>
> Added to amdgpu_acpi.c by commit d7a2952f1ade ("drm/radeon: Add
> support for the ATIF ACPI method to the radeon driver").
>
> Added to amdgpu_bios.c by commit 6a9ee8af344e ("vga_switcheroo:
> initial implementation (v15)").
>
> Signed-off-by: Lukas Wunner 

Applied 6 and 7.  thanks!

Alex


> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> index aef4a7a..a142d5a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> @@ -25,7 +25,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> index 02add0a..c44c0c6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> @@ -29,7 +29,6 @@
>  #include "amdgpu.h"
>  #include "atom.h"
>
> -#include 
>  #include 
>  #include 
>  /*
> --
> 1.8.5.2 (Apple Git-48)
>

[PATCH 3/9] vga_switcheroo: Use enum vga_switcheroo_client_id instead of int

2015-10-12 Thread Alex Deucher

On Fri, Aug 28, 2015 at 6:54 AM, Lukas Wunner  wrote:
> Signed-off-by: Lukas Wunner 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/vga/vga_switcheroo.c | 17 ++---
>  include/linux/vga_switcheroo.h   |  6 +++---
>  2 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/vga/vga_switcheroo.c 
> b/drivers/gpu/vga/vga_switcheroo.c
> index 9896305..af0d372 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -102,7 +102,7 @@ struct vga_switcheroo_client {
> struct fb_info *fb_info;
> enum vga_switcheroo_state pwr_state;
> const struct vga_switcheroo_client_ops *ops;
> -   int id;
> +   enum vga_switcheroo_client_id id;
> bool active;
> bool driver_power_control;
> struct list_head list;
> @@ -233,7 +233,8 @@ EXPORT_SYMBOL(vga_switcheroo_unregister_handler);
>
>  static int register_client(struct pci_dev *pdev,
>const struct vga_switcheroo_client_ops *ops,
> -  int id, bool active, bool driver_power_control)
> +  enum vga_switcheroo_client_id id, bool active,
> +  bool driver_power_control)
>  {
> struct vga_switcheroo_client *client;
>
> @@ -288,7 +289,7 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
>   * vga_switcheroo_register_audio_client - register audio client
>   * @pdev: client pci device
>   * @ops: client callbacks
> - * @id: client identifier, see enum vga_switcheroo_client_id
> + * @id: client identifier
>   *
>   * Register audio client (audio device on a GPU). The power state of the
>   * client is assumed to be ON.
> @@ -297,7 +298,7 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
>   */
>  int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
>  const struct 
> vga_switcheroo_client_ops *ops,
> -int id)
> +enum vga_switcheroo_client_id id)
>  {
> return register_client(pdev, ops, id | ID_BIT_AUDIO, false, false);
>  }
> @@ -315,7 +316,8 @@ find_client_from_pci(struct list_head *head, struct 
> pci_dev *pdev)
>  }
>
>  static struct vga_switcheroo_client *
> -find_client_from_id(struct list_head *head, int client_id)
> +find_client_from_id(struct list_head *head,
> +   enum vga_switcheroo_client_id client_id)
>  {
> struct vga_switcheroo_client *client;
>
> @@ -497,7 +499,8 @@ static int vga_switchoff(struct vga_switcheroo_client 
> *client)
> return 0;
>  }
>
> -static void set_audio_state(int id, enum vga_switcheroo_state state)
> +static void set_audio_state(enum vga_switcheroo_client_id id,
> +   enum vga_switcheroo_state state)
>  {
> struct vga_switcheroo_client *client;
>
> @@ -584,7 +587,7 @@ vga_switcheroo_debugfs_write(struct file *filp, const 
> char __user *ubuf,
> int ret;
> bool delay = false, can_switch;
> bool just_mux = false;
> -   int client_id = VGA_SWITCHEROO_UNKNOWN_ID;
> +   enum vga_switcheroo_client_id client_id = VGA_SWITCHEROO_UNKNOWN_ID;
> struct vga_switcheroo_client *client = NULL;
>
> if (cnt > 63)
> diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
> index 88909a8..c557511 100644
> --- a/include/linux/vga_switcheroo.h
> +++ b/include/linux/vga_switcheroo.h
> @@ -100,7 +100,7 @@ struct vga_switcheroo_handler {
> int (*switchto)(enum vga_switcheroo_client_id id);
> int (*power_state)(enum vga_switcheroo_client_id id,
>enum vga_switcheroo_state state);
> -   int (*get_client_id)(struct pci_dev *pdev);
> +   enum vga_switcheroo_client_id (*get_client_id)(struct pci_dev *pdev);
>  };
>
>  /**
> @@ -132,7 +132,7 @@ int vga_switcheroo_register_client(struct pci_dev *dev,
>bool driver_power_control);
>  int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
>  const struct 
> vga_switcheroo_client_ops *ops,
> -int id);
> +enum vga_switcheroo_client_id id);
>
>  void vga_switcheroo_client_fb_set(struct pci_dev *dev,
>   struct fb_info *info);
> @@ -158,7 +158,7 @@ static inline void vga_switcheroo_client_fb_set(struct 
> pci_dev *dev, struct fb_i
>  static inline int vga_switcheroo_register_handler(struct 
> vga_switcheroo_handler *handler) { return 0; }
>  static inline int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
> const struct vga_switcheroo_client_ops *ops,
> -   int id) { return 0; }
> +   enum vga_switcheroo_client_id id) { return 0; }
>  static inline void vga_switcheroo_unregister_handler(void) {}
>  static inline int vga_switcheroo_process_delayed_switch(void) { return 0;

[PATCH 2/9] vga_switcheroo: Use VGA_SWITCHEROO_UNKNOWN_ID instead of -1

2015-10-12 Thread Alex Deucher

On Fri, Aug 28, 2015 at 7:30 AM, Lukas Wunner  wrote:
> Signed-off-by: Lukas Wunner 
Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/vga/vga_switcheroo.c | 17 +
>  include/linux/vga_switcheroo.h   |  4 
>  2 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/vga/vga_switcheroo.c 
> b/drivers/gpu/vga/vga_switcheroo.c
> index a7870d2..9896305 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -84,9 +84,9 @@
>   * @fb_info: framebuffer to which console is remapped on switching
>   * @pwr_state: current power state
>   * @ops: client callbacks
> - * @id: client identifier, see enum vga_switcheroo_client_id.
> - * Determining the id requires the handler, so GPUs are initially
> - * assigned -1 and later given their true id in vga_switcheroo_enable()
> + * @id: client identifier. Determining the id requires the handler,
> + * so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
> + * and later given their true id in vga_switcheroo_enable()
>   * @active: whether the outputs are currently switched to this client
>   * @driver_power_control: whether power state is controlled by the driver's
>   * runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
> @@ -145,7 +145,8 @@ struct vgasr_priv {
>
>  #define ID_BIT_AUDIO   0x100
>  #define client_is_audio(c) ((c)->id & ID_BIT_AUDIO)
> -#define client_is_vga(c)   ((c)->id == -1 || !client_is_audio(c))
> +#define client_is_vga(c)   ((c)->id == VGA_SWITCHEROO_UNKNOWN_ID || \
> +!client_is_audio(c))
>  #define client_id(c)   ((c)->id & ~ID_BIT_AUDIO)
>
>  static int vga_switcheroo_debugfs_init(struct vgasr_priv *priv);
> @@ -173,7 +174,7 @@ static void vga_switcheroo_enable(void)
> vgasr_priv.handler->init();
>
> list_for_each_entry(client, _priv.clients, list) {
> -   if (client->id != -1)
> +   if (client->id != VGA_SWITCHEROO_UNKNOWN_ID)
> continue;
> ret = vgasr_priv.handler->get_client_id(client->pdev);
> if (ret < 0)
> @@ -277,7 +278,7 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
>const struct vga_switcheroo_client_ops 
> *ops,
>bool driver_power_control)
>  {
> -   return register_client(pdev, ops, -1,
> +   return register_client(pdev, ops, VGA_SWITCHEROO_UNKNOWN_ID,
>pdev == vga_default_device(),
>driver_power_control);
>  }
> @@ -583,7 +584,7 @@ vga_switcheroo_debugfs_write(struct file *filp, const 
> char __user *ubuf,
> int ret;
> bool delay = false, can_switch;
> bool just_mux = false;
> -   int client_id = -1;
> +   int client_id = VGA_SWITCHEROO_UNKNOWN_ID;
> struct vga_switcheroo_client *client = NULL;
>
> if (cnt > 63)
> @@ -652,7 +653,7 @@ vga_switcheroo_debugfs_write(struct file *filp, const 
> char __user *ubuf,
> client_id = VGA_SWITCHEROO_DIS;
> }
>
> -   if (client_id == -1)
> +   if (client_id == VGA_SWITCHEROO_UNKNOWN_ID)
> goto out;
> client = find_client_from_id(_priv.clients, client_id);
> if (!client)
> diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
> index e636617..88909a8 100644
> --- a/include/linux/vga_switcheroo.h
> +++ b/include/linux/vga_switcheroo.h
> @@ -59,6 +59,9 @@ enum vga_switcheroo_state {
>
>  /**
>   * enum vga_switcheroo_client_id - client identifier
> + * @VGA_SWITCHEROO_UNKNOWN_ID: initial identifier assigned to vga clients.
> + * Determining the id requires the handler, so GPUs are given their
> + * true id in a delayed fashion in vga_switcheroo_enable()
>   * @VGA_SWITCHEROO_IGD: integrated graphics device
>   * @VGA_SWITCHEROO_DIS: discrete graphics device
>   * @VGA_SWITCHEROO_MAX_CLIENTS: currently no more than two GPUs are supported
> @@ -66,6 +69,7 @@ enum vga_switcheroo_state {
>   * Client identifier. Audio clients use the same identifier & 0x100.
>   */
>  enum vga_switcheroo_client_id {
> +   VGA_SWITCHEROO_UNKNOWN_ID = -1,
> VGA_SWITCHEROO_IGD,
> VGA_SWITCHEROO_DIS,
> VGA_SWITCHEROO_MAX_CLIENTS,
> --
> 1.8.5.2 (Apple Git-48)
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

2015-10-12 Thread Yakir Yang



On 10/12/2015 11:51 AM, Krzysztof Kozlowski wrote:
> On 12.10.2015 11:43, Yakir Yang wrote:
>> On 10/12/2015 08:49 AM, Krzysztof Kozlowski wrote:
>>> On 12.10.2015 09:37, Yakir Yang wrote:
 Hi Krzysztof,

 On 10/10/2015 11:46 PM, Yakir Yang wrote:
> Both hsync/vsync polarity and interlace mode can be parsed from
> drm display mode, and dynamic_range and ycbcr_coeff can be judge
> by the video code.
>
> But presumably Exynos still relies on the DT properties, so take
> good use of mode_fixup() in to achieve the compatibility hacks.
>
> Signed-off-by: Yakir Yang 
> ---
> Changes in v6: None
 +of_property_read_u32(dp_node, "hsync-active-high",
 + >h_sync_polarity);
 +of_property_read_u32(dp_node, "vsync-active-high",
 + >v_sync_polarity);
 +of_property_read_u32(dp_node, "interlaced",
 + >interlaced);
 +}


 Sorry, forget to fix your previous comment here, would
 remember to fix it to v7 version, wish v6 would collect
 more comment/reviewed/ack.  :)
>>> Right.
>>>
>>> You can send a v7 of only this patch.
>>>
>>> In the same time I would prefer not to chain-reply next version of
>>> entire patchset to cover letter of previous version. It confuses me
>>> because v6 appears UNDER v4 so I can't really find v6. I see v4 at the
>>> top of my email list.
>> Okay, I wish this chain-reply would make people easy to find the
>> previous comments, but actually it is little mess now. I would give
>> up this way to send patchset  :)
>>
>>> In the same time the patchset is quite big. Put the latest version (with
>>> this issue above fixed!) on some repo and link it in cover letter.
>> Yeah, it's quite big now, I would like to back the patchset to previous
>> format, like:
>>
>> ---> [PATCH v6 00/17] Cover letter
>>|> [PATCH v6 01/17]
>>|> [PATCH ..]
>>|> [PATCH v6 05/17]
>>   |> [PATCH v7 05/17]
>>|> [PATCH ..]
>>|> [PATCH v6 17/17]
>>
>> Is it right, and can resend the v6 to fix this chain-reply issue with
>> RESEND flag ([PATCH RESEND v6 ...]) ?
>>
>> ---> [PATCH RESEND v6 00/17] Cover letter
>>|> [PATCH RESEND v6 01/17]
>>|> [PATCH ..]
>>|> [PATCH RESEND v6 05/17]
>>   |> [PATCH v7 05/17]
>>|> [PATCH ..]
>>|> [PATCH RESEND v6 17/17]
>>
> No, don't resend everything. I mean in this case with such big patchset
> if you want to fix one patch just send one email [PATCH v7 05/17]
> chained to proper id (cover letter or v6-05/17). Add a short note that
> this is resend of only one patch from the set.

Oh, understand now, just keep this chain-reply no changes for now.

> [PATCH v4 00/16] Cover letter
|> [PATCH v5 00/17] Covert letter
|> [PATCH ..]
|
|> [PATCH v6 00/17] Covert letter
|> [PATCH v6 01/17]
|> [PATCH ..]
|> [PATCH v6 17/17]
|> [PATCH v7 05/17]


> Of course you can just wait for some more comments and then send v7 of
> everything.

I would choice to send it now :)

Thanks,
- Yakir

> Best regards,
> Krzysztof
>
>
>
>

[PATCH 1/9] vga_switcheroo: Use enum vga_switcheroo_state instead of int

2015-10-12 Thread Alex Deucher

On Fri, Aug 28, 2015 at 5:56 AM, Lukas Wunner  wrote:
> Signed-off-by: Lukas Wunner 
> Reviewed-by: Jani Nikula 
Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/vga/vga_switcheroo.c | 6 +++---
>  include/linux/vga_switcheroo.h   | 4 ++--
>  2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/vga/vga_switcheroo.c 
> b/drivers/gpu/vga/vga_switcheroo.c
> index 1acbe20..a7870d2 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -100,7 +100,7 @@
>  struct vga_switcheroo_client {
> struct pci_dev *pdev;
> struct fb_info *fb_info;
> -   int pwr_state;
> +   enum vga_switcheroo_state pwr_state;
> const struct vga_switcheroo_client_ops *ops;
> int id;
> bool active;
> @@ -344,7 +344,7 @@ find_active_client(struct list_head *head)
>   *
>   * Return: Power state.
>   */
> -int vga_switcheroo_get_client_state(struct pci_dev *pdev)
> +enum vga_switcheroo_state vga_switcheroo_get_client_state(struct pci_dev 
> *pdev)
>  {
> struct vga_switcheroo_client *client;
> enum vga_switcheroo_state ret;
> @@ -496,7 +496,7 @@ static int vga_switchoff(struct vga_switcheroo_client 
> *client)
> return 0;
>  }
>
> -static void set_audio_state(int id, int state)
> +static void set_audio_state(int id, enum vga_switcheroo_state state)
>  {
> struct vga_switcheroo_client *client;
>
> diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
> index 3764991..e636617 100644
> --- a/include/linux/vga_switcheroo.h
> +++ b/include/linux/vga_switcheroo.h
> @@ -138,7 +138,7 @@ void vga_switcheroo_unregister_handler(void);
>
>  int vga_switcheroo_process_delayed_switch(void);
>
> -int vga_switcheroo_get_client_state(struct pci_dev *dev);
> +enum vga_switcheroo_state vga_switcheroo_get_client_state(struct pci_dev 
> *dev);
>
>  void vga_switcheroo_set_dynamic_switch(struct pci_dev *pdev, enum 
> vga_switcheroo_state dynamic);
>
> @@ -157,7 +157,7 @@ static inline int 
> vga_switcheroo_register_audio_client(struct pci_dev *pdev,
> int id) { return 0; }
>  static inline void vga_switcheroo_unregister_handler(void) {}
>  static inline int vga_switcheroo_process_delayed_switch(void) { return 0; }
> -static inline int vga_switcheroo_get_client_state(struct pci_dev *dev) { 
> return VGA_SWITCHEROO_ON; }
> +static inline enum vga_switcheroo_state 
> vga_switcheroo_get_client_state(struct pci_dev *dev) { return 
> VGA_SWITCHEROO_ON; }
>
>  static inline void vga_switcheroo_set_dynamic_switch(struct pci_dev *pdev, 
> enum vga_switcheroo_state dynamic) {}
>
> --
> 1.8.5.2 (Apple Git-48)
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 9/9] drm/amdgpu: Fix kernel-doc copy/paste snafu

2015-10-12 Thread Alex Deucher

On Mon, Oct 12, 2015 at 6:00 AM, Lukas Wunner  wrote:
> Introduced by f482a1419545 ("drm/radeon: document radeon_kms.c")
> and inherited by the amdgpu fork.
>
> Signed-off-by: Lukas Wunner 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 371f015..b1d499e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -485,11 +485,11 @@ static int amdgpu_info_ioctl(struct drm_device *dev, 
> void *data, struct drm_file
>   * Outdated mess for old drm with Xorg being in charge (void function now).
>   */
>  /**
> - * amdgpu_driver_firstopen_kms - drm callback for last close
> + * amdgpu_driver_lastclose_kms - drm callback for last close

Already fixed as part of this patch:
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=8b7530b15c3332220a081035ab467c9359aff409

Up to you if you want to respin the second hunk or not.

Alex

>   *
>   * @dev: drm dev pointer
>   *
> - * Switch vga switcheroo state after last close (all asics).
> + * Switch vga_switcheroo state after last close (all asics).
>   */
>  void amdgpu_driver_lastclose_kms(struct drm_device *dev)
>  {
> --
> 1.8.5.2 (Apple Git-48)
>

[PATCH 8/9] drm/radeon: Fix kernel-doc copy/paste snafu

2015-10-12 Thread Alex Deucher

On Mon, Oct 12, 2015 at 5:44 AM, Lukas Wunner  wrote:
> Introduced by f482a1419545 ("drm/radeon: document radeon_kms.c").
>
> Signed-off-by: Lukas Wunner 
> ---
>  drivers/gpu/drm/radeon/radeon_kms.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 4e2780f..ee5cc14 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -598,11 +598,11 @@ static int radeon_info_ioctl(struct drm_device *dev, 
> void *data, struct drm_file
>   * Outdated mess for old drm with Xorg being in charge (void function now).
>   */
>  /**
> - * radeon_driver_firstopen_kms - drm callback for last close
> + * radeon_driver_lastclose_kms - drm callback for last close

Already fixes as part of this patch:
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=8c70e1cda04b966b50ddfefafbd0ea376ed8edd5

Up to you if you want to respin the second hunk or not.

Alex

>   *
>   * @dev: drm dev pointer
>   *
> - * Switch vga switcheroo state after last close (all asics).
> + * Switch vga_switcheroo state after last close (all asics).
>   */
>  void radeon_driver_lastclose_kms(struct drm_device *dev)
>  {
> --
> 1.8.5.2 (Apple Git-48)
>

[PATCH 9/9] drm/amdgpu: Fix kernel-doc copy/paste snafu

2015-10-12 Thread Lukas Wunner

Introduced by f482a1419545 ("drm/radeon: document radeon_kms.c")
and inherited by the amdgpu fork.

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 371f015..b1d499e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -485,11 +485,11 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
  * Outdated mess for old drm with Xorg being in charge (void function now).
  */
 /**
- * amdgpu_driver_firstopen_kms - drm callback for last close
+ * amdgpu_driver_lastclose_kms - drm callback for last close
  *
  * @dev: drm dev pointer
  *
- * Switch vga switcheroo state after last close (all asics).
+ * Switch vga_switcheroo state after last close (all asics).
  */
 void amdgpu_driver_lastclose_kms(struct drm_device *dev)
 {
-- 
1.8.5.2 (Apple Git-48)

[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley

2015-10-12 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #39 from Mathias Tillman  ---
(In reply to Andy Furniss from comment #38)
> (In reply to Andy Furniss from comment #32)
> 
> > I'll try over the weekend - no locks so far.
> 
> Still good, I've also tried to hang with Unreal demos and mplayer+uvd, no
> hangs and no vm faults so far.

Assuming you tried it with the scheduler enabled? Just tried it with the
scheduler enabled and semaphores disabled on drm-fixes-4.3, and it also seems
to work.

Is the scheduler going to be left enabled from now on? If so we could probably
say that this issue has been solved (though more testing is probably required).
However, something is causing all of those vm faults when the scheduler is
disabled, so it might still be worth looking into if it's going to be possible
to disable it using a module parameter.

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

[PATCH 7/9] drm/amdgpu: Drop unnecessary #include

2015-10-12 Thread Lukas Wunner

This was added to two radeon files even though they don't use any
vga_switcheroo symbols, the amdgpu fork inherited them:

Added to amdgpu_acpi.c by commit d7a2952f1ade ("drm/radeon: Add
support for the ATIF ACPI method to the radeon driver").

Added to amdgpu_bios.c by commit 6a9ee8af344e ("vga_switcheroo:
initial implementation (v15)").

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index aef4a7a..a142d5a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
index 02add0a..c44c0c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -29,7 +29,6 @@
 #include "amdgpu.h"
 #include "atom.h"

-#include 
 #include 
 #include 
 /*
-- 
1.8.5.2 (Apple Git-48)

[PATCH 8/9] drm/radeon: Fix kernel-doc copy/paste snafu

2015-10-12 Thread Lukas Wunner

Introduced by f482a1419545 ("drm/radeon: document radeon_kms.c").

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/radeon/radeon_kms.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 4e2780f..ee5cc14 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -598,11 +598,11 @@ static int radeon_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
  * Outdated mess for old drm with Xorg being in charge (void function now).
  */
 /**
- * radeon_driver_firstopen_kms - drm callback for last close
+ * radeon_driver_lastclose_kms - drm callback for last close
  *
  * @dev: drm dev pointer
  *
- * Switch vga switcheroo state after last close (all asics).
+ * Switch vga_switcheroo state after last close (all asics).
  */
 void radeon_driver_lastclose_kms(struct drm_device *dev)
 {
-- 
1.8.5.2 (Apple Git-48)

[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2

2015-10-12 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #25 from Barto  ---
(In reply to Roland Scheidegger from comment #24)
> You'll notice right there ("when built with CMake") this patch is not always
> needed with llvm 3.7. The different name is really FUBAR but is beyond
> mesa's control as it only depends on how llvm is built... Albeit I don't
> know what the resolution to that llvm problem was if there's any yet.

CMAKE might be the culprit if the generation of libLLVM.so file ( 3.7.0 version
) has problems,

I found two interesting links about the "CMAKE way" when building LLVM 3.7.0 :

https://llvm.org/bugs/show_bug.cgi?id=23649

http://lists.freedesktop.org/archives/mesa-dev/2015-September/095696.html

and I found also that archlinux developers for the 3.6.2 version of LLVM have
used the classic way ( ./configure, make, make install ) for building LLVM
3.6.2,

then for the 3.7.0 version they have switched ( archlinux developers ) to the
CMAKE build method,

LLVM 3.6.2 lib works without problems with mesa 11.0.3, LLVM 3.7.0 lib triggers
a crash when mesa 11.0.3 tries to use it ( when r600 driver is used with an amd
radeon HD4650 pcie card ),

it's just a supposition : my bug could be the consequence of the switch to the
CMAKE build method, something went wrong in CMAKE files configuration in LLVM
3.7.0,

to be sure I am currently trying to compile LLVM 3.7.0 with the classic way (
./configure ) by reverting this patch in order to allow this :

http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150629/284970.html

and I will see if the bug is still here when libLLVM.so.3.7 is building with
./configure and not CMAKE

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

[PATCH 6/9] drm/radeon: Drop unnecessary #include

2015-10-12 Thread Lukas Wunner

This was added to three files even though they don't use any
vga_switcheroo symbols:

Added to radeon_acpi.c by commit d7a2952f1ade ("drm/radeon: Add
support for the ATIF ACPI method to the radeon driver").

Added to radeon_asic.c by commit 0a10c85129c2 ("drm/radeon: create
radeon_asic.c").

Added to radeon_bios.c by commit 6a9ee8af344e ("vga_switcheroo:
initial implementation (v15)").

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/radeon/radeon_acpi.c | 1 -
 drivers/gpu/drm/radeon/radeon_asic.c | 1 -
 drivers/gpu/drm/radeon/radeon_bios.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c 
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 77e9d07..59acd0e 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index f2421bc..1d4d452 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "radeon_reg.h"
 #include "radeon.h"
 #include "radeon_asic.h"
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index d27e4cc..21b6732 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -30,7 +30,6 @@
 #include "radeon.h"
 #include "atom.h"

-#include 
 #include 
 #include 
 /*
-- 
1.8.5.2 (Apple Git-48)

[PATCH 5/9] drm/i915: Drop unnecessary #include

2015-10-12 Thread Lukas Wunner

Commit 599bbb9de0fe ("drm/i915: i915 cannot provide switcher services.")
removed all remaining vga_switcheroo symbols from intel_acpi.c but left
the include. Drop it.

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/i915/intel_acpi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
b/drivers/gpu/drm/i915/intel_acpi.c
index d96eee1..68119b6 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -5,7 +5,6 @@
  */
 #include 
 #include 
-#include 
 #include 
 #include "i915_drv.h"

-- 
1.8.5.2 (Apple Git-48)

[PATCH] drm/nouveau/disp, pm: constify nvkm_object_func structures

2015-10-12 Thread Ben Skeggs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/11/2015 10:18 PM, Julia Lawall wrote:
> These nvkm_object_func structures are never modified.  All other 
> nvkm_object_func structures are declared as const.
> 
> Done with the help of Coccinelle.
I've picked up the patch, thanks!

Ben.

> 
> Signed-off-by: Julia Lawall 
> 
> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv04.c |2 +- 
> drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c   |2 +- 2
> files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv04.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv04.c index
> 62d3fb6..2be8463 100644 ---
> a/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv04.c +++
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv04.c @@ -109,7
> +109,7 @@ nv04_disp_mthd(struct nvkm_object *object, u32 mthd, void
> *data, u32 size) return -EINVAL; }
> 
> -static struct nvkm_object_func +static const struct
> nvkm_object_func nv04_disp_root = { .mthd = nv04_disp_mthd, .ntfy =
> nvkm_disp_ntfy, diff --git
> a/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c index
> 0db9be2..2721592 100644 ---
> a/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c +++
> b/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c @@ -633,7 +633,7 @@
> nvkm_perfmon_dtor(struct nvkm_object *object) return perfmon; }
> 
> -static struct nvkm_object_func +static const struct
> nvkm_object_func nvkm_perfmon = { .dtor = nvkm_perfmon_dtor, .mthd
> = nvkm_perfmon_mthd,
> 
> ___ dri-devel mailing
> list dri-devel at lists.freedesktop.org 
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWGwQdAAoJEHYLnGJQkpH74lsQAMlUrNJ9gRc1d6P6fKcTwVGa
YwBG8R2pg+nQ4UY9GoFvTJO1CSanG+4bLM88ccTDeuF7nIhV9g7Z8vPg8Jy1B2ZX
V7mVvNdO+sagYT6PcitXzDDirM6yoNZLf+7y0I+8HPNwg9TBCXUFZCF0w3DY0Txu
S6HZmCO/rlhQJFGuOsOrfKAtrEwIaw1JiAWMS8VUNbjdzHgozetJQgq7xAoe49A2
GGtQ6b1JtI8bmzYDVhJmhSqzTwBmZO5RLL6Wo3DFta/E6bR6SQgpeU2im9lkwgKH
WOBkotpg/EJJ4ltSMpjOkJlTu5xWEUr12RA5SYlcyWEX7XwnLX7S4TXa8Dh6jIFE
Jv4tnWsKVFrzLKQ/Q75uaFgbhJiWt8VNpfGaLmnnI3qYjujAoXBgiapp7Xi/fd25
vUx1j/OWmKQy3dDdjAQKXDp2MK+DrJig7lfQahwGQRztLwvMv65hq7fXLlt0LbjH
DzU9Q2VzSbEfW02zDcgCem7gIUf+X3cKkMx2c9Bok56cGOybUPm33OFFZ5IE0KJ4
3yRHE5aq2kzeWsN99N/IvyE6WhtK+kCNmEfkddYOvPQ3XioAk1zjNAdkQudM0Ii0
JWjFFVt0fixVOl8zmGIDNFNBnzYKu5SwvA31Usr1Vsltx+c4LXAmIGG6/vey5Uiv
WmpIfcA3EmL2jRoaS/DG
=00y+
-END PGP SIGNATURE-

[PATCH v6 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

2015-10-12 Thread Yakir Yang



On 10/12/2015 08:49 AM, Krzysztof Kozlowski wrote:
> On 12.10.2015 09:37, Yakir Yang wrote:
>> Hi Krzysztof,
>>
>> On 10/10/2015 11:46 PM, Yakir Yang wrote:
>>> Both hsync/vsync polarity and interlace mode can be parsed from
>>> drm display mode, and dynamic_range and ycbcr_coeff can be judge
>>> by the video code.
>>>
>>> But presumably Exynos still relies on the DT properties, so take
>>> good use of mode_fixup() in to achieve the compatibility hacks.
>>>
>>> Signed-off-by: Yakir Yang 
>>> ---
>>> Changes in v6: None
>> +of_property_read_u32(dp_node, "hsync-active-high",
>> + >h_sync_polarity);
>> +of_property_read_u32(dp_node, "vsync-active-high",
>> + >v_sync_polarity);
>> +of_property_read_u32(dp_node, "interlaced",
>> + >interlaced);
>> +}
>>
>>
>> Sorry, forget to fix your previous comment here, would
>> remember to fix it to v7 version, wish v6 would collect
>> more comment/reviewed/ack.  :)
> Right.
>
> You can send a v7 of only this patch.
>
> In the same time I would prefer not to chain-reply next version of
> entire patchset to cover letter of previous version. It confuses me
> because v6 appears UNDER v4 so I can't really find v6. I see v4 at the
> top of my email list.

Okay, I wish this chain-reply would make people easy to find the
previous comments, but actually it is little mess now. I would give
up this way to send patchset  :)

> In the same time the patchset is quite big. Put the latest version (with
> this issue above fixed!) on some repo and link it in cover letter.

Yeah, it's quite big now, I would like to back the patchset to previous
format, like:

---> [PATCH v6 00/17] Cover letter
   |> [PATCH v6 01/17]
   |> [PATCH ..]
   |> [PATCH v6 05/17]
  |> [PATCH v7 05/17]
   |> [PATCH ..]
   |> [PATCH v6 17/17]

Is it right, and can resend the v6 to fix this chain-reply issue with
RESEND flag ([PATCH RESEND v6 ...]) ?

---> [PATCH RESEND v6 00/17] Cover letter
   |> [PATCH RESEND v6 01/17]
   |> [PATCH ..]
   |> [PATCH RESEND v6 05/17]
  |> [PATCH v7 05/17]
   |> [PATCH ..]
   |> [PATCH RESEND v6 17/17]


Thanks :-)
- Yakir

>
> Best regards,
> Krzysztof
>
>> Best regards,
>> - Yakir
>>
>>> Changes in v5:
>>> - Switch video timing type to "u32", so driver could use
>>> "of_property_read_u32"
>>> to get the backword timing values. Krzysztof suggest me that driver
>>> could use
>>> the "of_property_read_bool" to get backword timing values, but that
>>> interfacs
>>> would modify the original drm_display_mode timing directly (whether
>>> those
>>> properties exists or not).
>>>
>>> Changes in v4:
>>> - Provide backword compatibility with samsung. (Krzysztof)
>>>
>>> Changes in v3:
>>> - Dynamic parse video timing info from struct drm_display_mode and
>>> struct drm_display_info. (Thierry)
>>>
>>> Changes in v2: None
>
>
>

v4.3-rc4: i915: ThinkPad Yoga 12: ERROR The master control interrupt lied (SDE)!

2015-10-12 Thread Jani Nikula

On Sat, 10 Oct 2015, Darren Hart  wrote:
> The Debian 3.16.0 kernel does not emit the error, but I have not attempted a
> bisection.
>
> The warning was added by:
> 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8)
>  2014-06-18 (1 year, 4 months ago), Oscar Mateo 

But we don't start hitting the warning right away with that commit, do
we? There's a bug about this with a bisected bad commit [1], please
let's track this there.

Thanks,
Jani.


[1] https://bugs.freedesktop.org/show_bug.cgi?id=92084


>
> Follows: v3.15-rc8
> Preceedes: 3.17-rc1
>
> This is not present in v3.16, so perhaps not present in the Debian kernel and
> this is not a regression, but just reporting the condition as intended.
>
> Linux Version: v4.3-rc4
> Platform: Lenovo ThinkPad Yoga 12
> OS: Debian 8.2
>
> $ dmesg | grep -i drm
> [   10.918367] [drm] Initialized drm 1.1.0 20060810
> [   11.235005] [drm] Memory usable by graphics device = 4096M
> [   11.235009] fb: switching to inteldrmfb from simple
> [   11.235093] [drm] Replacing VGA console driver
> [   11.241160] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [   11.241162] [drm] Driver supports precise vblank timestamp query.
> [   11.256249] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: 
> Can't calculate constants, dotclock = 0!
> [   11.326946] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit 
> banging on pin 5
> [   11.344097] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on 
> minor 0
> [   11.344913] fbcon: inteldrmfb (fb0) is primary device
> [   12.462509] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   12.466498] i915 :00:02.0: fb0: inteldrmfb frame buffer device
> [   12.794359] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.869733] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.869894] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.870058] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   22.656986] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506246] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506415] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506584] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506746] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722570] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722744] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722908] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776390] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776549] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776710] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 4057.592685] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
>
> -- 
> Darren Hart
> Intel Open Source Technology Center

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v6 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

2015-10-12 Thread Krzysztof Kozlowski

On 12.10.2015 09:37, Yakir Yang wrote:
> Hi Krzysztof,
> 
> On 10/10/2015 11:46 PM, Yakir Yang wrote:
>> Both hsync/vsync polarity and interlace mode can be parsed from
>> drm display mode, and dynamic_range and ycbcr_coeff can be judge
>> by the video code.
>>
>> But presumably Exynos still relies on the DT properties, so take
>> good use of mode_fixup() in to achieve the compatibility hacks.
>>
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v6: None
> 
> +of_property_read_u32(dp_node, "hsync-active-high",
> + >h_sync_polarity);
> +of_property_read_u32(dp_node, "vsync-active-high",
> + >v_sync_polarity);
> +of_property_read_u32(dp_node, "interlaced",
> + >interlaced);
> +}
> 
> 
> Sorry, forget to fix your previous comment here, would
> remember to fix it to v7 version, wish v6 would collect
> more comment/reviewed/ack.  :)

Right.

You can send a v7 of only this patch.

In the same time I would prefer not to chain-reply next version of
entire patchset to cover letter of previous version. It confuses me
because v6 appears UNDER v4 so I can't really find v6. I see v4 at the
top of my email list.

In the same time the patchset is quite big. Put the latest version (with
this issue above fixed!) on some repo and link it in cover letter.

Best regards,
Krzysztof

> 
> Best regards,
> - Yakir
> 
>> Changes in v5:
>> - Switch video timing type to "u32", so driver could use
>> "of_property_read_u32"
>>to get the backword timing values. Krzysztof suggest me that driver
>> could use
>>the "of_property_read_bool" to get backword timing values, but that
>> interfacs
>>would modify the original drm_display_mode timing directly (whether
>> those
>>properties exists or not).
>>
>> Changes in v4:
>> - Provide backword compatibility with samsung. (Krzysztof)
>>
>> Changes in v3:
>> - Dynamic parse video timing info from struct drm_display_mode and
>>struct drm_display_info. (Thierry)
>>
>> Changes in v2: None

[PATCH RFC 5/5] gpu/doc: Convert to markdown harder

2015-10-12 Thread Lukas Wunner

This snippet...

* Lock VMA manager for extended lookups. Only *_locked() VMA function calls
* are allowed while holding this lock. All other contexts are blocked from 
VMA
* until the lock is released via drm_vma_offset_unlock_lookup().

...causes markdown-enabled kernel-doc to barf:

debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3247: parser error 
: Opening and ending tag mismatch: emphasis line 3247 and function
   *locked VMA function calls are allowed 
while
 ^

/root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3249: 
parser error : Opening and ending tag mismatch: function line 3249 and emphasis
   released via drmvma_offset_unlock_lookup.
^
unable to parse 
/root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml

A quick workaround is to replace *_locked() by X_locked().

Cc: Danilo Cesar Lemes de Paula 
Signed-off-by: Lukas Wunner 
---
 include/drm/drm_vma_manager.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index 2ca44db..c1e41b8 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -97,7 +97,7 @@ drm_vma_offset_exact_lookup(struct drm_vma_offset_manager 
*mgr,
  * drm_vma_offset_lock_lookup() - Lock lookup for extended private use
  * @mgr: Manager object
  *
- * Lock VMA manager for extended lookups. Only *_locked() VMA function calls
+ * Lock VMA manager for extended lookups. Only X_locked() VMA function calls
  * are allowed while holding this lock. All other contexts are blocked from VMA
  * until the lock is released via drm_vma_offset_unlock_lookup().
  *
-- 
1.8.5.2 (Apple Git-48)

v4.3-rc4: i915: ThinkPad Yoga 12: ERROR The master control interrupt lied (SDE)! [regression]

2015-10-12 Thread Daniel Vetter

Another regression for Jairo to track.
-Daniel

On Sat, Oct 10, 2015 at 12:08:43PM -0700, Darren Hart wrote:
> The Debian 3.16.0 kernel does not emit the error, but I have not attempted a
> bisection.
> 
> The warning was added by:
> 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8)
>  2014-06-18 (1 year, 4 months ago), Oscar Mateo 
> 
> Follows: v3.15-rc8
> Preceedes: 3.17-rc1
> 
> This is not present in v3.16, so perhaps not present in the Debian kernel and
> this is not a regression, but just reporting the condition as intended.
> 
> Linux Version: v4.3-rc4
> Platform: Lenovo ThinkPad Yoga 12
> OS: Debian 8.2
> 
> $ dmesg | grep -i drm
> [   10.918367] [drm] Initialized drm 1.1.0 20060810
> [   11.235005] [drm] Memory usable by graphics device = 4096M
> [   11.235009] fb: switching to inteldrmfb from simple
> [   11.235093] [drm] Replacing VGA console driver
> [   11.241160] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [   11.241162] [drm] Driver supports precise vblank timestamp query.
> [   11.256249] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: 
> Can't calculate constants, dotclock = 0!
> [   11.326946] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit 
> banging on pin 5
> [   11.344097] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on 
> minor 0
> [   11.344913] fbcon: inteldrmfb (fb0) is primary device
> [   12.462509] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   12.466498] i915 :00:02.0: fb0: inteldrmfb frame buffer device
> [   12.794359] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.869733] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.869894] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.870058] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   22.656986] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506246] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506415] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506584] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506746] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722570] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722744] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722908] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776390] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776549] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776710] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 4057.592685] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> 
> -- 
> Darren Hart
> Intel Open Source Technology Center

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

[Intel-gfx] 4.2-rc4 kernel warnings on HSW laptop [regression]

2015-10-12 Thread Daniel Vetter

Another pile of regressions for Jairo to track ...

On Sat, Oct 10, 2015 at 11:46:29AM +0200, Takashi Iwai wrote:
> Hi,
> 
> I noticed that a HSW laptop gets a few new warnings since 4.2-rc
> kernels.  One error messages pops at each boot time:
> 
>  Console: switching to colour dummy device 80x25
>  [drm] Replacing VGA console driver
>  [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>  [drm] Driver supports precise vblank timestamp query.
>  vgaarb: device changed decodes: 
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
>  [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate 
> constants, dotclock = 0!

There's patches for this one already, but I accidentally applied them for
-next, not -fixes. They should land for -rc6.

> Then a warning when I start powertop:
> 
>  WARNING: CPU: 1 PID: 1674 at drivers/gpu/drm/drm_atomic.c:889 
> drm_atomic_get_property+0x232/0x2b0 [drm]()
>  CPU: 1 PID: 1674 Comm: powertop Tainted: GW   4.3.0-rc4-test+ #93
>  Hardware name: Hewlett-Packard HP ProBook 430 G1/1946, BIOS L73 Ver. 08.05 
> 2013/03/15
>   a005b289 880059173ca8 81346fa9 
>   880059173ce0 81063232 8800372bc028 8800373f3740
>   8800372bc000 880062ad37c0 0001 880059173cf0
>  Call Trace:
>   [] dump_stack+0x4b/0x72
>   [] warn_slowpath_common+0x82/0xc0
>   [] warn_slowpath_null+0x1a/0x20
>   [] drm_atomic_get_property+0x232/0x2b0 [drm]
>   [] drm_object_property_get_value+0x6c/0x70 [drm]
>   [] dpms_show+0x2f/0x70 [drm]
>   [] dev_attr_show+0x20/0x50
>   [] sysfs_kf_seq_show+0xbc/0x130
>   [] kernfs_seq_show+0x23/0x30
>   [] seq_read+0xca/0x360
>   [] kernfs_fop_read+0x10a/0x160
>   [] __vfs_read+0x28/0xd0
>   [] ? security_file_permission+0xa0/0xc0
>   [] ? rw_verify_area+0x4f/0xe0
>   [] vfs_read+0x83/0x130
>   [] SyS_read+0x46/0xa0
>   [] ? syscall_return_slowpath+0x50/0x130
>   [] entry_SYSCALL_64_fastpath+0x16/0x75
> 
> 
> Both don't look like serious issues, but not sexy to see at each time.

This should be fixed with

commit 621bd0f6982badd6483acb191eb7b6226a578328
Author: Daniel Vetter 
Date:   Tue Sep 29 09:56:53 2015 +0200

drm: Fix locking for sysfs dpms file

If not please scream.

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

[Intel-gfx] [PATCH 09/20] i915: switch from acpi_os_ioremap to memremap

2015-10-12 Thread Daniel Vetter

On Fri, Oct 09, 2015 at 06:16:25PM -0400, Dan Williams wrote:
> i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
> map it with memremap rather than the implied cache setting of
> acpi_os_ioremap().
> 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: intel-gfx at lists.freedesktop.org
> Cc: David Airlie 
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Dan Williams 

Assuming you've run sparse over this to make sure you've caught them all,
and with the nit below addressed this is

Reviewed-by: Daniel Vetter 

Feel free to pull v2 into whatever tree you think it's suitable for (but
you can also resend and I'll pick it up).

> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index e2ab3f6ed022..c8444d5f549f 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -387,7 +387,7 @@ intel_panel_detect(struct drm_device *dev)
>  
>   /* Assume that the BIOS does not lie through the OpRegion... */
>   if (!i915.panel_ignore_lid && dev_priv->opregion.lid_state) {
> - return ioread32(dev_priv->opregion.lid_state) & 0x1 ?
> + return *(dev_priv->opregion.lid_state) & 0x1 ?

() are redundant now here.
-Daniel

>   connector_status_connected :
>   connector_status_disconnected;
>   }
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH 2/2] drm: Add DRM_DEBUG_VBL()

2015-10-12 Thread Daniel Vetter

On Fri, Oct 09, 2015 at 10:57:37PM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville SyrjÃ¤lÃ¤ 
> 
> Add a new debug class for _verbose_ debug message from the vblank code.
> That is message we spew out potentially for every vblank interrupt.
> Thierry already got annoyed at the spew, and now I managed to lock up
> my box with these debug prints (seems serial console + a few debug
> prints every vblank aren't a good combination).
> 
> Or should I maybe call it DRM_DEBUG_IRQ?

I like _VBL since that's what this is about. The irq helpers are really,
really tiny in drm_irq.c and mostly just here for *bsd/linux abstraction
i.e. historical reasons.

Both patches applied to drm-misc.

Thanks, Daniel
> 
> Cc: Thierry Reding 
> Signed-off-by: Ville SyrjÃ¤lÃ¤ 
> ---
>  drivers/gpu/drm/drm_irq.c | 22 +++---
>  include/drm/drmP.h| 11 ++-
>  2 files changed, 21 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index bc2e7c6..eba6337 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -213,17 +213,17 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, unsigned int pipe,
>   diff = DIV_ROUND_CLOSEST_ULL(diff_ns, framedur_ns);
>  
>   if (diff == 0 && flags & DRM_CALLED_FROM_VBLIRQ)
> - DRM_DEBUG("crtc %u: Redundant vblirq ignored."
> -   " diff_ns = %lld, framedur_ns = %d)\n",
> -   pipe, (long long) diff_ns, framedur_ns);
> + DRM_DEBUG_VBL("crtc %u: Redundant vblirq ignored."
> +   " diff_ns = %lld, framedur_ns = %d)\n",
> +   pipe, (long long) diff_ns, framedur_ns);
>   } else {
>   /* some kind of default for drivers w/o accurate vbl 
> timestamping */
>   diff = (flags & DRM_CALLED_FROM_VBLIRQ) != 0;
>   }
>  
> - DRM_DEBUG("updating vblank count on crtc %u:"
> -   " current=%u, diff=%u, hw=%u hw_last=%u\n",
> -   pipe, vblank->count, diff, cur_vblank, vblank->last);
> + DRM_DEBUG_VBL("updating vblank count on crtc %u:"
> +   " current=%u, diff=%u, hw=%u hw_last=%u\n",
> +   pipe, vblank->count, diff, cur_vblank, vblank->last);
>  
>   if (diff == 0) {
>   WARN_ON_ONCE(cur_vblank != vblank->last);
> @@ -800,11 +800,11 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
> drm_device *dev,
>   etime = ktime_sub_ns(etime, delta_ns);
>   *vblank_time = ktime_to_timeval(etime);
>  
> - DRM_DEBUG("crtc %u : v 0x%x p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d 
> rep]\n",
> -   pipe, vbl_status, hpos, vpos,
> -   (long)tv_etime.tv_sec, (long)tv_etime.tv_usec,
> -   (long)vblank_time->tv_sec, (long)vblank_time->tv_usec,
> -   duration_ns/1000, i);
> + DRM_DEBUG_VBL("crtc %u : v 0x%x p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, 
> %d rep]\n",
> +   pipe, vbl_status, hpos, vpos,
> +   (long)tv_etime.tv_sec, (long)tv_etime.tv_usec,
> +   (long)vblank_time->tv_sec, (long)vblank_time->tv_usec,
> +   duration_ns/1000, i);
>  
>   return ret;
>  }
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 3dc56d3..4d3b842 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -107,6 +107,9 @@ struct dma_buf_attachment;
>   * ATOMIC: used in the atomic code.
>   * This is the category used by the DRM_DEBUG_ATOMIC() macro.
>   *
> + * VBL: used for verbose debug message in the vblank code
> + * This is the category used by the DRM_DEBUG_VBL() macro.
> + *
>   * Enabling verbose debug messages is done through the drm.debug parameter,
>   * each category being enabled by a bit.
>   *
> @@ -114,7 +117,7 @@ struct dma_buf_attachment;
>   * drm.debug=0x2 will enable DRIVER messages
>   * drm.debug=0x3 will enable CORE and DRIVER messages
>   * ...
> - * drm.debug=0xf will enable all messages
> + * drm.debug=0x3f will enable all messages
>   *
>   * An interesting feature is that it's possible to enable verbose logging at
>   * run-time by echoing the debug value in its sysfs node:
> @@ -125,6 +128,7 @@ struct dma_buf_attachment;
>  #define DRM_UT_KMS   0x04
>  #define DRM_UT_PRIME 0x08
>  #define DRM_UT_ATOMIC0x10
> +#define DRM_UT_VBL   0x20
>  
>  extern __printf(2, 3)
>  void drm_ut_debug_printk(const char *function_name,
> @@ -217,6 +221,11 @@ void drm_err(const char *format, ...);
>   if (unlikely(drm_debug & DRM_UT_ATOMIC))\
>   drm_ut_debug_printk(__func__, fmt, ##args); \
>   } while (0)
> +#define DRM_DEBUG_VBL(fmt, args...)  \
> + do {\
> + if

[PATCH v4 1/2] drm/dp: Store the drm_connector device pointer on the helper.

2015-10-12 Thread Daniel Vetter

On Fri, Oct 09, 2015 at 02:50:10PM -0700, Rafael Antognolli wrote:
> On Tue, Sep 29, 2015 at 06:25:44PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 29, 2015 at 05:27:33PM +0200, Lukas Wunner wrote:
> > > Hi Daniel,
> > > 
> > > On Tue, Sep 29, 2015 at 05:04:03PM +0200, Daniel Vetter wrote:
> > > > On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote:
> > > > > On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote:
> > > > > > This is useful to determine which connector owns this AUX channel.
> > > > > 
> > > > > WTF? I posted a patch in August which does exactly that:
> > > > > http://lists.freedesktop.org/archives/dri-devel/2015-August/088172.html
> > > > > 
> > > > > Can also be pulled in from this git repo:
> > > > > https://github.com/l1k/linux/commit/b78b38d53fc0fc4fa0f6acf699b0fcad56ec1fe6
> > > > > 
> > > > > My patch has the advantage that it updates all the drivers which use
> > > > > drm_dp_aux to fill that attribute. Yours only updates i915.
> > > > > 
> > > > > Daniel Vetter criticized storing a drm_connector pointer in 
> > > > > drm_dp_aux,
> > > > > quote:
> > > > > 
> > > > > "That will also clear up the confusion with drm_dp_aux, adding a
> > > > > drm_connector there feels wrong since not every dp_aux line has a
> > > > > connector (e.g. for dp mst). If we can lift this relation out into 
> > > > > drivers
> > > > > (where this is known) that seems cleaner."
> > > > > 
> > > > > So now Intel itself does precisely what Daniel criticized? Confusing!
> > > > > 
> > > > > Source:
> > > > > http://lists.freedesktop.org/archives/dri-devel/2015-August/089108.html
> > > > 
> > > > Critism is still valid, and thinking about this again a cleaner solution
> > > > would be to just have a correct parent/child relationship in the device
> > > > hirarchy. I.e. add a struct device *parent to the aux channel structure
> > > > which should point to the right connector.
> > > 
> > > We already have that:
> > > 
> > > struct drm_dp_aux {
> > >   const char *name;
> > >   struct i2c_adapter ddc;
> > >   struct device *dev; <---
> > >   struct mutex hw_mutex;
> > >   ssize_t (*transfer)(struct drm_dp_aux *aux,
> > >   struct drm_dp_aux_msg *msg);
> > >   unsigned i2c_nack_count, i2c_defer_count;
> > > };
> > > 
> > > What Rafael is struggling with is that you cannot unambiguously
> > > get from drm_dp_aux->dev to the drm_connector. (The drm_device
> > > may have multiple drm_connectors with type
> > > DRM_MODE_CONNECTOR_DisplayPort.)
> > 
> > What I meant to say is that we don't need that, if instead of filling in
> > the overall dev in dp_aux->dev we fill in the connector sysfs device
> > thing. The we have proper nesting, like with i2c buses. And then there's
> > no need for a connector property in sysfs to show that link (which should
> > be done with a proper sysfs link anyway).
> 
> OK, I sent a new version, which does not add a new *connector pointer,
> and uses the dev pointer on the struct to store the drm_connector
> device, instead of the drm_device device. Is that what you meant? In
> any case, as I mention on the patch, it is already how some drivers do,
> while others store the drm_device.
> 
> This leaves the aux device, for instance in my case, at:
> 
> /sys/class/drm/card0/card0-eDP-1/drm_dp_aux0
> 
> If this is what you wanted, I can send other patches to the proper
> mailing lists, trying to update other drivers.

Yeah that's kinda what I had in mind, makes the nesting more obvious.
Especially for mst hub dp aux channels.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v6 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

2015-10-12 Thread Yakir Yang

Hi Krzysztof,

On 10/10/2015 11:46 PM, Yakir Yang wrote:
> Both hsync/vsync polarity and interlace mode can be parsed from
> drm display mode, and dynamic_range and ycbcr_coeff can be judge
> by the video code.
>
> But presumably Exynos still relies on the DT properties, so take
> good use of mode_fixup() in to achieve the compatibility hacks.
>
> Signed-off-by: Yakir Yang 
> ---
> Changes in v6: None

+   of_property_read_u32(dp_node, "hsync-active-high",
+>h_sync_polarity);
+   of_property_read_u32(dp_node, "vsync-active-high",
+>v_sync_polarity);
+   of_property_read_u32(dp_node, "interlaced",
+>interlaced);
+}


Sorry, forget to fix your previous comment here, would
remember to fix it to v7 version, wish v6 would collect
more comment/reviewed/ack.  :)

Best regards,
- Yakir

> Changes in v5:
> - Switch video timing type to "u32", so driver could use 
> "of_property_read_u32"
>to get the backword timing values. Krzysztof suggest me that driver could 
> use
>the "of_property_read_bool" to get backword timing values, but that 
> interfacs
>would modify the original drm_display_mode timing directly (whether those
>properties exists or not).
>
> Changes in v4:
> - Provide backword compatibility with samsung. (Krzysztof)
>
> Changes in v3:
> - Dynamic parse video timing info from struct drm_display_mode and
>struct drm_display_info. (Thierry)
>
> Changes in v2: None
>
>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 
> +
>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   8 +-
>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
>   3 files changed, 106 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 96afb67..9d802ef 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
> *dp)
>   return;
>   }
>   
> - ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
> -  dp->video_info->link_rate);
> + ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
> +  dp->video_info.link_rate);
>   if (ret) {
>   dev_err(dp->dev, "unable to do link train\n");
>   return;
> @@ -1030,6 +1030,85 @@ static void analogix_dp_bridge_disable(struct 
> drm_bridge *bridge)
>   dp->dpms_mode = DRM_MODE_DPMS_OFF;
>   }
>   
> +static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *orig_mode,
> + struct drm_display_mode *mode)
> +{
> + struct analogix_dp_device *dp = bridge->driver_private;
> + struct drm_display_info *display_info = >connector->display_info;
> + struct video_info *video = >video_info;
> + struct device_node *dp_node = dp->dev->of_node;
> + int vic;
> +
> + /* Input video interlaces & hsync pol & vsync pol */
> + video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
> + video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
> + video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
> +
> + /* Input video dynamic_range & colorimetry */
> + vic = drm_match_cea_mode(mode);
> + if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
> + (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
> + video->dynamic_range = CEA;
> + video->ycbcr_coeff = COLOR_YCBCR601;
> + } else if (vic) {
> + video->dynamic_range = CEA;
> + video->ycbcr_coeff = COLOR_YCBCR709;
> + } else {
> + video->dynamic_range = VESA;
> + video->ycbcr_coeff = COLOR_YCBCR709;
> + }
> +
> + /* Input vide bpc and color_formats */
> + switch (display_info->bpc) {
> + case 12:
> + video->color_depth = COLOR_12;
> + break;
> + case 10:
> + video->color_depth = COLOR_10;
> + break;
> + case 8:
> + video->color_depth = COLOR_8;
> + break;
> + case 6:
> + video->color_depth = COLOR_6;
> + break;
> + default:
> + video->color_depth = COLOR_8;
> + break;
> + }
> + if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
> + video->color_space = COLOR_YCBCR444;
> + else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
> + video->color_space = COLOR_YCBCR422;
> + else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
> + video->color_space = COLOR_RGB;
> + else
> +

86 matches

Mail list logo